We're using S5D5/D9 devices with SSP 1.60 and e2studio 7.3.0. For RSA we're using sf_crypto frameworks.
Bug 1: when verifyFinal() operation fails, subsequent contextInit() call fails with error SSP_ERR_INVALID_CALL. It is because of the bug in the SF_CRYPTO_SIGNATURE_VerifyFinal() function (file sf_crypto_signature.c):
When HAL verify returns error SSP_ERR_CRYPTO_SCE_VERIFY_FAIL which is correct and expected, the internal state isn't updated and then state check fails on the next contextInit() call(s).
The SSP_ERR_CRYPTO_SCE_VERIFY_FAIL is the correct result when signature check fails which is one of two expected outputs. IMO above check is incorrect on any error and the state should be updated unconditionally.
Also, the contextInit() logic is dubious. Why it checks the current state? It should always reset the operation and start from the beginning.
Now how to fix it? The fix is easy but the sf_crypto_signature.c file is encrypted. What is the expected way to fix such problems?
Bug 2: RSA keyGenerate() functions returns SSP_ERR_CRYPTO_SCE_FAIL occasionally. It is rare but I've already seen it few times when tested bug 1. Called the same way from the same code and normally it works as expected. This part of code isn't even available as encrypted sources, only as libraries. Which is really bad idea because such bugs can't be debugged and fixed.
In reply to JanetC:
Sure. They're part of sf_crypto framework which is, I assume, standard way how to use crypto on Renesas platforms. These bugs aren't related to Xware crypto at all. Our project isn't using any part of your crypto framework, it has a bit different purpose than we need and also, part of sources are missing which I see as a big problem. Both development and security.
Relevant part of our project configuration:
In reply to Michal:
In reply to Renesas Karol:
thanks. More descriptive error code would help for #2. Current one is defined like this:
SSP_ERR_CRYPTO_SCE_FAIL = 0x10002, ///< Internal I/O buffer is not empty */
Also, shouldn't it be handled internally? However, I understand it could take rather long time.
As for #1, I believe it is mainly contextInit() problem. It shoudln't check the current state and reset the context unconditionally, instead. What's the purpose of this check, anyway? If I understand correctly, it is supposed to be called when one wants to start new sign/verify operation regardless of the result of previous one.
Hi Karol, I disagree with #1, that's not true. This function returns SSP_ERR_CRYPTO_SCE_VERIFY_FAIL when data passed in aren't verified by the signature. This isn't an error, this is expected result. One of two possibilities, verified or not verified. The function is imperfectly designed, it would better return verification result as a separate (bool) parameter and not as an error code. Current way it has to handle SSP_ERR_CRYPTO_SCE_VERIFY_FAIL error code differently as it isn't hw exception but the result. I'd agree with your reasoning i.e. close/open after a real error but this particular error code has to be handled differently. The purpose of this function is to verify data signature and it makes no sense if it stops work on data which were refused. The data come from external source and it is quite possible some won't be valid. As for #2, thanks for confirmation. Still I'd suggest to rename the error code to something more descriptive :) Michal