kSecAccessControlOr?

Hello,


Trying to understand kSecAccessControlOr.


I attempt to store data into the keychain - protected by password or TouchId.


the idea was to use access control like that:

kSecAccessControlTouchIDAny|kSecAccessControlOr|kSecAccessControlDevicePasscode

I would interpret this as use touchIdAny or passcode. Now if there is no finger print saved this results in an error.

if it was

kSecAccessControlTouchIDAny|kSecAccessControlAnd|kSecAccessControlDevicePasscode -> ok - yes, clearly it should fail


So, how to understand the kSecAccessControlOr?

As kSecAccessControlTouchIDAny|kSecAccessControlOr|kSecAccessControlDevicePasscode and kSecAccessControlTouchIDAny|kSecAccessControlAnd|kSecAccessControlDevicePasscode seem to result in the same - what is the difference?

Any insights?

Thanks!

best



Up vote post of steff3 Down vote post of steff3
1.1k views
Posted by
steff3
Reply
Add a Comment

Replies

Before we go down the 

kSecAccessControlOr
rabbit hole, I want to ask about your high-level goal. You wrote:

I attempt to store data into the keychain - protected by password or [Touch ID].

Why don’t you use 

kSecAccessControlUserPresence
for this?

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware 

let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment

Hello Quinn,


thanks for your answer, very much appreciated.


This is my suggestion (to the stake holders) as well, to take the UserPresence. However, the documentation for the UserPresence-option as well does not give me a concise explanation. [On top it is stated that is concerns TouchId and passcode; at the bottom it states equivalent to TouchIdAny, Or and ApplicationPassword ] And my tests did not output what I expected from the description there ( equivalent to TouchIdAny, Or and ApplicationPassword) either.


Nevertheless, as a developer it always feels good to be able to have arguments when discussing this with stake holders. 😉


Thus, it seems that it might be good to understand kSecAccessControlOr


Thanks!


best wishes,

Steff

Posted by
steff3
Up vote reply of steff3 Down vote reply of steff3
Add a Comment

To start, I presume we’re talkinga about iOS here. This stuff is supported on macOS and works pretty much the same way, but I’ve been running my tests on iOS.

This is my suggestion (to the stake holders) as well, to take the UserPresence. However, the documentation for the UserPresence-option as well does not give me a concise explanation. [On top it is stated that is concerns TouchId and passcode; at the bottom it states equivalent to TouchIdAny, Or and ApplicationPassword ]

And my tests did not output what I expected from the description there ( equivalent to TouchIdAny, Or and ApplicationPassword) either.

I’m having a hard time parsing the above. Well, I get your first point, (that the documentation is not great) but I don’t understand your second point. 

kSecAccessControlUserPresence
seems to do exactly what you want, namely:

  • If the device has Touch ID enabled, it authenticates using Touch ID

  • If not, it authenticates using the device passcode

I tried this out here in my office, setting up the access control like this:

kSecAttrAccessControl: SecAccessControlCreateWithFlags(nil, kSecAttrAccessibleWhenUnlocked, [.userPresence], nil)!,

and it worked as I’ve described it above.

Do your expectations match mine? And what are you seeing?

Thus, it seems that it might be good to understand 

kSecAccessControlOr

Fair enough. Alas, I don’t have any experience to share on that front. If you need help with 

kSecAccessControlOr
then you should open a DTS tech support incident and talk to DTS’s Security framework expert.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware 

let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment