Why does the following code generate a public key that can't be parsed by openssl? import Security import CryptoKit func generateKeys() throws -> (privateKey: SecKey, publicKey: SecKey) { let query: [String: Any] = [ kSecAttrKeyType as String: kSecAttrKeyTypeECSECPrimeRandom, kSecAttrKeySizeInBits as String: 256, kSecAttrIsPermanent as String: false ] var error: Unmanaged<CFError>? guard let privateKey = SecKeyCreateRandomKey(query as CFDictionary, &error) else { throw error!.takeRetainedValue() } let publicKey = SecKeyCopyPublicKey(privateKey)! return (privateKey, publicKey) } extension SecKey { func exportBase64EncodedKey() -> String { var error: Unmanaged<CFError>? guard let data = SecKeyCopyExternalRepresentation(self, &error) else { fatalError("Failed to export key: \(error!.takeRetainedValue())") } return (data as Data).base64EncodedString(options: [.lineLength64Characters]) } } func printPublicKey() { let keyPair = try! generateKeys() let encodedPublicKey = keyPair.publicKey.exportBase64EncodedKey() var header = "-----BEGIN PUBLIC KEY-----" var footer = "-----END PUBLIC KEY-----" var pemKey = "\(header)\n\(encodedPublicKey)\n\(footer)\n" print(pemKey) } printPublicKey() when parsing the key I get this: openssl pkey -pubin -in new_public_key.pem -text -noout Could not find private key of Public Key from new_public_key.pem 404278EC01000000:error:1E08010C:DECODER routines:OSSL_DECODER_from_bio:unsupported:crypto/encode_decode/decoder_lib.c:102:No supported data to decode. Replacing kSecAttrKeyTypeECSECPrimeRandom with kSecAttrKeyTypeRSA and a bigger key size (e.g. 2048) gives me a working public key that can be parsed by Openssl. Thanks!

We are working with an iOS app where we have enabled the “Generate Debug Symbols” setting to true in Xcode. As a result, the .dSYM files are generated and utilized in Firebase Crashlytics for crash reporting. However, we received a note in our Vulnerability Assessment report indicating a potential security concern. The report mentions that the .ipa file could be reverse-engineered due to the presence of debug symbols, and that such symbols should not be included in a released app. We could not find any security-related information about this flag, “Generate Debug Symbols,” in Apple’s documentation. Could you please clarify if enabling the “Generate Debug Symbols” flag in Xcode for a production app creates any security vulnerabilities, such as the one described in the report? The report mentions the following vulnerability: TEST-0219: Testing for Debugging Symbols The concern raised is that debugging symbols, while useful for crash symbolication, may be leveraged to reverse-engineer the app and should not be present in a production release. Your prompt confirmation on this matter would be greatly appreciated. Thank you in advance for your assistance.

Hey all, Question for the masses.... Does the Yubikey authentication have a OS dependency and it only works with a stable, public OS? Does Azure/Okta/Yubikey beta OS26? My CEO installed iPadOS 26 on his iPad and was not able to authenticate via Yubikey into our company environment. I ran the same scenario on my iPad using iPadOS 26 and I had the same results. Downgrading to iPAdOS doesn't pose these issues. I'm assuming something isn't fine-tuned yet?

I modified the system.login.screensaver rule in the authorization database to use "authenticate" instead of "use-login-window-ui" to display a custom authentication plugin view when the screensaver starts or the screen locks. However, I noticed an issue when the "Require Password after Display is Turned Off" setting is set to 5 minutes in lock screen settings: If I close my Mac’s lid and reopen it within 5 minutes, my authentication plugin view is displayed as expected. However, the screen is not in a locked state—the desktop remains accessible, and the black background that typically appears behind the lock screen is missing. This behavior differs from the default lock screen behavior, where the screen remains fully locked, and the desktop is hidden. Has anyone encountered this issue before? Is there a way to ensure the screen properly locks when using authenticate in the screensaver rule?

I’m implementing Passkey registration on iOS using ASAuthorizationPlatformPublicKeyCredentialProvider. On the server side, I’m using a WebAuthn library that throws the error UnexpectedRPIDHash: Unexpected RP ID hash during verifyRegistrationResponse(). Domain: pebblepath.link (publicly routable, valid SSL certificate, no warnings in Safari) Associated Domains in Xcode**: webcredentials:pebblepath.link AASA file: { "applinks": { "apps": [] }, "webcredentials": { "apps": [ "H33XH8JMV6.com.reactivex.pebblepath" ] } } Xcode Configuration: Team ID: H33XH8JMV6 Bundle ID: com.reactivex.pebblepath Associated Domains: webcredentials:pebblepath.link Logs: iOS clientDataJSON shows "origin": "https://pebblepath.link". Server logs confirm expectedOrigin = "https://pebblepath.link" and expectedRPID = "pebblepath.link". Despite this, the server library still errors out: finishRegistration error: UnexpectedRPIDHash. I’ve verified that: The domain has a valid CA-signed SSL cert (no Safari warnings). The AASA file is reachable at https://pebblepath.link/.well-known/apple-app-site-association. The app’s entitlements match H33XH8JMV6.com.reactivex.pebblepath. I’ve removed old passkeys from Settings → Passwords on the device and retried fresh. I’m testing on a real device with iOS 16+; I am using a Development provisioning profile, but that shouldn’t cause an RP ID mismatch as long as the domain is valid. Every log indicates that the domain and origin match exactly, but the WebAuthn library still throws UnexpectedRPIDHash, implying iOS is embedding a different (or unrecognized) RP ID hash in the credential. Has anyone else encountered this with iOS passkeys and a valid domain/AASA setup? Is there an extra step needed to ensure iOS recognizes the domain for passkey registration? Any guidance or insights would be greatly appreciated!

Our business model is to identify Frauds using our advanced AI/ML model. However, in order to do so we need to collect many device information which seems to be ok according to https://developer.apple.com/app-store/user-privacy-and-data-use/ But it's also prohibited to generate a fingerprint, so I need more clarification here. Does it mean I can only use the data to identify that a user if either fraud or not but I cannot generate a fingerprint to identify the device? If so, I can see many SKD in the market that generates Fingerprints like https://fingerprint.com/blog/local-device-fingerprint-ios/ and https://shield.com/?

Greetings, We are struggling to implement device binding according to your documentation. We are generation a nonce value in backend like this: public static String generateNonce(int byteLength) { byte[] randomBytes = new byte[byteLength]; new SecureRandom().nextBytes(randomBytes); return Base64.getUrlEncoder().withoutPadding().encodeToString(randomBytes); } And our mobile client implement the attestation flow like this: @implementation AppAttestModule - (NSData *)sha256FromString:(NSString *)input { const char *str = [input UTF8String]; unsigned char result[CC_SHA256_DIGEST_LENGTH]; CC_SHA256(str, (CC_LONG)strlen(str), result); return [NSData dataWithBytes:result length:CC_SHA256_DIGEST_LENGTH]; } RCT_EXPORT_MODULE(); RCT_EXPORT_METHOD(generateAttestation:(NSString *)nonce resolver:(RCTPromiseResolveBlock)resolve rejecter:(RCTPromiseRejectBlock)reject) { if (@available(iOS 14.0, *)) { DCAppAttestService *service = [DCAppAttestService sharedService]; if (![service isSupported]) { reject(@"not_supported", @"App Attest is not supported on this device.", nil); return; } NSData *nonceData = [self sha256FromString:nonce]; NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults]; NSString *savedKeyId = [defaults stringForKey:@"AppAttestKeyId"]; NSString *savedAttestation = [defaults stringForKey:@"AppAttestAttestationData"]; void (^resolveWithValues)(NSString *keyId, NSData *assertion, NSString *attestationB64) = ^(NSString *keyId, NSData *assertion, NSString *attestationB64) { NSString *assertionB64 = [assertion base64EncodedStringWithOptions:0]; resolve(@{ @"nonce": nonce, @"signature": assertionB64, @"deviceType": @"IOS", @"attestationData": attestationB64 ?: @"", @"keyId": keyId }); }; void (^handleAssertion)(NSString *keyId, NSString *attestationB64) = ^(NSString *keyId, NSString *attestationB64) { [service generateAssertion:keyId clientDataHash:nonceData completionHandler:^(NSData *assertion, NSError *assertError) { if (!assertion) { reject(@"assertion_error", @"Failed to generate assertion", assertError); return; } resolveWithValues(keyId, assertion, attestationB64); }]; }; if (savedKeyId && savedAttestation) { handleAssertion(savedKeyId, savedAttestation); } else { [service generateKeyWithCompletionHandler:^(NSString *keyId, NSError *keyError) { if (!keyId) { reject(@"keygen_error", @"Failed to generate key", keyError); return; } [service attestKey:keyId clientDataHash:nonceData completionHandler:^(NSData *attestation, NSError *attestError) { if (!attestation) { reject(@"attestation_error", @"Failed to generate attestation", attestError); return; } NSString *attestationB64 = [attestation base64EncodedStringWithOptions:0]; [defaults setObject:keyId forKey:@"AppAttestKeyId"]; [defaults setObject:attestationB64 forKey:@"AppAttestAttestationData"]; [defaults synchronize]; handleAssertion(keyId, attestationB64); }]; }]; } } else { reject(@"ios_version", @"App Attest requires iOS 14+", nil); } } @end For validation we are extracting the nonce from the certificate like this: private static byte[] extractNonceFromAttestationCert(X509Certificate certificate) throws IOException { byte[] extensionValue = certificate.getExtensionValue("1.2.840.113635.100.8.2"); if (Objects.isNull(extensionValue)) { throw new IllegalArgumentException("Apple App Attest nonce extension not found in certificate."); } ASN1Primitive extensionPrimitive = ASN1Primitive.fromByteArray(extensionValue); ASN1OctetString outerOctet = ASN1OctetString.getInstance(extensionPrimitive); ASN1Sequence sequence = (ASN1Sequence) ASN1Primitive.fromByteArray(outerOctet.getOctets()); ASN1TaggedObject taggedObject = (ASN1TaggedObject) sequence.getObjectAt(0); ASN1OctetString nonceOctet = ASN1OctetString.getInstance(taggedObject.getObject()); return nonceOctet.getOctets(); } And for the verification we are using this method: private OptionalMethodResult<Void> verifyNonce(X509Certificate certificate, String expectedNonce, byte[] authData) { byte[] expectedNonceHash; try { byte[] nonceBytes = MessageDigest.getInstance("SHA-256").digest(expectedNonce.getBytes()); byte[] combined = ByteBuffer.allocate(authData.length + nonceBytes.length).put(authData).put(nonceBytes).array(); expectedNonceHash = MessageDigest.getInstance("SHA-256").digest(combined); } catch (NoSuchAlgorithmException e) { log.error("Error while validations iOS attestation: {}", e.getMessage(), e); return OptionalMethodResult.ofError(deviceBindError.getChallengeNotMatchedError()); } byte[] actualNonceFromCert; try { actualNonceFromCert = extractNonceFromAttestationCert(certificate); } catch (Exception e) { log.error("Error while extracting nonce from certificate: {}", e.getMessage(), e); return OptionalMethodResult.ofError(deviceBindError.getChallengeNotMatchedError()); } if (!Arrays.equals(expectedNonceHash, actualNonceFromCert)) { return OptionalMethodResult.ofError(deviceBindError.getChallengeNotMatchedError()); } return OptionalMethodResult.empty(); } But the values did not matched. What are we doing wrong here? Thanks.

I'm working on a Password Manager app that integrates with the AutoFill Credential Provider to provide stored passwords and OTPs to the user within Safari and other apps. Password AutoFill works perfectly. I'm unable to get iOS to register that the app supports OTPs though. I've followed the Apple documentation here: https://developer.apple.com/documentation/authenticationservices/providing-one-time-passcodes-to-autofill and added "ProvidesOneTimeCodes" to the AutoFill extension's Info.plist, but iOS just doesn't seem to notice the OTP support. &lt;key&gt;ASCredentialProviderExtensionCapabilities&lt;/key&gt; &lt;dict&gt; &lt;key&gt;ProvidesOneTimeCodes&lt;/key&gt; &lt;true/&gt; &lt;key&gt;ProvidesPasswords&lt;/key&gt; &lt;true/&gt; &lt;/dict&gt; Any help would be greatly appreicated!

Hi Team, How can we fetch the macOS password requirement(for setting a new password) that are inforce during login for users? Is there a way to get this info in swift programming?

In the hopes of saving others time, the updated demo project (i.e. the new Shiny) can be found from the video 'Resources' section under 'Performing fast account creation with passkeys'. The beta documentation can also be found from there. All of the new functionality is available only on *OS 26 at this time.

The Passwords App is accessing websites found in the ASCredentialIdentityStore associated with a 3rd Party password management app (SamuraiSafe). This behaviour appears to be associated with looking up website favicons in order to display in Passwords. However the websites contacted are not stored in the Passwords App/iCloud KeyChain - only the 3rd Party password management app (SamuraiSafe). This is effectively leaking website information stored in the 3rd Party password management app. I first noticed this behaviour on macOS, and it appears to happen every 8 days. Today it was seen on iOS. The behaviour is revealed through the App Privacy Report on iOS (and LittleSnitch on macOS). I would not be surprised to see the Passwords App do this for websites saved in the Passwords App/iCloud KeyChain, however I believe it should not be arbitrarily testing every website found in the ASCredentialIdentityStore as reference to that website url should be entirely under the control of the end user. See attached screenshots from App Privacy Report. Filed bug with Apple: FB16682423

We have a macOS app that has a Photos Extension, which shares documents with the app via an app group container. Historically we used to have an iOS-style group identifier (group.${TeamIdentifier}${groupName}), because we were lead by the web interface in the developer portal to believe this to be the right way to name groups. Later with the first macOS 15 betas last year there was a bug with the operating system warning users, our app would access data from different apps, but it was our own app group container directory. Therefore we added a macOS-style group identifier (${TeamIdentifier}${groupName}) and wrote a migration of documents to the new group container directory. So basically we need to have access to these two app group containers for the foreseeable future. Now with the introduction of iOS-style group identifiers for macOS, Xcode Cloud no longer archives our app for TestFlight or AppStore, because it complains: ITMS-90286: Invalid code signing entitlements - Your application bundle’s signature contains code signing entitlements that aren’t supported on macOS. Specifically, the “[group.${TeamIdentifier}${groupName}, ${TeamIdentifier}${groupName}]” value for the com.apple.security.application-groups key in isn’t supported. This value should be a string or an array of strings, where each string is the “group” value or your Team ID, followed by a dot (“.”), followed by the group name. If you're using the “group” prefix, verify that the provisioning profile used to sign the app contains the com.apple.security.application-groups entitlement and its associated value(s). We have included the iOS-style group identifier in the provisioning profile, generated automatically, but can't do the same for the macOS-style group identifier, because the web interface only accepts identifiers starting with "group". How can we get Xcode Cloud to archive our app again using both group identifiers? Thanks in advance

I am currently working on ways my application which would monitor the dlopen() and dlsym() calls made on macOS. In the current list of events endpoint security framework provides, I don't see a relevant event which would give me this information. Are there any alternate ways we can get these events on macOS?

I’d like to confirm something regarding the hosting of the apple-app-site-association (AASA) file. We have a server that publicly hosts the AASA file and is accessible globally. However, this server sits behind an additional security layer (a security server/reverse proxy). My question is: Will this security layer affect Apple’s ability to access and validate the AASA file for Universal Links or App Clips? Are there specific requirements (e.g. headers, redirects, TLS versions, etc.) that we need to ensure the security server does not block or modify? Any guidance or best practices would be appreciated. Thanks!

Step1. Update system.login.screensaver authorizationdb rule to use “authenticate-session-owner-or-admin”( to get old SFAutorizationPluginView at Lock Screen ). Here I will use my custom authorization plugin. Step 2. Once the rule is in place, logout and login, now click on Apple icon and select “Lock Screen”. Is there a way programmatically to update the Lock Icon and the test getting displayed on the first Unlock screen? When I write a custom authorisation plug-in, I am getting control of the text fields and any consecutive screen I add from there on. But all I want is to update the lock icon and text fields on 1st unlock display itself. Can you please suggest how I can achieve this? Here is the screenshot with marked areas I am looking control for.

Hi, We came accross with 2 devices, iPhone 12 and iphone16 pro. the both have same device code. Both the devices have same apple id and belongs to same user I had understanding that device codes are unique to device. How this can happen? Any remediation? Thanks, Veena

Hi, I’d like to confirm something regarding the hosting of the apple-app-site-association (AASA) file. We have a server that publicly hosts the AASA file and is accessible globally. However, this server sits behind an additional security layer (a security server/reverse proxy). My question is: Will this security layer affect Apple’s ability to access and validate the AASA file for Universal Links or App Clips? Are there specific requirements (e.g. headers, redirects, TLS versions, etc.) that we need to ensure the security server does not block or modify? Any guidance or best practices would be appreciated.

Title: Sporadical - Permissions Not Cleared After App Uninstallation on iOS18 I install and launch my private MAUI App I ask for example Bluetooth permissions (can be any other permission) I tap Allow button on native settings (or Don't Allow) I unistall app from real phone (we can wait for a while) I install and launch My Private MAUI App I ask for example Bluetooth permissions &lt;- here is an issue. Bluetooth is already granted, so I cannot ask for it again. Occurrence: This issue occurs inconsistently: On iOS 18.5: approximately 5 out of 10 times On iOS 17: approximately 1 out of 50 times Tested using my automated system using Appium latest. After each scenario I unistall app using: "mobile: removeApp" with bundleId

I’m considering storing some sensitive information in the userID field of a passkey, as described in the createCredentialRegistrationRequest method.(link to method). I'm aware of the largeBlob extension introduced in iOS 17+, but it doesn't meet my needs since I want to create a cross-platform passkey that can be used across various devices — and currently, not many devices support the largeBlob extension. According to W3C documentation, the userID field is not considered private information and can be displayed to the user without requiring a verification process. Based on my understanding, it's also not encrypted, which means it might be accessible with physical access to the device. So here are my questions: How do Apple devices (especially iPhones) handle the userID field in their authenticators? Is it possible to access the userID without user verification, as permitted by the W3C specification? Are there any alternative methods to access the userID value stored in a passkey on Apple devices?

WebAuthn Level 3 § 5.1.3 Step 22 Item 4 states the steps a user agent MUST follow when "conditional" mediation is used in conjunction with required user verification: Let userVerification be the effective user verification requirement for credential creation, a Boolean value, as follows. If pkOptions.authenticatorSelection.userVerification is set to required If options.mediation is set to conditional and user verification cannot be collected during the ceremony, throw a ConstraintError DOMException. Let userVerification be true. On my iPhone 15 Pro Max running iOS 18.5, Safari + Passwords does not exhibit this behavior; instead an error is not reported and user verification is not performed (i.e., the UV bit is 0). Per the spec this results in a registration ceremony failure on the server which is made all the more "annoying" since the credential was created in Passwords forcing a user to then delete the credential. : If the Relying Party requires user verification for this registration, verify that the UV bit of the flags in authData is set. In contrast when I use Google Password Manager + Chrome on a Samsung Galaxy S24 running Android 15, user verification is enforced and the UV bit is 1. Either the UV bit should be 1 after enforcing user verification or an error should be thrown since user verification cannot be performed.