RSA bugs

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.

  • I am not able to find these functions. I assume they are part of the non-Xware crypto framework? I would still be willing to take a look and possibly consult with our TLS/crypto developer if you can explain which components of the project you are using. A screenshot or export of the project would work.

    Cheers,
    Janet
  • 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:

    Michal

  • In reply to Michal:

    Well, I would expect some response from Renesas. Or should I report it directly as a bug?
  • In reply to Michal:

    Hi Michal, I contacted Renesas last Friday but have not heard back.

    In general, if you want serious action on any issue, contact tech support and report a bug. That way the request is logged, it has a an expiration timeout (nag feature), and a specific engineer assigned to resolve the problem, find a workaround and/or submit a FIXME in the development database. With renesas rulz posts, there are no such reminders , nor is one engineer assigned responsibility, so it is not uncommon for an issue to go unattended for periods of time.

    Bug 1: You mentioned your crypto library is binary only. But if you can access this part of the crypto source code , you can test your idea by adding

    if (SSP_SUCCESS != err)
    {
    return (err);
    }

    directly after the sf_crypto_signature_hal_verify_final() call and see if that error status is returned properly. I don't have a working set up so I can only get as far as the init/open stage.


    Bug 2: I don't see an instance where this SSP_ERR_CRYPTO_SCE_FAIL is set. Is this an error status received from the TLS peer? Crypto is always hard to debug because of the indirect use of all these function pointers. Grepping on KeyGeneration only shows where it is declared. It is used by:


    const crypto_instance_t g_sce =
    { .p_ctrl = &g_sce_ctrl, .p_cfg = &g_sce_cfg, .p_api = &g_sce_crypto_api };

    But thereafter I cannot see where/when it is called.

    I need to find out who the crypto developer is and ask about both bugs. But I recommend you go ahead and submit a formal tech support request for Bug #1 because it looks obviously wrong, and that will expedite getting attention on this.

    For Bug #2, the development engineer/team might require more information from you (so lump this into the same support request or create a separate ticket).

    Between the two of us, we should get some answers back.

    Janet
  • In reply to JanetC:

    Hi Michal,

    We're looking into issue you pointed out in #1. #2 likely occurs when the generated key is insufficient quality (which prompts user to try again).

    Regards
  • In reply to Renesas Karol:

    Hi 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.

    Michal

  • In reply to JanetC:

    Hi Janet,

    thanks for the info and for notifying Renesas. Next time I'll report such bugs directly. Now it seems it isn't necessary.

    As for #2, I believe it is returned from HAL crypto code and there is no source for it. That's why we can't find it.

    Michal
  • In reply to Michal:

    Hello Michal,

    Upon closer investigation and speaking to the developers the issue you mentioned in #1 is the intended behavior. This function would only fail due to the hardware exception, at which point it is no longer secure to continue the sequence of cryptographic functions. Leaving internal state unaltered at failure forces user to perform close -> open sequence to reset the context and restore operation of the Framework.

    I can confirm that #2 is only thrown due to insufficient key quality and in such cases it is recommended to invoke this function few times until it eventually succeeds. The comment by the error code indicates that even when this error is thrown, some data might have already been output to the I/O buffer.

    Regards
  • In reply to Renesas Karol:

    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