Generating SRP verifier in S140?

[evanperrygrove]

I would like to use the CC310's SRP accelerator with an application that uses S140. The uC in question is nRF52840.

I have added this code to the ble_app_blinky example. In essence, this code does the following:

1. initialize the crypto engine with nrf_crypto_init
2. initialize the RNG using nrf_crypto_rng_init
3. initialize an SRP context using CRYS_SRP_HK_INIT, supplying a non-null password, and a custom rndGenerateVectFunc that calls the SoftDevice random number generator functions.
4. Generate a salt and verifier pair by calling CRYS_SRP_PwdVerCreate.

Here is a sample of the output:

00> <info> app: Blinky example started.
00> <info> app: my_rnd_generate_func
00> <info> app: out_ptr:
00> <info> app:  0D 43 72 A3 D5 DF 78 B0|.Cr...x.
00> <info> app: verifier:
00> <info> app:  00 00 00 00 00 00 00 00|........
00> <info> app: salt:
00> <info> app:  0D 43 72 A3 D5 DF 78 B0|.Cr...x.

The random numbers are being generated, and they are written into the salt, which makes sense. However, the verifier is zero. The gist shows me printing the first 8 bytes of the verifier, but I also checked bytes 16-23, 128-135, and 256-263, and those are zero as well.

Am I doing something wrong? Some discussions here seem to indicate that the library support for CC310 is shaky, but I'm not getting any error codes from the function calls. Is this an issue of library support, or am I just using the library wrong?

Also, if it's a library issue and I can't use CC310 through S140, will Oberon do the job?

[Kenneth]

Hi,

Unfortunately we don't have any example or experience with SRP Functionality in CryptoCell. I don't have any good suggestion here, other that you may consider using the RNG in the CC310 (instead of the RNG in the softdevice). That is what nrf_crypto is doing, and I suggest you try the same.

Kenneth

[evanperrygrove]

For now, I am using Oberon, since it seems to work properly and it provides the functionality I need. If I understand the documentation correctly, I'm probably not supposed to be calling directly into the Oberon API, but this seems to be the path of least resistance.