Is it safe to use updateApplicationContext to send keychain value

Question

In watchOS 2, there are no more shared keychains.

If I want to send a keychain value from the iOS app to the Watch app, is it safe to send it via WCSession updateApplicationContext?

Malefaction

What do you mean by "safe"? – Servais

By safe I mean hacker cannot get the passwords etc.... – Malefaction

@Servais Based on this comment, the OP has concerns about this aspect. – Seppuku

@PetahChristian that makes sense, though probably a question only Apple can answer. – Servais

@Malefaction given the above, your best chance to get an answer is to contact apple. perhaps a bug report? – Servais

Answer 1

Response from Apple:

The app’s content is encrypted during transit. Otherwise the content is stored in the app’s container which provides the inherent security of containers.

Here is a link to the Security White Paper. https://www.apple.com/business/docs/iOS_Security_Guide.pdf

For the in-transit part, you should take a look at the “Apple Watch” section under "App Security". For the pertinent part of container security, you should take a look at the “File Data Protection” section under "Encryption and Data Protection”.

Malefaction

Answer 2

Yes.

If your keychain value doesn't change, and you repeatedly update your application context, you may want to arrange to only send the value one time (for the watch to add to its keychain), instead of repeatedly resending the keychain value.

An Apple engineer discusses using Watch Connectivity to send keychain items on the developer forum:

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.

Update:

In watchOS 2, Watch Connectivity is the mechanism for transferring data between a paired phone and its watch. Communication between devices is encrypted, according to the iOS Security Guide.

As for whether the dictionary may be accessible while in-memory, or how it might be persisted before your extension ever receives it, I think you have to rely on Apple to address any possible vulnerabilities.

It's probably reasonable to say that the info isn't in as safe a place as the keychain, until your extension wakes, receives the update, then stores the value in the keychain.

Seppuku

Value may change, that is why I prefer using updateApplicationContext. But this dictionary - is it stored in a safe place where hacker cannot get the data? – Malefaction

Answer 3

As per the Apple Security guideline:-

Keychain Data Protection Many apps need to handle passwords and other short but sensitive bits of data, such as keys and login tokens. The iOS keychain provides a secure way to store these items. The keychain is implemented as a SQLite database stored on the file system. There is only one database; the securityd daemon determines which keychain items each process or app can access. Keychain access APIs result in calls to the daemon, which queries the app’s “keychain-access-groups,” “application-identifier,” and “applicationgroup” entitlements. Rather than limiting access to a single process, access groups allow keychain items to be shared between apps. Keychain items can only be shared between apps from the same developer. This is managed by requiring third-party apps to use access groups with a prefix allocated to them through the iOS Developer Program via application groups. The prefix requirement and application group uniqueness are enforced through code signing, Provisioning Profiles, and the iOS Developer Program.

Keychain data is protected using a class structure similar to the one used in file Data Protection. These classes have behaviors equivalent to file Data Protection classes, but use distinct keys and are part of APIs that are named differently.

---

Apple Watch it uses the security features and technology built for iOS to help protect data on the device, as well as communications with its paired iPhone and the Internet. This includes technologies such as Data Protection and keychain access control. The user’s passcode is also entangled with the device UID to create encryption keys. Pairing Apple Watch with iPhone is secured using an out-of-band (OOB) process to exchange public keys, followed by the BTLE link shared secret. Apple Watch displays an animated pattern, which is captured by the camera on iPhone. The pattern contains an encoded secret that is used for BTLE 4.1 out-of-band pairing. Standard BTLE Passkey Entry is used as a fallback pairing method, if necessary. Once the BTLE session is established, Apple Watch and iPhone exchange keys using a process adapted from IDS, as described in the iMessage section of this paper. Once keys have been exchanged, the Bluetooth session key is discarded, and all communications between Apple Watch and iPhone are encrypted using IDS, with the encrypted BTLE and Wi-Fi links providing a secondary encryption layer. Key rolling is utilized at 15-minute intervals to limit the exposure window, should traffic be compromised. To support apps that need streaming data, encryption is provided using methods described in the FaceTime section of this paper, utilizing the IDS service provided by the paired iPhone. Apple Watch implements hardware-encrypted storage and class-based protection of files and keychain items, as described in the Data Protection section of this paper. Access-controlled keybags for keychain items are also used. Keys used for communication between the watch and iPhone are also secured using class-based protection. When Apple Watch is not within Bluetooth range, Wi-Fi can be used instead. Apple Watch will not join Wi-Fi networks unless the credentials to do so are present on the paired iPhone, which provides the list of known networks to the watch automatically. Apple Watch can be manually locked by holding down the side button. Additionally, motion heuristics are used to attempt to automatically lock the device shortly after it’s removed from the wrist. When locked, Apple Pay can’t be used. If the automatic locking provided by wrist detection is turned off in settings, Apple Pay is disabled. Wrist detection is turned off using the Apple Watch app on iPhone. This setting can also be enforced using mobile device management. The paired iPhone can also unlock the watch, provided the watch is being worn. This is accomplished by establishing a connection authenticated by the keys established during pairing. iPhone sends the key, which the watch uses to unlock its Data Protection keys. The watch passcode is not known to iPhone nor is it transmitted. This feature can be turned off using the Apple Watch app on iPhone. Apple Watch can be paired with only one iPhone at a time. Pairing with a new iPhone automatically erases all content and data from Apple Watch. Enabling Find My Phone on the paired iPhone also enables Activation Lock on Apple Watch. Activation Lock makes it harder for anyone to use or sell an Apple Watch that has been lost or stolen. Activation Lock requires the user’s Apple ID and password to unpair, erase, or reactivate an Apple Watch.

Keychain Services Ease of Use https://developer.apple.com/library/ios/documentation/Security/Conceptual/keychainServConcepts/02concepts/concepts.html

Elbaelbart