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.

CC1350: Constant time code execution and instruction caching

Part Number: CC1350


When doing testing for constant execution time on some cryptographically sensitive functions we came across issues related to instruction caching. The first execution of a function would always be a bit slower than the iterations that followed. From what I could find, only instructions are cached and this is not dependent on the actual data being processed. So for our test systems we simply disabled this caching behaviour to get consistent results.

Were the assumptions correct, or are there some edge-cases unbeknownst to me where the execution-time could be influenced by the actual data being processed? In other words, is the caching behaviour on the CC1350 cryptographically safe?

  • Hi Kim,

    As you mentioned, it is very likely that it is instruction caching that is responsible for that behaviour.

    I however did contact our PSIRT team, so that we can confirm that. They will get back to us with an answer.

    Regards,

    Arthur

  • Hi again,

    The PSIRT team will respond in approximately 3-5 business days.

    Regards,

    Arthur

  • What is the status of this?

  • Hi Kim,

    I just got the following answer:

    "

    Kim,

     

    Thank you for reaching out with your observations and concerns. We apologize for the delay in a response.

     

    We have investigated your report, assigning PSIRT number TI-PSIRT-2023-07187.

     

    The CC13x0 and CC26x0 family of parts, including the CC1350, contains an AES HW accelerator which implements the AES algorithm in a constant-time manner with respect to data and key values. Further, because the AES algorithm is implemented in the HW, the SoC’s cache does not impact the security of the AES implementation. This, of course, assumes the SW is using the AES HW accelerator and not implementing AES in SW. Thus, we encourage customers to use the AES SW drivers TI provides in its SDK(s) for these parts as the drivers for these parts make use of the AES HW.

     

    We believe you are correct that the timing difference you are seeing is due to the caching of the SW driver code. This conclusion is supported both by the design of the system and by your test observations when you disabled the cache.

     

    Therefore, we do not believe the observed timing difference represents any risk to the confidentiality of the AES key or data being processed by the AES engine.

     

    In the future, please directly contact the PSIRT team about this or any other suspected vulnerabilities. See https://www.ti.com/psirt for more information. This allows us to follow industry standard disclosure for sensitive information should we conclude that a vulnerability exists. If asking about an issue already reported to PSIRT, it is helpful if the PSIRT number is included. Again, for this report, the number is TI-PSIRT-2023-07187. Please do reach out if you have any additional questions. However, at this time, we plan no further actions on TI-PSIRT-2023-07187.

     

    Thank you again and best regards,

    TI PSIRT.
    "

    Regards,

    Arthur