• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 32 subscribers
  • Views 1379 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.

Permanently Lock Interrupt Vector Table

MrRobot
Prodigy 60 points

Hello,

I would like to implement my own immutable interrupt handler which gets executed at any interrupt and cannot be unset. For this reason, I already locked the interrupt vector table using the command FlashProtectSet(0x0, FlashReadOnly). However, an attacker can simply bypass my protection by storing a modified interrupt vector table in Flash and then redirecting all interrupts to this table using the "Vector Table Offset" register (e.g., with the command HWREG(NVIC_VTABLE)= NEW_ADDRESS). Is there any way how I can permanently set all interrupt handlers, so that further executed command cannot unset them?

Regards

  • 0
    TI__Guru**** 244400 points
    Hello MrRobot,

    No. That is not possible. By the way is the mechanism that you envision for an attacker to use to be able to change the code execution. May be that will help in providing a solution.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 60 points
    Hello Amit,

    thank you for your answer! Ultimately, my goal is to have a protected execute-only code region which once executed cannot be interrupted until execution is completely run through (e.g., because the protected code region performs a cryptographic operation which should not leak any information). However, for this to achieve if the attacker is in the possession of the device, I have to find a way how to permanently disable or control all interrupts.

    Regards
  • 0 in reply to MrRobot
    TI__Guru**** 244400 points
    Hello MrRobot,

    One method is to disable JTAG so that the attacker cannot upload a new application code. To do so, use the BOOTCFG register to disable JTAG and the other method is to ensure that the JTAG pins are connected to GND on the final design.

    Another method is to enable NMI handler which shall perform the operation without any user intervention causing a branch.

    Regards
    Amit
  • 0 in reply to MrRobot
    Guru 27665 points
    That kind of protection probably requires the use of a secure micro rather than a general purpose one.

    Note: it's a matter of increasing difficulty not prevention.

    Robert
  • 0 in reply to Robert Adsett
    TI__Guru**** 244400 points
    Hello Robert

    Well said Sir. I did find the wiki link, which would add value to forum members searching for the similar topics.

    processors.wiki.ti.com/.../Code_Security_Module_FAQ_for_C2000

    Regards
    Amit
  • 0 in reply to Robert Adsett
    Guru 47900 points

    We note that USA's "Fort Knox" (Gold Repository) some way/how does NOT employ ANY vendors' low-cost, non-secure MCUs to achieve security.

    Fools' Gold takes many forms - expecting that one can secure an inexpensive MCU may not prove the case.   If in doubt - ask "Lloyds of London" (or any low cost MCU vendor) to issue a (reasonable) policy to guarantee such "security." (they will not...)

  • 0 in reply to Amit Ashara
    Prodigy 60 points
    Okay. Thank you both for your answer. Do you think the MSP432P4xx family is better suited for my problem, since it specifically addresses the problem of IP protection? I think it will also not be possible to prevent interrupts with this board, but maybe using the "Secure Zones" one can minimize the amount of confidential data that is disclosed to the attacker at each interrupt (which would only be the data in CPU registers, right?)?
  • 0 in reply to MrRobot
    TI__Guru**** 244400 points
    Hello MrRobot,

    I would suggest looking at both C2000 and MSP432 devices actively. One good place would be the forum for the respective devices... Do search the forums for related data before posting to the forums.

    Regards
    Amit
  • 0 in reply to MrRobot
    Guru 27665 points
    A secure micro has specific protections built-in including but not limited to anti-tamper circuits that will erase the contents.

    An SEM is not a particularly expensive piece of equipment anymore. Guarding against an attacker with physical access to the chip is not an easy task.

    Searches on secure micros is likely to bring up some (legitimate, academic) research on protection schemes and their inadequacies.

    Robert
  • 0 in reply to Robert Adsett
    Guru 27665 points
    Also the back issues of the Risks list may prove fruitful.

    Robert
  • 0 in reply to MrRobot
    Guru 27665 points

    As an example of a secure micro, this is a short section of the feature list of one (note that I have little use for a secure micro and have done no in depth evaluation of how well they would actually meet your needs)

    Security Features Facilitate System-Level Protection

    • Secure Boot Loader with Public Key Authentication
    • AES, DES and SHA Hardware Accelerators
    • Modulo Arithmetic Hardware Accelerator (MAA)Supporting RSA, DSA, and ECDSA
    • 8-Line Secure Keypad Controller
    • Hardware True Random-Number Generator
    • Die Shield with Dynamic Fault Detection
    • 6 External Tamper Sensors with IndependentRandom Dynamic Patterns
    • 256-Bit Flip-Flop-Based Battery-Backup AES KeyStorage
    • Temperature and Voltage Tamper Monitor
    • Real-Time Clock

    Note the highlighted sections that are there to protect against physical access.

    Robert

  • 0 in reply to Robert Adsett
    Guru 47900 points
    Re: Robert's "secure micro" write-up.

    Be sure to "gas-up & fill-up" your check-book - when ordering such "secure" devices.

    And be prepared to spend days/months mastering the extra code, methods & practices such devices demand.

    Fools' gold, "Ain't only in them thar hills!" Bandaid security "patches" will delay amateurs - those dedicated to "getting your code" will SURELY, "Have your code!"

    Pity that MCU vendors offer "slight security" and far too often (IMO) rely upon user's lack of awareness/sophistication to trust that "slight security" to prove adequate.

    Again - ask your MCU vendor to "guarantee" that their published security methods will "protect" your code from skilled/determined third parties. None will do so - that's telling - is it not?