We recently deployed Attestation on our application, and for a majority of the 40,000 users it works well. We have about six customers who are failing attestation. In digging through debug logs, we're seeing this error "iOS assertion verification failed. Unauthorized access attempted." We're assuming that the UUID is blocked somehow on Apple side but we're stumped as to why. We had a customer come in and we could look at the phone, and best we can tell it's just a generic phone with no jailbroken or any malicious apps. How can we determine if the UUID is blocked?
General
RSS for tagPrioritize user privacy and data security in your app. Discuss best practices for data handling, user consent, and security measures to protect user information.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
Hi everyone,
I’m currently developing an MFA authorization plugin for macOS and am looking to implement a passwordless feature. The goal is to store the user's password securely when they log into the system through the authorization plugin.
However, I’m facing an issue with using the system's login keychain (Data Protection Keychain), as it runs in the user context, which isn’t suitable for my case. Therefore, I need to store the password in a file-based keychain instead.
Does anyone have experience or code snippets for objective-c for securely storing passwords in a file-based keychain (outside of the login keychain) on macOS? Specifically, I'm looking for a solution that would work within the context of a system-level authorization plugin.
Any advice or sample code would be greatly appreciated!
Thanks in advance!
Under iOS 18.0.1, I can't do any development that uses HTTPS, because I can't authorize my generated certificates on my phone. This was not a problem in the past.
Normally you AirDrop a root certificate authority to your phone, install the "profile" for it, and then trust it in Settings / General / About / Certificate Trust Authority. Then you can connect to another server on your network that's using the accompanying certificates.
But after sucessfully installing two profiles on my phone, neither shows up in Certificate Trust Authority. Anybody else seeing this?
This problem, in combo with this one (which prevents running on my Mac as an iPad app) has completely halted my project.
I've found reports of this problem that blamed an empty "common name" field in the certs, but that field is populated in both of these.
I am trying to generate public and private keys for an ECDH handshake.
Back end is using p256 for public key. I am getting a failed request with status 0
public func makeHandShake(completion: @escaping (Bool, String?) -> ()) {
guard let config = self.config else { completion(false,APP_CONFIG_ERROR)
return
}
var rData = HandshakeRequestTwo()
let sessionValue = AppUtils().generateSessionID()
rData.session = sessionValue
//generating my ECDH Key Pair
let sPrivateKey = P256.KeyAgreement.PrivateKey()
let sPublicKey = sPrivateKey.publicKey
let privateKeyBase64 = sPrivateKey.rawRepresentation.base64EncodedString()
print("My Private Key (Base64): \(privateKeyBase64)")
let publicKeyBase64 = sPublicKey.rawRepresentation.base64EncodedString()
print("My Public Key (Base64): \(publicKeyBase64)")
rData.value = sPublicKey.rawRepresentation.base64EncodedString()
let encoder = JSONEncoder()
do {
let jsonData = try encoder.encode(rData)
if let jsonString = String(data: jsonData, encoding: .utf8) {
print("Request Payload: \(jsonString)")
}
} catch {
print("Error encoding request model to JSON: \(error)")
completion(false, "Error encoding request model")
return
}
self.rsaReqResponseHandler(config: config, endpoint: config.services.handShake.endpoint, model: rData) { resToDecode, error in
print("Response received before guard : \(resToDecode ?? "No response")")
guard let responseString = resToDecode else {
print("response string is nil")
completion(false,error)
return
}
print("response received: \(responseString)")
let decoder = JSONDecoder()
do {
let request = try decoder.decode(DefaultResponseTwo.self, from: Data(responseString.utf8))
let msg = request.message
let status = request.status == 1 ? true : false
completion(status,msg)
guard let serverPublicKeyBase64 = request.data?.value else {
print("Server response is missing the value")
completion(false, config.messages.serviceError)
return
}
print("Server Public Key (Base64): \(serverPublicKeyBase64)")
if serverPublicKeyBase64.isEmpty {
print("Server public key is an empty string.")
completion(false, config.messages.serviceError)
return
}
guard let serverPublicKeyData = Data(base64Encoded: serverPublicKeyBase64) else {
print("Failed to decode server public key from Base64. Data is invalid.")
completion(false, config.messages.serviceError)
return
}
print("Decoded server public key data: \(serverPublicKeyData)")
guard let serverPublicKey = try? P256.KeyAgreement.PublicKey(rawRepresentation: serverPublicKeyData) else {
print("Decoded server public key data is invalid for P-256 format.")
completion(false, config.messages.serviceError)
return
}
// Derive Shared Secret and AES Key
let sSharedSecret = try sPrivateKey.sharedSecretFromKeyAgreement(with: serverPublicKey)
// Derive AES Key from Shared Secret
let symmetricKey = sSharedSecret.hkdfDerivedSymmetricKey(
using: SHA256.self,
salt: "AES".data(using: .utf8) ?? Data(),
sharedInfo: Data(),
outputByteCount: 32
)
// Storing AES Key in Config
let symmetricKeyBase64 = symmetricKey.withUnsafeBytes { Data($0) }.base64EncodedString()
print("Derived Key: \(symmetricKeyBase64)")
self.config?.cryptoConfig.key = symmetricKeyBase64
AppUtils.Log(from: self, with: "Handshake Successful, AES Key Established")
} catch {
AppUtils.Log(from: self, with: "Handshake Failed :: \(error)")
completion(false, self.config?.messages.serviceError)
}
}
} this is request struct model public struct HandshakeRequestTwo: Codable {
public var session: String?
public var value: String?
public enum CodingKeys: CodingKey {
case session
case value
}
public init(session: String? = nil, value: String? = nil) {
self.session = session
self.value = value
}
} This is backend's response {"message":"Success","status":1,"data":{"senderId":"POSTBANK","value":"MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAErLxbfQzX+xnYVT1LLP5VOKtkMRVPRCoqYHcCRTM64EMEOaRU16yzsN+2PZMJc0HpdKNegJQZMmswZtg6U9JGVw=="}} This is my response struct model public struct DefaultResponseTwo: Codable {
public var message: String?
public var status: Int?
public var data: HandshakeData?
public init(message: String? = nil, status: Int? = nil, data: HandshakeData? = nil) {
self.message = message
self.status = status
self.data = data
}
}
public struct HandshakeData: Codable {
public var senderId: String?
public var value: String?
public init(senderId: String? = nil, value: String? = nil) {
self.senderId = senderId
self.value = value
}
}
Hi,
I'm working on developing my own CryptoTokenKit (CTK) extension to enable codesign with HSM-backed keys. Here's what I’ve done so far:
The container app sets up the tokenConfiguration with TKTokenKeychainCertificate and TKTokenKeychainKey.
The extension registers successfully and is visible via pluginkit when launching the container app.
The virtual smartcard appears when running security list-smartcards.
The certificate, key, and identity are all visible using security export-smartcard -i [card].
However, nothing appears in the Keychain.
After adding logging and reviewing output in the Console, I’ve observed the following behavior when running codesign:
My TKTokenSession is instantiated correctly, using my custom TKToken implementation — so far, so good.
However, none of the following TKTokenSession methods are ever called:
func tokenSession(_ session: TKTokenSession, beginAuthFor operation: TKTokenOperation, constraint: Any) throws -> TKTokenAuthOperation
func tokenSession(_ session: TKTokenSession, supports operation: TKTokenOperation, keyObjectID: TKToken.ObjectID, algorithm: TKTokenKeyAlgorithm) -> Bool
func tokenSession(_ session: TKTokenSession, sign dataToSign: Data, keyObjectID: Any, algorithm: TKTokenKeyAlgorithm) throws -> Data
func tokenSession(_ session: TKTokenSession, decrypt ciphertext: Data, keyObjectID: Any, algorithm: TKTokenKeyAlgorithm) throws -> Data
func tokenSession(_ session: TKTokenSession, performKeyExchange otherPartyPublicKeyData: Data, keyObjectID objectID: Any, algorithm: TKTokenKeyAlgorithm, parameters: TKTokenKeyExchangeParameters) throws -> Data
The only relevant Console log is:
default 11:31:15.453969+0200 PersistentToken [0x154d04850] invalidated because the client process (pid 4899) either cancelled the connection or exited
There’s no crash report related to the extension, so my assumption is that ctkd is closing the connection for some unknown reason.
Is there any way to debug this further?
Thank you for your help.
I'm writing an app on macOS that stores passwords in the Keychain and later retrieves them using SecItemCopyMatching(). This works fine 90% of the time. However, occasionally, the call to SecItemCopyMatching() fails with errSecAuthFailed (-25293). When this occurs, simply restarting the app resolves the issue; otherwise, it will consistently fail with errSecAuthFailed.
What I suspect is that the Keychain access permission has a time limitation for a process. This issue always seems to arise when I keep my app running for an extended period.
Binary code is associated with the NSUserTrackingUsageDescription deleted at present, but in the revised App privacy will contain NSUserTrackingUsageDescription, I feel very confused, don't know should shouldn't solve.
In iOS 18, i use CNContactPickerViewController to access to Contacts (i know it is one-time access).
After first pick up one contact, the Setting > Apps > my app > Contacts shows Private Access without any option to close it.
Is there any way to close it and undisplay it ?
I tried to uninstall and reinstall my app, but it didn't work.
When I reboot my iPhone 14 pro with Live Activity started, KeyChain information disappears.
So there is a problem that I have to sign-in again when I enter the app.
There is no problem rebooting the iPhone without Live Activity.
iOS17 didn't have this problem.
I'm seeing some odd behavior which may be a bug. I've broken it down to a least common denominator to reproduce it. But maybe I'm doing something wrong.
I am opening a file read-write. I'm then mapping the file read-only and private:
void* pointer = mmap(NULL, 17, PROT_READ, MAP_FILE | MAP_PRIVATE, fd, 0);
I then unmap the memory and close the file. After the close, eslogger shows me this:
{"close":{"modified":false,[...],"was_mapped_writable":false}}
Which makes sense.
I then change the mmap statement to:
void* pointer = mmap(NULL, 17, PROT_READ, MAP_FILE | MAP_SHARED, fd, 0);
I run the new code and and the close looks like:
{"close":{"modified":false, [....], "was_mapped_writable":true}}
Which also makes sense.
I then run the original again (ie, with MAP_PRIVATE vs. MAP_SHARED) and the close looks like:
{"close":{"modified":false,"was_mapped_writable":true,[...]}
Which doesn't appear to be correct.
Now if I just open and close the file (again, read-write) and don't mmap anything the close still shows:
{"close":{ [...], "was_mapped_writable":true,"modified":false}}
And the same is true if I open the file read-only.
It will remain that way until I delete the file. If I recreate the file and try again, everything is good until I map it MAP_SHARED.
I tried this with macOS 13.6.7 and macOS 15.0.1.
Hi! We are developing an authentication plugin for macOS that integrates with the system's authentication flow. The plugin is designed to prompt the user for approval via a push notification in our app before allowing access. The plugin is added as the first mechanism in the authenticate rule, followed by the default builtin:authenticate as a fallback.
When the system requests authentication (e.g., during screen unlock), our plugin successfully displays the custom UI and sends a push notification to the user's device. However, I've encountered the following issue:
If the user does not approve the push notification within ~30 seconds, the system resets the screen lock (expected behavior).
If the user approves the push notification within approximately 30 seconds but doesn’t start entering their password before the timeout expires, the system still resets the screen lock before they can enter their password, effectively canceling the session.
What I've Tried:
Attempted to imitate mouse movement after the push button was clicked to keep the session active.
Created a display sleep prevention assertion using IOKit to prevent the screen from turning off.
Used the caffeinate command to keep the display and system awake.
Tried setting the result as allow for the authorization request and passing an empty password to prevent the display from turning off.
I also checked the system logs when this issue occurred and found the following messages:
___loginwindow: -[LWScreenLock (Private) askForPasswordSecAgent] | localUser = >timeout
loginwindow: -[LWScreenLock handleUnlockResult:] _block_invoke | ERROR: Unexpected _lockRequestedBy of:7 sleeping screen
loginwindow: SleepDisplay | enter
powerd: Process (loginwindow) is requesting display idle___
These messages suggest that the loginwindow process encounters a timeout condition, followed by the display entering sleep mode. Despite my attempts to prevent this behavior, the screen lock still resets prematurely.
Questions:
Is there a documented (or undocumented) system timeout for the entire authentication flow during screen unlock that I cannot override?
Are there any strategies for pausing or extending the authentication timeout to allow for complex authentication flows like push notifications?
Any guidance or insights would be greatly appreciated. Thank you!
Hello Apple Developer Community,
We have been experiencing a persistent notification issue in our application, Flowace, after updating to macOS 15 and above. The issue is affecting our customers but does not occur on our internal test machines.
Issue Description
When users share their screen using Flowace, they receive a repetitive system notification stating:
"Flowace has accessed your screen and system audio XX times in the past 30 days. You can manage this in settings."
This pop-up appears approximately every minute, even though screen sharing and audio access work correctly. This behavior was not present in macOS 15.1.1 or earlier versions and appears to be related to recent privacy enhancements in macOS.
Impact on Users
The frequent pop-ups disrupt workflows, making it difficult for users to focus while using screen-sharing features.
No issues are detected in Privacy & Security Settings, where Flowace has the necessary permissions.
The issue is not reproducible on our internal test machines, making troubleshooting difficult.
Our application is enterprise level and works all the time, so technically this pop only comes after a period of not using the app.
Request for Assistance
We would like to understand:
Has anyone else encountered a similar issue in macOS 15+?
Is there official Apple documentation explaining this new privacy behavior?
Are there any interim fixes to suppress or manage these notifications?
What are Apple's prospects regarding this feature in upcoming macOS updates?
A demonstration of the issue can be seen in the following video: https://youtu.be/njA6mam_Bgw
Any insights, workarounds, or recommendations would be highly appreciated!
Thank you in advance for your help.
Best,
Anuj Patil
Flowace Team
I created an app in Xcode using ApplescriptObjC that is supposed to communicate with Finder and Adobe Illustrator. It has been working for the last 8 years, until now I have updated it for Sonoma and it no longer triggers the alerts for the user to approve the communication. It sends the Apple Events, but instead of the alert dialog I get this error in Console:
"Sandboxed application with pid 15728 attempted to lookup App: "Finder"/"finder"/"com.apple.finder" 654/0x0:0x1d01d MACSstill-hintable sess=100017 but was denied due to sandboxing."
The Illustrator error is prdictably similar.
I added this to the app.entitlements file:
<key>com.apple.security.automation.apple-events</key>
<array>
<string>com.apple.finder</string>
<string>com.adobe.illustrator</string>
</array>
I added this to Info.plist:
<key>NSAppleEventsUsageDescription</key>
<string>This app requires access to Finder and Adobe Illustrator for automation.</string>
I built the app, signed with the correct Developer ID Application Certificate.
I've also packaged it into a signed DMG and installed it, with the same result as running it from Xcode.
I tried stripping it down to just the lines of code that communicate with Finder and Illustrator, and built it with a different bundle identifier with the same result.
What am I missing?
I have been trying to find a way to be able to sign some data with private key of an identity in login keychain without raising any prompts.
I am able to do this with system keychain (obviously with correct permissions and checks) but not with login keychain. It always ends up asking user for their login password.
Here is how the code looks, roughly,
NSDictionary *query = @{
(__bridge id)kSecClass: (__bridge id)kSecClassIdentity,
(__bridge id)kSecReturnRef: @YES,
(__bridge id)kSecMatchLimit: (__bridge id)kSecMatchLimitAll
};
CFTypeRef result = NULL;
OSStatus status = SecItemCopyMatching((__bridge CFDictionaryRef)query, (CFTypeRef *)&amp;result);
NSArray *identities = ( NSArray *)result;
SecIdentityRef identity = NULL;
for (id _ident in identities) {
// pick one as required
}
SecKeyRef privateKey = NULL;
OSStatus status = SecIdentityCopyPrivateKey(identity, &amp;privateKey);
NSData *strData = [string dataUsingEncoding:NSUTF8StringEncoding];
unsigned char hash[CC_SHA256_DIGEST_LENGTH];
CC_SHA256(strData.bytes, (CC_LONG)strData.length, hash);
NSData *digestData = [NSData dataWithBytes:hash length:CC_SHA256_DIGEST_LENGTH];
CFErrorRef cfError = NULL;
NSData *signature = (__bridge_transfer NSData *)SecKeyCreateSignature(privateKey,
kSecKeyAlgorithmRSASignatureDigestPKCS1v15SHA256,
(__bridge CFDataRef)digestData,
&amp;cfError);
Above code raises these system logs in console
default 08:44:52.781024+0000 securityd client is valid, proceeding
default 08:44:52.781172+0000 securityd code requirement check failed (-67050), client is not Apple-signed
default 08:44:52.781233+0000 securityd displaying keychain prompt for /Applications/Demo.app(81692)
If the key is in login keychain, is there any way to do SecKeyCreateSignature without raising prompts? What does client is not Apple-signed mean?
PS: Identities are pre-installed either manually or via some device management solution, the application is not installing them.
I wrote a Keychain controller that add, delete and fetch keychain items using SecItemAdd(_:_:)and related APIs with data protection keychain enabled (kSecUseDataProtectionKeychain). I am using it in a macOS Cocoa app.
I am using Swift Testing to write my tests to ensure that the controller works as expected.
As I understand, I should create my own keychain for testing rather than use the actual keychain in macOS. Currently, I created a separate keychain group (e.g. com.testcompany.testapp.shared) and added it to myapp.entitlements file so that the tests pass without failing because of the missing entitlement file.
SecKeychainCreate(_:_:_:_:_:_:) and SecKeychainDelete(_:) API are deprecated with no alternative provided in the documentation. I noticed SecKeychain class but documentation doesn't explain much about it.
How should I test my keychain controller properly so that it does not use the actual macOS keychain, which is the "production" keychain?
With the update to iOS version 18.0, there was a significant improvement in information security and user privacy, allowing apps to be locked using FaceID (or TouchID), with no possibility of using the phone's unlock passcode to access the locked app (see reference: https://www.reddit.com/r/Wealthsimple/comments/1fr1nnj/psa_ios_18_require_face_id_feature_mitigates/).
As a result, even if someone else knew your iPhone unlock passcode, they wouldn't be able to open the locked apps, as FaceID (or TouchID) would be required. However, after updating to iOS 18.1.1, someone who knows your iPhone unlock passcode and is using your iPhone (or has stolen your iPhone and requested the unlock passcode) can inadvertently open the locked apps, because after a few failed attempts to open the locked app without FaceID (or TouchID), the iPhone will prompt for the unlock passcode to open the locked app.
Even if the user has moved the app to the hidden folder, the content of that folder and the hidden apps within it can be opened with the iPhone unlock passcode after several failed attempts to open the hidden app without FaceID (or TouchID).
It would be very important for users if this security and privacy weakness were eliminated, returning to what iOS 18.0 did: the only way to open a locked app is through FaceID (or TouchID), and it would not be possible to open it with the iPhone unlock passcode.
Hi
We use login using apple id feature in our website. However when it comes to apple id, it is possible for user to hide the original email and show a relay email. We have found that this relay email doesn't work
Hence looking for a possible solution to acquire the real email from the user. Is there a possibility in doing that? any help would be greatly appreciated.
Best Regards
Hasintha
Hello, first time poster here.
I'm struggling to find any info/documentation on why bluetooth game controllers DON'T require bluetooth entitlement when app sandboxing is enabled but do require USB.
any pointers would be much appriciated
Chris
I was curious as to the procedure for having an encryption key leaked and was hoping to have your opinions on how these two questions will be answered [if you were in the position].
Q1: Let's say, for instance, that you're making a social media network that stores private messages in a database network (such as Firebase) and uses basic encryption to store that data into an encrypted format (e.g., text message: "Hello Mous772!"; Firebase data: "deaErG5gao7J5qw/QI3EOA==").
But oh no! Someone got access to the encryption key used to encrypt hundreds of thousands of messages. You cannot simply delete thousands of messages because of this hacker, so how should you deal with this? This is where my question comes in. Is it possible to change the encryption key for all of the data if I am using the code system at the bottom of this question and using that code system to store encrypted data in Firebase? If so, how would you go about doing that? (Please use simple language; I'm not good with this stuff).
Q2: What, in your opinion, is the best way to prevent this in the first place? I was told that a good solution was to store two sets of the same data; when one kegs it, we shut down the original and use the backup; however, this does not sound sustainable at all. I want to know what steps can be taken to ensure this never happens.
[Please don't give me "Well... you can never *really hide these keys!" I'm well aware it's not possible to never have them leaked ever; I'm just looking for best practices only.]
This is the encryption system we are using for this hypothetical app.
// MARK: Value
// MARK: Private
private let key: Data
private let iv: Data
// MARK: - Initialzier
init?(key: String, iv: String) {
guard key.count == kCCKeySizeAES128 || key.count == kCCKeySizeAES256, let keyData = key.data(using: .utf8) else {
debugPrint("Error: Failed to set a key.")
return nil
}
guard iv.count == kCCBlockSizeAES128, let ivData = iv.data(using: .utf8) else {
debugPrint("Error: Failed to set an initial vector.")
return nil
}
self.key = keyData
self.iv = ivData
}
// MARK: - Function
// MARK: Public
func encrypt(string: String) -> Data? {
return crypt(data: string.data(using: .utf8), option: CCOperation(kCCEncrypt))
}
func decrypt(data: Data?) -> String? {
guard let decryptedData = crypt(data: data, option: CCOperation(kCCDecrypt)) else { return nil }
return String(bytes: decryptedData, encoding: .utf8)
}
func crypt(data: Data?, option: CCOperation) -> Data? {
guard let data = data else { return nil }
let cryptLength = data.count + key.count
var cryptData = Data(count: cryptLength)
var bytesLength = Int(0)
let status = cryptData.withUnsafeMutableBytes { cryptBytes in
data.withUnsafeBytes { dataBytes in
iv.withUnsafeBytes { ivBytes in
key.withUnsafeBytes { keyBytes in
CCCrypt(option, CCAlgorithm(kCCAlgorithmAES), CCOptions(kCCOptionPKCS7Padding), keyBytes.baseAddress, key.count, ivBytes.baseAddress, dataBytes.baseAddress, data.count, cryptBytes.baseAddress, cryptLength, &bytesLength)
}
}
}
}
guard Int32(status) == Int32(kCCSuccess) else {
debugPrint("Error: Failed to crypt data. Status \(status)")
return nil
}
cryptData.removeSubrange(bytesLength..<cryptData.count)
return cryptData
}
}
//let password = "UserPassword1!"
//let key128 = "1234567890123456" // 16 bytes for AES128
//let key256 = "12345678901234561234567890123456" // 32 bytes for AES256
//let iv = "abcdefghijklmnop" // 16 bytes for AES128
//let aes128 = AES(key: key128, iv: iv)
//let aes256 = AES(key: key256, iv: iv)
//let encryptedPassword128 = aes128?.encrypt(string: password)
//aes128?.decrypt(data: encryptedPassword128)
//let encryptedPassword256 = aes256?.encrypt(string: password)
//aes256?.decrypt(data: encryptedPassword256)
Trying to validate external reference identifiers with SecTrustEvaluateWithError Method by setting reference Ids to SecPolicyCreateSSL() & SecPolicyCreateWithProperties()
But two concerns are -
Validates for correct reference IDs but gives error for combination of wrong & correct reference Ids
398 days validity works mandatorily before reference Ids check.
Is there any other to validate external reference Ids?, which give flexibility
To pass multiple combinations of reference IDs string (wrong, correct, IP, DNS)
To validate reference ID without days validity of 398.
Please suggest. Any help here is highly appreciated.