Security

RSS for tag

Secure the data your app manages and control access to your app using the Security framework.

Security Documentation

Posts under Security tag

347 results found
Sort by:
Post not yet marked as solved
22 Views

App password saved with Keychain SecItemAdd() can be viewed in iPhone/iPad?

We are using Keychain Services and saving password using SecItemAdd() with kSecClassGenericPassword in our App. We know using the Keychain Access on Mac, we can see Keychain Items for MacOS Apps by the admin of Mac PC. Is there a way exist to view keychain items for iOS(iPhone/iPad).? My use case is, iPad(company device, not MDM) is shared between two or more persons.Each time app-user logs in to the same app using their own respective passwords(stored in keychain) . Security Concern is, such keychain items(passwords) will be able to see by others(including the owner of iPad/iPhone)? Ex: connecting to another Mac PC or some tool exist like Keychain Access present in MacOS or case when current local keychain is sync'd to iCloud Keychain. We don't want users of iPad/iPhone to see other users password. Is there any other solution exists other than Keychain?
Asked
by AThomas.
Last updated
.
Post not yet marked as solved
40 Views

iOS 15 with FaceID authentication error when resetting FaceID

We use biometricID (faceID/touchID) authentication to access to a secret stored in keychain. We create the access control object with the biometryCurrentSet option as shown to make sure if FaceID / TouchID changes the entry should be invalidated. let secAccessControlObj = SecAccessControlCreateWithFlags(nil, kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly, .biometryCurrentSet, accessControlError) Below is the set and get query, Set Query: [String(kSecClass): kSecClassGenericPassword,         String(kSecAttrAccount): group as AnyObject,         String(kSecAttrService): service as AnyObject,         String(kSecUseAuthenticationUI) : kSecUseAuthenticationUIAllow as AnyObject,         String(kSecAttrAccessControl) : secAccessControlObj,         String(kSecValueData) : value as AnyObject,         String(kSecAttrCreationDate) : Date() as AnyObject] Get Query: [String(kSecClass): kSecClassGenericPassword,         String(kSecAttrAccount): group as AnyObject,         String(kSecAttrService): service as AnyObject,         String(kSecUseAuthenticationUI) : kSecUseAuthenticationUIAllow as AnyObject,         String(kSecAttrAccessControl) : secAccessControlObj,         String(kSecValueData) : value as AnyObject,         String(kSecAttrCreationDate) : Date() as AnyObject] Steps: Set the value in keychain using the set query above Reset the faceID Use the get query to get the value from keychain by authenticating against TouchID/ FaceID. Result: When we try to get the value from keychain using SecItemCopyMatching(query as CFDictionary, result) we get the error code errSecAuthFailed (-25293) on iOS 15. Analysis: Prior to this (iOS 14 and below) the error code would be errSecItemNotFound which makes more sense. This is an issue for iOS 15 only as we also get errSecAuthFailed when user backgrounds the app while authenticating with FaceID/TouchID. This creates a ambiguity for us. In our testing when we backgrounded the app while authentication is in progress, we found the actual call to SecItemCopyMatching(::) was made when app's state was actually active but when the call returned the state had become background and the error code was again errSecAuthFailed This seems to be a bug with iOS 15 as it creates a ambiguity for the caller. I think the error code returned after resetting faceID should still be errSecItemNotFound in which case we can know the secret is actually lost since FaceID is reset and can treat errSecAuthFailed as error where the secret is actually not lost but just that failed temporarily. Please let us know if we need to file a bug
Asked
by axp9103.
Last updated
.
Post not yet marked as solved
90 Views

Fatal Exception: NSInvalidArgumentException SecKeyGetAlgorithmId called with NULL SecKeyRef on ios 15 only

As usual crash is happening on newer version of iOS 15 Crash log Fatal Exception: NSInvalidArgumentException 0 CoreFoundation 0x1814dc05c __exceptionPreprocess 1 libobjc.A.dylib 0x1999f6f54 objc_exception_throw 2 CoreFoundation 0x181533190 __CFDictionaryCreateGeneric 3 Security 0x18a239674 SecKeyGetAlgorithmId 4 Security 0x18a2d53d0 SecKeyGetSignatureAlgorithmForPadding 5 Security 0x18a2d5328 SecKeyRawSign 6 App Name 0x100bc90f8 -[login privatekeytouch] + 1484 (CprLoginContrl.m:1484) 7 libdispatch.dylib 0x18114cc04 _dispatch_call_block_and_release 8 libdispatch.dylib 0x18114e950 _dispatch_client_callout 9 libdispatch.dylib 0x18115cd30 _dispatch_main_queue_callback_4CF 10 CoreFoundation 0x181494ce4 CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE 11 CoreFoundation 0x18144eebc __CFRunLoopRun 12 CoreFoundation 0x1814623c8 CFRunLoopRunSpecific 13 GraphicsServices 0x19cc7338c GSEventRunModal 14 UIKitCore 0x183e080bc -[UIApplication _run] 15 UIKitCore 0x183b85be8 UIApplicationMain 16 App Name 0x10079a7b8 main + 22 (main.m:22) 17 ??? 0x101639a24 (Missing) crashed during SecKeyRawSign, anything has changed on ios 15?
Asked
by LCTech.
Last updated
.
Post not yet marked as solved
26 Views

WKWebView cache client cert

Hi, we uses WKWebView to load IDP login page and the client cert authentication is also required after user credential submitted. We implemented didReceiveAuthenticationChallenge function to retrieve the client cert from our app and create NSURLCredential with NSURLCredentialPersistenceNone. However, we found the client cert get cached. When IDP issues a new client cert and the old cert become invalid, although the user import the new cert into our app, the cache of the old cert is used, didReceiveAuthenticationChallenge is not called. We tried to use WKWebsiteData to delete all cookies and website data include WKWebsiteDataTypeMemoryCache, disckCache and localStorage, but no luck. The only workaround is terminate our app and restart it will clear the cache. Is there anything we missed? Thanks, Ying
Asked
by yingha.
Last updated
.
Post not yet marked as solved
28 Views

Unlock keychain on headless system does not work on BigSur

I am trying to setup a headless machine (no GUI session whatsoever, only SSH) to CI/CD My pre-build steps is to setup a keychain, but it looks like unlocking the keychain using just a SSH session is not working on macOS 11.6 ec2-user@ip-172-31-40-2 code % security create-keychain -p Passw0rd dev ec2-user@ip-172-31-40-2 code % security list-keychain -d user -s dev ec2-user@ip-172-31-40-2 code % security set-keychain-settings -t 0 dev security: SecKeychainSetSettings dev: User interaction is not allowed. ec2-user@ip-172-31-40-2 code % security unlock-keychain -p Passw0rd dev ec2-user@ip-172-31-40-2 code % security set-keychain-settings -t 0 dev security: SecKeychainSetSettings dev: User interaction is not allowed. ec2-user@ip-172-31-40-2 code % security import ~/AppleWWDRCA.cer -t cert -k dev -A 1 certificate imported. ec2-user@ip-172-31-40-2 code % security import ~/AppleWWDRCAG3.cer -t cert -k dev -A 1 certificate imported. ec2-user@ip-172-31-40-2 code % security import ~/AppleRoot.cer -t cert -k dev -A 1 certificate imported. ec2-user@ip-172-31-40-2 code % security import ~/DevAuthCA.cer -t cert -k dev -A 1 certificate imported. ec2-user@ip-172-31-40-2 code % security import ~/apple_dev_key.p12 -k dev -A # this is my private key + cert security: SecKeychainItemImport: User interaction is not allowed. ec2-user@ip-172-31-40-2 code % security unlock-keychain -p Passw0rd dev ec2-user@ip-172-31-40-2 code % security import ~/apple_dev_key.p12 -k dev -A security: SecKeychainItemImport: User interaction is not allowed. When doing the same from agri session, I can see that despite the unlock-keychain command, a GUI prompt is presented to the user to unlock the keychain.
Asked
by sebsto.
Last updated
.
Post not yet marked as solved
2.7k Views

Troubleshooting -34018 Keychain Errors

Recently I’ve had a couple of folks ping me about debugging reproducible -34018 errors when using the keychain. Pasted in below is my advice on that topic. If you have any feedback about this, or you are having this problem and can’t fix it using these instructions, please put the details in a new thread. Make sure to tag it with Security so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Change history: 11 Mar 2019 — First posted. 13 Mar 2019 — Added a clarification about query dictionaries. 23 Oct 2021 — Updated to fix the formatting and repair a broken link. Minor editorial changes. 23 Oct 2021 — Added the Change in Query Behaviour section. Troubleshooting -34018 Keychain Errors Learn how to resolve -34018 errors from the keychain. Error -34018 translates to errSecMissingEntitlement. This error means that your app is trying to use a keychain access group for which it does not have entitlements. See the Set Your App’s Access Groups section of Sharing Access to Keychain Items Among a Collection of Apps for information on how the system determines the list of keychain access groups that you have access to. Note On macOS, the advice in this post only applies if you’re using the data protection keychain. If you’re using the traditional file-based keychain, you should never see error -34018. There are two common scenarios for this error: Reproducible. The problem happens every time you run the code, typically during development but possibly in other contexts, like after submitting your app to TestFlight, or during enterprise deployment. Intermittent. The problems shows up very occasionally on user devices in the field but is otherwise hard to reproduce. If you’re seeing this problem intermittently, read the suggestions in Error -34018 errSecMissingEntitlement. In contrast, if the problem is reproducible, read the rest of this post for advice on how to debug it. Check Your Entitlements The first step in troubleshooting this problem is to check your app’s entitlements. To start, use the codesign tool to dump the entitlements: $ codesign -d --entitlements :- /path/to/your.app IMPORTANT Dump the entitlements of your built app, not the .entitlements file you see in your Xcode project. The .entitlements file is an important input to Xcode’s code signing machinery, but it is not what the system uses to determine your app’s entitlements. You should see something like this: $ codesign -d --entitlements :- TestKeychain.app … <plist version="1.0"> <dict> <key>com.apple.developer.team-identifier</key> <string>SKMME9E2Y8</string> <key>application-identifier</key> <string>SKMME9E2Y8.com.example.apple-samplecode.testkeychain.app</string> <key>keychain-access-groups</key> <array> <string>SKMME9E2Y8.example.apple-samplecode.testkeychain.app</string> <string>SKMME9E2Y8.example.apple-samplecode.testkeychain.shared</string> … </array> <key>com.apple.security.application-groups</key> <array> <string>group.com.example.apple-samplecode.testkeychain</string> … </array> … </dict> </plist> In this output you’ll see the following: The com.apple.developer.team-identifier property is your Team ID. The application-identifier (com.apple.application-identifier on macOS) is your App ID, that is, your App ID prefix (in most cases this is your Team ID) followed by your bundle ID. keychain-access-groups, if present, starts with your App ID and then lists any other keychain access groups you use. com.apple.security.application-groups, if present, lists the shared app groups you use (this is only relevant on iOS-based platforms; shared app groups can’t be used as keychain access groups on macOS). As discussed in the Set Your App’s Access Groups section of Sharing Access to Keychain Items Among a Collection of Apps, the system uses the last three entitlements to form of list of keychain access groups that you’re app is entitled to use. Your keychain access group must appear in one of these entitlements. If it’s not there, read Technote 2415 Entitlements Troubleshooting for advice on how to fix that. Check Your Keychain Calls Once you’ve confirmed that your app has the entitlements to access the expected keychain access group, the next step is to confirm that you’re passing the correct access group to the keychain API. To do this, set a breakpoint on your keychain calls. For example, in the following code snippet you would set a breakpoint on the last line: let query: NSDictionary = [ kSecClass: kSecClassGenericPassword, kSecAttrService: "myService", kSecAttrAccount: username, kSecAttrAccessGroup: "SKMME9E2Y8.example.apple-samplecode.testkeychain.shared", kSecMatchLimit: kSecMatchLimitAll, kSecReturnData: true, ] var copyResult: CFTypeRef? = nil let err = SecItemCopyMatching(query, &copyResult) Note See Change in Query Behaviour (below) for an interesting edge case here. When you hit the breakpoint, use the debugger to print the query dictionary: (lldb) p query (NSDictionary) $R4 = 0x0000600000fedb00 6 key/value pairs { … [5] = { key = 0x0000000111838958 "agrp" value = "SKMME9E2Y8.example.apple-samplecode.testkeychain.shared" } } Here the agrp attribute holds the keychain access group being searched (agrp is the value of kSecAttrAccessGroup). It must either be not present, in which case you get the default behaviour discussed below, or included in the list of entitlements as determined by the previous section. If it’s some other value, trace the origin of that bad value and correct it. If the kSecAttrAccessGroup attribute is missing, you will see one of three behaviours: For query dictionaries, like the one passed to SecItemCopyMatching, the system interprets a missing value as a wildcard, that is, the query will match an item in any access group that you have access to. For SecItemAdd, the system will use your app’s default keychain access group, that is, the first entry in the list of entitlements as determined by the previous section. For the second parameter of SecItemUpdate, a missing value indicates that it should not change the keychain access group attribute. Change in Query Behaviour In the example above I used SecItemCopyMatching to illustrate how to check the access group used by a call. This brings up an interesting change in behaviour when you pass in an access group that you’re not entitled to access: In iOS 13 and later, the call will fail with errSecMissingEntitlement. In earlier systems, the call will simply cause the query to not match. The current behaviour is better because it makes is very likely that you’ll catch this mistake early.
Asked
by eskimo.
Last updated
.
Post not yet marked as solved
4.7k Views

Error -34018 errSecMissingEntitlement

Error -34018 is errSecMissingEntitlement. The immediate cause of this error is that you’re trying to do something with the Security framework that requires an entitlement and your app was not signed with that entitlement. The entitlement in question is usually the application-identifier entitlement (com.apple.application-identifier on macOS), which is the primary mechanism by which the Security framework identifies your app. There are two ways this error manifests: Reproducible — That is, it happens every time you run the code, typically during development but possibly in other contexts (like TestFlight or enterprise deployment). Intermittent — That is, it shows up very occasionally on user devices in the field but is otherwise hard to reproduce. If the problem is reproducible, it’s related to how your code was signed or the context in which that code is running. There are some well-known causes for this; the most obvious one is related to a change in the iOS 10 simulator and is covered by this thread. If you encounter reproducible -34018 errors in a context not covered by that thread, please start a new thread to discuss them. If the problem only shows up intermittently on user devices in the field, it may be the result of a bug on iOS-based platforms. If you believe you’re hitting this bug, please follow up on this thread. Share and Enjoy — Quinn “The Eskimo!” Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = "eskimo" + "1" + "@apple.com" Change history: 3 Oct 2016 — First posted. 23 Sep 2021 — Updated to fix the formatting and repair a broken link.
Asked
by eskimo.
Last updated
.
Post not yet marked as solved
76 Views

Cannot uninstall XCode Previews App iOS 15

Hello, I’m not a developer but a regular user and while I was checking out iOS 15’s features I came across XCode Previews within the Accessibility > Per App Settings menu. I never downloaded this app and it did not appear in the Home Screen or App Library until I opened it with a Shortcuts > Scripting > Open App command. Now it appears in the App Library but I am unable to remove it. Why is it in my phone? How can I remove it? Can it be maliciously accessed? Please help removing it.
Asked
by Mindmusik.
Last updated
.
Post not yet marked as solved
41 Views

Touch ID / Face ID biometryCurrentSet never fails on iOS 15

I've got some admittedly old Objective-C code handling Keychain items protected by Touch ID / Face ID that uses the access control flag kSecAccessControlTouchIDCurrentSet, accessing the items would fail with errSecItemNotFound when the user adds or removes a finger/face from the device, however on iOS 15.0 this is not happening. It does work on iOS 14.6 still. My deployment target is still iOS 11.0 so I haven't moved to kSecAccessControlBiometryCurrentSet as the replacement for the now deprecated TouchID value - but the enum raw values are the same so I don't see how that could be the cause. I can't see what the new error code is, because I'm not using Xcode 13, but I'll try and get the DeviceSupport copied in (official support for this is please!) to help search: Swift touchIDCurrentSet biometryCurrentSet Objective-C kSecAccessControlTouchIDCurrentSet kSecAccessControlBiometryCurrentSet
Asked
by AshtonX.
Last updated
.
Post marked as solved
88 Views

Is it possible somehow in iOS to prevent screen capture?

Is there's way to prevent taking screenshots entirely while using my app? I need to prevent screen capture by users of my app, for security reasons. The contents I display are confidential and should not be copied onto the device.
Asked
by DBox.
Last updated
.
Post marked as solved
532 Views

sandbox-exec file-write behaves unexpectedly

hiI have a rules file like this(version 1) (deny default) ... (allow file-write* (regex "/Users/thomas/Desktop"))When I use it on app A, it works fine (the app can write to the desktop) but when use it on app B, it doesn't work (the app cannot save a file to the desktop). So I made a test app (app C), a simple cocoa app that just writes a dummy string to a file, and it still doesn't work. If I replace (allow file-write* (regex "/Users/thomas/Desktop")) with (allow file-write*) it works on app B and C too, so I know that's the only thing that's wrong.So I really don't understand what's going on. How can it work for app A but not for B or C? Especially given that:allowing all file-writes works (so I know the regex is the culprit, even though it works for app A (I tested that the app A can save to Desktop but not to other locations)app C is minimal and is not a "blackbox"I tried tons of different variations: literal instead of regex, "^/Users/thomas/Desktop", "^/Users/thomas/Desktop/" , "^/Users/thomas/Desktop/*", ...apps A, B and C are not sandboxed apps if I run them normally (I can check this in the activity monitor)Thanks in advance for your help!
Asked Last updated
.
Post not yet marked as solved
124 Views

AES 256 Symmetric Cryptography

I am unable to encrypt or decrypt using aes 256 block mode cbc padding pkcs5 please convert this c# to swift ````public class EncDec { static string key = ""; // your key public static string Encrypt(string data) { RijndaelManaged rijndaelCipher = new RijndaelManaged(); rijndaelCipher.Mode = CipherMode.CBC; //remember this parameter rijndaelCipher.Padding = PaddingMode.PKCS7; //remember this parameter rijndaelCipher.KeySize = 0x80; rijndaelCipher.BlockSize = 0x80; byte[] pwdBytes = Encoding.UTF8.GetBytes(key); byte[] keyBytes = new byte[0x10]; int len = pwdBytes.Length; if (len &gt; keyBytes.Length) { len = keyBytes.Length; } Array.Copy(pwdBytes, keyBytes, len); rijndaelCipher.Key = keyBytes; rijndaelCipher.IV = keyBytes; ICryptoTransform transform = rijndaelCipher.CreateEncryptor(); byte[] plainText = Encoding.UTF8.GetBytes(data); return Convert.ToBase64String (transform.TransformFinalBlock(plainText, 0, plainText.Length)); } public static string Decrypt(string data) { if (data != null) { RijndaelManaged rijndaelCipher = new RijndaelManaged(); rijndaelCipher.Mode = CipherMode.CBC; rijndaelCipher.Padding = PaddingMode.PKCS7; rijndaelCipher.KeySize = 0x80; rijndaelCipher.BlockSize = 0x80; byte[] encryptedData = Convert.FromBase64String(data); byte[] pwdBytes = Encoding.UTF8.GetBytes(key); byte[] keyBytes = new byte[0x10]; int len = pwdBytes.Length; if (len &gt; keyBytes.Length) { len = keyBytes.Length; } Array.Copy(pwdBytes, keyBytes, len); rijndaelCipher.Key = keyBytes; rijndaelCipher.IV = keyBytes; byte[] plainText = rijndaelCipher.CreateDecryptor().TransformFinalBlock (encryptedData, 0, encryptedData.Length); return Encoding.UTF8.GetString(plainText); } else { return null; } } }````
Asked Last updated
.
Post not yet marked as solved
54 Views

OCSP chain revocation

Hi, I'm doing some testing to use OCSP with SecureTransport, and I want to check if kSecTrustOptionRequireRevPerCert is still relevant or if the whole chain is always checked. I did some testing and seems that the whole chain is always checked. Cheers, Jose
Asked Last updated
.
Post marked as solved
2.6k Views

Different SSO behavior for ASWebAuthenticationSession in iOS 14

In our app we're performing authentication using ASWebAuthenticationSession. SSO seems to work fine in iOS 13 for different paths for the same domain but when running the same app in iOS 14, cookies don't seem to be attached to subsequent requests once authenticated in safari window. I'm not sure if it helps : Looking at the logging in instruments when running the app in iOS 14 device, I can see : 00:09.690.903 Default iOS B2c Sample (1691) CFNetwork Default iOS B2c Sample 0x1631f Faulting in NSHTTPCookieStorage singleton 00:09.690.929 Default iOS B2c Sample (1691) CFNetwork Default iOS B2c Sample 0x1631f Faulting in CFHTTPCookieStorage singleton 00:09.690.944 Default iOS B2c Sample (1691) CFNetwork Default iOS B2c Sample 0x1631f Creating default cookie storage with default identifier (Above logs don't happen in iOS 13) and later in iOS 14: 00:10.113.701 Debug iOS B2c Sample (1691) CFNetwork Default iOS B2c Sample 0x1631c Task <88E60E41-6B7B-4787-ABF6-B65C92C8FF4E>.<1> request https://testb2c.b2clogin.com/testb2c.onmicrosoft.com/b2c_1_susi/oauth2/v2.0/token is NOT allowed to set HSTS for main doc  In iOS 13 : 00:15.570.171 Debug iOSB2C (5320) CFNetwork Default iOSB2C 0x24045d Task <79A2078B-718D-4D4D-A46D-1FF1B2238431>.<6> request n/a is NOT allowed to set HSTS for main doc  00:23.139.303 Debug iOSB2C (5320) CFNetwork Default iOSB2C 0x24045d Task <88D45825-FB1E-4C38-8EFF-87A8528B61E3>.<7> request n/a is NOT allowed to set HSTS for main doc  Has anyone noticed similar issue with ASWebAuthenticationSession?
Asked
by amepatil.
Last updated
.
Post not yet marked as solved
725 Views

One time code autofill not working with some codes

We are working on a banking application with sms authentication with otp. We have tagged our ITUextfields correctly with the type .oneTimeCode With some codes this is not being suggested on the keyboard as would be expected. In Messages app they are not suggested for copying either, but we don't know why. Aviso Bankia: Solicitado 27/05 consulta del PIN de tu tarjeta *0285 en Bankia Online. Codigo Firmamovil: 9N2U --&gt; suggested correctly Aviso Bankia: Solicitado 27/05 consulta del PIN de tu tarjeta *0285 en Bankia Online. Codigo Firmamovil: 9QNJ --&gt; It's not suggested Aviso Bankia: Alta de la tarjeta *285 en Apple Pay 28/05. Codigo Firmamovil: RB7V --&gt; suggested correctly Aviso Bankia: Alta de la tarjeta *028 en Apple Pay 29/06. Codigo Firmamovil: 9TVT --&gt; It's not suggested Aviso Bankia: Solicitado 27/05 consulta del PIN de tu tarjeta *0285 en Bankia Online. Codigo Firmamovil: 3T3E --&gt; suggested correctly Aviso Bankia: Solicitada consulta de CVV de su tarjeta ***0285 en Bankia Online. 28/05. Codigo Firmamovil: 8MQG --&gt; It's not suggested Thanks.
Asked
by SergiMob.
Last updated
.