Can I calculate data integrity check for RSA keys using the key itself?

Question

I'm developing a solution which stores in a DB, for each customer, an RSA key which will be used to sign payments. Those keys are so called SIM keys created via an SKS HSM, long story short we don't store actually the key in our DB but only an encrypted blob that only the HSM can use. In this way no one, except the HSM, knows what the keys are.

In order to prevent an inside attacker, with access to the DB, to switch keys among users it was decided to calculate, for each key, an integrity check and store it together with the key.

The solution is to perform an HMAC of customerId + key, in this way it would be impossible to switch keys among users without breaking the integrity check.

The key used to calculate the HMAC is dedicated for this use case and is stored in the HSM. However this point is the one I would like to change and for which I'm making this question.

Technically speaking it would be possible to calculate the integrity check using the RSA key itself by encrypting customerID + key using the public part of the key. However CTOs are blocking this solution because they said the same key should never be used for signing and encrypting.

In my opinion the guideline to have separate keys for signing and encrypting doesn't apply to this case, in fact the guideline is true but only if we would actually expose an API that perform encryption and signing using the same key, which is not the case. The encryption operation we perform is against data generated by the application itself, not an input, is always the same for the entire lifetime of the key and is used only for the integrity check of the key itself.

I'm looking for someone with security knowledge that can help me understanding if the principle "don't use the same key for signing and encryption" really applies to this case, which in my opinion doesn't.

Thanks a lot.

Answer 1

Your CTO is correct on blocking this. Because you didn't give the details on what kind of payment solution you're building, just the fact you're storing, process and/or transmitting cardholder and/or sensitive authentication data puts you in scope for a PCI-DSS or a PA-DSS audit.

But there are very strict rules for key rotation, strength (you didn't mention the SHA to use with HMAC) and storage when handling sensitive cardholder data.

If you aren't familiar with the PCI Security Council , get ready to learn fast. They publish the guidelines that you as a developer must abide by if you are either developing an in-house solution or one for resale. The first overview are the guidelines themselves:

https://www.pcisecuritystandards.org/pci_security/maintaining_payment_security

As stated above, this forum really is no place to begin to discuss the details of all of the required secure coding practices, network segmentation considerations, employee separation of duties, etc. that are included in complianc = and along with mountains of paperwork and possible quarterly scans. And, based on your size and payment volume, an outside auditor.

In a former position I managed the US, Europe and South America's PCI & PA-DSS software compliance programs and it was very costly. Talk to an expert because you do not want to be the next breach of the day. It sounds like your CTO understands the implications so I'd listen to him.