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.
https://github.com/square/Valet/issues/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
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:
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. https://github.com/square/Valet/issues/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:
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: