 And welcome to our talk on Are Your Secrets Secure in OpenStack. So my name is Dave McAwen, and I'm an engineer at Cisco Systems, and I work in our private cloud group, both on security hardening and security features. And I'm a core reviewer for the Barbican project of OpenStack and previously served as PTL. Hi, and my name is Audie Lee. I work for Red Hats. I am the current PTL of Barbican. And I've been working on the Barbican project for, I think, since Liberty or so. And so here's our agenda for the talk. We're going to start off with an introduction of how secrets are used in OpenStack and why it's important that they're kept secret. So we'll talk about the use cases. And then that'll feed into why you need key management to protect those secrets. And then to answer the question, are my secrets secure? First, we'll talk about a set of criteria to evaluate how secure a secret storage is. And then we'll talk about the different options of the deployment and plug-in choices and we'll evaluate each one and then try to figure out how to compare them and help you all make the decisions of are my secrets secure enough for my cloud. So to start off with, when we talk about secrets, we're really talking about cryptography. So what are the use cases for cryptography in OpenStack? One is to protect storage. So you want to encrypt sensitive data to protect it and we're protecting it both from privacy to make sure that people who are not supposed to have access to that information can't access it, but also to make it tamper-resistant. You want those records to be secured and to somebody can't tamper with that information. Another use case for cryptography is authentication, both on the client side or the server side, to prove your identity to the other party. This can involve passphrases, for example, on the client side or X509 certificates offered on the server side. In addition, you have secure messaging to set up some of these secure connections. You could take either a passphrase or a certificate to start off the handshake to start secure messaging. And finally, there's a validation use case and this is to you want to prove the integrity of the software before you load or run it in your cloud and this is the signed software case. But all these have in common from an implementation point of view is they all require some sort of secret to achieve their goals. So in the case of protecting storage, you have encryption keys. In the case of authentication, you have X509 certificates usually and then in the case of validation, you have RSA key pairs, the public-private key pair that you can use to sign software to make sure that it's authentic. And so this is where key management comes in because you have all these different secret types to meet these use cases and these need to be stored securely. So you have your different types and it's a good idea to decentralize key storage in this case. If it's all in one place, you have just one thing to protect. If they're scattered all around your cloud, then you'd have lots of different places to protect it. Having them centralized also helps with audit. If you want to need to go back in time and figure out who accessed which secret at which time, having it centralized, let's see you keep a concise audit log. In addition to that, when you're talking about encryption keys, to have a strong encryption key, you want to have one generated with lots of entropy. So it will be really hard to guess or predict what those keys are. And then by having a centralized key manager where you can generate keys with a specialized hardware, you can guarantee that you're generating strong and hard to guess encryption keys. And that ties in with specialized hardware which can also be used for storing the secrets or encrypting the secrets. We'll talk about that as we get to the different deployment options. So how this all ties together with OpenStack is we have Barbican, which is the secret manager for OpenStack. So it's a project about six years old. Like most shared services in OpenStack, it provides a restful interface to access to performance functions. It uses Keystone for authentication and authorization to verify users who want to perform actions with Barbican. It uses Oslo policy to either set up a role-based access control or access control list. And it provides a set of different access points, either through the restful HTTP interface through the OpenStack CLI or through Python libraries. And then finally, there's the configurable plug-ins, and that's what we'll talk about for the rest of this talk. So to answer the question, are your secrets secure? Let's talk about what it means for your secrets to be secure. And there's five pillars that we want to talk about today. So the first pillar for consideration is security. You want to make sure that your secure storage is in fact secure. And this means both protection for the secrets that you want to secure. Usually they're secured by encryption, so therefore you need to have some sort of master key or key encryption key. So you also want to evaluate how that master key is protected. An important part of security is that you want these keys to be separate from your storage. So if you have your encrypted data and your key and they're stored on the same hard drive, that's pretty dull. That's pretty easy to defeat if you're a hacker or a rogue admin. So you want to have some sort of separation and isolation between your secret storage and your data. Your use case may involve different access roles for administrators. So by separating your key service on one set of servers with one set of admins and your maybe storage admins on a different set of servers, you have some sort of opportunity for different roles and separation of privileges. Another important aspect is the integrity of storage, these keys in addition to being hidden away, you also want to make sure that no one can tamper with those keys. So the integrity of the storage is an important consideration. And then finally, depending where you live and what industry you're in, you may have a set of standards that you need to comply with, whether it's FIPS or ANSI or GDPR, et cetera. This will be another consideration as you make your choice on secret storage. So the second pillar that you may want to consider is the maturity of the solution that you choose. Some of you may choose a tried and true solution. You want to make sure that someone else has tried it and worked out all the kinks. However, there is a lot of innovations in security and new hardware and new open source projects that maybe you want to take advantage of. So you've got to trade off there whether you want to have a very secure, tried and true solution or whether you want to take advantage of some new innovations. Ease of use of course is a consideration, but you need to consider day zero as well as day one and day one on. So perhaps you want ease of installation. So some of these plugins we'll talk about today are very easy to install, one line of config and off you go. But then if you think about your ongoing operations, if you ever need to re-key your secrets, that can be more complicated if there's not a good mechanism in place for re-key. And we'll talk about that as we talk about the deployment options. And then finally ease of use, if you already have an HSM for example, you may really want to have a secure storage plugin that's compatible with your existing infrastructure. And that would be easier for you to use to another consideration. And the final two aspects for consideration is you evaluate your secret storage. One is we're operating in clouds, we need to run in cloud scale. So your secrets need to be highly available. As your cloud is running, if the secrets are not accessible, then your data is not going to be accessible, because you won't be able to decrypt that data. So you want to make sure that you have a highly available access and needs to be durable as well. So you want to make sure that you've got syncs back in, sync databases or multiple storage repositories in case one or the other crashes. And then performance, of course, is an aspect depending on the number of volumes you have or the number of instances you have booting. So you want to make sure that you can handle the load of secret access attempts that you expect in your cloud. And then finally, cost. We live in the real world, we need to balance cost. You can get lower costs by taking advantage of your existing infrastructure. Or at the end of the day, the specialized hardware, some of the stuff we talk about such as HSMs can be very expensive for the ones that are large and can run in cloud scale. So that'll be a factor as well in your decisions. So to highlight, I mentioned compliance. Here's some highlights that you may want to think about as you evaluate security storage solutions. So one is GDPR. All of these obviously are a lot more complicated, but maybe I wanted to just pull out a couple of key aspects that apply to these scenarios. So one of the key aspects of GDPR that might be hard to meet in a cloud is the right to be forgotten. So if someone says, please erase all my data. That can be tricky to do when you have backups in different places. You don't know exactly where the data is in the cloud because everything's virtualized. But if all the data is encrypted and you have the key and you can find the key and delete the key securely, then you've wiped the data and you can prove that it's been wiped. So that can be a real handy feature with key management. So you want to make sure your solution can do a true delete of a key when you want to do that. ANSI is another compliance standard in France. One of the keys there that jumps out at me is the separate user roles. They want to make sure that the administrator who's responsible for the secrets cannot have access to the data until you want to make your deployment decisions. So maybe that's possible that whoever can log into the key server cannot log into the data server and vice versa. So there's a consideration. And then common criteria is another popular one that will deal with choices around encryption key lengths and access to audit logs and so forth. And so something else to consider that makes sure your security storage choices match whatever compliance standards that you need to comply with. So let's start talking about deployment decisions. There's two types of decisions we'll talk about in the remainder of the talk. One is the architecture choice and the second is the plug-in choice. So first, the architecture choice. So we know we want to use Barbican because that's the secret manager for OpenStack. We need to figure out where to run it if you have an existing cloud. Your typical architecture, you may have controllers where you run the shared services. You'll have specialized servers, separate servers for the compute where you're running the instances. And then you'll have a set of storage servers where your volumes and the data is actually stored. And so now we have a choice. I'm going to add Barbican to the mix. Where do I want to run Barbican? A pretty poor choice, of course, would be on the storage servers because, like I said, you want to keep your keys separate from the data. One very reasonable choice since Barbican's shared service, that's where shared services usually run on the controllers. So that would be a very reasonable place to put Barbican and run on the controllers where Keystone and Horizon and Glantz usually run. That would make a lot of sense. Unless you really want to make sure you have separation of privileges, in which case maybe you want to add a set of key manager servers and run Barbican on its own infrastructure. And that would be a way to add some additional isolation to privileges. The next decision in deployment. So Barbican is really a secret manager as opposed to the secret storage. And what it does is it provides, like a lot of open stack services, provides plugins on the back end. And you can decide where you want to store your secrets. We have two different types of secret storage. One are called database adapters. In which case you have one part that does encryption, encrypts the secrets. And then the encrypted secret is then stored in the database. So you have those two parts. There's a second set of adapters which are KMS adapters, in which case the key is given to that service, such as HSM, and then the secret is actually stored within the HSM, within the specialized hardware. And we'll get into more details with that as we talk about the different plugins. So the first plugin we're going to talk about and then evaluate for how secure is it is simple crypto. So as you can guess by the name, the answer to the question, is it secure? The answer is going to be no, but it's still a valid choice. So it's worth understanding and having that as a baseline for comparison. So in this case, we start off with the user up on the top of the screen, and he sends a post to Barbican and say, here, please store my secret. So Barbican is running. And in this case, there's a key encrypting key, and that is stored in the Barbican.cont file. And so you see there's just one key in this scenario. Barbican will take the secret given to it, will take the key from the file, encrypt the secret, and then store the secret in the database. And as you can see, that's very simple. As you can imagine, to configure it, it's just one line of key, which is that single key. But let's evaluate it against our scorecard in these five pillars. So the first question on security, it's not very secure because there's a single global key. And for every project, for every tenant, it's still that single key. And there's no storage system separation because the key is right there, yeah, within the Barbican file. And the master key is stored there, unencrypted. So it's easy if someone has access to the file system to see that key. So security, it's not very good. Probably still better than nothing. In terms of maturity, this is very well tested. This is what we use as we develop. This is what we use running in the gate, in the CICD for OpenStack. So it's been tested, you know, thousands and thousands of times. So at least we know that it's stable and it works well. In terms of ease of use, it's sort of a mixed bag. Simple to deploy. It runs right there on the same server as Barbican. It's one line of config. You just have to give it a master key. But if you think long run, if that key is ever compromised and you need to rekey it, now you're stuck because you need to replace that master key, then you need to replace all your secrets, which made them in turn require re-encrypting all your data. So not very good just having a single key to encrypt all your secrets directly. But in terms of scale, that's fine. The HA is easy because your controllers are already HA. So having simple crypto run part of Barbican, you automatically get the HA. And the cost of course is great. It's free because you already have that. So that's simple crypto. So let's see if we can do better with some other options. And I'll turn off the audio. Okay. So the next option that is a little a lot better than simple crypto is something called the PKCS11 plugin. And the PKCS11 plugin is essentially, it's also a database adapter in the sense that, so you can, right over here, you can imagine that at the top you have the user saying, you know, store my key, store my secret please. In the back end over here, you have this database plugin that goes and gets the keys from another device. And it talks PKCS11 to that device. Now, depending on the type of device that's back there, you have different options which give you different amounts of security. So if you're talking, for example, to an HSM, then you're going to have a lot of security there. If you're talking, you could talk to something like a soft HSM. You could talk to a hardware HSM. You could talk to various other devices, and we'll talk about some of the different possibilities over here. In this particular case, I believe, yeah, we're talking specifically about talking to an HSM itself. So in this case, you talk to your HSM. There are actually two keys there. One is a master key, encryption key. So this is the key that is actually used to, there's a couple of different layers here. So first of all, when a project first goes and talks to Barbican, there is a project key encryption key, a project encryption key that is generated within Barbican, and that is encrypted by the key encryption key, and that is stored in the database. And then subsequently, whenever a secret is stored within Barbican, what we do is we retrieve that key encryption key from the database, bring it back into the HSM, and then unencrypt it, and then encrypt the secret with that particular key. So as a result, then you have a separation because you have separation between different projects, because different projects are encrypted by different project key encryption key, but at the same time, all of those are encrypted by the master key encryption key, which is stored in the HSM. In addition to provide more sort of authentication for the encryption, each of the key project key encryption keys are actually signed and an HMAC is generated with this HMAC key that's here inside the database, inside the HSM. So you have two keys here. Again, because it's a database adapter, the secrets and the project key encryption keys are stored in the database, but you're talking PKCS11 to a key store like an HSM. So let's evaluate what that looks like. Well, your security is great because you do have hardware separation. An HSM is a device that is designed, you know, is specifically engineered to be tamper-proof and provide good security, to provide good entropy and so on and so forth. The idea is that once your key is in the HSM, it doesn't come out. And so therefore you have hardware protection of keys, you have separation of those keys because those keys are in a completely separate device. Typically the HSMs all have a security certification, so you're going to get your common criteria, you're on C, your FIPS, you have to be careful there because for example, on C only accepts certain types of HSMs and not others and so on. But all of the HSMs generally have some sort of security certification. And so you would need to pick the ones that you have that would match the certifications that you would need. So you would need to pick the ones that would match the certifications that you would need to have a dedicated encryption that takes place. So great security. The maturity it is, again, a lot of people are using it, and I've met a lot of people here that are using HSMs that are there. But right now there is no upstream testing within the HSMs that we can use every time we produce a patch and have a testing there. That may change in future. But we do have downstream testing of course, so I have to know for OSP for example that I have been working specifically with certain HSMs and testing them and confirming them and making sure that all of this works. And then in fact, there are some HSM vendors themselves who are talking to us in their test suites to ensure that whenever they produce a new version of the HSM it doesn't break while we can for instance. So maturity is sort of a mixed bag but in general it's pretty good. Easy of use, it's relatively complicated to deploy. You have an extra device which you also need to have redundancy of as well and you need to set things up. HSMs are not necessarily the simplest things to set up. You know, for a Tullus HSM in order for you for your client to register to be a client of that, it actually has to be registered by a separate admin server first and then you have to do the registration as well. So it's a relatively complicated process to set things up. However beyond that operations like re-keying and so on are very possible. In particular, you can re-key the master key encryption key. In which case the only thing you would need to do is to re-encrypt all of the project key encryption keys because those are the ones that are encrypted there. You can do the same thing for the HMAC and then all that means you would need to do is recalculate the HMACs and so on. So in general re-keying is very possible and it's an easy thing to do and we do have some utilities within HSM within Barbican that allows you to do that. Failover, scaling of course you have your standard failover mechanisms for Barbican putting it behind HEProxy or whatever the case may be and then of course the HSMs themselves have their mechanisms for ensuring that you have failover between HSMs. Again, tricky to set up but possible and available. Big downfall of here is this is a great security solution but it's expensive and depending on you got to remember of course that all of your encryption operations are taking place in the HSM because the master key encryption key is inside the HSM. So even when you're decrypting a secret you're going in there, you're getting a project key, encryption key, you're getting a handle to that key and as a result of taking that handle you're then decrypting and doing all your decryptions inside the HSM. So you need something that's fairly performant and depending on your encryption, it could be something that's quite expensive. So this is one option but it could be expensive. SGX. So SGX is very interesting. There is a bunch of folks at Intel that have developed a plugin using the SGX technology and the SGX technology is essentially a technology that Intel has created to create an enclave of encrypted memory inside an Intel machine. And so this encrypted memory has various keys. There's a seal key that is used there to encrypt all of the data that's inside there and it's essentially sort of like a poor man's HSM in some ways. But essentially you have this memory that is encrypted. You can't get to it. You can't get anything out of it without the sealing key. So there's a lot of things there. Not only that but there's the capability of doing things like attestation for instance, making sure that the proper server is talking to the proper clients and so on and so forth. And they wrote a bunch of code and a plugin specifically using the SGX where they work with these operations. So great idea. Good security. They say that you get essentially the same type of security as you would with an HSM. You do have hardware protection in your keys because essentially this is something that where the keys and the entropy and so on are guaranteed by the Intel hardware. You've got good protection of your database entries because their plugin actually did a validation in an HMAC on the database entries that are there as well too. All of the authentication is using GCM mode encryption so there's authenticated authorization and encryption there and you have the possibility of doing attestation. The downside is that all this wonderful code doing it out there and it's up in a GitHub somewhere but it hasn't been pushed up into Barbican upstream which means that it's unless people are using it, it essentially becomes bit rotted necessarily even the changes that they suggested for Barbican haven't been pushed up upstream yet. If there's anyone that's truly really interested in SGX encourage you to go through it and take advantage of that code but at this point no one has taken it and taken ownership of it and so the maturity is the results that they got were great. They have a great paper which details all of those results and all of those moments and so on but we're not quite sure that was a year ago. We're not quite sure what the status is now. So that's the disadvantage over there. Hopefully that will change in future and someone will take that up. Rekeying it's relatively complicated to deploy but as things would be but the rekeying is very possible. There's a failover and HA and so on in different ways of having two different Intel devices and two different enclaves talking to each other and having the keys you have to replicate the keys between enclaves and there are ways of being able to do that performance they report to be very, very good. It is Intel hardware and it's not clear what the costs and so on there but it's certainly not as much as an HSM would be. This one is a relatively new one. This is using the same PKCS11 plugin that we talked about before but talking to a device that has been generated by a company called Fortanix and I know of at least one set of folks that I met here that is actually using this in production. The idea here is that you store the same master kicks and the same HMAC keys inside the Fortanix key store but the Fortanix key store is essentially an HSM like device that is created on top of an SGX onclick so they've taken the SGX technology that Intel had provided they provided a PKCS11 and it came up interface into that device and so you essentially use that enclave like you would in an HSM so it's like an HSM kind of device that has been created using an SGX enclave. Kind of cool but basically you're doing the same thing as the PKCS11 plugins same kind of different key manipulations and so on and so forth storing everything inside the database. So same as with the PKCS11 plugin you're getting the same sort of security guarantees hardware separation you've got the hardware protection of the SGX there is a possible attest one of the interesting things that Fortanix has actually done is taken the entire Barbican process and put it into the enclave itself and so this allows the entire Barbican process to run within this encrypted memory the secure memory allows you then to do attestation between enclaves so you can do an attestation between a client and a server to ensure that the clients that you want to connect to the one you want to connect to the servers you want to connect to the servers to connect maturity right now there's no upstream gate at this point but they've been talking to us and they plan for Stein to add an upstream gate they have a hosted SGX enclave that they can then use for us to point to be able to do an upstream gate to ensure that we don't break anything in future so that could be really good in that case so maturity could be good it's relatively complicated to deploy but again it's a good solution rekeying is definitely possible same sort of mechanisms as with the PKCS11 the performance has been reported to be good and I don't really know what the cost is but that's something you'd have to check with Fortanix came a plugin so now we've gone from the previous plugins that were there were all database adapters that is the secrets were stored within the Barbican database but with the keys being encrypted inside and provided from a key store now we're going to ones that are secret store adapters so in this particular case what happens is that the secrets themselves and everything are stored in a completely different device so we have something that's a KMIP plugin which is something that talks KMIP to a key store somewhere else out there and you can have an HSM that talks KMIP you can have some other KMIP device you could even have for example the one I just talked about the Fortanix device that can also talk KMIP and so you can talk KMIP specifically to this thing and instead of just encrypting the data and so what you're doing is you're saying take the secret store it there and then when you want to bring it back out so the secret there is stored inside the secret store itself and we have a KMIP plugin that does that the only thing that gets stored there is a metadata and the metadata basically says well when I want to go get my secret store I can go what secret do I need to get to get it from the secret store so KMIP plugin that we have great separation right separation of key store versus Barbican access is controlled by however you you have access policies to your HSM maturity is the only thing that in this particular case is kind of tough the KMIP plugin that was written was implemented using KMIP and this was written by a bunch of Johns Hopkins guys and we're not quite sure whether it's going to continue to be maintained so in fact as it turns out the upstream gate has been broken for several weeks now and we don't quite know how to fix it so we could probably fix it but then the question is from a long-term perspective how long that's going to be doable so that's the main disadvantage of that one and of course you need a KMIP device which could depending on cost and scale someone depends on the device that you're talking to dog tag so this is actually a project that I worked on dog tag is a component of something called the reddit certificate system and it was a component that was used to store keys and the idea was that you could store the keys using encryption keys that are either stored in an HSM or in an NSS database and again it's the same sort of thing it's a secret store plugin so what that means is you're actually just storing the secrets and storing the reference to the data inside the public database so completely separated the nice thing about the so let's see what that looks like so again great security hardware separation you can store it either in an HSM or you have software so you've got sort of a higher cost than a lower cost solution as well too dog tag itself when you use it with an HSM has various you know the FIPS and common criteria and various types of certifications it is tested with the upstream gate it's been around for a while now and it's tested every time you have a patch there it's relatively easy to install and configure of course is very possible the disadvantage and the main reason a lot of people haven't used it is that it's another system and it's a relatively complicated system and so it's another system that you have to add and to manage and there's redundancy potentially there and of course you need to have redundancy so you have to have another system there it may be a perfectly reasonable thing for example you have an IDM system which is identity manager type system you have one already there that already has this particular system in there and so you could end up reusing that system that you currently already have so that might be a viable option there that way you don't actually need another system to manage failover of course is possible in different ways and the only concern that we have over there is you know there could be a concern about performance depending on how much performance you actually need because here you have multiple hops you're not talking you're going from Barbican to dog tag, dog tag to your HSM getting your secrets bringing it back it's a main B less performer to say going through the PKCS and then plug in going directly to your HSM it depends on your performance but that would be true for every secret management system that was outside and extracted away from Barbican and of course it's free because it's part of CentOS and part of REL so part of REL so Vaults so this is a relatively new plugin over here again it's a secret store plugin that is separated away from from Barbican you store the secrets directly there and this is basically you pass the secret in and it's stored within Vault Vault itself can of course contain a secret that it has you store the Shamir secret share kind of thing so it has its own encryption keys there as well as or you can store them with an HSM store within an HSM that costs money so security there of the Vaults you've got your process and your physical separation again it's a separate key store that is there and you can put it on a separate machine or something like that right now the Vault plugin that is available is not quite ready for prime time in the sense that the authorization model that is used there is actually very simple right now it uses like a root token or something which is something that Vault says don't do that do something more secure during the style cycle we're adding things to the Vault plugin to make sure that it's the security model is more robust and that we're doing some of the right things there so that's it's something that's definitely fixable and it should be fixed hopefully in the style cycle it is integration it's possible to integrate with an HSM but you have to pay money there is a test for this in the upstream gates right now Vault itself has come up and is being deployed in a number of different places so it's probably relatively mature at this point and again just the plugin itself specifically as I mentioned is fairly new and still being improved in style Vault, one of the key things about Vault is that they make it really easy to deploy and they can very easily do things like re-heating and so on and so forth they do have a chain failover but I believe that also costs money potentially and again performance we don't really know yet because it's still new so but I believe I've heard of people that are using and trying and testing it out we'll see basic modes free money for HSMs and probably the HA okay so in conclusion you know kind of question of what plugins do I use simple crypto is better than nothing it's it's you know nothing basically means that all of your secrets are stored inside your config files all over your open stack deployment and so you have multiple files that have the same level of encryption but that are basically in the open in the clear and you have to you have to secure all of those files if you're going to do that you might as well secure all of those files in one place and Bobby can have a single place where things are stored do you have a regulatory requirements or a security requirement for an HSM you know that is a key thing if you have a regulatory requirement then you're going to use dog tag you need to use KMIP you need to use pkcs11 potentially you can use one of the sgx or fortanix simple crypto dog tag again vault sgx those are all possible options as well there can I use hsmx that depends right so pkcs if typically what I would tell people in terms of can I use hsmx is I would say you got to try out the pkcs11 plugin and see if you can get it to work but one of the things that we've done recently is we've parametrized a lot of the things inside the pkcs11 plugin because pkcs11 is sort of a loose API in some ways it's unclear in some cases and where it is unclear the vendors have sort of filled it in with their own vendor defined things in there and so as long as you have the right parameters and so on and the things in there and you have the vendors actual hsm a pkcs11 library you should be able to make it work and if you can't make it work talk to us and we can try and figure out how to make it work and how do you scale you need to set up multiple instances of Bob again of course and that's true and then of course you're going to have to figure out how to make sure those keys are available to each of those instances and then finally performance depending on your performance things you will get better performance obviously if you have something that's a database adapter there's less hops over there you can get better performance that way best performance you're going to get is from a simple crypto because you're basically doing one operation for any crypto or decrypt and it's right there and the keys in memory but you've got the worst worst performance might be going to a completely separate system that is has network latency and a bunch of different things as well too you have to see what kind of performance you need to get but we do need help from hsm vendors if there's anyone that would love to test their stuff with us we'd love to get to talk to them I do know that right now for example I'm working with a couple of hsm's and doing performance tests on them and seeing how well they do compared to each other so I think at this point we're at an end this is informative but if there are any questions take some right now you mentioned that there is sgx plugin for Intel hardware there's also like given the race of ARM architecture do you think it would make sense to create a plugin for using the trusted execution environment in ARM architecture like I think it would be even more widely used since it wouldn't be probably specific to one single ARM vendor yes I agree that would be a fantastic idea it just hasn't been done yet but yes I think that would be great great the sgx one was written by the Intel guys thanks great well thank you