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.

RTOS/TM4C129XNCZAD: bug in AES library causing unintended access the memory

Part Number: TM4C129XNCZAD
Other Parts Discussed in Thread: AES-128

Tool/software: TI-RTOS

Hi,

I'm using the TI-RTOS tirtos_tivac_2_16_01_14

there is a bug in the AES library that caused unexpected behavior for our application, and after many hours of trouble shooting, the bug is found.

the bug is in the in AESDataWrite API which is invoked by AESDataProcess. such that i have a packet of data with length 23 byte that i wanted to be encrypted using the AES-128 and even the data length that is passed by the application is 23 but the AESDataWrite  will write to the memory of length 32bytes which is multiple of 16 bytes regardless of the application passed value.

I'm writing this thread for two reasons:

1- show the bug to TI so they can fix it.

2- help other people to fix thier application because i know that such issue will cause hours and hours of investigation depending on the random behavior that can be caused by unintended access to the wrong memory location.

Thanks,

Mohammed Fawzy

  • Hello Mohammed,

    Thank you for taking the time to post on our forums. I want to inform you that the described behavior is not a firmware bug. Let me explain what is occurring and why.

    First of all, the API description is very clear on how it functions:

    //! Writes plaintext/ciphertext to data registers with blocking.
    //!
    //! \param ui32Base is the base address of the AES module.
    //! \param pui32Src is a pointer to an array of bytes.
    //!
    //! This function writes a block of either plaintext or ciphertext into the
    //! AES module.  If the input is not ready, the function waits until it is
    //! ready before performing the write.  A block is 16 bytes or 4 words.
    //!
    //! \return None.

    Note that is specifically calls out that it will write a block to the AES module and that the block is '16 bytes'. Therefore all writes must be in multiples of 16, so that is clearly documented.

    Furthermore, this requirement is not a firmware driven requirement but rather it comes directly from the AES encryption process. From the datasheet:

    "AES is an efficient implementation of the Rijndael cipher (the AES algorithm) and a 128-bit polynomial multiplication (referred to here as GHASH, as per the AES-GCM specification). Rijndael is a block cipher in which each data block is 128 bits"

    Therefore, to use the AES cipher, it must get 128 bits of data, which is 16 bytes, which is where the requirement to have multiples of 16 comes from, and that is why the TivaWare API's are written as they are.

    Does this explain to you why the TivaWare code is configured that way so it is now apparent that it is not a bug in the library? With proper understanding, you can address it correctly within your system.

  • Thank you Jacob for your reply.

    great, and i want to understand more, so how the function will wait till the data being ready ?
    "If the input is not ready, the function waits until it is ready before performing the write. A block is 16 bytes or 4 words."
  • Hello Mohammed,

    That concerns checking that the AES peripheral being ready to receive the next 16 bytes of data. There is a flag which can be checked within the Control Register for the AES peripheral which indicates when the peripheral can accept new data. The API polls that flag until the peripheral indicates it is ready to receive data, and then the API loads the data passed to it into the AES peripheral Data Registers.

  • Hello Ralph,

    I understood more and if i'm going to develop the same driver, i will do the same technically.
    but i think that the function description isn't clear about the incoming length restriction to be multiple of 16 bytes, especially that the description mentioned the maximum length which is 2^32. so i wish if the description can be modified so no one can misunderstood the input parameters constrains.

    Best Regards,
    Mohammed Fawzy