keychain OS 2.0

If you have data on the phone that you want to access on the watch your app can use WatchConnectivity to transfer the specific data and keychain items it needs. The keychain on Apple Watch contains a distinct set of entries from the keychain on the paired iPhone, so if you need something in both places you can either generate it once for each device or use WatchConnectivity to transfer it between them.

Is this documented anywhere, especially that part about "The keychain on Apple Watch contains a distinct set of entries from the keychain on the paired iPhone" I couln't find the information on the migration docs. Also, just to confirm, accessGroups won't work with watchOS 2?

Just for clarification, in OS 1.0 we needed to use accessGroups for keychain so the watch could read the iPhone app's keychain, Specifically, this was to check the login state of the app. If the user was already logged in on the iPhone, then there was no need to ask the user to log in again.

> Is this documented anywhere, especially that part about "The keychain on

> Apple Watch contains a distinct set of entries from the keychain on the

> paired iPhone" I couln't find the information on the migration docs.

>

No, not explicitly. It's implied by the over all architecture of native watch

apps and, by extension, the fact that app group data is not being shared.

> Also, just to confirm, accessGroups won't work with watchOS 2?

>

I don't if we've talked about how app groups would work among multiple vendor

apps running on the same watch, but I suspect they'd work in that sense.

However, they won't work between the watch and the iPhone, which is what I

think you meant.

-Kevin

OK, I think I am still a bit confused about this. It sounds like you are saying that there is no way for the phone and watch to share a keychain with accessGroup. This would seem to imply that the user would have to log into each the watch and the phone separately for the same app, that seems wrong. However, I don't see any other way to securely do this if the keychain can't be shared. Am I missing something? Sorry for the confusion....

> OK, I think I am still a bit confused about this. It sounds like you are

> saying that there is no way for the phone and watch to share a keychain with

> accessGroup.

>

Yes, that's correct.

> This would seem to imply that the user would have to log into each the

> watch and the phone separately for the same app, that seems wrong.

>

Yes, that's correct. The phone and watch apps can now be completely

independant entities with their own login credentials. You can leverage the

phone app to improve the onboard-ing process for the watch app, but

fundamentally they are independant devices with their own data stores.

> However, I don't see any other way to securely do this if the keychain

> can't be shared. Am I missing something? Sorry for the confusion....

>

You'll need to build your own authentication infrastructure here. My first

pass advice would be to have your phone app log into your service and generate

your authentication token to use for future communication (the same way most

modern web service work), then transfer that token to your watch app which

then stores the data into it's local keychain.

-Kevin

RE: "You'll need to build your own authentication infrastructure here. My first

pass advice would be to have your phone app log into your service and generate

your authentication token to use for future communication (the same way most

modern web service work), then transfer that token to your watch app which

then stores the data into it's local keychain."

I really don't get how this would work securly and reliably.

Assume the user logs into the phone, the phone then stores the token in its keychain. The user then leaves the app. Later the user opens/installs the watch app. The watch calls the phone but since the watch and phone can't share the keychain, how can the watch get the token? Currently, only if the watch is part of the accessGroup can it read the keychain.

We could try and pass the token with WCSession as soon as the token is received (on the phone) but is that sent securely? Also, this would fail if the watch app wasn't installed yet which would mostlikey be the case if the app was just installed on the phone. This apprach doesn't seem very reliable. And this doesn't even touch on the issues with keeping the two keychains in sync....

Sorry if I am missing something here 😟 , just trying to figure out the best solution.

Has anyone had time to work out a solution for this change in watchOS 2???

I've run into the same issue. It's unfortunate that Keychain Sharing via access groups is no longer supported between an iPhone app and it's accompanying Watch 2 app. I'll have to devise an alternate solution outside of this mechanism.

Hey rp1230. Followed your discussion in 3 different forums about this. Were you ever able to figure out if WCSession is a secure connection or if there is a more reliable way to pass the token and login credentials to the watch?

Hi pdemorest, this document (https://www.apple.com/business/docs/iOS_Security_Guide.pdf ) seems to indicate that WCSession is secure as it would use the BTLE or WiFi connection to the paired iPhone. Look under the Apple Watch section starting on page 22 for the details on security.

However, I am still working on a good soltion for the actual log in on the watch. Nothing seems to be without possible issues...😕 Please let me know if you have any good suggestions on how you plan on handling it.

Thanks!