Using Intel’s SGX to keep secrets even safer

When you unlock 1Password there are lots of secrets it needs to manage. There are the secrets that you see and manage such as your passwords and secure notes and all of the other things you trust to 1Password. But there are lots of secrets that 1Password has to juggle that you never see. These include the various encryption keys that 1Password uses to encrypt your data. These are 77-digit (256-bit) completely random numbers.

You might reasonably think that your data is encrypted directly by your Master Password (and your secret Account Key), but there are a number of technical reasons why that wouldn’t be a good idea. Instead, your Master Password is used to derive a key encryption key which is used to encrypt a master key. The details differ for our different data formats, but here is a little ditty from our description of the OPVault data format to be sung to the tune of Dry Bones.

Each item key’s encrypted with the master key
And the master key’s encrypted with the derived key
And the derived key comes from the MP
Oh hear the word of the XOR
Them keys, them keys, them random keys (3x)
Oh hear the word of the XOR

And that is a simplification! But it is the appropriate simplification for what I want to talk about today: Some of our intrepid 1Password for Windows beta testers can start using a version of 1Password 6 for Windows that will have an extra protection on that “master key” described in that song. We have been working with Intel over the past few months to bring the protection of Intel’s Software Guard Extensions (SGX) to 1Password.

Soon (some time this month) 1Password for Windows customers running on systems that support Intel’s SGX will have another layer of protection around some of their secrets.

SGX support in 1Password isn’t ready for everybody just yet as there are a number of system requirements, but we are very happy to talk about what we have done so far and where we are headed. I would also like to say that we would not be where we are today without the support of many people at Intel. It has been great working with them, and I very much look forward to continuing this collaberation.

What does Intel’s SGX do?

Intel, as most of you know, make the chips that power most of the desktop and laptop computers we all use. Their most recent CPUs include the ability for software running on Windows and Linux to create and use secure enclaves that are safe from attacks coming from the operating system itself. It is a security layer in the chip that cryptographically protects regions of operating system memory.

SGX does a lot of other things, too; but the feature I’m focusing on now is the privacy it offers for regions of system memory and computation.

Ordinary memory protection

A program running on a computer needs to use the system’s memory. It needs this both for the actual program and for the data that the program is working on. It is a Bad Thing™ if one program can mess with another program’s memory. And it is a security problem if one program can read the memory of another program. We don’t want some other program running on your computer to peer what is in 1Password’s memory when 1Password is unlocked. After all, those are your secrets.

It is the operating system’s (OS’s) job to make sure that one process can’t access the memory of another. Back in the old days (when I had to walk two miles through the snow to school, up hill, both ways) some operating systems did not do a good job of enforcing memory protection. Programs could easily cause other programs or the whole system to crash, and malware was very easy to create. Modern operating systems are much better about this. They do a good job of making sure that only the authorized process can read and manipulate certain things in memory. But if the operating system itself gets compromised or if some other mechanism might allow for the reading of all memory then secrets in one program’s part of memory may still be readable by outsiders.

Extraordinary memory protection

One way to protect a region of memory from the operating system itself is to encrypt that region’s contents using a key that even the operating system can’t get to. That is a tricky thing to do as there are few places to keep the key that encrypts this memory region if we really want to keep it out of the hands of the operating system.

SGX memory access drawingSo what we are looking for is the ability to encrypt and decrypt regions of memory quickly, but using a key that the operating system can’t get to. Where should that key live?  We can’t just keep it in the the innards of a program that the operating system is running, as the operating system must be able to see those innards to run the program. We can’t keep the key in the encrypted memory region itself because that is like locking your keys in your car: Nobody, not even the rightful owner, could make use of what is in there. So we need some safe place to create and keep the keys for these encrypted regions of memory.

Intel’s solution is to create and keep those keys in the hardware of the CPU. A region of memory encrypted with such a key is called an enclave. The SGX development and runtime tools for Windows allow us to build 1Password so that when we create some keys and call some cryptographic operations those will be stored and used with an SGX enclave.

An enclave of one’s own

When 1Password uses certain tools provided by Intel, the SGX module in the hardware will create an enclave just for the 1Password process. It does a lot of work for us behind the scenes. It requests memory from the operating system, but the hardware on Intel’s chip will be encrypting and validating all of the data in that region of memory.

When 1Password needs to perform an operation that relies on functions or data in the enclave, we make the request to Intel’s crypto provider, which ends up talking directly to SGX portions of the chip which will then perform the operation in the encrypted SGX enclave.

Not even 1Password has full access to its enclave; instead 1Password has the ability to ask the enclave to perform only those tasks that it was programmed to do. 1Password can say, “hey enclave, here is some data I would like you to decrypt with that key you have stored” Or “hold onto this key, I may ask you to do things with it later.”

What’s in our enclave? Them keys, of course!

protected-keysWhen you enter your Master Password in 1Password for Windows, 1Password processes that password with PBKDF2 to derive the master key to your primary profile in the local data store. (Your local data store and the profiles within it are things that are well hidden from the user, but this is where the keys to other things are stored. What is important about this is that your master key is a really important key.)

When you do this on a Windows system that supports SGX the same thing happens, except that the the computation of the master key is done within the enclave.  The master key that is derived through that process is also retained within the enclave. When 1Password needs to decrypt something with that key it can just ask the enclave to perform that decryption. The key does not need to leave the enclave.

Answers to anticipated questions

What does (and doesn’t) this protect us from?

I must start out by saying what I have often said in the past. It is impossible for 1Password (or any program) to protect you if the system you are running it on is compromised. You need to keep your devices free of malware. But using SGX makes a certain kind of local attack harder for an attacker, particularly as we expand our use of it.

The most notable attacks that SGX can start to help defend against are attacks that exploit Direct Memory Access. Computers with certain sorts of external ports can sometimes be tricked in allowing a peripheral device to read large portions of system memory.

As we expand and fine tune our use of SGX we will be in a better position to be more precise about what attacks it does and doesn’t defend against, but the ability to make use of these enclaves has so much potential that we are delighted to have made our first steps in using the protections that SGX can offer.

What will be in our enclave in the future?

As we progress with this, we will place more keys and more operations involving those keys into the SGX secure enclave. What you see today is just the beginning. When the master key is used to decrypt some other key that other key should only live within the enclave. Likewise the secret part of your personal key set should also have a life within the enclave only. I can’t promise when these additions will come. We still need to get the right cryptographic operations functioning within the enclave and reorganize a lot of code to make all of that Good Stuff™ happens, but we are very happy to have taken the first steps with the master key.

We do not like promising features until they are delivered. So please don’t take this as a promise. It is, however, a plan.

Sealed enclaves?

Among the features of SGX that I have not mentioned so far is the ability to seal an enclave. This would allow the enclave to not just keep secrets safe while the system is running, but to allow it to persist from session to session. Our hope is that we can pre-compute secrets and keep them in a sealed enclave. This should (if all goes to plan) allow 1Password to start up much more quickly as most of the keys that it needs to compute when you first unlock it can already be in an enclave ready to go.

A sealed enclave would also be an ideal place to store your secret Account Key, as a way of protecting that from someone who gains access to your computer.

Is security platform-specific?

1Password can only make use of SGX on some Windows PCs running on CPUs with Intel’s Skylake CPUs and which have been configured to make use of SGX. Thus SGX support in 1Password is not going to be available to every 1Password user. So it is natural to ask whether 1Password’s security depends on the platform you use.

Well, there is the trivial answer of “yes”. If you use 1Password on a device that hasn’t been updated and is filled with dubious software downloaded from who knows where, then using 1Password will not be as secure as when it is running on a device which is better maintained. That goes without saying, but that never stops me from saying it. Really, the easiest and number one thing you can do for your security is to keep your systems and software up to date.

The nontrivial answer is that 1Password’s security model remains the same across all of the platforms on which we offer it. But it would be foolish to not take advantage of some security feature available on one platform merely because such features aren’t available on others. So we are happy to begin to offer this additional layer of security for those of our customers how have computers which can make use of it.

Upward and downward!

I’d like to conclude by just saying how much fun it has been breaking through (or going around) layers. People like me have been trained to think of software applications and hardware being separated by the operating system. There are very good reasons for that separation — indeed, that separation does a great deal for application security — but now we see that some creative, thoughtful, and well-managed exceptions to that separation can have security benefits of its own. We are proud to be a part of this.

15 replies
  1. Greg Lloyd (@roundtrip)
    Greg Lloyd (@roundtrip) says:

    Thanks for the good work – and helpful explanation. Can you compare Intel’s SGX and Apple’s iOS Secure Enclave co-processor (for ARM 7 and newer)? Including how 1Password uses Apple’s ARM + iOS security tech.

    • Dave Teare
      Dave Teare says:

      Thanks for the great question, Greg! It’s such a good question that I’m going to wait for Jeff to answer directly – I can’t wait to hear the answer myself 🙂

      Normally I try to help Jeffery keep up on comments on his blog posts but in this case I need to defer to our Chief Defender Against the Dark Arts himself as I just don’t know enough about the inner workings of SGX and Apple’s secure enclave to compare the two. The thing is he’s traveling at the moment so you may need to wait a few days before he’s able to get back to you. I’ll ping him and learn along side you when he gets back to us. Get the popcorn ready. 🍿 🙂


    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      This is a really good question, Greg. There are lots of differences between Apple’s Secure Enclave and Intel’s SGX. But the single difference the probably drives most of the differences is the relationship with the operating system.

      Apple’s enclave is tightly integrated with security features of iOS. For example the keys for the file system encryption are derived from an “entangling” of your passcode with keys that are build into the enclave. Things like TouchID make use of the enclave. Unlock rate limiting is built into the enclave. The iOS keychain encryption is like the file system encryption, etc. So on iOS we take advantage of these features through the operating system. For example, when we set data protection classes for the files we write or make use of the iOS keychain, or use TouchID we are making use of Apple’s secure enclave, but only indirectly.

      Intel’s SGX is (largely) independent of the operating system (though it needs some OS support to allow it to be run as the OS needs to pass some control about memory allocation to it). Currently it is available on Windows and Linux, but its basic use is to go around lots of stuff in the OS.

      As a consequence, Intel’s SGX is designed to be used by software developers in ways that are not tightly bound to the OS. Apple’s enclave is designed so that the OS is more secure and the OS can offer security features to software developers.

      Thanks for asking. I had wanted to discuss this comparison in the post, but it was already getting too long.


    • Dave Teare
      Dave Teare says:

      I told you we were in for a treat, Greg! 🙂

      Thank you Jeff, I enjoyed reading your answer here. Along with my popcorn! 🍿 😉


  2. Andrew
    Andrew says:

    In the article, you write “1Password can only make use of SGX on some Windows PCs running on CPUs with Intel’s Skylake CPUs and which have been configured to make use of SGX”

    I believe the i7-6660U, i7-6567U and i7-6920HQ Skylake CPUs in the 2016 MacbookPro’s (with and without touchbar) all support SGX.

    Why does SGX only work on Windows? Could SGX work with the mac version of 1Password too? Or is there some equivalent technology that is already being used by 1Password mac?

    • Dave Teare
      Dave Teare says:

      Hi Andrew,

      You’re right, quite a few devices have support for SGX already. From what I understand though it needs support from the BIOS as well as the operating system to make use of it. For example, my relatively new Surface Pro 4 comes with the SGX chip but I’ll be unable to make use of it until a future update (hopefully) enables it.

      As for Mac, we’ll need to wait for macOS to expose these APIs to us before we can make use of the SGX there. Apple has had a secure enclave on iOS devices for years and just recently introduced a similar concept in the new MacBook Pros. I suspect they will keep pushing their own approach over SGX but that’s just a personal hunch.


    • Dave Teare
      Dave Teare says:

      Hello again Andrew,

      I was expecting you to ask this 🙂

      There’s been a lot of progress on Windows since we last talked but as we discussed there’s several other things that we need to tackle before adding support for Dropbox Syncing and the standalone OPVault format. We’re still executing on that plan and I’ll be very happy to announce more details once they’re available. Stay tuned to this blog and you’ll be one of the first to know. 📣

      Take care,


    • Dave Teare
      Dave Teare says:

      Hey Andrew, there’s nothing to worry about! I simply have comment moderation enabled to help combat spam. 👀

      Spam can be a real pain but I enjoy allowing customers to comment here directly too much to disable comments completely. WordPress does an okay job as it will show your comment that you wrote immediately after posting, along with some text explaining it’s in moderation, but it falls short in that reloading the page won’t show the comment until it’s approved. So it ends up making it appear as if it disappeared, and so it’s tempting to resubmit comments multiple times. This is why I try to approve and reply quickly, and I do, but as you’ve seen, even answering in 2 hours and 43 minutes gives people a chance to get antsy, and I can’t reply much faster than that 🙂

      Hopefully in the future we can live with out spam and remove moderation, but for now, we’ll make the best of what we have. 🖖


    • Andrew
      Andrew says:

      Ok….no problem. I figured that was what was happening. But then I came back to the page and saw the comments that had been previously marked as “awaiting approval” were now gone, and other comments / replies had started showing up.

  3. Josh
    Josh says:

    Will you be able to use any of this work to protect individual passwords once they’re decrypted, or the master password while it’s being entered?
    I could imagine that some clever DMA malware author might realize that they can’t read the keys, but could potentially see the master password as it’s being typed in, or the passwords for individual sites when a user decrypts the password database.

    • Dave Teare
      Dave Teare says:

      Hi Josh,

      These are some great questions. Thanks for giving me a lot to think about on this lovely Sunday afternoon. 🙂

      I suspect there’s many more ways to use SGX but I don’t see how we could use it for individual passwords. In theory we could keep them there but we decrypted the password so we could use it for something, and that something is likely outside of the protection of SGX. For example, when 1Password goes to fill a password for you on a website, it needs to pass that password to another process (the browser) and fill it there. The SGX module is only protecting memory accessible by 1Password so we’d be forced to take it out.

      In other words, we wouldn’t be able to keep the password in the secure enclave during it’s entire life cycle, so having that password start life within the enclave isn’t going to provide much protection.

      As for the Master Password, Windows itself has some safe guards to protect against keyloggers in password fields, but from what I understand those safeguards can be avoided by crafty malware. I don’t see how SGX could protect us here as it’s the keyboard input that’s being monitored here, not memory.

      So in general we should be excited SGX as it does offer an additional layer of protection against certain attacks, but we need to be careful thinking it’s a security panacea.

      Take care and enjoy the rest of your weekend! 👋


    • Josh
      Josh says:

      Thanks for the detailed reply, Dave!

      What I was thinking of with the master password was a malicious DMA device that snoops on either kernel memory or 1password process memory as the master password is typed in. I wonder if there’s any way to have some kind of SGX-secured input, where the master password would be added to SGX directly as it’s typed in and never stored in plaintext in RAM. I’m not at all familiar windows’s driver/keyboard infrastructure, so I have no idea if that’s feasible, but it might provide some meaningful protection. As it is, I believe that a malicious DMA device wouldn’t need to steal the decryption keys–it could just get the master password and compute the keys itself, right?

    • Dave Teare
      Dave Teare says:

      Good morning, Josh. I see you are continuing to do a great job keeping me on my toes 🙂

      I’m going to preface my response that I’m in the same boat as you: I’m not a Windows driver/keyboard infrastructure expert, either. So I’m not sure if your SGX-secured input idea is possible or not. It sounds great on the surface and it may very well provide some additional protection, but it too would have its limits. For example, if a USB keylogger was installed between the keyboard and the computer (like this one for example), then all keys would be recorded before they ever reached the protection of the SGX-secured enclave. I think an SGX-secured input could provide protection against software based keystroke loggers, however.

      To your point about capturing the Master Password, you’re right, an attacker isn’t required to steal the encryption keys from memory. They could grab the Master Password and compute the keys themselves (we’re very open about our data format, which is a very good thing). Stealing the keys is just one attack vector of many, and the secure enclave does a great job of protecting against that particular attack.

      This brings me back to my panacea point earlier, and something I know Jeff talks about often as well: security is a process and defense in depth is an important part of that process. Intel’s new SGX secure enclave gives us additional protections from some attacks, but no single piece of hardware or software can make anyone completely secure against all current and future attacks. Once a compromised machine is involved, it is no longer your machine and so it very much becomes a game of cat and mouse.

      We’re still at the beginning of the story here with SGX so I’m quite hopeful that many more ingenious uses will be found for it. I think your SGX-secured input idea is an interesting next step as every app could benefit from that.

      Take care,


Leave a Reply

Want to join the discussion?
Feel free to contribute!

What's on your mind?