Shop Learn
Possible that Prop can be more code secure than other MCUs? - Page 3 — Parallax Forums

Possible that Prop can be more code secure than other MCUs?



  • HannoHanno Posts: 1,130
    edited 2011-08-21 15:45
    Tubular- let's catch up later today to discuss next steps...

    I think the first goal of this is to properly document how to use the Propeller in commercial applications where the code must remain secret. (I'm surprised this hasn't been published as an official app note years ago) At first I would stress simplicity wherever possible....

    Longer term goal would be to let customers update their own firmware on their device. This is harder- but still doable. Customers would receive an encrypted binary and tool with which they update their device. Upon receiving a new binary, the Propeller would zero all RAM and then decrypt the new image and restart.
  • TubularTubular Posts: 4,414
    edited 2011-08-21 20:09
    Hanno, I'm out on site for most of the next 36 hours, but lets use skype chat

    I guess there are various forms this can take.

    For what I want to do, all the secure stuff (algorithms) would be pushed all the way down into cogs, similar to what Siemens PLCs do (some function blocks can be IP protected). These secure cog(s) are loaded at the factory and battery backed up forever afterwards.

    The other cogs and hub ram would be regarded as not secure, and the usual prop tools could be used to write and modify "glue code" and constants/setpoints that makes use of the services provided by the secure cog(s).

    Ideally we would find a way to "protect" the secure cogs from an accidental cogstop command, but this isn't essential, at least initially.

    Lawson, you're right, and I'm looking at using RCFAST for normal operation, plus an external clock for serial syncing (a bit like the prop acting as an SPI slave with external master clock for serial data streaming), and RCSLOW after power is lost. However one problem with allowing access to the "unsecure" hub is that the clock source could be switched to external, then stopped or slowly ramped down.

    Phil, I'm looking at the ADG3308's for potentially isolating the pins during the power down state. They allow data transfer in both directions without having to manage the directions pin by pin. I haven't fired them up just yet though.

    I have to admit, the debug conduit has risks, and it may be simpler to start with a heavily locked down design (and get it working), then gradually open it up to make it more practical.
  • HannoHanno Posts: 1,130
    edited 2011-08-23 15:58
    Status Update- Tubular and I had a very productive discussion on properly documenting the hardware to allow secure commercial applications using the Propeller- as well as using one cog to allow users to update their firmware securely.

    Is anyone else interested in using the Propeller for commercial applications - but currently reluctant to do so due to lack of code protection?
  • Cluso99Cluso99 Posts: 17,970
    edited 2011-08-23 17:30
    I am interested although I don't have a specific requirement for code protection ATM.
  • Mark_TMark_T Posts: 1,981
    edited 2011-08-25 08:48
    Leon wrote: »
    Dunking it in red fuming nitric acid will dissolve the epoxy.

    There are chips with strong code encryption, of course, that are virtually immune to attack.

    The nitric acid attack would risk shorting out the supply (fuming nitric acid is ionic and conducts well) thus losing the program. It is a standard method for attacking SIMs and smartcards which have program in ROM. Having exposed the bare chip you can read out busses with micro probes and directly manipulate the chip.

    Having the program only in RAM makes this a harder attack. Of course static RAM does preserve its state after powerdown to some degree owing to capacitance and ion migration related burn-in, so it might be a feasible attack given enough resources...

    Those with the requisite resources would probably try more direct means of obtaining the commented source code from the developer's machine which is likely to have more points-of-entry - do you trust a source code management system's security that much?
  • zoopydogsitzoopydogsit Posts: 174
    edited 2011-08-25 20:33
    Hi Tubular, what a fascinating idea and an amazing read. I hope this works!

    If so then I can see parallax/others building it into consumer grade platforms aka spinneret style of near finished solution that you'd just need to code. Still probably keeping the EEPROM to issue a self destruct overwrite to ram on a forced/tamper reset.

    Something to add in the supporting technote is a caution to ensure secure programming and bounds checking on all external input to prevent buffer overflow conditions from cracking the device. For example if the product used the SD card, and someone replaces the data on the SD card, yet your code loads into a ram until a null terminator, then they could load the code of their choice to adresses beyond where you expect data. Then when your code tries to execute (the now overwritten code) from the next location it starts running their code not yours. Their code might be to dump memory contents out of p31. However if your code only pulls in 4 longs, and doesn't wait for the terminator then they can only muck with data.
  • prof_brainoprof_braino Posts: 4,312
    edited 2011-08-26 07:18
    Hanno wrote: »
    Is anyone else interested in using the Propeller for commercial applications - but currently reluctant to do so due to lack of code protection?


    I figured it was possible but beyond my ability. Now that the "big people" are focusing on this, I'm looking forward to results, positive or negative. I image there will be various degrees of success, and trade-off, as in all things.

    Thanks for the effort!
Sign In or Register to comment.