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.

LAUNCHCC3220MODASF: Cloning Protection and encryption of gang_images

Part Number: LAUNCHCC3220MODASF

Hello,

i have some questions related to the cloning protection and the encryption of gang_images and unpacked images.

* Is Cloning protection always active ?

* If an production image created with uniflash and flashed via spi programmer to s-flash is save in terms of the information inside the image ?

** This means if i have flashed the gang image and then bootloader has unpacked the image and if i then read it back could i extract sensible information about the software ?

*** Like some private keys which are placed in it? I think information in there is only save if i use my private certification chain with everything what's needed.

*** Whats about certificate updates if a certifcate is invalid or unsecure and i want to update that and things in field are only having OTP information as they left our production ?

Best regards,

Arnaud

  • Private information (such as private keys) can be stored as secure files.

    The MCU image is always stored as secure file.

    Once the bootloader extracts the gang image, it will create the FS where all the secure files are encrypted using unique device key. 

    This will prevent the cloning threat (the content can only be decrypted by the the same device that encrypted it).

    Br,

    Kobi

  • Hello Kobi thanks, that was the information i need. But what will happen to ota-files ? Files which will be flashed in our production could be assumed that there is no leak. But when deploying ota file's could there be the information extracted from ?

    In Addition Cloning protection will always be on or do i have to take some explicit steps while creating uniflash image ?

    BR,

    Arnaud

  • Hi,

    in addition setting the dummy-root-ca-cert as secure won't be successfull because it has to be unsecured. So this file could be read back even after unpacking loaded gangimage thorugh nwp and securing file system right ?

  • Hi i think there is a bug in my thoughts.

    dummy-rootca-cert is the public key so it could be used for verifiyng not for signing right ? So it could be left there unsecure. mcuflashimg.bin will be encrypted by UDID of NWP so it is safe.

    For OTA-packages i assume information could be retrieved if i got access to a ota package. Like getting an ota-file because i am getting the file from the update server while he won't check if the client is allowed to receive a ota package. So we have to ensure ota packages won't get by everyone only client which got the rights to do that. I we keep ota file on seperate storage we should encrypt this additional storage right ?

    So if secure the process in retrieving ota packages and keeping them in an encrypted place like an additional faslh we are safe right ?

    BR,

    Arnaud

    PS: Am i assuming right that communication from Host MCU(Application Controller)(sl_api) to NWP on TICC3220MODASF isn't encrypted ? So if i am sniffing that communication the content could be read from my side so there is backdoor because i have to use sl_api for getting information from sflash via NWP ?

  • The cloning protection is always enabled.

    The OTA process assumes that both the server is secure (so you private file can't be accessed by others) and the data transfer is secure (i.e. using SSL/TLS).

    Those are basic requirements from an OTA server.

    Once the image is loaded to the device, the ota library parses it and stores the secure file encrypted.

    Public keys can be stored without security.

    Note that the dummy Playground certificate are just for development and should not be used in production (as everyone has access to the private keys).

    The communication between the HOST and the NWP is not encrypted, but this is not a problem in CC32xx devices as this SPI is not exposed.

    br,

    Kobi