As Apple docs state, apps can share keychain data if they have the same App ID prefix and they've set the same keychain-access-groups in Entitlements.
However, I've been able to access shared keychain data from the app that has a different App ID prefix as long as I provide the proper keychain-access-groups as a hard-coded string. Like ABCDEFGHIJ.my.keychain.group.
It seems that keeping the keychain-access-groups value secret is the only thing that prevents someone from accessing the keychain data. Obviously, since it's just a plist value, this is not safe at all.
Is there any way to ensure that an app that is not included in my Apple Developer Program will not be able to access shared keychain, even if it knows my keychain-access-groups value?
Related
I have stored fabric_api key in Info.plist file.But I don't want to include my key and secret in the info.plist file when the the app is live.
what is the best way to keep fabric/crashlytics key secure?
I only know several ways:
Just put it in a constant variable, or if you want under your struct that handles all your keys. That's it.
UserDefaults.
Use libraries to obfuscate somehow your keys, such as https://github.com/orta/cocoapods-keys
Keychain.
The last one is discussed by Apple.
Keeping a private key in a keychain is a great way to secure it. The key data is encrypted on disk and accessible only to your app or the apps you authorize.
https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/storing_keys_in_the_secure_enclave
Also some interesting discussions:
In iOS, how can I store a secret "key" that will allow me to communicate with my server?
swift3 - How to protect secret key
I hope this helps.
By implementing universal links, you end up with an apple-app-site-association file that you put in the root of your server. The file contains both bundleID and teamID. Is this safe?
I can clearly download e.g. Google’s one and get their IDs since the scenario is always the same.
There is no security risk from displaying the bundle ID and team ID. It is not possible to use these two pieces of information for anything (either productive or dangerous) without also having access to your Apple Developer account password.
I'm trying to figure out what exactly means the status code errSecDuplicateItem for the SecItemAdd method when trying to add a certificate identity to the iOS keychain.
Reading the iOS documentation, it only says that this status code means the item is duplicated in the keychain, but what is the criteria to determine if an identity is a duplicate? Issuer name? Expiration date? Both?
If you read to the Mac OSX documentation, the discussion section for a similar method says the following:
If the certificate has already been added to the specified keychain,
the function returns errSecDuplicateItem and does not add another copy
to the keychain. The function looks at the certificate data, not at
the certificate object, to determine whether the certificate is a
duplicate. It considers two certificates to be duplicates if they have
the same primary key attributes.
I know there is a difference, I'm trying to save the certificate identity in the keychain, and this discussion is for the SecCertificateAddToKeychain method which saves the certificate; but I believe there is a connection.
What's the meaning of "primary keys attributes"?
I tried adding the same identity twice and of course I get the errSecDuplicateItem, but I'm afraid that users may get an error if they want to update the certificate in someway I'm not considering.
Any thoughts?
Thanks in advance
As far as I know, the keychain's primary key attributes aren't documented. However, according to a message from Ken McLeod, certificates are identified by their certificate type, issuer, and serial number. The keychain will refuse to accept more than one certificate that has the exact same values for these attributes.
Certificate authorities are required not to issue two certificates with the same serial number, so this error is unlikely to happen for your users. If you're generating certificates yourself, you must also make sure you do not accidentally reuse serials.
I am storing the key & secret required for API call in iOS keychain using Apple code
My key & secret keeps on changing after every call to API. So once they are changed I save them in Keychain again. So I am accessging the iOS keychain frequently.
My questions are
Is it ok to store key & secret in iOS keychain ?
Does Apple allow this as I am accessing the keychain everytime I need to call API ?
Sure. That's what it's there for.
You access your keychain every time you want to get in your car, right?
I am implementing SSL client authentication for our iPhone app and am using the app keychain to store the client identity (certificate + private key). After adding the items to the keychain, I am getting some unexpected results when using SecItemCopyMatching. Quick summary: I add exactly one SecIdentityRef to the keychain, but SecItemCopyMatching finds two afterwards. Let me start with the facts.
I am running my app on an iPod with iOS 4.3.5.
I have an empty app keychain to start with.
My certificates are all created using openssl and deployed to the iPod via a PKCS#12 file as an email attachment.
The PKCS#12 file contains:
Client certificate
Client CA certificate (issuer of the Client certificate)
Root CA certificate (issuer of the Client CA certificate)
RSA private key of the client certificate
SecPKCS12Import successfully imports the file and the resulting dictionary has the following content:
one "identity"
one "trust"
one "chain" (CFArray which holds the three certificates mentioned above)
Using SecItemAdd, I successfully add the "identity" to the keychain.
Next, I retrieve the "chain" array from the dictionary and attempt to add the certificates. In doing so, the first one fails with error errSecDuplicateItem. I assume this is because the first certificate is the client certificate and that it was already added to the keychain when I added the identity. The other two certificates are added without error.
Now, if I go back and use SecItemCopyMatching with these key/value pairs...
keys = {kSecClass, kSecReturnRef, kSecMatchLimit}
values = {kSecClassIdentity, kCFBooleanTrue, kSecMatchLimitAll}
...two identities are returned! Furthermore, if I retrieve the certificate for each (SecIdentityCopyCertificate) and then the summary (SecCertificateCopySubjectSummary), I see the both identities have the same certificate!
Lastly, when I try to clear the identities from the keychain (SecItemDelete), the first attempt is successful but the second fails with errSecItemNotFound.
It is clear from all the googling I have been doing that there are "issues" with the iOS keychain. However, I have not seen this reported; nor have I seen anything even remotely related.
So, my questions:
Am I using SecItemCopyMatching correctly?
When using SecItemCopyMatching to find identities in the keychain, how does it determine the identities that are present? Is this dynamic, or strictly based on how many SecIdentityRef items were added?
could this problem possibly be related to the certificates themselves? Note that despite this issue, I am still able to retrieve the first identity and certificates in order to respond to didReceiveAuthenticationChallenge.
I can post code and/or certificate dump, if needed.
Thanks in advance,
Ken Cross
Siemens Enterprise Networks.
As far as I can tell, you're using SecItemCopyMatching correctly.
SecIdentityRef items are not actually stored on the keychain; they are generated dynamically for certificates that have an associated private key available. Duplicate identities are indeed strange, and probably indicate a framework issue -- perhaps the framework gets confused by the duplicate in the second set of certificates? (Please do file a bug at bugreport.apple.com!) Does the duplicate identity go away when you restart the app?
On the other hand, duplicate identities won't necessarily lead to any actual problem. If you are worried that you might be using the wrong identity, simply ask SecItemAdd to provide a persistent reference to the one it "creates" and use that to retrieve the SecIdentityRef when needed.