Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reconsider Design of Keychain integration #1

Open
tholenst opened this issue Jul 7, 2023 · 0 comments
Open

Reconsider Design of Keychain integration #1

tholenst opened this issue Jul 7, 2023 · 0 comments

Comments

@tholenst
Copy link
Contributor

tholenst commented Jul 7, 2023

Tink ObjC has integration with the iOS keychain in https://github.com/tink-crypto/tink-objc/blob/main/Tink/core/TINKKeysetHandle.

However, when adding a keyset to the keychain, the attributes are set by Tink (e.g. https://github.com/tink-crypto/tink-objc/blob/main/Tink/core/TINKKeysetHandle.mm#L288-L296). In general, I don't find it clear that Tink choosing these attributes for the user is the correct choice.

For example, for kSecAttrAccessible, the Apple developer documentation states: "Choose the most restrictive option that meets your app’s needs so that the system can protect that item to the greatest extent possible." It doesn't seem that Tink can do this.

It also sets kSecAttrSynchronizable to false, which for some users also might not be what they want.

Another point is that it sets kSecClass to kSecClassGenericPassword, which intuitively feels wrong (though I can imagine that there is a very good reason for this).

In general, I feel it might be better if the user sets these attributes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant