Crypto hardware reentrancy

We're using S5D5/D9 devices with SSP 1.60.

The SSP manual states: Crypto hardware engine does not support reentrancy. When the crypto hardware engine is busy performing a task, any new request will receive a status error code SSP_ERR_CRYPTO_SCE_RESOURCE_CONFLICT.

My question is if it is meant globally i.e. only one task can use crypto engine at time. It'd be very limiting. Or per operation/alghorithm type like crypto, hash, TRNG etc.

The problem we encountered is we're using RSA key generation from one thread which is rather time consuming task, it can take 10 sec or more. We need to use SHA256 and/or AES GCM from other thread in parallel. We use sf_crypto frameworks and there is one global lock (mutex) for all HAL SCE APIs access so once RSA key generation is started, hash and crypto operations from other thread block on this mutex causing unacceptable delay (breaking our communication protocol).

I'm asking if it is possible to make a workaround and use HAL SCE module for RSA key generation directly skipping the global lock and use at least SHA256 in parallel.

Unfortunately, there aren't sources for SCE modules so I can't check myself :-/

  • Hi Michal,

    The SCE is a single unit able to do one crypto task at a time. So, if it generating an RSA key pair it cannot be hashing other data. It can of course be used from multiple threads but they will have to perform crypto operations sequentially.

    Regards,

    Ian.
  • In reply to Ian:

    Hi Ian,

    thanks. So it is hardware limitation? Well, really strong one against software solution...

    We're using sf_crypto frameworks where locking is handled internally so it works but when RSA keys are generated, other threads are waiting for this mutex for 5 - 20 sec which is both unexpected and hard to handle. Communication timeouts, WDT... tens to hundreds ms for other crypto operations aren't real problem but this one is.

    Michal
  • In reply to Michal:

    I tried to disable sf_crypto mutex just for the sake of the test and when RSA key generation is in progress, hash HAL functions really return SSP_ERR_CRYPTO_SCE_RESOURCE_CONFLICT. Oh well...
  • In reply to Michal:

    Hi Michal-
    If you are willing to share more about your application, I'd be interested to understand what your application needs to do in parallel. Seems like you may be generating keys fairly often. Is that the case? Or is it just unpredictable when you need to do it?
    Do you basically want to have some background secure communications going on, using hash and encrypt/decrypt as needed, in parallel with generating keys? And you can't suspend communications while keys are generated?
    If this is a common use case, I'd like to submit a feature request to allow the required parallelism...
  • In reply to WarrenM:

    Hi Warren,

    it is basically as you say. Our device implements some 3rd party (government) security protocol which involves RSA encryption, verification and generating keys in unpredictable times. It communicates with the host using encrypted and/or signed communication so it needs AES GCM and/or SHA256. When a command which starts RSA key generation is received, the device starts it in a threads and responds to the host. Then the host is free to send next commands and expects responses in reasonable time and here things break because crypto operations necessary for communication are blocked until key generation finished. Which can take 10 - 20 sec. The device is required to respond within 2 sec so host timeouts. We can make a workaround and exceptions for this case but we don't have full control over the host code; we provide an example and communication library but it is a customer who implements the host part and s/he is free to write own code according to our specification. We can of course describe this exception in docs but it is ugly and complicates things for customers which we don't want...

    Well, is there any documentation about SCE hardware? I'm still unsure if the limitation is hardware or software. Normally, RSA key generation is iterative process which can be paused and resumed so parallelism is possible. But if it is completely done by hardware as a single operation, it may not be possible.

    I'm really missing SCE docs and HAL source code. I believe it should be available. Security by obscurity doesn't work.

    Michal
  • In reply to Michal:

    Hi Michal-
    Thanks for the clarification. I believe you should contact your Renesas FAE to find out what SCE docs are available.

    Warren
  • In reply to WarrenM:

    Warren, I already have opened support ticked for it (and Ian responds there).
  • In reply to Michal:

    Hi Michal,

    SCE documentation and SSP SCE driver source are not available.

    Regards,

    Ian.