Post not yet marked as solved
Snyk and Fortify (3rd party security scanning software) scans have flagged our auth code when using evaluatePolicy for LaContext. Our app is an iOS only app.
"Avoid using evaluatePolicy for local user authentication. The API can be hooked and thus the return value can be changed leading to a potential authentication bypass on jailbroken devices. Consider using iOS keychain APIs."
Has anyone encountered this issue in their security scans and we're you able to mediate with the suggested fix using the keychain APIs.
I'm developing a macOS app that will usually be running in a non-admin user environment. But I have a screen of the app that I would like to secure so as to make it only accessible to admin users (think: parents).
I can't figure out what API I'm supposed to use to prompt for specifically an ADMIN user. I've tried googling a ton, but I must be trying the wrong search terms, because I can't find anything.
The API for LAContext() is almost what I want, I can get it to prompt for a password, but it seems to ONLY work for the current logged in user. I can't find a policy type that allows me to specify something like .adminUserAuthentication. It seems like LAContext() was not meant for this use case. But then, what is the right API to call to do this?
Can someone point me in the right direction?
I don't want to limit myself to this only working for supervised users, or users with parental controls turned on, I would like a generic solution. I've seen apps that prompt for admin credentials on regular non-admin users, so it must be possible, right?
Hi,
I want to implement FIDO based biometric authentication in our app. I don't want to use passkeys because they are only compatible with iOS 16 and higher.
Is there a way to use it through the SFSafariViewController, a web view, ASWebAuthenticationSession or any another method?
Post not yet marked as solved
On iOS 17 beta 1 or previous iOS versions, the [LAContext canEvaluatePolicy:error:] method works well without requiring the NSFaceIDUsageDescription key in the plist.
However, when iOS 17 beta 2 (21A5268h) released, we notice some crash issues related to TCC_CRASHING_DUE_TO_PRIVACY_VIOLATION. The crash termination reason suggests that an NSFaceIDUsageDescription key must be included in the plist file, providing a string value explaining to the user how the app uses Face ID data. It is important to note that we do not actually require this permission.
It is challenging to reproduce this issue, as it occurs sporadically without clear triggering conditions. These problems are likely associated with changes made to the LocalAuthentication or TCC frameworks within Apple's beta system.
Thread 1:
0 libsystem_kernel.dylib 0x00000001e6a68ba0 semaphore_wait_trap + 8
1 libdispatch.dylib 0x00000001a8a3e89c _dispatch_sema4_wait + 28 (lock.c:139)
2 libdispatch.dylib 0x00000001a8a3ef4c _dispatch_semaphore_wait_slow + 132 (semaphore.c:132)
3 LocalAuthentication 0x00000001d51349b8 -[LAClient _checkIdResultForTCC:synchronous:error:retryBlock:finally:] + 500 (LAClient.m:383)
4 LocalAuthentication 0x00000001d5135828 __64-[LAClient evaluatePolicy:options:uiDelegate:synchronous:reply:]_block_invoke_2 + 180 (LAClient.m:547)
5 CoreFoundation 0x00000001a0dd65b4 __invoking___ + 148
6 CoreFoundation 0x00000001a0d83a0c -[NSInvocation invoke] + 428 (NSForwarding.m:3399)
7 Foundation 0x000000019fdffdf4 __NSXPCCONNECTION_IS_CALLING_OUT_TO_REPLY_BLOCK__ + 16 (NSXPCConnection.m:170)
8 Foundation 0x000000019fdd1f64 -[NSXPCConnection _decodeAndInvokeReplyBlockWithEvent:sequence:replyInfo:] + 520 (NSXPCConnection.m:316)
9 Foundation 0x00000001a050eb5c __88-[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:]_block_invoke_5 + 188 (NSXPCConnection.m:1662)
10 Foundation 0x000000019fd965fc -[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:] + 2244 (NSXPCConnection.m:1679)
11 CoreFoundation 0x00000001a0d82c0c ___forwarding___ + 1008 (NSForwarding.m:3634)
12 CoreFoundation 0x00000001a0de79d0 _CF_forwarding_prep_0 + 96
13 LocalAuthentication 0x00000001d513573c __64-[LAClient evaluatePolicy:options:uiDelegate:synchronous:reply:]_block_invoke + 204 (LAClient.m:546)
14 LocalAuthentication 0x00000001d5134fe4 __47-[LAClient _performSynchronous:callId:finally:]_block_invoke + 504 (LAClient.m:446)
15 libdispatch.dylib 0x00000001a8a3e300 _dispatch_client_callout + 20 (object.m:561)
16 libdispatch.dylib 0x00000001a8a4dce8 _dispatch_sync_invoke_and_complete + 56 (queue.c:1071)
17 LocalAuthentication 0x00000001d5134dac -[LAClient _performSynchronous:callId:finally:] + 196 (LAClient.m:465)
18 LocalAuthentication 0x00000001d5135634 -[LAClient evaluatePolicy:options:uiDelegate:synchronous:reply:] + 296 (LAClient.m:545)
19 LocalAuthentication 0x00000001d513f38c -[LAContext _evaluatePolicy:options:synchronous:reply:] + 188 (LAContext.m:373)
20 LocalAuthentication 0x00000001d513f084 -[LAContext _evaluatePolicy:options:log:cid:synchronous:reply:] + 388 (LAContext.m:348)
21 LocalAuthentication 0x00000001d5124268 -[LAContext _evaluatePolicy:options:log:cid:error:] + 272 (LAContext.m:402)
22 LocalAuthentication 0x00000001d5123fec -[LAContext canEvaluatePolicy:error:] + 276 (LAContext.m:548)
....
Thread 24 Crashed:
0 libsystem_kernel.dylib 0x00000001e6a78394 __terminate_with_payload + 8
1 libsystem_kernel.dylib 0x00000001e6a9aca0 abort_with_payload_wrapper_internal + 136 (terminate_with_reason.c:106)
2 libsystem_kernel.dylib 0x00000001e6a9acb4 abort_with_payload + 16 (terminate_with_reason.c:124)
3 TCC 0x00000001c1471928 __TCC_CRASHING_DUE_TO_PRIVACY_VIOLATION__ + 172 (TCC.c:563)
4 TCC 0x00000001c14720a0 __TCCAccessRequest_block_invoke_7 + 600 (TCC.c:707)
5 TCC 0x00000001c146f154 __tccd_send_message_block_invoke + 624 (TCC.c:0)
6 libxpc.dylib 0x0000000208d09b14 _xpc_connection_reply_callout + 116 (serializer.c:119)
7 libxpc.dylib 0x0000000208cfc484 _xpc_connection_call_reply_async + 80 (connection.c:881)
8 libdispatch.dylib 0x00000001a8a3e380 _dispatch_client_callout3 + 20 (object.m:587)
9 libdispatch.dylib 0x00000001a8a5bb04 _dispatch_mach_msg_async_reply_invoke + 344 (mach.c:3102)
10 libdispatch.dylib 0x00000001a8a50d40 _dispatch_root_queue_drain_deferred_item + 336 (queue.c:7011)
11 libdispatch.dylib 0x00000001a8a50628 _dispatch_kevent_worker_thread + 500 (queue.c:6484)
12 libsystem_pthread.dylib 0x0000000208ca8e88 _pthread_wqthread + 344 (pthread.c:2635)
13 libsystem_pthread.dylib 0x0000000208ca8bf0 start_wqthread + 8
My end goal is to use eciesEncryptionCofactorX963SHA256AESGCM with a key generated on the Secure Enclave using CryptoKit, that requires Biometric Authentication.
CryptoKit does not implement the ECIES encryption algorithms, so my goal was to fall back to the Security framework.
The public key can be easily converted to a SecKey because it implements x963Representation which can then be imported as follows:
let enclaveSecKey: SecKey = SecKeyCreateWithData(enclaveKey.x963Representation as CFData, [
kSecAttrKeyType: kSecAttrKeyTypeECSECPrimeRandom,
kSecAttrKeyClass: kSecAttrKeyClassPublic,
kSecAttrKeySizeInBits: 256
] as [String: Any] as CFDictionary, nil),
I have everything working except the code to decrypt with the private key. Naturally, the Secure Enclave does not expose the private key - as is its design - rather some kind of token?
I did read the Keychain documentation which notes that it is not possible to simply obtain an x963Representation of the private key (as it's a custom representation returned by the Secure Enclave).
However, my ultimate question is this: can one convert the Secure Enclave representation into something that can be used as a SecKey for encryption/decryption (without necessarily being stored in the Keychain - i.e., 'correct') as it seems both CryptoKit and Security have a means of representing the private key token returned by the Secure Enclave? (Or is one's only recourse to use the Security framework for generating and storing the keys too?)
I have also tried this code to create a SecKey representation, having retrieved the GenericPasswordConvertible out of the keychain (note the use of kSecAttrTokenID: kSecAttrTokenIDSecureEnclave) with the aforementioned goal of loading the Secure Enclave's private token as a SecKey:
let enclaveSecKey: SecKey = SecKeyCreateWithData(enclaveKey.rawRepresentation as CFData, [
kSecAttrKeyType: kSecAttrKeyTypeECSECPrimeRandom,
kSecAttrKeyClass: kSecAttrKeyClassPrivate,
kSecAttrTokenID: kSecAttrTokenIDSecureEnclave,
kSecAttrAccessible: kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,
kSecUseAuthenticationContext: try await createAuthContext(
reason: "Decrypt data",
fallbackTitle: "Enter your device password to decrypt data",
mustEvaluate: true
),
kSecAttrIsPermanent: true,
kSecAttrIsExtractable: false,
kSecAttrSynchronizable: false,
kSecAttrKeySizeInBits: 256,
kSecAttrAccessControl: SecAccessControlCreateWithFlags(
nil,
kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,
[.biometryAny, .privateKeyUsage],
&cfSecKeyCreateError
)!
] as [String: Any] as CFDictionary, nil)
This works, in and of itself, (i.e., it loads without error and cfSecKeyCreateError is nil, however when I try SecSecKeyCopyPublicKey I get a different, incorrect public key and - naturally, I suppose - if I attempt to decrypt data with the private key that fails with:
Optional(Swift.Unmanaged<__C.CFErrorRef>(_value: Error Domain=NSOSStatusErrorDomain Code=-50 "ECIES: Failed to aes-gcm decrypt data (err -69)" UserInfo={numberOfErrorsDeep=0, NSDescription=ECIES: Failed to aes-gcm decrypt data (err -69)}))
Post not yet marked as solved
Hi, TO obtain TOKEN during the development process of MFI findmy products.I submitted a CSR file (generated by the WIN7 KEYTOOLS command) in the Software Authentication Certificate Request on the MFI Portal, and the system rejected it and prompted the server unknown. Error, the reason is "server unable to process the csr request". What is the reason and how to solve it? (By the way, previously rejected 10 times due to a company name mismatch)
Post not yet marked as solved
I'm writing an application which is using a custom right to require that a user authenticate as an admin to access a specific part of my app, and I'm struggling with cases where smart card usage is enforced.
The simplest way is to use a custom right, but the dialog presented to the user gives no feedback that smartcard is required should they try to authenticate with password when the token isn't connected (i.e. a yubikey for example isn't plugged in to the USB bus)
Instead, in this case, the authentication dialog simply wobbles as though they hadn't entered the correct password.
It looks like the same is true of default macOS dialogs too such as unlocking a preference pane.
I've looked around the API docks to see if there's any other way I can do this, but I don't seem to find any API methods that explicitly state I want the user to authenticate with a PIV token?
Do I need to use CryptoTokenKit to send raw ADPU commands to a connected token to achieve this?
I was hoping I could use LAContext from LocalAuthentication to do this as it supports watch/fingerprint auth, but again I couldn't see any obvious sign of support for smartcards.
Post not yet marked as solved
Apple's guidance in the Human Interface Guidelines has always been: "In general, avoid offering an app-specific setting for opting in to biometric authentication. People enable biometric authentication at the system level, so presenting an in-app setting is redundant and could be confusing."
However, FaceID and TouchID behave differently.
With FaceID, a user may configure whether to enable FaceID on a per app basis in system settings, so an in-app setting is redundant and potentially confusing.
With TouchID, a user cannot configure whether to enable TouchID on a per app basis in system settings.
What is Apple's recommendation of a UX for allowing a user to enable TouchID (to log in to the app) on a per app basis. Is the developer expected to provide an in-app setting for TouchID but not FaceID?
Post not yet marked as solved
I would like to use Biometrics authentication when my iOS app comes back from background. I added this process but it always returns "success".
Is this iOS Biometrics authentication spec?
If not, please let me know how to do.
Post not yet marked as solved
I am using Xcode 13, Swift 5.5, & SwiftUI. I am trying to create a login page for an app. The user data is stored in Core Data.
I cannot find a current tutorial or post explaining how to do this. Can someone explain to me how to create a login page that verifies credentials entered into a form match values that are stored in CoreData entity?
Obviously macOS allows to leave the password field blank so users can set the blank password. But in this case LAContext evaluatePolicy never allow authentication with empty password unlike System Settings(System Preferences). And canEvaluatePolicy produces true on macOS Catalina and BigSur. (while macOS Ventura returns false with "Passcode is not set." NSError)
I tested with Intel macOS 11.7 BigSur and M1 macOS 13 Ventura, they work differently but they both failed to authenticate. The detail is as follows:
[Intel / macOS 11.7 BigSur] & [Intel / macOS 10.15.7 Catalina]
When evaluatePolicy called, the password window popped up. If I just click 'OK' button, the password window closed and popped up again right away. And clicking 'OK' again produces an error:
(ACMContextVerifyPolicyEx returned 0, still requesting 1:1, 3:1, 15:1 (on context 9c1ee373))
And canEvaluatePolicy with LAPolicyDeviceOwnerAuthentication returns true on these environments..
[M1 / macOS 13 Ventura]
When evaluatePolicy called, the password window doesn't pop up with an error: (passcode is not set.)
Is this a bug or is there any way that I can figure out this case?
I have integrated the face ID authentication using LAPolicy.deviceOwnerAuthentication of LocalAuthentication
Is there a way to determine whether the user disabled the faceID in the app settings programatically ?
Post not yet marked as solved
I am using deviceOwnerAuthentication policy of local authentication for biometric authentication. If user have not added any fingerprints or faceID, is there a method to determine it. LABiometricType is only checking if the device can support the touch/face ID. Couldn't find a method to determine if the user have added it.
kliedl64.
