• State Resolved
  • Locked Locked
  • Replies 15 replies
  • Subscribers 33 subscribers
  • Views 1556 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

EEPROMBlockHide() behaviour after flashing

Peter Russel
Prodigy 80 points


I am working with the TI Stellaris Launchpad but this question should also be applicable to the Tiva series.

I was wondering about the behaviour of the EEPROMBlockHide() function which is suggested as a means to store keys or other secrets on the board. The idea is to write a key to the EEPROM and then use EEPROMBlockHide() to make the memory section unavailable to any code afterwards. However, if an attacker would get hold of the device and re-flash the board with a firmware that simply reads out the whole EEPROM, he might be successful if the contents of the EEPROM are not deletet during the erasure of flash memory.

I tested it and it seems like the EEPROM indeed does not get deleted, which makes the protection vulnerable to such re-flashing "attacks". I know it is quite a strong adversary model. However, do you have any thoughts on it and if there are any workaround to re-establish security in such a scenario?

Thanks

  • 0
    TI__Guru**** 244440 points
    Hello Peter,

    Which TM4C device is this: TM4C123x or TM4C129x? I am sure there is an errata on EEPROM hidden blocks with soft reset.

    Also a JTAG Unlock Sequence can erase the entire flash and eeprom.

    Lastly, if you have stored the key in EEPROM, with a password, where do you store the password to retrieve the key?

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 80 points

    Dear Amit, in fact I am implementing on the Stellaris platform lm4f120h5qr. I could not find any errata for this mcu and this topic. Also, I am not using any password to protect the EEPROM block as the current functionality of EEPROMBlockHide() seems to be sufficient except the case that a physical attacker could easily read out the secret by flashing her on firmware. Regards

  • 0 in reply to Peter Russel
    TI__Guru**** 244440 points
    Hello Peter,

    LM4F devices will be marked as Rev 1-4 and as far as I know they are not in production. TM4C devices are the equivalent devices for LM4F.

    As for the issue I mentioned. Once the EEHIDE bit is set and a Soft reset of the EEPROM is set then does the EEHIDE bit also get cleared!!!

    Regards
    Amit
  • 0
    Guru 27665 points
    Actually Peter, that's a fairly weak adversary.

    Robert
  • 0 in reply to Robert Adsett
    Intellectual 580 points

    Dear Amit,

    I know that once a (soft) reset is triggered, the previosly hidden EEPROM block will become visible again. However, if the EEPROMBlockHide() function is triggerd inside the bootloader and if one can assure the integrity of this code, then this will pose no problem. Howeever, again, as the attacker would be able to flash the firmware and thus replace the bootloader with some code that simply reads out the EEPROM blocks, this introduces a problem. Thus, I guess an appraoch to mitigate the stated problem is to disable re-flashing functionality entirely or at least for the boto loader section. I will read the data sheets for such functionality.

    Dear Robert,


    it depends on the context. Of course there might be even stronger adversaries that are able to de-package the whole chip using FIB lasers etc. However, in the context of developing a crypto protocol, a physical attacker is considered to be quite strong comapred to a network-based adversary.

    Cheers

  • 0 in reply to André Schaller
    TI__Guru**** 244440 points
    Hello Andre,

    It is the EEPROM reset and not the device soft reset. So even if the boot loader is protected, it does not stop the debugger from doing a soft reset of the EEPROM peripheral, thereby opening the EEPROM for read.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 80 points

    Thanks all for the input. Based on Amit's reply, if one would be able to further disable debugging to mitigate the problem Amit stated? I came across the following thread to disable JTAG access by issuing:

    HWREG(FLASH_FMD) = 0xFFFFFFFD;
HWREG(FLASH_FMA) = 0x75100000;
HWREG(FLASH_FMC) = FLASH_FMC_WRKEY | FLASH_FMC_COMT;

    Further, by using DBG0 and DBG1 one can possibly turn of debugging interface.

    What are your thoughts on that?

  • 0 in reply to André Schaller
    Guru 27665 points
    If you can rely on the security of the device (no attacker will get access to the board), then on chip techniques are of questionable value to begin with. That said I believe you are overestimating the difficulty of getting at the IC inside the package (assuming that's even required which is a big assumption).

    For a number of devices physical security is taken care of already because of where they will be used, so the danger is that an attacker with a copy of the board will find a communication vulnerability that affects all boards. Unless you use a common key EEPROM security doesn't enter into the equation.

    Robert
  • 0 in reply to Peter Russel
    TI__Guru**** 244440 points
    Hello Peter

    Yes, that would close the debug interface and reduce one set of variables. There is one risk that still needs mitigation. The Application code must be a trusted application code. Assume that an incorrect application code gets flashed by the boot loader, which can "unhide" the EEPROM, then it is rather easy for the application code to transmit the key over a serial interface.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 80 points

    Thanks. This effectively means that any updating of the firmware after enrolment must be prohibited unless it is guaranteed to be trusted. Unfortunately I could not find an errata for Tiva MCUs that considers the Soft Reset and EEPROM issue.

  • 0 in reply to Peter Russel
    TI__Guru**** 244440 points
    Hello Peter

    In the description of the register EEHIDE0 "Once hidden, the block is not accessible until the next reset."

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 80 points
    Hi,

    I also figured another alternative to securely hide a key on the Stellaris (besides the EEPROM approach) - on Flash memory.

    The data sheet (SPMA044A) states there are 2 bits FMPPEn and FMPREn that allow for configuring write-, execute- or erase-only on the Flash memory by invoking FlashProtectSet() function. Thus, I thought of the following scenario: In the bootloader a respective memory range in Flash that is supposed to store a secret key is configured to be execute-only and the key is written to it. As far as I can see the bootloader code must not be made write-protected as changes to Flash via FlashProtectSet() seem to be permanent and cannot be undone via chip reset or power cycle (page 32). Thus, one needs to perform a debug port unlock sequence.

    However, I wonder how code should be designed to "compute" the stored secret in executable-only memory?

    Could you please share your thoughts on that approach?

    Thanks!
  • 0 in reply to Peter Russel
    TI__Guru**** 244440 points
    Hello Peter

    If the JTAG is disabled then you can perform soft configuration of the FMPPE and FMPRE registers. At Power On Reset the register value is 1's. if you change the value of the register to 0 then it cannot be written as 1 again or a soft reset does not turn them back to 1. But this would then mean that once a new value must be configured, you must provide either a Power On Reset using power cycle or Reset Pin or have one of the on chip reset source perform a Power On Reset. The second method is only available on TM4C129x devices.

    Regards
    Amit
  • 0 in reply to Peter Russel
    Guru 27665 points
    Will O' Wisp, you are chasing a Will O' Wisp.

    Easily broken, as soon as there is access to the JTAG (which I expect is easy to get) you can just run a program from flash or SRAM to execute anything in the execute only area. That's assuming the method used to get access to the JTAG doesn't also provide a way to bypass the execute-only flag which is a rather optimistic assumption.

    Seriously if you need to protect the key look at external cryptographic modules (TPM comes to mind as the big one but I'm pretty sure there are others, perhaps with better attributes). Such devices do not let the key out of the module. Good ones should have anti-tamper circuitry, but even less secure ones will have more thought behind the architecture and probably better protection than you can provide.

    You also need to consider how to manage security certificates, chains of authority and revocation. If you are using a single key than all this extra protection is probably completely pointless.

    Robert
  • 0 in reply to Robert Adsett
    Prodigy 80 points

    Rvobert, thanks for your thoughts.

    With regard to JTAG access there seems to be a method to permanently disable debug interface (see this thread):

    HWREG(FLASH_FMD) = 0xFFFFFFFD;
    HWREG(FLASH_FMA) = 0x75100000;
    HWREG(FLASH_FMC) = FLASH_FMC_WRKEY | FLASH_FMC_COMT;


    I know that the solution I am striving for is questionable. However, for a lot of low-cost/legacy devices TPM is not an option. Thus, I was thinking about how far one could push the limits on such devices.