Posts

Post not yet marked as solved
2 Replies
2.6k Views
Hi, When attempting to perform a credential registration, I constantly get the error Application with identifier <...> is not associated with domain <domain> I've verified the following: The file is present on the required URL path https://123.com/.well-known/apple-app-site-association { "webcredentials": { "apps": [ "<PREFIX>.bundleID" ] } } Added the Capabilities to my domain Confirmed that the CA is valid and there are no redirects. Am I missing something? My device is able to properly access the file
Posted Last updated
.
Post marked as solved
16 Replies
3.1k Views
At present, we have been receiving numerous reports from customers who integrate our SDK who have been encountering the failures (errSecItemNotFound) while trying to retrieve a key using SecItemCopyMatching. We are raising this query we are still in the midst of properly reproducing this issue though it has been reported to occur in several devices during the OS upgrade to the iOS 17 betas. This issue is still occurring in the latest iOS 17 beta 7. This issue was not present in previous iOS version. At present, we are of the conclusion that this issue is occurring randomly amongst devices that upgraded to the iOS 17 betas and it is not limited to older devices. What we believe is occurring is that: A key is created and stored into Keychain using SecItemAdd. The same key is queried at a later timepoint but encounters the error errSecItemNotFound. Our SDK then attempts to regenerate a new key for the same label and attribute to store it using SecItemAdd, but the system then reports errSecDuplicateItem at the key already exists. The workaround here includes a manual deletion of the said key. This issue seems to occur only during an OS upgrade to the iOS17 betas with the likelihood that the key was already present in Keychain prior to the upgrade. I share below the snippet relating to how this said key is generated, stored and retrieved. // Initial key is added // A random data of 32 bytes length is generated CFDataRef dataRef = <32bytes of data>; *attr = CFDictionaryCreateMutable(kCFAllocatorDefault, 0, &kCFTypeDictionaryKeyCallBacks, &kCFTypeDictionaryValueCallBacks); BREAK_IF_NULL(*attr); CFDictionarySetValue(*attr, kSecClass, kSecClassGenericPassword); CFStringRef aKey = CFStringCreateWithCString(kCFAllocatorDefault, "KEY_ACCOUNT", kCFStringEncodingUTF8); CFDictionaryAddValue(*attr, kSecAttrAccount, aKey); CFDictionarySetValue(*attr, kSecReturnData, kCFBooleanFalse); CFDictionarySetValue(*attr, kSecAttrAccessible, kSecAttrAccessibleAfterFirstUnlock); label = CFStringCreateWithFormat(NULL, NULL, CFSTR("A_LABEL")); CFDictionarySetValue(attr, kSecAttrService, label); CFDictionarySetValue(attr, kSecValueData, dataRef); SecItemAdd(attr); // Query for retrieval of key label = CFStringCreateWithFormat(NULL, NULL, CFSTR("A_LABEL")); CFDictionarySetValue(attributes, kSecAttrService, label); CFDictionarySetValue(attributes, kSecReturnData, kCFBooleanTrue); CFDictionarySetValue(attributes, kSecMatchLimit, limit); CFDictionarySetValue(attributes, kSecReturnAttributes, returnAttributes); osStatus = SecItemCopyMatching(attributes, result); if (errSecItemNotFound == osStatus) { } Please do let me know if more information could be useful. At present, we have ensured that the key generated are well-within the size limits and is stored simply as a kSecClassGenericPassword with limited access control to the key. Additionally, the query used was intended to be generalised to avoid encountering such occurrences.
Posted Last updated
.
Post not yet marked as solved
1 Replies
574 Views
Don't currently see a means of generating a registration/authentication request with this, do Passkeys currently support the handling/processing of client extensions as defined by WebAuthn? If so, is there a reference list of supported client extensions by Passkey? In particular, do Passkeys support creation of 'payment' credentials? https://www.w3.org/TR/secure-payment-confirmation/#sctn-payment-extension-registration extension
Posted Last updated
.
Post marked as solved
1 Replies
2.2k Views
Hi, When trying to enable this through Settings -> Developer, the Switch constantly turns back Off once leaving and returning to the page. Attempting to use the Platform authenticator according to the steps here Leads to the error: The operation couldn't be completed. Syncing platform authenticator must be enabled to register a platform public key credential; this can be enabled in Settings > Developer.
Posted Last updated
.
Post not yet marked as solved
0 Replies
412 Views
Hi, In DeviceCheck attestKey(_:clientDataHash:completionHandler:) is it possible to set the up and uv values if a separate user verification (via LAContext for e.g.) is completed outside theDCAppAttestService flow? Otherwise, the bit-values for up and uv are currently always returning false.
Posted Last updated
.
Post marked as solved
1 Replies
630 Views
Hi, Using the https://developer.apple.com/documentation/devicecheck I should be able to leverage the attest APIs to verify the integrity of my apps. However, I am constantly getting an unknownSystemFailure when attempting to attestKey(_:). This is after key pair generation and clientDataHash for the challenge. Please refer to the code sample. Would appreciate any feedback on how to get this to work.         let service = DCAppAttestService.shared         guard service.isSupported else {             return         }                  service.generateKey { (keyId, error) in             if error != nil {                 print("\(error!.localizedDescription)")                 return             }                          print(keyId!)             let challenge = "r6ctg89rt3948tc497tn4379".data(using: .utf8)             let hash = Data(SHA256.hash(data: challenge!))             service.attestKey(keyId!, clientDataHash: hash) { (attestationObject, error) in                 if error != nil {                     print("\(error!.localizedDescription)")                     return                 }                 print(attestationObject?.debugDescription)             }         }
Posted Last updated
.
Post marked as solved
2 Replies
859 Views
Hi, Using the https://developer.apple.com/documentation/devicecheck I should be able to leverage the attest APIs to verify the integrity of my apps. However, I am constantly getting an unknownSystemFailure when attempting to attestKey(_:). This is after key pair generation and clientDataHash for the challenge. Please refer to the code sample. Would appreciate any feedback on how to get this to work. let service = DCAppAttestService.shared      guard service.isSupported else {            return      }                service.generateKey { (keyId, error) in            if error != nil {                print("\(error!.localizedDescription)")                return            }                        print(keyId!)            let challenge = "r6ctg89rt3948tc497tn4379".data(using: .utf8)            let hash = Data(SHA256.hash(data: challenge!))            service.attestKey(keyId!, clientDataHash: hash) { (attestationObject, error) in                if error != nil {                    print("\(error!.localizedDescription)")                    return                }                print(attestationObject?.debugDescription)            }        }
Posted Last updated
.
Post not yet marked as solved
5 Replies
1.8k Views
When attempting to generate a key pair using SecKeyGeneratePair to be stored in SecureEnclave whilst also supplying an kSecAccessControlApplicationPassword, an error code 26276 (Internal Error) is returned.A corresponding log:[client] Unable to connect to com.apple.setoken even after retriesKeypair generation would work when:1) kSecAccessControlApplicationPassword is omitted2) keypair generation does not use the kSecAttrTokenIDSecureEnclaveSample code:NSError *secError = NULL; SecAccessControlCreateFlags flags = kSecAccessControlApplicationPassword ; SecAccessControlRef accessControlRef = SecAccessControlCreateWithFlags(kCFAllocatorDefault, kSecAttrAccessibleWhenUnlockedThisDeviceOnly, flags, (CFErrorRef*)(__bridge void*)secError); if (secError != NULL) { NSLog(@"ERRORRRRRR: %@", secError.localizedDescription); return; } CFMutableDictionaryRef privateKeyParams = CFDictionaryCreateMutable(kCFAllocatorDefault, 0, &amp;kCFTypeDictionaryKeyCallBacks, &amp;kCFTypeDictionaryValueCallBacks); CFDictionarySetValue(privateKeyParams, kSecAttrIsPermanent, kCFBooleanTrue); CFDictionarySetValue(privateKeyParams, kSecAttrAccessControl, accessControlRef); CFMutableDictionaryRef keygenParams = CFDictionaryCreateMutable(kCFAllocatorDefault, 0, &amp;kCFTypeDictionaryKeyCallBacks, &amp;kCFTypeDictionaryValueCallBacks); CFDictionarySetValue(keygenParams, kSecAttrTokenID, kSecAttrTokenIDSecureEnclave); CFDictionarySetValue(keygenParams, kSecAttrKeyType, kSecAttrKeyTypeEC); int size = 256; CFNumberRef sizeInBitsNumberRef = CFNumberCreate(kCFAllocatorDefault, kCFNumberIntType, &amp;size); CFDictionarySetValue(keygenParams, kSecAttrKeySizeInBits, sizeInBitsNumberRef); CFDictionarySetValue(keygenParams, kSecClass, kSecClassKey); CFDictionarySetValue(keygenParams, kSecPrivateKeyAttrs, privateKeyParams); CFDictionarySetValue(keygenParams, kSecAttrLabel , (__bridge CFStringRef)@"abcde"); _context = [[LAContext alloc]init]; CFDictionarySetValue(keygenParams, kSecUseAuthenticationContext, (__bridge const void *)(_context)); SecKeyRef publicKey = NULL; OSStatus generationStatus = SecKeyGeneratePair(keygenParams, &amp;publicKey, NULL); NSLog(@"Generation Status: %d", (int) generationStatus);Usage of the combination flags below would fail as well: SecAccessControlCreateFlags flags = kSecAccessControlApplicationPassword | kSecAccessControlAnd | kSecAccessControlPrivateKeyUsage ;Works as intended on existing iOS. Tested on iOS 13 beta 2.Any feedback / help / suggestion is much appreciated! Filed a Feedback too.
Posted Last updated
.