Why is the datasheet only available with NDA? This is a reason for me to switch something else ... It's impossible to use the crypto element without datasheet ...
Nice explanation! at 9:01 when you say "no knowledge of IO Prot key", I presume the IO Prot is stored in the MCU flash. Can't it be read externally using an MCU tool/programmer? How is that key protected in the MCU? Also, on the same diagram, how does the mcu know the result of the CheckMAC (happy or sad face)? How does the secure element send the result back to the MCU? Can this specific transaction be intercepted and spoofed - ie, just send happy faces all the time?
What exactly makes the bootloader "immutable"? Can't an attacker just replace the bootloader with some malicious code that does not initiate the secure boot process?
Protection from uC HW itself. You got lock bits and locked memory regions.Also the App Image can check the boot-loader too with the Auth IC's help i guess.Some uC vendors can completely lock flash writing in the hardware (embedded flash controller will simply deny the write operation) until the application/boot-loader itself re-enables it.
We do not want use OEM root private key for signature. Keys should be used for one purpose and not for others. The proper way is to use use an OEM intermediate key to sign the application image. A Certificate from OEM root would be needed to ensure the validity of the OEM intermediate public key. => Could you please provide more details, to still allow a possibility to enlighten more than to confuse all this.
Your approach is spot-on. You would keep the OEM root public key in the ECC608. Sign the firmware image with the intermediate private key and provide the certificate with the intermediate public key and signed by the OEM private key. Verify the intermediate public key signature with the OEM root public key inside the ECC608 first. Then use the intermediate public key to verify the firmware signature. I think we just described the same thing. Contact support.microchip.com if you want to talk with an expert in your area.
Hello Amando. We don't provide technical support here on RUclips. Please go to support.microchip.com to post this question on one of our forums or to create a support ticket.
Why is the datasheet only available with NDA? This is a reason for me to switch something else ... It's impossible to use the crypto element without datasheet ...
But it all falls apart if the boot loader is compromised.
Nice explanation!
at 9:01 when you say "no knowledge of IO Prot key", I presume the IO Prot is stored in the MCU flash. Can't it be read externally using an MCU tool/programmer? How is that key protected in the MCU?
Also, on the same diagram, how does the mcu know the result of the CheckMAC (happy or sad face)? How does the secure element send the result back to the MCU? Can this specific transaction be intercepted and spoofed - ie, just send happy faces all the time?
What exactly makes the bootloader "immutable"? Can't an attacker just replace the bootloader with some malicious code that does not initiate the secure boot process?
Authenticate the bootloader itself. AFAIK in AVR you can read the bootloader from the bootloader flash area.
Protection from uC HW itself. You got lock bits and locked memory regions.Also the App Image can check the boot-loader too with the Auth IC's help i guess.Some uC vendors can completely lock flash writing in the hardware (embedded flash controller will simply deny the write operation) until the application/boot-loader itself re-enables it.
We do not want use OEM root private key for signature. Keys should be used for one purpose and not for others. The proper way is to use use an OEM intermediate key to sign the application image. A Certificate from OEM root would be needed to ensure the validity of the OEM intermediate public key. => Could you please provide more details, to still allow a possibility to enlighten more than to confuse all this.
Your approach is spot-on. You would keep the OEM root public key in the ECC608. Sign the firmware image with the intermediate private key and provide the certificate with the intermediate public key and signed by the OEM private key. Verify the intermediate public key signature with the OEM root public key inside the ECC608 first. Then use the intermediate public key to verify the firmware signature. I think we just described the same thing. Contact support.microchip.com if you want to talk with an expert in your area.
how to ensure that the unchangeable bootloader supports this chip and its Methods ? (Where is the kompatability List ?)
hi, I try to use this ATECC608A with a PIC 18f4550, but I don`t know which is the best form to used. I really apreciatte your help.
Hello Amando. We don't provide technical support here on RUclips. Please go to support.microchip.com to post this question on one of our forums or to create a support ticket.
@@MicrochipTechnology thanks, I'll send my question