Category: enarx

Enarx end-to-end complete!

We now have a fully working end-to-end proof of concept, with no smoke and mirrors.

I’ve written lots about the Enarx project, a completely open source project around deploying workloads to Trusted Execution Environments, and you can find a few of the articles here:

I have some very exciting news to announce.

A team effort

Yesterday was a huge day for the Enarx project, in that we now have a fully working end-to-end proof of concept, with no smoke and mirrors (we don’t believe in those). The engineers on the team have been working really hard on getting all of the low-level pieces in place, with support from other members on CI/CD, infrastructure, documentation, community outreach and beyond. I won’t mention everyone, as I don’t want to miss anyone out, and I also don’t have their permission, but it’s been fantastic working with everyone. We’ve been edging closer and closer to having all the main pieces ready to go, and just before Christmas/New Year we got attested AMD SEV Keeps working, with the ability to access information from that attestation within the Keep. This allowed us to move to the final step, which is creating an end-to-end client-server architecture. It is this that we got running yesterday.

I happened to be the lucky person to be able to complete this part of the puzzle, building on work by the rest of the team. I don’t have the low-level expertise that many of the team have, but my background is in client-server and peer-to-peer distributed systems, and after I started learning Rust around March 2020, I decided to see if I could do something useful for the project code base: this is my contribution to the engineering. To give you an idea of what we’ve implemented, let’s look at a simple architectural diagram of an Enarx deployment.

Simple Enarx architectural diagram

Much of the work that’s been going on has been concentrated in the Enarx runtime component, getting WebAssembly working in SGX and SEV Trusted Execution Environments, working on syscall implementations and attestation. There’s also been quite a lot of work on glue – how we transfer information around the system in a standards-compliant way (we’re using CBOR encoding throughout). The pieces that I’ve been putting together have been the Enarx client agent, the Enarx host agent (or Enarx Keep Manager) and two pieces which aren’t visible in this diagram (but are in the more detailed one below): the Enarx Keep Loader and Enarx Wasm Loader (“App loader” in the detailed view).

Detailed Enarx architectural diagram

The components

Let’s look at what these components do, and then explain exactly what we’ve achieved. The name in bold refers to the diagram, the name in italics relates to the Rust crate (and, where already merged, the github repository) associated with the component.

  • Enarx Client Agent (client) – responsible to talking to the enarx-keepmgr and requesting a Keep. It checks that the Keep is correctly set up and attested and then sends the workload (a WebAssembly package) to the enarx-wasmldr component, using HTTPS with a one-use certificate derived from the attestation process.
  • Enarx Keep Manager (enarx-keepmgr) – creates enarx-keepldr components at the request of the client, proxying communications to them from the client as required (for certain attestation flows, for instance). It is untrusted by the client.
  • Enarx Keep Loader (enarx-keepldr) – there is an enarx-keepldr per Keep, and it performs the loading of components into the Trusted Execution Environment itself. It sits outside the TEE instance, and is therefore untrusted by the client.
  • Enarx App Loader (enarx-wasmldr) – the enarx-wasmldr component resides within the TEE instance, and is therefore has confidentiality and integrity protection from the rest of the host. It receives the WebAssembly (Wasm) workload from the client component and may access secret information provisioned into the Keep during the attestation process.

Here’s the post I made to the Enarx chat #development channel yesterday to announce what we managed to achieve:

  1. client -> keepmgr: “create sev keep”
  2. keepmgr launches sev keep via systemd
  3. client -> keepmgr: “perform attestation, include this private key” (note – private key is encrypted from keepmgr)
  4. keepmgr -> keepldr: “attestation + private key”
  5. keepldr creates keep, passes private key to it
  6. wasmldr creates certificate from private key
  7. wasmldr waits for workload
  8. client sends workload of HTTPS to wasmldr
  9. wasmldr accepts workload over HTTPS
  10. wasmldr executes workload

WE HAVE A FULLY WORKING END-TO-END DEMO! Thank you everyone

What does this mean? Well, everything works! The client requests a Keep using with an AMD SEV instance, it’s created, attested, listens for an incoming connection over HTTPS, and the client sends the workload, which then executes. The workload was written in Rust and compiled to WebAssembly – it’s a real application, in other words, and not a hand-crafted piece of WebAssembly for the purposes of testing.

What’s next?

There’s lots left to do, including:

  • merging all of the code into the main repositories (I was working in a separate set to avoid undue impact on other efforts)
  • tidying it to make it more presentable (both what the demo shows and the quality of the code!)
  • add SGX support – we hope that we’re closing in on this very soon
  • make the various components production-ready (the keepmgr, for instance, doesn’t manage multiple enarx-keepldr components very well yet)
  • define the wire protocol fully (somewhere other than in my head)
  • document everything!

But most of that’s easy: it’s just engineering. 🙂

We’d love you to become involved. If you’re interested, read some of my articles, visit project home page and repositories, hang out on our chat server or watch some of our videos on YouTube. We really welcome involvement – and not just from engineers, either. Come and have a play!

Vint Cerf’s “game changer”

I’m really proud to be involved with a movement which I believe can change the way we do computing.

Today’s article is a little self-indulgent, but please bear with me, as I’m a little excited. Vint Cerf is one of a small handful of people who have a claim to being called “greats”. He’s one of the co-developers of TCP/IP protocol with Bob Kahn in 1974, and has been working on technology – much of it pretty cool technology – since then. I turned 50 recently, and if I’d achieved half of what he had by his 50th birthday, I’d be feeling more accomplished than I do right now! As well as his work in technology, he’s also an advocate for accessibility, which is something which is also dear to my heart.

What does this have to do with Alice, Eve and Bob – a security blog? Well, last week, Dark Reading[1], an influential technology security site, published a commentary piece by Cerf under its “Cloud” heading: Why Confidential Computing is a Game Changer. I could hardly have been more pleased: this is an area which I’m very excited about, and which the Enarx project, of which I’m co-founder, addresses. The Enarx project is part of the Confidential Computing Consortium (mentioned in Cerf’s article), a Linux Foundation project to increase use of confidential computing through open source projects.

So, what is confidential computing? Cerf describes it as “a breakthrough technology that encrypts data in use, while it is being processed”. He goes on to give a good description of the technology, noting that Google (his employer[2]) has recently released a product using confidential computing. Google is actually far from the first cloud service provider to do this, but it’s only fair that Cerf should mention his employer’s services from time to time: I’m going to forgive him, given how enthusiastic he is about the technology more generally. He describes it as a transformational technology which “will and should be a part of every enterprise cloud deployment”.

I agree, and it’s really exciting to see such a luminary embracing the possibilities the confidential computing presents. For those readers who aren’t aware of what it is, confidential computing allows you to keep data and processes secret in the cloud, on private servers, on the Edge, IoT, etc. – even from administrators, hypervisors and the host kernel. It uses TEEs – Trusted Execution Environments – to protect the confidentiality and integrity of the workloads (application, programs) that you want to run. If you’re not sure you trust your cloud provider, if your regulatory body won’t let you run your applications in certain places, if you want to deploy to machines which are vulnerable to attack – physical or logical – then TEEs and confidential computing can help.

You can find a more information in some of my articles:

You can always visit the Confidential Computing Consortium[3] or visit the Enarx project (links above): all of our code and documentation is open, and we’d love to see you. I’m really proud to be involved with – in fact, deeply embedded in – a movement which I believe can change the way we do computing. And really excited that someone like Vint Cerf agrees.

1 – I have no affiliation with Dark Reading, though I do recommend it to readers of this blog.

2- neither do I have any affiliation with Google or Alphabet, its parent!

3 – I am, however, a member of both the Governing Board and the Technical Advisory Council of the Confidential Computing Consortium. I’m also the Treasurer.

Why Enarx is open

It’s not just our coding that we do in the open.

When Nathaniel McCallum and I embarked on the project which is now called Enarx, we made one decision right at the beginning: the code for Enarx would be open source, a stance fully supported by our employer Red Hat (see standard disclaimer). All of it, and for ever. That’s a decision that we’ve not regretted at any point, and it’s something we stand behind. As soon as we had enough code for a demo, and were ready to show it, we created a repository on github and made it public. There’s a very small exception, which is that there are some details of upcoming chip features that are shared with us under NDA[1] where if we write code for them, publishing that code would be a breach of the NDA. But where this applied (which is rarely) we are absolutely clear with the various vendors that we intend to make the code open as soon as possible, and lobby them to release details as early as they can (which may be earlier than they might prefer), so that more experts can look over both their designs and our code.

Auditability and trust

This brings us to possibly the most important reasons for making Enarx open source: auditability and trust. Enarx is a security-related project, and I believe passionately not only that security should be done in the open, but that if anybody is actually going to trust their sensitive data, algorithms and workloads to a piece of software, then they want to be in a position where as many experts as possible have looked at it, scrutinised it, criticised it and improved it: whether that is the people running the software, their employees, contractors or (even better) the wider security community. The more people who check the code, the happier you should be to trust it. This is important for any piece of security software, but vital for software such as Enarx which is designed to protect your more most sensitive workloads.

Bug-catching

There are bugs in Enarx. I know: I’m writing some of the code[2] and I found one yesterday (which I’d put in), just as I was about to give a demo[3]. It is very, very difficult to write perfect code, and we know that if we make our source open, then more people can help us fix issues.

Commonwealth

For Nathaniel and me, open source is an ethical issue, and we make no apologies for that. I think it’s the same for most, if not all, of the team working on Enarx. This include a number of Red Hat employees (see standard disclaimer), so shouldn’t come as a surprise, but we have non-Red Hat contributors from a number of backgrounds, and we feel that Enarx should be a Common Good, and contribute to the commonwealth of intellectual property out there.

More brain power

Making something open source doesn’t just make it easier to fix bugs: it can improve the quality of what you produce in general. The more brain power you have to apply to the problem, but better your chances of making something great – assuming that the brain power is applied efficiently (not always an easy task!). We had a design meeting yesterday where one of the participants said towards the end, “I’m sure I could implement some of this, but don’t know a huge amount about this topic, and I’m worried that I’m not contributing to this discussion.” In fact, they had, by asking questions and clarifying some points, and we assured them that we wanted to include experienced, senior developers for their expertise and knowledge, and to pull out assumptions and to validate the design, and not because we expected everybody to be experts in all parts of the project. Having bright people around, involved in design and coding, spreads expertise and knowledge, and helps keep the work from becoming an insulated, isolated “ivory tower” construction, understood by few, and almost impossible to validate.

Not just code

It’s not just our coding that we do in the open. We manage our architecture in the open, our design meetings, our protocol design, our design methodology[4], our documentation, our bug-tracking, our chat, our CI/CD processes: all of it is open. The one exception is our vulnerability management process, which needs to have the opportunity for confidential exposure for a limited time.

We also take diversity seriously, and the project contributors are subject to the Contributor Covenant Code of Conduct.

In short, Enarx is an open project. I’m sure we could do better, and we’ll strive for that, but our underlying principles are that open is good in general, and vital for security. If you agree, please come and visit!

1 – Non-Disclosure Agreement.

2 – to the surprise of many of the team, including myself. At least it’s not in Perl.

3 – I fixed it. Admittedly after the demo.

4 – we’ve just moved to a Sprint pattern – the details of which we designed and agreed in the open.

An Enarx milestone: binaries

Demoing the same binary in very different TEEs.

This week is Red Hat Summit, which is being held virtually for the first time because of the Covid-19 crisis. The lock-down has not affected the productivity of the Enarx team, however (at least not negatively), as we have a very exciting demo that we will be showing at Summit. This post should be published at 1100 EDT, 1500 BST, 1400 GMT on Tuesday, 2020-04-28, which is the time that the session which Nathaniel McCallum and I recorded will be released to the world. I hope to be able to link to that once it’s released to the world. But what will we be showing?

Well, to set the scene, and to discover a little more about the Enarx project, you might want to read these articles first (also available in Japanese – visit each article of a link):

Enarx, as you’ll discover, is about running workloads in TEEs (Trusted Execution environments), using WebAssembly, in what we call “Keeps”. It’s a mammoth job, particularly as we’re abstracting away the underlying processor architectures (currently two: Intel’s SGX and AMD’s SEV), so that you, the user, don’t need to worry about them: all you need to do is write and compile your application, then request that it be deployed. Enarx, then, has lots of moving parts, and one of the key tasks for us has been to start the work to abstract away the underlying processor architectures so that we can prepare the runtime layers on top. Here’s a general picture of the software layers, and how they sit on top of the hardware platforms:

What we’re announcing – and demoing – today is that we have an initial implementation of code to allow us to abstract away process-based and VM-based types of architecture (with examples for SGX and SEV), so that we can do this:

This seems deceptively simple, but what’s actually going on under the covers is rather more than is exposed in the picture above. The reality is more like this:

This gives more detail: the application that’s running on both architectures (SGX on the left, SEV on the right) is the very same ELF static-PIE binary. To be clear, this is not only the same source code, compiled for different platforms, but exactly the same binary, with the very same hash signature. What’s pretty astounding about this is that in order to make it run on both platforms, the engineering team has had to write two sets of seriously low-level code, including more than a little Assembly language, providing the “plumbing” to allow the binary to run on both.

This is a very big deal, because although we’ve only implemented a handful of syscalls on each platform – enough to make our simple binary run and print out a message – we now have a framework on which we know we can build. And what’s next? Well, we need to expand that framework so that we can then build the WebAssembly layers which will allow WebAssembly applications to run on top:

There’s a long way to go, but this milestone shows that we have an initial framework which we can improve, and on which we can build.

What’s next?

What’s exciting about this milestone from our point of view is that we think it puts Enarx at a stage where more people can join and take part. There’s still lots of low-level work to be done, but it’s going to be easier to split up now, and also to start some of the higher level work, too. Enarx is completely open source, and we do all of our design work in the open, along with our daily stand-ups. You’re welcome to browse our documentation, RFCs (mostly in draft at the moment), raise issues, and join our calls. You can find loads more information on the Enarx wiki: we look forward to your involvement in the project.

Last, and not least, I’d like to take a chance to note that we now have testing/CI/CD resources available for the project with both Intel SGX and AMD SEV systems available to us, all courtesy of Packet. This is amazingly generous, and we both thank them and encourage you to visit them and look at their offerings for yourself!

2019幎はEnarxの幎でした

2020幎はデモなど色々なプランを考えおいたす

 

私にずっお2019幎はEnarxプロゞェクトがほずんどでした。

他のしなければいけない業務もあっお、䟋えば顧客䌚議、IBM7月に私の勀めるRed Hatを買収しおたすの業務、Kubernetesのセキュリティやパヌトナヌ䌁業ず協業など重芁なこずは色々ありたした。しかしEnarxが2019幎のハむラむトです。

 

幎始に私たちは実珟できるこずがあるず確信し、内郚のリヌダヌシップチヌムに察しお、達成可胜であるこずの蚌明を課されたした。

その課題に察しお、私たちはAMDのSEVチップず五月のボストンでのRed Hat Summitでデモを行い、このブログでアナりンスをしたした。

IntelのSGXチップセットず10月のリペンでのOpen Source Summitでフォロヌアップをしおいたす。2019幎のEnarxの開発でずおも倧切なこずだったず考えおいたす。

 

チヌム

 

Enarxは私だけのものではもちろん、ありたせん。Nathaniel McCallumず共にプロゞェクトの共同創立者の䞀人であるこずは非垞に誇りです。ここたで達成できたのは倚くのチヌムメンバヌのおかげですし、オヌプン゜ヌスプロゞェクトずしお貢献し䜿甚しおいる皆様のおかげです。貢献者ペヌゞにはたくさんのメンバヌの名前がありたすが、ただ党員の名前が挙がっおいるわけではありたせん。たた、Red Hat内倖の䜕人かの方から頂いたプロゞェクトに察するアドバむス、サポヌトずスポンサリングはずおも倧切なものです。その皆様の名前を蚀う蚱可は埗おいないので、ここではお話しせず、䞁重に扱う事ずしたす。皆様のサポヌトずそのお時間を頂けたこずに非垞に感謝しおいたす。

 

ナヌスケヌスずパヌトナヌ

 

2019幎に成し埗た重芁なこずの䞀぀に、皆さんがどのように「野良状態で」Enarxを䜿いたいのかをたずめたこずず、その比范的詳现な分析を行い、曞き䞊げたこずです。

その党おが公開されたわけではないですが、私が任されおいるこずなんですけどもねこれは実際にEnarxを䜿甚したいず考えおいるパヌトナヌを芋぀けるのに䞍可欠です。ただ公衚できたせんが、皆さんも聞いたこずがあるグロヌバル䌁業のいく぀かから、たた将来的に増えるであろうスタヌトアップ䌁業からも、ずおも興味深いナヌスケヌスが挙がっおきおいたす。このように興味を持っおいただくこずは、ロゞェクトの実甚化に䞍可欠で、Enarxはただ゚ンゞニアの情熱から飛び出しただけのプロゞェクトではないず蚀う事なのです。

 

倖郚を芋るず

 

2019幎の重倧むベントはLinux FoundationのOpen Source SummitでのConfidential Computing Consortiumの発衚でした。私たちRed HatではEnarxはこの新しいグルヌプにぎったりだず考えおおり、10月の正匏発足でプレミアメンバヌになったこずを嬉しく思っおいたす。これを曞いおいる2019幎12月31日時点では、䌚員数は21、このコン゜ヌシアムは幅広い業界で懞念ず興味を惹き぀けるものだず蚀うこずがはっきりしおきたした。Enarxの信念ず目的が裏付けされおいるず蚀うこずです。

 

2019幎に成し遂げたのはコン゜ヌシアムぞの参加だけではありたせん。カンファレンスで講挔を行い、このブログ䞊やNext.redhat.comたたOpensource.comで蚘事を発衚、プレスずの䌚芋、りェブキャストなどです。䞀番倧切なのは六角圢のステッカヌを䜜ったこずでしょう欲しい方がいらっしゃったらご連絡ください

 

最埌に倧切なこずを䞀぀。私たちはプロゞェクトを公衚しおいきたす。内補のプロゞェクトからRed Hat倖の参加を促進するために掻動しおいたす。詳现は12月17日のBlogをご芧ください。

 

アヌキテクチャずコヌド

 

他に䜕かあるでしょうか。そうだ、コヌドですね。そしおいく぀かのコンポヌネントの成熟し぀぀あるアヌキテクチャセットです。

私たちは圓然これら党おを倖郚に公衚する぀もりですが、ただできおいない状態です。すべきこずが本圓にたくさんあるのです。私たちは皆さんが䜿甚できるようにコヌドを公開するこずに尜力しおいお、2020幎に向けデモやそれ以倖の倧きな蚈画を立おおいたす。

 

最埌に

 

他にも倧切なこずはもちろんあり、私がWileyから出版するトラスト信頌性に関連する本を曞いおいるこずです。これはEnarxに深く関連するものです。基本的に、技術はずおも「クヌル」なものですが、Enarxプロゞェクトは既存の需芁に芋合うものですから、Nathanielず私はクラりドやIoT、゚ッゞ、その他機密情報ずアルゎリズムが実装される党おのワヌクロヌドの管理方法を倉えおいくいい機䌚だず考えおいたす。

 

このブログはセキュリティに関するものですが、トラスト信頌性ず蚀うものはずおも重芁な郚分だず考えおいたす。Enarxはそれにぎったりず合うのです。ですから、これからも信頌性ずEnarxに関するポストをしおいきたす。Enarx.ioの最新情報に泚目しおいおください。

 

元の蚘事https://aliceevebob.com/2019/12/31/2019-a-year-of-enarx/

2019幎12月31日　Mike Bursell

 

タグセキュリティ、Enarx、オヌプン゜ヌス、クラりド

 

2019: a year of Enarx

We have big plans for demos and more in 2020

2019幎はEnarxの幎でした

This year has, for me, been pretty much all about the Enarx project.  I’ve had other work that I’ve been doing, including meeting with customers, participating in work with IBM (who acquired the company I work for, Red Hat, in July), looking at Kubernetes security, interacting with partners and a variety of other important pieces, but it’s been Enarx that has defined 2019 for me from a work point of view.

We started off the year with a belief that we could do something, and a challenge from our internal leadership to prove that it was possible.  We did that with a demo on AMD’s SEV chipset at Red Hat Summit in Boston, MA in May, and an announcement of the project on this blog.  We followed up with a demo on Intel’s SGX chipset at Open Source Summit Europe in Lyon in October.  I thought I would mention some of the most important components for the development (in the broadest sense) of Enarx this year.

Team

Enarx is not mine: far from it.  I’m proud to be counted one of the co-founders of the project with Nathaniel McCallum, but we wouldn’t be where we are without a broader team, and as an open source project, it belongs to everyone who contributes and to everyone who uses it.  You’ll find many of the members on the contributors page, but not everybody is up there yet, and there have been some very important people whose contribution has been advice, support and sponsorship of the project both within Red Hat and outside it.  I don’t have permission to mention everybody’s name, so I’m going to play it safe and mention none of them.  You know who you are, and we really appreciate your time.

Use cases – and partners

One of the most important things that we’ve done this year is to work out how people might want to use Enarx “in the wild”, as it were, and to perform some fairly detailed analysis and write-ups.  Not enough of these are externally available yet, which is down to me, but the fact that we had done the work was vital in finding partners who are actually interested in using Enarx for real.  I can’t talk about any of these in public yet, but we have some really interesting use cases from a number of multi-national organisations of whom you will definitely have heard, as well as some smaller start-ups about whom you may well be hearing more in the future.  Having this kind of interest was vital to get buy-in to the project and showed that Enarx wasn’t just a flight of fancy by a bunch of enthusiastic engineers.

Looking outside

The most significant event in the project’s year was the announcement of the Confidential Computing Consortium at the Linux Foundation’s Open Source Summit this year.  We at Red Hat realised that Enarx was a great match for this new group, and was very pleased to be a premier member at the official launch in October.  At time of writing, there are 21 members, and it’s becoming clear that this the consortium has identified an area of concern and interest for the wider industry: this is another great endorsement of the aims and principles of Enarx.

Joining the Consortium hasn’t been the only activity in which we’ve been involved this year.  We’ve spoken at conferences, had articles published (on Alice, Eve and Bob, on now + Next and on Opensource.com), spoken to press, recorded webcasts and more.  Most important (arguably), we have hex stickers (if you’re interested, get in touch!).

Last, but not least, we’ve gone external.  From being an internal project (though we always had our code as open source), we’ve taken a number of measures to try to encourage and simplify involvement by non-Red Hat contributors – see 7 tips for kicking off an open source project for a little more information.

Architecture and code

What else?  Oh, there’s code, and an increasingly mature set of architectures for the various components.  We absolutely plan to make all of this externally visible, and the fact that we haven’t yet is that we’re just running to stand still at the moment: there’s just so much to do.  Our focus is on getting code out there for people to use and contribute to themselves and, without giving anything away, we have some pretty big plans for demos and more in 2020.

Finally

There’s one other thing that’s been important, of course, and that’s the fact that I’m writing a book for Wiley on trust, but I actually see that as very much related to Enarx.  Fundamentally, although the technology is cool, and we think that the Enarx project meets an existing need, both Nathaniel and I believe that there’s a real opportunity for it to change how people manage trust for workloads in the cloud, in IoT, at the Edge and wherever else sensitive data and algorithms need to be executed.

This blog is supposed to be about security, and I’m strongly of the opinion that trust is a very important part of that.  Enarx fits into that, so don’t be surprised to see more posts around trust and about Enarx over the coming year.  Please keep an eye out here and at https://enarx.io for the latest information.

 

 

コンフィデンシャルコンピュヌティング　ヌ新しいHTTPSずは

デフォルトで付いおくるセキュリティなんおありたせん。

この蚘事は
https://aliceevebob.com/2019/12/03/confidential-computing-the-new-https/　を翻蚳したものです。
ここ数幎、「http://
&#8221」のようなりェブサむトはなくなっおきたした。これはやっず業界がりェブサむトにセキュリティが「ある」こずに気付いたからです。ず同時にサヌバヌずクラむアントどちらずもHTTPS通信の蚭定をするこずが容易になったからです。

同じような動きがクラりド、゚ッゞ、IoT、ブロックチェヌン、AI/MLなどのコンピュヌティングにも珟れるこずでしょう。

ストレヌゞ内に保存するデヌタやネットワヌクで転送されるデヌタはは暗号化すべきである、ずは認識されおいたした。けれどプロセスしおいる間䜿甚されおいるデヌタを暗号化するのは難しく、高䟡でした。

Trusted Execution Environment TEEなどのハヌドりェアを䜿っお、䜿甚䞭のデヌタやアルゎリズムを保護したす。コンフィデンシャルコンピュヌティングは、ホストシステムや攻撃されやすい環境のデヌタを保護するのです。

TEE　ずEnarx ProjectNathaniel McCallumず共同創立しおいるプロゞェクトです、参考 Enarx for everyone (a quest) and Enarx goes multi-platform に付いおは䜕床かブログに投皿しおいたす。
EnarxはTEEを䜿っおいお、Enarkでプラットフォヌムや䜿甚蚀語に䟝存せず、機密性が必芁なアプリケヌションやマむクロサヌビスなどのコンポヌネントを安党に信頌できないホストにデプロむするこずができたす。

Enarxはもちろん完党にオヌプン゜ヌスでApache2.0のラむセンス䜿甚です。
ワヌクロヌドを信頌できないホストで皌働させるのはコンフィデンシャルコンピュヌティングが保蚌するずころです。これからは䞋蚘のような堎合の機密性があるデヌタにコンフィデンシャルコンピュヌティングが普通に䜿われるようになるでしょう。

ストレヌゞストレヌゞむンフラを完党に信甚できないので、保存したデヌタは暗号化したい
ネットワヌクネットワヌクむンフラを完党に信甚できないので、転送䞭のデヌタを暗号化したい
コンピュヌティングコンピュヌティングむンフラを信甚できないので、䜿甚䞭のデヌタを暗号化したい

信頌信甚に関しおはもっず蚀いたいこずはあるのですが「完党に」ずいう蚀葉が倧切です。これは掚敲の最䞭に曞き足したした。
パケットを送ったりやブロックを保存したりするかどうか、䞊蚘のどのケヌスでもCPUやファヌムりェアなど、むンフラをある皋床信頌しなくおはいけたせん。ずいうのも、それらを信頌できなければコンピュヌティングなんおできたせん。
準同型暗号ずいう技術があり提䟛され぀぀ありたすが、ただ限定的で技術も未完成です

CPU呚りで芋぀かる脆匱性があるず、CPUを完党に信頌するかどうか、たた乗っおいるホストの物理攻撃に完党に安党がどうか、ずいうのは䜕床も出おくる疑問です。
どちらの疑問にも、「いいえ」ず答えられたすね。しかし拡匵性ずデプロむの費甚の問題から珟状ではベストな技術でしょう。

二番目の疑問に぀いおは、誰ももしくは他の技術完党に安党だず停装できないずいうこずです。私たちがすべきなのはthreat model を考慮し、この堎合ではTEEが特定の芁件に察しお十分なセキュリティを提䟛できるかどうか決定する、ずいうこずです。

䞀぀目の疑問に関しおはEnarxの圓おはたるモデルは、特定のCPUセットを信頌するかどうかデプロむメントの際に党お決め打ちする、ずいうこずでしょう。
䟋えばQずいうベンダのR䞖代のチップに脆匱性が芋぀かったずしたしょう。「ワヌクロヌドをQから出おいるR䞖代のCPUにはデプロむさせず、Q瀟のSタむプ、Tタむプ、Uタむプのチップず、P瀟、M瀟、N瀟のCPUにはデプロむOKずする」ず宣蚀できれば簡単ですね。

コンフィデンシャルコンピュヌティングが泚目されおいたすが、そこに適応させるには3぀の倉化のステヌゞがあるず考えおいたす。

1　ハヌドりェアの皌働性
TEEがサポヌトされおいるハヌドりェアが手に入るようになったのはここ半幎から䞀幎の間です。IntelのSGXやAMDのSEVなど垂堎で鍵ずなる補品が出おきだこずからもわかりたす。
これからもTEEが䜿えるハヌドりェアの補品が出おくるず予想されたす。

2　業界の受け入れ状態
アプリケヌションのデプロむメントずしおクラりドが急激に受け入れられおいるのに合わせお法芏制や敎備は扱うデヌタを保護するよう、組織や団䜓に察しお芁求を増やしおきおいたす。
組織や団䜓は、信頌性のないホストでの機密性の高いアプリケヌションもしくは機密デヌタを扱うアプリの皌働方法にざわざわしおきおいたす。正確には、圌らが完党に信甚できないホスト䞊で、のアプリに関しおですね。

これは別に驚くこずではないのです。もしマヌケットが投資に倀するものではなければ、チップベンダヌはこの技術に投資しないでしょう。
Linux FoundationのConfidential Computing Consortium (CCC)の䜓制は、どれくらい業界がコンフィデンシャルコンピュヌティングの共通䜿甚モデルを芋぀けようずしおいるか、オヌプン゜ヌスプロゞェクトにこのような技術採甚を勧めおいるか、の別のよい䟋ですね。

その䞀぀がRed Hatが始めたEnarxはCCCのプロゞェクトです。

3　オヌプン゜ヌス
ブロックチェヌンのように、コンフィデンシャルコンピュヌティングはオヌプン゜ヌスを䜿うこずがずおも簡単な技術の䞀぀です。

機密性の高いアプリケヌションを動かす堎合、動いおいるもの自䜓を信甚しなくおはいけたせん。CPUやファヌムりェアのようなものではなく、TEEの䞭でワヌクロヌドの実際の実行を手䌝うフレヌムワヌクのこずです。

良い蚀い回しがありたす。
「私はホストマシヌンず゜フトりェアスタックが信甚できないからTEEを䜿うんだ」

しかしTEEの゜フトりェア環境に可芖性がなければ、ただ゜フトりェアを別の䞍可芖性の高い環境に移しただけです。
TEEのオヌプン゜ヌスによっお、あなたやコミュニティ5トはプロプラむ゚タリのベンダヌ仕様゜フトりェアにはできないチェックず監査ができるようになるのです。

このようにCCCはオヌプンな開発モデルをであるLinux Foundationに属しおいるのであり、TEEに関する゜フトりェアプロゞェクトにCCCに参加するよう、たたオヌプン゜ヌスにするように掚進しおいるのです。

このハヌドりェアの可動性、業界の受け入れずオヌプン゜ヌスの䞉぀がここ15から20幎の技術の倉革を促進するものだず考えたす。
ブロックチェヌン、AI、クラりドコンピュヌティング、りェブスケヌルコンピュヌティング、ビッグデヌタ、むンタヌネット販売は党おこの䞉぀が合わさっお、今たでになかった倉革を業界にもたらしたのです。

デフォルトのセキュリティはここ䜕十幎か必芁だず蚎えられおいるものですが、ただ達成されおいたせん。正盎なずころ、それが本圓に実珟するかはわかりたせん。

しかし新しい技術が実珟するこずで、業界で、特定のナヌスケヌスにセキュリティが浞透するこずがもっず実甚的になり、そこに期埅も集たるでしょう。

コンフィデンシャルコンピュヌティングは次の新しい倉革を迎えようずしおいたす。
そしお読者の皆さんがその革呜に参加する日が来るでしょう。オヌプン゜ヌスなのですから。

元の蚘事https://aliceevebob.com/2019/12/03/confidential-computing-the-new-https/
2019幎12月3日　Mike Bursell

 

プロゞェクトずプロダクトずセキュリティコミュニティず

党おのオヌプン゜ヌスが平等に䜜られおメンテナンスされおいる蚳ではないのです。

この蚘事は　https://aliceevebob.com/2019/10/15/of-projects-products-and-security-community/　を翻蚳したものです。
オヌプン゜ヌスは良いこず、です。
オヌプン゜ヌスは特にセキュリティ呚りにはピッタリです。

このこずに関しおは前の蚘事　Disbelieving the many eyes hypothesisずThe commonwealth of Open Sourceでも曞きたしたが、さらに曞き足したいず思いたす。

この蚘事ではオヌプン゜ヌスの機胜、議論の䜙地はありたすが、その欠点ず利点に぀いお぀いおです。さらにいうず、プロゞェクトずプロダクトの違いです。

䞀面から話したすがあらかじめ譊告するず、組織にずっおは「プロダクト」なのですが、ここでちょっずした免責事項から始めたしょう。

私はRed Hatに勀めおいたす。そしお、Red Hatはオヌプン゜ヌスをサポヌトするこずで利益を埗おいる䌁業です。
これは良いこずで、私はこの䌁業モデルを認めおいたすが、この蚘事に関しおはバむアスがかかっおるこずをはじめにお䌝えしたす。

オヌプン゜ヌスがセキュリティに良いずいう理由は、問題があるずきに䜕が起こっおいるか実際自分で芋るこずができる䞊、自分で修正するこずもできるからです。
もしくは珟実的に蚀うず、問題が起こったオヌプン゜ヌスプロゞェクトでセキュリティプロフェッショナルか぀その分野の゚キスパヌトでなければ、他の人が修正しおくれるかもしれたせん。
その分野に詳しいセキュリティ関連の人が十分にいお、゜フトりェアプロゞェクトの䞭の問題や脆匱性を解決しおくれるのを願うばかりです。

ただ、それよりはもっず事態は耇雑かもしれたせん。
組織ずしおはオヌプン゜ヌスを䜿甚するには二぀の方法がありたす。

・プロゞェクトずしお
コヌドを持っおきおどのバヌゞョンを䜿うか決め、自分でコンパむル、テスト、管理をする

・プロダクトずしお
ベンダヌがプロゞェクトを持っおきお、どのバヌションか決め、コンパむル、テスト、サポヌトをパッケヌゞに぀けお売りたす。ドキュメントやパッチ、アップデヌトも倧抵含みたす。

さお、「生」プロゞェクトを䜿えばオプションがもっずあるこずを吊定はできたせんね。
最新バヌゞョンをチェックしお、コンパむル、テストを自由にでき、プロダクトバヌゞョンよりも早く、さらに自分のビゞネスずナヌスケヌスに合ったセキュリティパッチを圓おるこずもできたす。ずおも良いこずのように思えたす

しかしながら、セキュリティ特有の欠点がありたす。

1　セキュリティパッチの䞭には芏制があるものがありたす。ブログ参照限られた組織倧䜓はベンダヌですだけがアクセスできるものです。
倧きな゚コシステムず同時期にアクセスを埗お修正できたずしおも、チェックしお、テストをしなければいけたせん。それもベンダヌによっおすでにされおいるかもしれたせん。もちろん盲目的にパッチを圓おるこずもできたすが、しないで

2　必芁性も緊急性がないのにコヌド倉曎をしたいずいう倧きな欲求
をアップストリヌムプロゞェクトに反映させるこずは、コヌドをフォヌクしおいるようなものです。
期日通りにアップストリヌムに入れこめたずしおも、その期間䞭はアップストリヌムにない倉曎を維持しおいるこずになるので、他のセキュリティパッチがあなたのバヌゞョンにすぐに圓おられないず蚀う危険性がありたす。これはセキュリティ関連ではないパッチにも圓おはたりたすが、セキュリティパッチの方が緊急性がありたす
オプションずしおもちろんあなたのバヌゞョンが他の人に䜿っおもらえるのであれば、プロゞェクトのオフィシャルフォヌクにするこずもできたす。コミュニティにそこを掚すこずもできたす、しかしその新しいバヌゞョンを内郚的たたは倖郚的にサポヌトし続けるか決めなければいけたせん。

3　゜フトりェアの党おのむンスタンスを同じ環境で同じバヌゞョンで皌働させおいるのでない限り、セキュリティパッチを叀いバヌゞョンにバックポヌトするこずが必芁です。そうするのであれば、はじめに修正を行った人ず同等もしくは同等皋床にセキュリティに粟通しおいなければいけたせん。
この堎合、オヌプン゜ヌスの「共同䜓」ず蚀う利点を捚おるずいうこずです。぀たり、コミュニティのスキルをコピヌできるような゚キスパヌトを雇う必芁があるからです。

プロダクトではなくプロゞェクトをデプロむするずいうこずは、プロゞェクトを内郚でプロダクト化するようなものです。

セキュリティパッチの「共同䜓」の利点だけでなく、ベンダヌサポヌトプロダクトモデルに本来ある「芏暡の経枈」を倱うこずになりたす。

「範囲の経枈」も倱っおいるかもしれたせん。倚くのベンダヌはたくさんのプロダクトをサポヌトしおいたす。それらのプロダクトサポヌトに重点を眮いおいない組織にずっおは、ハヌドルが高い方法を䜿っお、セキュリティ の゚キスパヌトをあおがうこずができるかもしれたせん。

このような経枈孊で芋るず、ベンダヌを䜿うこずの「共同䜓」の利点がわかりたす。
たくさんの顧客が補品を䜿うずいうこずは、セキュリティパッチず䞻芁な機胜に収益構造ずむンセンティブを芋出せるずいうこずなのです。

他のパッチや機胜向䞊にリ゜ヌスをあおがう堎合もあるかもしれたせん。しかし、スキルのあるセキュリティ゚キスパヌトが䞍足しおいるずいうこずは、「比范優䜍」性が蚎えるように、倧きなコミュニティの利点のためにそのポゞションを保持すべきなのです。

もし、ベンダヌがオヌプン゜ヌスプロゞェクトを補品化したバヌゞョンを終わりにする、もしくはサポヌトを終了する堎合どうなるでしょう。
そう、もちろん、ベンダヌ固有の゜フトが持぀問題です。
ベンダヌ゜フトの堎合、3぀のアりトカムがありたす。

・゜フトりェアの゜ヌスコヌドにアクセスできないので、機胜向䞊はできない
・あなただけが゜ヌスコヌドにアクセス暩を䞎えられおいるが、広げるこずができないので孀立しおいる
・党おの人が゜ヌスコヌドにアクセスできるが、機胜向䞊させるこずができるコミュニティがないので、゜フトが消える、もしくはコミュニティが゜フト呚りを敎えるのにものすごい時間がかかる

オヌプン゜ヌスの堎合、遞択したベンダヌがビゞネスを終了させたら、別のベンダヌを䜿う、新しいベンダヌに匕き継いでもらう、自分で補品化するその䞊で別の組織に提䟛する、最悪の堎合は内郚で補品化しお長期的な察策を緎る、などのオプションがありたす。

最近のオヌプン゜ヌスの䞖界では私たちコミュニティはオヌプン゜ヌスのコン゜ヌシアムの成長ずずもに、これらのオプションを䞊手く䜿えるようになっおきたした。
コン゜ヌシアムでは゜フトりェアのプロゞェクトやそれに関わるプロゞェクト呚りで組織や団䜓、個人が集たっお䞊蚘にあげた芏暡の経枈ず範囲の経枈を暡玢しながら、コミュニティの成長促進、機胜呚りや远加機胜を䞀埋にしたり、ただ䞊手く定矩されおいないナヌスケヌスの䞀般的なセキュリティ呚りや補品化をしたりしおいたす。

䟋ずしおは、Enarxプロゞェクトも貢献しおいるLinux FoundationのConfidential Computing Consortiumでしょう。

オヌプン゜ヌスの゜フトをプロゞェクトずしおではなくプロダクトずしお䜿うずいうこずは、トレヌドオフがありたす。

しかし、少なくずもセキュリティの芳点から蚀うず、組織の経枈に぀いおはずおも明確です。セキュリティの゚キスパヌトを雇う立堎出ないのであれば、プロダクトが䞀番ニヌズにあっおいるのです。
元の蚘事https://aliceevebob.com/2019/10/15/of-projects-products-and-security-community/
2019幎10月15日　Mike Bursell