iOS: Resigned app cannot access keychain through security API

Question

We have an app we are writing for a customer. We compile the app and deliver an IPA to the customer, who then resigns the app using their provisioning profiles and keys.

The app works fine until the customer resigns it. Then it fails when accessing the keychain. We get messages in the device console like this:

... SecItemAdd: missing entitlement
... SecItemCopyMatching: missing entitlement

Logging the return codes we are getting -25308 "Interaction with the Security Server is not allowed" from all SecItem* calls.

I've not been able to find anyone with this same problem and a solution.

Both the initial builds and subsequent code signings work and the app runs until it tries to access the keychain. When resigning the customer is specifying the same app id we originally built it with. I've added and entitlements file as well.

I have noticed that the app id used in the provisioning profile the customer is using is different to the id in the app. However the resigning works and the apps runs so I'm assuming at this point it's not an issue.

So far no luck.

Has anyone had this problem and solved it?

Answer 1

Thanks @borrrden for the replies. They gave me some good pointers.

I eventually got it all working. Here is what I found.

1. Wildcard ids are fine. I had no problem using a wild card id and accessing the keychain.

2. The problem was that the XCode creates a set of entitlements dynamically based on the ids that it knows about at compile time. When the resigning occurred the provisioning profile contain an app id which the generated entitlements did not match. Therefore iOS would not allow access.

3. To Solve this I created an entitlements file which I got the client to specify as part of the codesign arguments. This entitlements contained a key chain access group that matches the new app id in the provisioning profile. I also had to add the correct team id to the front of the access group. Normally XCode auto-inserts this.

4. Data protection also had nothing to do with the issue.