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

Update keychain usage, remove obsolete method #27

Merged
merged 2 commits into from
Jan 25, 2024
Merged

Conversation

akiselevn
Copy link
Collaborator

Given

Previous solution relied on generation public key / private key / certificate for each needed request
(retrieve card details / card lookup / retrieve pin).
Although, it is advisable to delete the keys that are no longer needed, or reuse the same key pair for multiple requests, if possible.
But it could be not so secure to expose generated keys tags and save it somewhere so it could be deleted later, or to reuse the same persistent private key for the long time (if it will be compromised we will not know about it) - SDK implementation used keys saved in keychain for crypto operations.

Problem

Possible impact on client’s devices:

  • private key block size: 512
  • public key block size: 512
  • Certificate size: 1224 bytes
    Those items will be saved in keychain for each request and will not be deleted
    Although keychain is presented by SQLLite, it can store a lot of records, but it will have impact on performance and filesystem.

A related discussion came up on Valet, a popular third-party Keychain library put out by Square.
Apparently, 4KB is the "soft limit" and 16MB is the only known hard limit.
Anything in-between risks a keychain error due to the system killing securityd.
square/Valet#246

Generating a new key pair for each user request and storing them in the keychain with different tags can result in a large number of keys in the keychain storage over time. This can have some negative effects, such as:

  • Increasing the size of the keychain database and the backup files.
  • Slowing down the keychain operations, such as searching, adding, or deleting keys.
  • Making it harder to manage and organize the keys, especially if you do not have a clear naming scheme for the tags (tags in our solution was autogenerated).

New SDK version

Do not use keychain as a persistent storage for generated keys (public / private), create certificate and do crypto operations on fly, then release that security data immediately after it was used.

Additional pros:

  • Obsolete method for key generation was replaced to recommended one
  • SecKeyGeneratePair (deprecated from iOS15) —> SecKeyCreateRandomKey
  • Instead of creating and saving public key at the same time as private key - generate private key and then when needed generate public from private

- keys generated on each request
- after each generation keys stored in keychain within generated tag
- since tag is not predefined - it is impossible to reuse or even clean keychain
@akiselevn akiselevn self-assigned this Jan 25, 2024
@akiselevn akiselevn merged commit 5f902da into main Jan 25, 2024
1 check passed
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

Successfully merging this pull request may close these issues.

None yet

1 participant