I have a service which generates cellular network SIM profiles, and persistently stores related provisioning data for the profiles on the customer's behalf for later retrieval. The data is confidential and must be protected. After generating the data, the service must not be able to access the data in an unprotected form. When requested, the service provides the data in an encrypted form, which can only be decrypted by the customer. The transport between the customer and the service uses TLS 1.3 mutual authentication.
When placing an order, the customer provides a RSA public key, for which they have a corresponding private key. For each set of data, the service generates a new AES secret key, encrypts the data using the secret key, encrypts the secret key using provided public key, creates a bundle consisting of the encrypted secret key and the encrypted data, and then stores the bundle is a database.
When the customer requests the provisioning data, the bundle is pulled from the database and provided as-is. The customer then reverses the process using their private key to obtain the secret key, and then uses that key to decrypt the provisioning data.
This is an example of what is included in the provisioning data. Almost all item values are either sequential or randomly generated, so the likelihood of two sets of data being identical are effectively zero.
Question 1: Since no two sets of provisioning data will ever be the same, does an IV with a random/non-repeating value actually provide any value? I am currently sizing it to the smallest permitted and leaving it with the value of 0.
Question 2: SonarLint is flagging the use of RSA/ECB/PKCS1Padding as a potential vulnerability. Is it something that I should be concerned with for this type of application?
Ron McLeod wrote:]Since no two sets of provisioning data will ever be the same, does an IV with a random/non-repeating value actually provide any value? I am currently sizing it to the smallest permitted and leaving it with the value of 0.
Even if you can guarantee that two sets of data are never the same, can you guarantee that no two blocks that the data consists of will ever be the same? Why run the risk? Generate a unique IV for each message and add it to the bundle.
Is it something that I should be concerned with for this type of application?
ECB is insecure if your message size is larger than one block. Seeing as your AES keys are smaller than the RSA block size, you're probably good.