Trust no one (TNO)

[Deleted User]

I keep hearing about the concept of "Trust No One". Citing Wikipedia "The Trust No One approach teaches that no one (but yourself) should be trusted when it comes to the storage of the keys behind the applied encryption technology"

There is substantive information on the Agilebits web sites describing the cryptographic techniques used, key management, protecting data in transit and at rest (e.g. at iCloud or Dropbox).... reading this is interesting but after a while I start to see red dots in front of my eyes - just joking - but talk about complicated !

Can someone explain in a few paragraphs what TNO means in the context of 1Password?

khad

We do not know or have access to your Master Password (from which is derived the encryption keys that protect your data). Your Master Password is never transmitted for syncing or stored in the data format. You do not need to trust us for your data to be protected. The data format is verifiable as well as the specific fact that your Master Password is not stored in the data format or transmitted for syncing.

There is no back door. If you forget your Master Password there is no way for us to recover it. If there was, that would be something an attacker could exploit.

It is great that you are thinking about these things. Please let me know if you have any other questions. We are always here to help!

[EDIT: Added bolded text to clarify for @benfdc below.]

RichardPayne

The reality is that Trust No One is a principle that is impossible to follow as soon as you start to use hardware or software that you didn't build yourself. You trust that the OS developer is not inserting backdoors. You do the same with your PC's BIOS code and network drivers. We all do the same with 1Password to a degree. While the data format is open and the encryption is mathematically solid, that's no guarantee that someone clever enough can't find a way to code in a vulnerability that is hard to detect, and that's assuming that there isn't a backdoor in the application itself. If Agilebits are to be believed then they have safe guards in place to prevent this, but this assumption is based on the idea that the whole company can't be evil, which is not an assumption that could be backed up.

TNO is an aspirational objective, not a absolutely practical one.

[Deleted User]

Thanks for your responses - very much on point - most appreciated.

khad

Happy to help, @toasted. Have a great rest of your week! :)

benfdc

One's master password was definitely stored in the early iOS apps (I know this from personal experience, because 1Password HD revealed my wife's passphrase to me, quite unexpectedly). Something posted recently by @jpgoldberg (don't feel like taking the time just now to run it down) suggested to me that this might still be true in 1P4/iOS.

khad

@benfdc,

As I said above:

your Master Password is not stored in the data format or transmitted for syncing.

This is now and has always been the case. You are referring to the Master Password being stored in the iOS keychain for automatic Dropbox syncing in 1Password 3 quite some time ago. Again, it was never stored in the data file itself or transmitted for syncing. Additionally, 1Password 3 is no longer available for sale on the App Store, and Dropbox has deprecated the API used by 1Password 3 for iOS. So even if you still have a copy installed this is not something users need to worry about.

There is a case where the Master Password is stored in the iOS keychain: enabling the PIN code in 1Password for iOS version 4.5 or later. But, again, it is neither stored in the data file itself nor transmitted for syncing. It resides obfuscated and protected only on the device itself. It is optional, and not enabled by default. As stated in 1Password 4 for iOS security settings:

Use a 4-digit code to quickly access your data.

This is only recommended if Auto-Lock has been turned on in this device's settings. When PIN Code is enabled, your Master Password will be stored in the iOS keychain.

And the storage of the PIN code in the iOS keychain can be disabled while still using the PIN code feature. (Essentially it then behaves as the old Quick Unlock Code did pre-4.5.) You can toggle "Use iOS keychain" in Settings > Advanced.

You can read the complete details of the iOS PIN Code Design in the 1Password for iOS User Guide including additional information on the security and history.

I hope that helps. Please let me know if you have any other questions or concerns after reviewing the aforelinked section of the User Guide! :)

benfdc

@khad‌—

I never said that the master password was transmitted when syncing, or that it was stored in the data format. I was questioning the second sentence in your #2 above:

Your Master Password is never transmitted or stored.

I believe that you have conceded your error. :-) To be fair, you may have been trying to convey the point that master passwords are never transmitted to AgileBits or Dropbox, and therefore cannot be stored by AgileBits or Dropbox. But that isn’t what you wrote.

Furthermore, you can correct me if I am wrong, but I believe that the iOS keychain is transmitted during backups. So the master password, if it is stored in the iOS keychain, can indeed be transmitted. And backups that are transmitted can be intercepted.

I do not mean to suggest that storing a master password in the iOS keychain is necessarily a problem. However, it is unquestionably a risk, as was illustrated quite vividly by 1Password HD, which, as I inadvertently discovered, could be induced to disclose the stored master password to the user. Apparently this was not a bug, but an ill-conceived (IMO) feature inserted to aid in troubleshooting 1Password 3/iOS sync problems.

—Ben F

benfdc

I probably should have read the iOS PIN Code Design article before posting the above, but it doesn’t really change my views. Indeed, there is a statement in that article with which I take issue:

That obfuscated Master Password never leaves your device, even if you have iCloud keychain synching on. It is only stored temporarily in that 1Password (if it has the opportunity) will remove it from the iOS keychain once the Master Password “Request after” time has expired.

Again, unless I am mistaken, the obfuscated Master Password leaves the device if it has not been deleted by 1Password prior to the next time that the iOS keychain is backed up. People do try to attack these backups. You may have very good reasons to believe that such off-device attacks cannot succeed, but IMO the risk exists nonetheless and should be expressly acknowledged and discussed in the Knowledgebase article.

—Ben F

p.s. The second sentence in the Knowledgebase article following the ones that I quoted above needs some clean-up.

p.p.s. Another risk not mentioned in the Knowledgebase article is the risk that AgileBits might, inadvertently or not, once again do what it (IMO foolishly) intentionally did in 1Password HD—add a “feature” to the app itself which could be exploited to make the app disclose the stored master password.

roustem

Ben,

We use the kSecAttrAccessibleWhenUnlockedThisDeviceOnly attribute for the master password stored in the iOS keychain.

The kSecAttrAccessibleWhenUnlockedThisDeviceOnly security attribute makes sure that the value stored in the keychain is protected by the unique device hardware key unique and it is not possible to decrypt the value unless you are performing the decryption operation on the device ifself.

I am not quite sure how this is implemented on the older devices. The iPhone 5s is using the Secure Enclave to perform the decryption.

jpgoldberg

Hi @benfdc‌,

I'm sorry for the ambiguity in the document you cited. 1Password attempts to clear the obfuscated item quickly, but there are circumstances under which it may not have the opportunity to do so.

"ThisDeviceOnly", as @khad‌ pointed out means what it says. It is encrypted with a key that is baked into the device in a way that makes it unfeasible to retrieve from the hardware, and so those things can only be decrypted on the device itself.

Are you concerned that Apple or someone has those device keys despite their claims that nobody has those? Perhaps that is so, but then you are already trusting that other parts of their system behave as claimed. There are ways that they could get your Master Password without that. (There could be an iOS update that has a special version just for your device that puts a hole in the system.)

This goes back to what @RichardPayne‌ said. "Trust No One" is an aspiration. It is a good thing to aim for, but ultimately you will be trusting hardware and operating system distributors. This is not a reason for us to say that such security concerns don't matter. This is one of the reasons that we did make storing that Master Password optional.

I'm not sure exactly the details of the NDA I am under from WWDC, but in iOS 8, so I will be vague. I believe that you will be happy with a new feature of iOS keychain security that may be appearing in iOS 8, which is even more restrictive than kSecAttrAccessibleWhenUnlockedThisDeviceOnly. I don't do much actual coding, but I was pleased to add one line of code to one of our branches to make use of this. People who are members of Apple's developer program should take a look at WWDC 14 session 711. But again, this is under NDA until Apple makes it fully public.

benfdc

@jpgoldberg—

I agree with everything in your post, but I still question the statement in the Knowledgebase article that “the obfuscated password never leaves your device.” It can leave the device in a backup of the iOS keychain, and it can be recovered from that backup by an attacker who gains physical access to your device. How realistic is this attack scenario? That depends on the user’s threat model, which IMO is not something that AgileBits should presume to judge.

1Password for Mac is designed to protect my data even if my computer is lost or stolen, or an attacker gains access to my machine when I step away from it. That is why you do not allow 1Password to store the Master Password in the OS X keychain. A user has a right to expect that 1Password for iOS will protect the user’s data from the same sorts of threats as does 1Password for Mac.

For that reason, I contend that the above statement in the Knowledgebase article is not a regrettable ambiguity. I view it as an outright error, and I am not inclined to concede that the error is harmless and therefore need not be corrected.

jpgoldberg

I'll file a documentation bug about this.

The single most common question that we received about the PIN in the keychain was whether it synced as part of iCloud keychain. Most people had never heard of the iOS keychain before iCloud keychain, and so their conception of the iOS keychain was for synching. So as I look over that document today, I see that it is attempting to address the primary concerns up top and not bury the lede.

But you are correct, @benfdc, and this originates from my error. I had forgotten about backups (where this data would be encrypted with the device key) when I uttered the words that got into that document (which I approved). Although I do know how this works, I fell back to an approximation for the meaning of "ThisDeviceOnly". Considering that this is in a section described as "Short And Approximate answer", any correction needs to not get to involved within that section. More can be added to Risks, and then more to the details further below.

At the risk of violating an Apple NDA, I should point out that future behavior is likely to conform to the current documentation in iOS 8.

benfdc

Nudge, nudge. Wink wink. Say no more. :-)

benfdc

@khad—

Thanks for editing your #2 in a way that both corrects your post and preserves the context of the subsequent discussion in this thread. Much appreciated.

khad

Not a problem, @benfdc‌. It was my mistake to have omitted those words in the first place. I knew what I meant, but I can't assume everyone else does unless I actually write it correctly. :)

If you haven't seen the updates to the iOS PIN Code Design document, @jpgoldberg updated it to clarify.

Thanks again!

benfdc

If you haven't seen the updates to the iOS PIN Code Design document, @jpgoldberg updated it to clarify.

No surprise that Jeff did a great job. I have no bones to pick with the revised Short (approximate) answer section. However, the second sentence in the Risks (short version) section still needs some editorial love.

Speaking of needing some love, I should not let the penultimate sentence of that Knowledgebase article pass without comment:

[W]e recommend you only use 1Password’s PIN Code in conjunction with the Use iOS Keychain setting if you have enabled Autolock on your device and used a strong passphrase.

Wouldn’t it be wonderful if the 1P/iOS password generator were to be enhanced so as to be able to help the user create a strong passphrase? ;-)

jpgoldberg

Acknowledged. Cheers!