(502005) Wi-Fi Sync Apparently Working When Mac 1Password Locked?
I understood from this explanation by @MikeT that:
For Wi-Fi, it is connected as long as both apps are unlocked and running, the sync is real-time. It will not sync in the background like it does for Dropbox only.
However with (502005), 1Password on iOS is showing that Wi-Fi sync is succeeding even when 1Password on my Mac is locked but still running. I haven't noticed this before.
Is this something new with this version?
Provided everything is secure (I'm sure it is) then this is of course a good thing because Wi-Fi sync works more often. Please would someone explain what's happening down at the data level for the keychain information exchange during Wi-Fi sync?
Comments
-
In the Last Sync field, does it match the time of the last successful sync or current sync? I had mine showing last sync 8 hours even when I haven't unlocked my app after waking up my Mac from sleep.
It can connect to the Mac app but as long as it is locked, it cannot pull data because it doesn't have the master password to decrypt the data.
0 -
After leaving my Mac with the display asleep overnight. When I open 1Password on my iPhone:
And after unlocking the Mac I confirm that 1Password is locked:
Same happens on my iPad Air.
0 -
Hi @Penelope Pitstop,
Strangely, I cannot reproduce this. I got the Unlock primary vault on your Mac prompt on my iOS devices.
Can you confirm what versions of 1Password you're using right now on both Mac and iOS, so I can try to break this.
Also, do a test for me:
- Make a change in your iOS app, create a brand new item or edit an existing test item.
- Tap on Sync Now, to sync it to the locked Mac app but do not unlock the Mac app just yet
- Now, kill the 1Password app on your iOS device, so no Wi-Fi sync can happen
- Unlock the Mac app, did it actually get the change you made?
Please let me know how it turns out.
0 -
Hi @MikeT,
iOS, 5.2 (502005)
OS X, 1Password Version 5.1.BETA-10 (510010)I read your reply on my iPad after my computer had been idle for several hours. So I opened 1Password on the iPad and it showed that it last synced 13 hours ago but a few seconds later it showed that sync completed and the item count dropped by about 200 which made sense because I removed a load of redundant password items on the Mac earlier that day.
I then followed your instructions.
When I tapped on Sync Now, I got a warning but then got out of that and just left the iPad alone and it appeared to sync. In fact the item count climbed by one.
I killed the app on iOS and went to the Mac and I just unlocked 1PW. Imagine my surprise to see:
Now this has me rather concerned because it would indicate that my keychain isn't really locked on the Mac.
0 -
Hi @Penelope Pitstop,
Stay tuned, I'm asking the team to see if we made a change in the recent betas to allow for this.
0 -
Hi @Penelope Pitstop,
I think I know where the issue is and we're going to investigate this tomorrow.
Can you reboot your Mac and then without unlocking once, does it now do what we expect?
0 -
Hi @MikeT,
Yes when I rebooted my Mac and launched 1Password left it unlocked, the iOS devices give the "Please unlock primary 1Password vault on your Mac" pop up.
Going a little off-topic, there are issues with that pop up warning. On the iPad it pops up over the prompt for the PIN which is an annoyance. Furthermore it pops up twice on both iPhone and iPad which is a bit irritating.
Wi-Fi sync continues to work after manually locking the vault on the Mac.
0 -
Yes when I rebooted my Mac and launched 1Password left it unlocked, the iOS devices give the "Please unlock primary 1Password vault on your Mac" pop up.
That basically confirms the theory, stay tuned for my follow-up. I'm trying to get more information to see if this is intentional or not. Basically, you have to unlock the app once in the same session before it can keep syncing.
Going a little off-topic, there are issues with that pop up warning. On the iPad it pops up over the prompt for the PIN which is an annoyance. Furthermore it pops up twice on both iPhone and iPad which is a bit irritating.
It's a known issue, we'll fix that as soon as possible.
0 -
Hi all,
I know that this looks suspicious, but it really is OK. Let me try to provide a sense of what is going on behind the scenes.
First start simple. Dropbox synching between Mac and iOS
I'm going to describe synching in general on Mac and iOS before getting into the details of wifi sync. I'm going to start with an example of synching with Dropbox. And I'm only going to talk about primary vaults. I will (eventually) get to WiFi synching, but it is easier to explain certain things in the "simple" case first.
1Password (on both iOS and OS X) separates the notion of synching data from "local" data. The local data is all in a SQLite database and is designed to be usable and searchable and such by the app. The data in there is encrypted with a set of master keys (let me just call it a single master key to keep things simple). Now suppose that you are also synching something in the OPVault format or Agile Keychain format via Dropbox. That also has a master key, but the master key is not the same as the master key for the local format. In each case, the master key is encrypted with a key derived from your Master Password.
So you have some sqlite data on your iOS device. The data within it is encrypted with a local master key which is protected by your Master Password. Your Agile Keychain data also has its own master key that is encrypted with your Master Password. And 1Password on the Mac has its own sqlite data that has its own master key, which is also encrypted with your Master Password.
So we have three master keys. One for the local data on your iOS device, one for the data in your Agile Keychain on Dropbox, and one for your local data on your Mac.
Dropbox sync from the Mac (the easy part)
Suppose you first set up Dropbox synching on your Mac. When you first do this, your Master Password is used to decrypt the master key for the Agile Keychain stuff. Then 1Password on your Mac will actually create a special item in your local data (that you never see) which contains the Agile Keychain master key. This gets stored like your other secrets in the local database. It is encrypted with the local master key (which in turn can be decrypted by your Master Password.
This way, when you unlock 1Password on your Mac, your Master Password gets processed into something that can decrypt the local master key. That local master key can be used to decrypt the rest of your local data. Included in that local data is the master key for your Agile Keychain. Thus when 1Password on your Mac is unlocked, get its local data in sync with the Agile Keychain data by decrypting a new or modified item with the master key of the source and then re-encrypting it with the master key of the destination.
Dropbox sync on iOS (it gets trickier)
On iOS, 1Password doesn't actually have a full copy of the Agile Keychain "on disk" the way it does on Mac. Instead it talks to Dropbox about individual files. But, of course, 1Password on iOS does have its local copy. 1Password on iOS can query dropbox about file date changes and such. So it can see that something probably changed before having to ask Dropbox for the file. (In the Agile Keychain format, each of your items is in its own file. It's a bit different for OPVault.) Furthermore, each item carries with it, unencrypted, a modify date. This helps 1Password know which items need updating before it has to actually decrypt anything.
Anyway, when you first set up Dropbox syncing on iOS, 1Password will use your Master Password to decrypt the master key for the data that it has fetched from Dropbox. Just as with 1Password on Mac, it will store that master key within its local data. So when you unlock 1Password on iOS, it also has access to the master key for the data on Dropbox.
Now because of how 1Password on iOS talks to Dropbox, we can think of a sync operation as having two steps. Let's consider a newly created item on iOS. 1Password on iOS of course store that new data locally. But it will also use its knowledge of the master key for the Dropbox data to create an update that is encrypted with the Dropbox data master key. This is kept in a staging area. At some point, when 1Password connects to Dropbox the stuff in the staging area gets sent up to Dropbox. Note that that second step (sending the staged data to Dropbox) can happen even when 1Password is locked. This is because the data got re-encrypted with the master key used for the data on Dropbox during staging. This allows for lots of things to
happen in the background even when 1Password is locked.A great deal of this also works because with the newer data, we have cryptographic checksums and multiple sync timestamps to help 1Password figure out what items it needs to update and "stage" for synching.
Wifi sync is different, but not as different as it was
When WiFi sync was re-introduced, it used its own special sync system that required 1Password to be unlocked at both ends. But we've been making a whole bunch of under-the-hood changes and redoing WiFi sync to work with the staging process. Depending on versions and such when WiFi sync was first set up, 1Password on iOS might have the master key for the local data for 1Password on Mac, and vice versa. So data from 1Password on Mac can get sent over WiFi to 1Password on iOS's staging area even when 1Password is locked at both ends. (Just as data can go between 1Password for iOS staging area and Dropbox even when 1Password is locked).
1Password on iOS, however, can only incorporate the (previously) fetched data when it is unlocked. But if it has the keys to both its own data and the date that is "waiting to be incorporated" it can do that even if the other end is locked.
Anyway, you will see WiFi sync making more and better use of this two step process. When it is fully wired up on the Mac end, it will mean that actual data transfer can happen any time, and the already transferred data can get incorporated as soon as you unlock 1Password.
I really wish there were a simple way to explain all of this. This is actually good for security as it makes the actual over-the-air data exchange with WiFi more secure.
0 -
Hi @jpgoldberg,
Thank you for taking the time to write such a comprehensive explanation. I think I understand and I am at least reassured that my data is safe. I also welcome the enhanced flexibility of Wi-Fi sync.
Why is a separate and different key used for the external storage of the keychain? Furthermore, why is it stored inside the keychain itself even if it is encrypted?
0 -
Hi @Penelope Pitstop ,
Why is a separate and different key used for the external storage of the keychain?
Think of it like the master key in the apartment building, you have the master key that can unlock all the doors (vaults) in the building but when you rent out one of the rooms, you don't want to give them your master key. You want them to have their own lock, so they can't unlock the rest of the rooms. Thus, each room (vault) has its own unique lock (vault master password).
That's why you want a different and separate key for each sync file you created via Dropbox or Folder Sync.
Furthermore, why is it stored inside the keychain itself even if it is encrypted?
Technically, we don't have to store it in the keychain but for convenience of the users, it is stored because you need it to unlock your data with your master password instead of dealing with keys manually.
Syncing then will not work easily because it needs the key to decrypt the file, not the vault password since the key is what is decrypted when you enter your vault password. That alone is very difficult to deal with on mobile devices that might not let you import keys like this (let alone a secure method that doesn't log the keys) and you'd have to do this each time to ensure the keys are not stored on the device.
Even if you can handle that, you have to spend more efforts on protecting the keys as it is not encrypted. There could be another way, encrypt the keys with your master password, then decrypt it as you import it into the app. At this point, the app doesn't really follow its namesake of only using 1Password.
0 -
Let me also add to some points about why there are separate keys for the different instances of your data.
First of all, general practice (for good reason) is to use completely random keys for encrypting data. So 1Password will pick a completely random number for a key when a new vault is created. Your Master Password is not the source of that key. Instead, your Master Password is the source of what is called a "key encryption key" (KEK). The KEK is what encrypts the randomly created keys.
The kinds of keys used for the Agile Keychain are different than the kinds of keys used in the local data. The Agile Keychain has two 128 bit AES keys. One for "security level 5" and one for "security level 3". (We no longer make use of SL3, but those keys are still there.) A 1Password 4 vault will have four 256 bit keys. A 256-bit master encryption key, a 256-bit master MAC key, a 256-bit overview encryption key, and a 256-bit overview MAC key. There simply is no (reasonable) way to use the same keys for the Agile Keychain as we use for more recent data forms.
Of course if you are synching with OPVault, iCloud, or WiFi, the Agile Keychain format doesn't come into play. But there are other reasons for separate keys. The simplest is that your keys are generated when you first set up your data. But also the number of PBKDF2 iterations is celebrated to particular resources and needs.
Because of different threats and capabilities we tune PBKDF2 to the particular instance. (PBKDF2 is part of the process for getting from your Master Password to a KEK. ) Because each local format will only be processed on the local machine, we can calibrate the number of PBKDF2 depending on the hardware it is running on. And because we consider that the data used for synching is more likely to be stolen, we try to use a higher number of PBKDF2 iterations on that.
Too much complexity?
Complexity is an enemy of security. It provides more opportunities to make mistakes in design or implementation. Also we aren't masochists. We don't enjoy all of this complexity. But the complexity that you see (well actually that we see and try to conceal from people using 1Password) is all there for good reasons. The straightforward notion that most people have of what it means to encrypt data turns out to lead to enormous insecurities. In one sense the crytographic part is the easy part (and it isn't easy); it's the internal key management that gets tricky.
We don't want to present all of the underlying complexity to people using 1Password. People have a mental model of what it means to encrypt or lock data. And we try to make 1Password's behavior conform to that. But every now and then, there will be a "gotcha". A place where 1Password's behavior seems surprising, and this is the consequence of the fact that the simple view of encryption that people have and that we present isn't what is actually going on behind the scenes. And so this thing about synching in one of those cases. 1Password is behaving securely, but because of all of its behind the scenes magic, it can do things that when looked at in terms of the simple model seem wrong.
0 -
Thanks again @jpgoldberg.
I think I now have some insight into the reasons behind the need for the variety of keys.
I'd like to read more about the generally accepted good practice that you refer to because I'm fascinated by it. Would Schneier's "Applied Cryptography: Protocols, Algorithms, and Source Code" be a good resource or would you suggest something else? I can handle material intended for graduates in mathematics and computer science but I'm more interested in the underlying principles than particular equations, proofs or writing code.
0 -
Would Schneier's Applied Cryptography: Protocols, Algorithms, and Source Code be a good resource
No
Applied Crypto was an extremely important but at the time; I, and lots of other people learned a lot of good stuff from it at the time. The problem is that it contains some bad advice which was excusable at the time, but leads to error. Quite a bit of today's not-really-up-to-snuff cryptographic software is the consequence of people treating Applied Crypto as scripture.
For actual cryptography, I think that the book I would recommend is Cristof Paar and Jan Pelzl's Understanding Cryptography. There are also full videos of a course taught using this textbook. (The lectures are in English, but some of the questions from students are in German).
For design of cryptographic systems, there is Niels Ferguson, Bruce Schneier, and Tadayoshi Kohno's Cryptographic Engineering.
0 -
Thanks very much. Let's hope Santa pops those into my stocking. :)
0 -
Ask Santa to send me a copy as well. :smiley:
0
