• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 30 subscribers
  • Views 201 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSPM0G1507: Possible to reduce secure bootloader size

Tiger Wang
Prodigy 155 points
Part Number: MSPM0G1507

Tool/software:

I understand that the bootloader (in SDK example) is using TI version of MCUBOOT. Comparing to the publicity version of MCUBOOT, it uses TI crypto libraries.

However, the crypto part isn't open-source and non-configurable.

I made a slightly change to the SDK, simply replace the public key verification with uECC (micro-ECC). I further optimized the build options of uECC, removing unused signature type (signing method, we only use secp256r1, aka ). I found out that the bootloader size could be reduced by 3784 bytes. What I am thinking about, probably following reasons:

  1. uECC has higher efficiency of ECC signature verification.
  2. Ti current library has multiple crypto support, such as RSA, and/or different bits support for ECC and RSA. Since we don't use other crypto suite at all, then we have benefit to use our customized uECC

So, the call-out is that what if:

  1. Can Ti provide relate source code and corresponding build script (makefile, etc..) to have further build option to reduce the size of the crypto library?
    1. By setting different flag, some crypto may not be supported, hence, save size.
  2. If open-source isn't available, can Ti provide multiple library that for each one, only support certain (/w combination) crypto suite?
    1. e.g.,  bimsupport-ecc256.a, bimsupport-rsapss2048.a, ...
  • 0
    TI__Genius 16000 points

    Hi Tiger,

    We do not plan to make our crypto libraries publicly available. So I believe that leaves us with your option #2, but to make sure I understand correctly, you'd like the examples to be offered with only one crypto suite each, so that the compiled library provided for each one is smaller and has a smaller memory footprint for users who only use one suite?

  • 0 in reply to Dylan OBrien
    Prodigy 155 points

    Yes, I think you understand correctly. If possible, please provide following:

    1. ECDSA256 only
    2. ECDSA385 only (if already supported)
    3. RSAPSA2048 only
    4. Full suit
    5. Other combination that you think valuable

    Thanks.

  • +1 in reply to Tiger Wang
    TI__Genius 16000 points

    This method would not actually reduce the memory footprint on your device, this would just reduce the size of the precompiled libraries before loading them to your device.

    When your project is being linked during the build process, only the function calls that you actually use in your project are pulled into the final output file. So if you only use one security suite in your code project, then only that code will be pulled into your final binary file. The extra code from the library that you do not call will not be included in the binary that is flashed to the device anyways.

    If your update simply the original library with this third party library, and it reduced your binary file's size significantly, I would say this is because the third party library is simply more optimized for memory footprint.