Crypto and BLE

Hi,

I saw RL78 does not feature hardware crypto. My question is : did you plan to add it one day as it seems the new RL78/G23 family still lacks it ?
It's a real deal breaker in a world where security is becoming critical, not to say mandatory almost everywhere. This forces many of us considering tiny 16bit MCUs only to jump into another solutions (PIC24 MCUs).

Would be very happy to see a crypto unit in your RL78 MCUs because they really rocks for everything else !

BLE 5.0, 5.1 and 5.2 SoCs/Modules would be also nice to be part of your products.

Best Regards

  • Hello Philou!

    We appreciate your suggestions regarding RL78 features. I hope our experts can get back to you soon. Thank you.

    All the best!

    Sai
    RenesasRulz Forum Moderator

    https://renesasrulz.com/
    https://academy.renesas.com/
    en-support.renesas.com/knowledgeBase

  • Hi Sai,

    Thanks.
    Anyway, is there a workaround such as an external tiny crypto chip to use along with the RL78/G14 MCU, but simple enough to do not overload the final board design?

    B.R.

  • Hi Philou,

    This is an old request, but I thought it was worth posting a correction. 

    You are incorrect about the RL78/G23, as it does feature basic hardware crypto elements for doing authentication, PKI Certificates, anti-cloning, and IP protection. 

    We also have crypto software libraries to help you use these features.

  • Hi Calvin,

    Could you show me in the RL78/G23 datasheet and block diagram, where the hardware crypto engine is, because I don't see any ? There's nothing actually featuring SHA1/2, AES128/256, ECC and/or RSA.
    Software libraries are not an option in a lot of security contexts. Yes for underlying mechanisms such as firmware protection there's, but I was talking about hardware unit used to encipher / decipher data streams and compute hashes on the fly during runtime...

    See for example the datasheet of this 8-bit MCU (section 3.13): STM8AL31E88TAY and you'll get what I mean. There's AES 128 hardware engine we can use through DMA in it, and many other 8/16-bit MCUs around there are even able to do much more... 

    B.R.


  • Here's the block diagram from the Renesas webpage. You can see the Crypto Hardware block in the lower right corner. The TRNG is an important base element for PKI. The unique ID is important for anti-cloning and authentication. There is also a configuration block for a OEM provided Customer unique ID.

    You are correct to point out that there is no AES acceleration or hashing acceleration. These would need to be implemented using a software library, which would limit the performance on high-speed data streams. But the RL78 isn't likely to be streaming encrypted video or audio data anyway... but if you really need it, there's a way to use the RL78/G24 (due out soon) hardware to speed up the AES process.

  • Hi Calvin,

    I saw that, but from the beginning I was not talking about the one to protect against cloning. I was talking about a way to encrypt/decrypt, sign/verify, hash any data buffer at runtime. Even if the chip isn't likely to stream video or audio, there's many scenarii where a device (powerfull or not) must send/receive data streams or chunks using CAN, I2S, I2C, SPI, RS232 or whatever. And if the payload is small, it's still not supposed to be caught and eventually replayed by any way, especially when we are talking about transactions involving signatures and authentications based on challenge/response...

    Communications are everywhere today and it's very common to use that kind of MCU to design wireless nodes, card readers, loggers and acces control devices using NFC, Bluetooth, WIFI or just network cables. That's why to me the RL78/G23 is definitely not what I consider to be a solution ready for such situations...

    Ok about RL78/G24, we will see. I would be very happy to see it's finally becoming true :-)

    B.R.

  • I agree there are going to be many cases where the RL78/G23 wouldn't fit, especially for high-speed AES encrypted data streams faster than 1Mbps. But there are plenty of cases where RL is a good fit.

    Lower speed (non-streaming), packet based encryption/decryption can easily be handled in AES using software libraries - depending on how much memory, and processing load is available. The same goes for hashing and signature verification, since those actions typically take place during connection initiation - not continuously. A good example is the RL78/G1H that runs at 32Mhz, handling WiSUN RF packet data with all verification, hashing, and encryt/decrypt operations handled in software. Sustained data throughput is 100kbps and faster.

    Is there a specific use case you are thinking of? What are the data rates and specific AES parameters? Are there network requirement for time-out or acknowledge that mean the crypto operations have to use acceleration?

  • It is worth noting that your request for BLE 5.x SOC modules has been realized since your original post. Since the merger with Dialog we have a number of products that might be of interest. BLE Modules

  • Hi Calvin,

    I understand your point, you already mentioned the fact there's a software library and I already replied that crypto based on software is considered to be a vulnerability in my environment. Here's why :

    There's no evidence the library is programmatically safe. And even it is, it comes with a firmware made by someone else. Code (signed or not) often contains bugs (buffer overruns, pointers to wrong areas) and/or unsafe practices (workflows based on external inputs with missing checks) which could give someone a chance to get the encryption/decryption keys stored because both the program and the data memory is accessible from the firmware itself.

    About placing a key in a data section by declaring a byte array in the source code, I would say it adds extra complexity if the main coder/programmer shouldn't know the value of that key. Putting a key in a dedicated key store lets both the firmware and the developer to use it, but not to read its value.

    There's many fields where the key value
    1) should never be known at all by anyone
    2) should never appear anywhere in both source code and common flash memory
    3) should never be directly accessed by anything from outside the engine

    HSMs/Smartcards and especially pkcs#11 devices attempt to execute commands sent within a pin protected session. These devices are often asked to generate a key that is never accessible by any way from outside the unit. Once the command succeeded, the only value you get is a key handle (just a number referring to that key). This way, the firmware is only allowed to perform encryption/decryption/signature via key handles. Although someone could introduce an issue in the firmware (libs or whatever), still NEVER someone could get the key value, because it is stored in a dedicated OTP key store inside the crypto unit that is not readable from any other units on the chip. This kind of key store is also supposed to be harder than common flash memory to be identified and read using heavier methods such as e-microscopes.

    About cases which could raise such considerations : I think any storage system potentially could.
    It's quite common when a device is asked to store whatever sensitive data into an external sram, fifo or flash, then read back them later. The right way to do is to generate a key, then use it only through it's corresponding key handle (#5 for example) to encrypt data before storing them. And of course we can later read them back encrypted and decrypt them using the same key handle.


    I'm ok with the fact your example does the job about workflow and right computations, but it doesn't about protecting few sensitive data at the best level we can get for a similar budget.
    And pushing further the idea that since there's software library, we needn't hardware engine, can lead to the following assumption too :

     - Why asking for an hardware I2C unit since you can do it using bit banging with a library already provided?
     - Why asking for a GPU since we can compute all transformations using the general purpose CPU and adequate libraries?
    ... and so on

    Thus some would reply :

    Why would we choose another way to do if, in a given laps of time, it won't produce more result, will consume more energy, will be programmatically less safe, less stable and won't cost less than the first solution ?


    In my case, I must keep all my keys in a stronger place and I care also about power efficiency.
    So let's see if the RL78/G24 will seduce me more...

  • Yes, I heard about it. I already bought a dozen of DA14531MOD three weeks ago and they are promising.
    Using SmartSnippets, I browsed few examples and found they're almost all made for Keil V5. The problem is that Keil recently passed in version 6 and all examples are unable to get compiled from out of the box. Since I did not find a way to get back Keil V5 for free, experiments are now in standby mode...

    Frankly, it would be nice if we could get rid of Keil. I don't think Keil is a good choice when it's about ARM32. GCC is both powerful and flexible enough without the need to subscribe anywhere nor pay for previous versions.