A new kind of code protection

123457»

Comments

  • I, for one, would love to see this happen. Peter has been here the whole time kicking arse. Sharing too.

    I doubt anyone could pack more into 16k.

    Forth and I don't get along, but... with that little assembler, monitor in there? Maybe. :D

    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: http://forums.parallax.com/showthread.php?123709-Commented-Graphics_Demo.spin<br>
  • Chip, what at what stage does the ROM need to be finalized?

    Is it something that can be dropped in towards the end? Or does it need to be there from the start so they can run those startup simulations?


  • Tubular wrote: »
    ... what at what stage does the ROM need to be finalized?
    If it can be done using OnSemi OTP block, then Parallax can sell various ROM choices/flavours..... ;)

    There is clearly a lot of experience and value, in terms of what could go into ROM.
  • Tachyon in ROM means FAT32 and that means booting is possible from SD cards as FAT32 files sans boot chip. It is also a great hardware debug...

    That's worth something right there. Could you squeeze enough into the remaining 14K to make it worth the effort?
  • I'm pretty sure the ROM contents come from a single mask layer. The ROM code is only needed at the end of the chip building process.

  • Locking is Locking,
    You don't want to get a thief in you home! Don't put a door in it.... It is useless .

    I do not need a protection system in p2, but for the 95% of common code theft, it wil slow them down.
    If you do not protect the code, the juridical argument would be that the theft don't know it was copy protected ....
    The last 5% just broke the system, they have the power to do it. Don't waste time on them.

    When you can get in en out the p2, somebody else can get in and out !
  • Guys, its simple.

    @Peter needs to write a TACHYON kernel using the XBYTE feature and nobody will ever be able to disassemble this and make any sense out of it, if he does not love the Parallax community.

    And then we are save!

    I am not a fan of FORTH, I would be fine with the P2-HOT monitor, but somehow it makes sense to me.

    Enjoy!

    Mike
    I am just another Code Monkey.

    A determined coder can write COBOL programs in any language. -- Author unknown.

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Chip, I looked for the updated ROM_Booter.spin2 in the zip, but that's the old version. Can you attach the new version?
  • The reason Basic and Cobol dropped out of the ROM race is very simple, they had zero chance of being selected. Now act so hurt & wounded! as if the final decision is made: Tachyon for ROM!
  • Here is the latest ROM code.
  • ErNa wrote: »
    The reason Basic and Cobol dropped out of the ROM race is very simple, they had zero chance of being selected. Now act so hurt & wounded! as if the final decision is made: Tachyon for ROM!
    If any interpreter is going to be added to the P2 ROM it would pretty much have to be Tachyon since it is the only one that currently exists that I am aware of. Developing one from scratch probably can't be done in the required timeframe.

  • jmg wrote: »
    Addit: this is CryptoAuthentication ATECCC508A feature list

    * Authentication without the need for secure storage in the host
    * No requirement for high-speed computing in client devices
    * Cryptographic accelerator with Secure Hardware-based Key Storage
    * Performs High-Speed Public Key (PKI) Algorithms
    * NIST Standard P256 Elliptic Curve Support
    * SHA-256 Hash Algorithm with HMAC Option
    * Host and Client Operations
    * 256-bit Key Length
    * Storage for up to 16 Keys
    * Two high-endurance monotonic counters
    * Guaranteed Unique 72-bit Serial Number
    * Internal High-quality FIPS Random Number Generator (RNG)
    * 10Kb EEPROM Memory for Keys, Certificates, and Data
    * Storage for up to 16 Keys
    * Multiple Options for Consumption Logging and One Time Write Information
    * Intrusion Latch for External Tamper Switch or Power-on Chip Enablement
    * Single Wire or I2C Interface
    * 2.0V to 5.5V Supply Voltage Range

    Along the same lines, I see Winbond have what they call Secure Flash Memory , which are a combined Crypto engine, and Flash.

    http://www.winbond.com/hq/product/code-storage-flash-memory/authentication-flash/?__locale=en&selected=32Mbit(4MB)#categoryArea

    "Secure Flash Memory solutions comes with standard HMAC-SHA-256 crypto accelerator and 4 separate Monotonic Flash Counters that are HMAC-signed by individual secret keys. System utilizing each Monotonic Flash Counter can not only verify the integrity and authenticity of the counter values, but also add a timestamp to the message/information transmitted with the resistance to reply attacks. W74M enables system designers to strengthen code/data storage as well as delivers increased security with multi-layered authenticity capability for the emerging IoT devices on the edge or outside the cloud. "
  • Good work jmg. Interesting stuff.
  • jmg,

    Your post really should be in a separate thread, so as not to confuse authentication with protection. Those are two entirely different issues.

    -Phil
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • I know this is OT, but I've just gotta say that I'd love to see a FORTH kernel and P2-Hot monitor in the P2 ROM.

    The monitor was one of the coolest features of P2-Hot. Having it sure would take the sting out of last-minute design reductions. :)

    And if resident FORTHs (Mecrisp and FISH) for ARM Cortex chips are great (and they are!), how much better to have a kernel from Peter in the P2!


  • K2 wrote: »
    I know this is OT, but I've just gotta say that I'd love to see a FORTH kernel and P2-Hot monitor in the P2 ROM.
    The monitor was one of the coolest features of P2-Hot.

    There is another thread about P2 monitor, requests are probably best in there.

    I'm not sure language kernels should be in ROM ? - there are better uses for ROM, and better ways to manage language features.


    If the ROM can read designated/protected Flash areas, (and OTP areas), then having "a FORTH kernel in the P2 ROM" becomes less important.
    You could tell the boot loader, to launch forth, via the Flash 'nano-FAT'. To the end user, that appears exactly like 'they booted-forth'.

    It could also launch any bytecode language, including Spin 2 - Parallax just needs to provide a flash-file image, compatible with the ROM, and users can update that.

    eg Winbond parts look to have 4k top/bottom protect and says Complement Protect bit (CMP) is a non-volatile read/write bit in the status register (S14).
    I think that allows a new 'FAT' to be written in the 'other' 4k, and then once verified, that can flip. CMP thus points to which 4K is active, ROM just needs to read that, then look at the info.

  • jmg wrote: »
    K2 wrote: »
    I know this is OT, but I've just gotta say that I'd love to see a FORTH kernel and P2-Hot monitor in the P2 ROM.
    The monitor was one of the coolest features of P2-Hot.

    There is another thread about P2 monitor, requests are probably best in there.

    I'm not sure language kernels should be in ROM ? - there are better uses for ROM, and better ways to manage language features.


    If the ROM can read designated/protected Flash areas, (and OTP areas), then having "a FORTH kernel in the P2 ROM" becomes less important.
    You could tell the boot loader, to launch forth, via the Flash 'nano-FAT'. To the end user, that appears exactly like 'they booted-forth'.

    It could also launch any bytecode language, including Spin 2 - Parallax just needs to provide a flash-file image, compatible with the ROM, and users can update that.

    eg Winbond parts look to have 4k top/bottom protect and says Complement Protect bit (CMP) is a non-volatile read/write bit in the status register (S14).
    I think that allows a new 'FAT' to be written in the 'other' 4k, and then once verified, that can flip. CMP thus points to which 4K is active, ROM just needs to read that, then look at the info.
    You're correct that there is really no reason to have anything in the boot ROM other than the boot code. All of these suggestions have been offered as a way to use the extra space. Certainly, having an interpreter in ROM doesn't hurt anything other than maybe a small delay in the boot process.

  • David Betz wrote: »
    You're correct that there is really no reason to have anything in the boot ROM other than the boot code. All of these suggestions have been offered as a way to use the extra space. Certainly, having an interpreter in ROM doesn't hurt anything other than maybe a small delay in the boot process.
    +1
    Nobody that used a Sun workstation or any other computer that ran OpenFirmware was ever disadvantaged or forced to program in Forth just as nobody had to program their printer in PostScript either.
    I personally like the idea that I can talk to a chip without the need for a Prop loader running on a PC. So I can just talk to a freshly installed chip via Bluetooth from my phone for instance and reprogram it or test the hardware, and neither do I need a boot chip if it is using an SD card running FAT32.

    Is this a case of "throwing the cake in the trash so that nobody gets a piece of it"?


    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    Tachyon Forth News Blog
    TACHYON DEMONSTRATOR
    Brisbane, Australia
  • Regarding the fuses can't the following be a safe solution?

    1) fuse status/value is shown/overlapped in one hub/cog memory location, or an opcode can read them, only if all of them are untouched/unburned. Else their value is available only to rom code.
    2) burn circuitry is enabled only under untouched status
    2) the untouched condition is verified at power-up and maintained for the present power-cycle
    3) any load/boot source (flash/serial/...) is able to execute a program that issues the burn command and is able to read its status again and comunicate it everywhere, even after reset. It can even try to reissue the burn command a few times in case it not detect the change in status.
    4) at next power cycle, since the fuses are not all un-burned, access to them is allowed only to rom code, and the only way to load/execute code is through the fuse-key.

    In this case perhaps the burned key will not be exactly the one I wish, but it will still be verified and known.
    I can't understand how can later an untouched fuse burn by itself. That means that any part of metal/silicon in the chip can do it either, isn't it? How can such a chip be reliable?
    Propeller Object Exchange (last Publications / Updates) --- Oldbitcollector's guest map
    JustForMe
  • The fuses are gone now.
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: http://forums.parallax.com/showthread.php?123709-Commented-Graphics_Demo.spin<br>
  • tonyp12tonyp12 Posts: 1,864
    edited October 26 Vote Up0Vote Down
    >untouched fuse burn by itself.
    The problem is hysteresis, blowing the fuse so spectacularly that there is no chance the state will change a month later.
    But the fuse will stop conducting enough electricity and heat to finish the job when 99% of it's gone, or maybe you just did go over by 1% margin.
    The 99% maybe go to 100% later or the 101% self heals to 99% later, changing the 256key read-value down the road.
Sign In or Register to comment.