Post Go back to editing

PKTE decryption examples

Category: Hardware
Product Number: ADSP-SC573

Hi there,

I'm attempting to use the PTKE module to decrypt a file. I was able to port the following example code from the SC8xx to SC573 and get it somewhat working:

 ADSP-SC58x/2158x PKTE Hashing-Decryption  - Example code 

The challenge is that the example only deals with a single block (16 bytes) of data. When I attempt to decrypt a larger data object, only the first sixteen bytes are decrypted correctly. This applies to the Host, TCM and Autonomous modes, and I suspect it relates to the Initialization Vector, but it's difficult to know for sure.

The example code isn't very clear (mysterious, hardcoded values and commented out lines of code. This is a very complex peripheral, and it would help greatly if an example could be provided that is able to decrypt more data, say 1MB.

Thanks in advance.

  • Hi,

    We are checking on this and we will get back to you as soon as possible.

    Regards,
    Nandini C

  • Edit - I'm now able to successfully decrypt a block of data using the TCM example, but I'm limited by the 20 bit TOTLEN field, meaning I can decrypt up to 1048575 bytes in one go.

    I'd appreciate some guidance on how to "chain" multiple PKTE_TCM operations together to iterate over a larger block of data than can be processed in a single iteration.

  • Hi,

    Apologies for delayed response.

    Glad to know that you were able to decrypt a block of data using TCM mode with 1,048,575 bytes of data.

    Unfortunately, we don’t have example code for TCM mode, but we do have examples for Direct Host mode and Autonomous Mode in PKTE, where larger data is processed using the chain descriptor method.

    If you haven't already checked application note EE-386 (Using the Security Packet Engine to Protect Data), we recommend to check the example code provided there. Please refer to the link below:
    https://www.analog.com/media/en/technical-documentation/application-notes/EE386v01.zip

    In this AES example, refer to the aes_dhm_example2 function. This example demonstrates how the PKTE is used when the data buffer is filled to its maximum capacity.

    Could you please use this as a reference and modify it according to your requirements for PKTE TCM mode?

    Regards,
    Nandini C

  • Thanks - I'll look into that. One other quick question, is the adi_pkte API add-in available for the ARM core on the SC573? The header is present in the Cortex-A5 toolchain (drivers/crypto/adi_pkte.h), however the linker returns an error when I attempt to use it:

    c:/analog/cces/3.0.2/arm/arm-none-eabi/bin/../lib/gcc/arm-none-eabi/10.2.0/../../../../arm-none-eabi/bin/ld.exe: src/security/pkte_api.o: in function `pkte_hashtest()':
    C:\Users\<redacted>\Debug/../src/security/pkte_api.cpp:242: undefined reference to `adi_pkte_Open'

  • Hi,

    Unfortunately, the adi_pkte.h driver is not supported on the ADSP-SC573xx processor. It is available starting from the ADSP-2156x processor.

    Regards,
    Nandini C

  • For anyone else who runs into PKTE challenges on the SC573:

    (1) There's no adi_pkte add-in for the SC57x, so you need to implement your own driver layer.

    (2) If you're hashing in multiple iterations (i.e. hashing a file that exceeds the TOTLEN max of ~1MB) then all individual hash operations must be executed on a block of data that's a multiple of the block size. Only the final block can deviate from that requirement.

    (3) The HWRM documentation is pretty minimal, for instance it doesn't describe the workflow for calculating an HMAC

    (4) You can more or less piece it together by using app notes for other products (like the ee-368.pdf doc for the Blackfin, linked to by Nandini C below). Although cryptic, this allowed me to get the HMAC to work. Note that the two operations below on the left are regular non-final hash operations. The operation on the right is the HMAC operation, and is of the "final" type.

    (4) It's very fussy about where you store the various buffers. For instance, it behaved differently if they're on the stack vs. the heap. If in doubt, stick 'em in the uncached L2 like below.

    uint8_t k0ipad[64]__attribute__ ((section (".l2_uncached_data")));
    uint8_t k0opad[64]__attribute__ ((section (".l2_uncached_data")));

  • Hi,

    We are checking this query internally, we will get back to you soon.

    Regards,
    Nandini C