Shop OBEX P1 Docs P2 Docs Learn Events
A new kind of code protection - Page 4 — Parallax Forums

A new kind of code protection

12467

Comments

  • Yup. I consider it all idle chatter anyway. We had to dump the fuses.

    Time to move on.

    Really, we all should be prepared for this stage of the project. As the final QC happens, we will be left with the possible.

    And that is still a great package!

  • TorTor Posts: 2,010
    Listen to Phil, guys.. he's 100% right. No home-made scheme has ever survived for long.
  • Heater.Heater. Posts: 21,230
    And, me. And me. I said it first http://forums.parallax.com/discussion/comment/1423111/#Comment_1423111 :)

    Thanks Phil for pushing the point.

    For reference, even the experts in the protection field can't do it : Denuvo’s DRM now being cracked within hours of release
    Best-in-class service can't even provide a full day of protection these days.
    https://arstechnica.com/gaming/2017/10/denuvos-drm-ins-now-being-cracked-within-hours-of-release/

  • evanhevanh Posts: 15,126
    Heater. wrote: »
    And, me. And me. I said it first ... :)
    Actually, I'll claim that one on the third reply. :P
  • Heater.Heater. Posts: 21,230
    So you did.

    We can all move on now, right?
  • AribaAriba Posts: 2,682
    Nobody here wants to invent a new secure protection scheme. That is just not necessary.
    It's the thinking of software guys that want to protect something that can be easy reproduced and distributed in unlimited quantities.

    But if you produce a hardware with a P2, the situation is totally different. The "Cloner" needs to reproduce the PCB, the enclosure and needs to invest money for all the components.
    If he then can not just copy the data from the Flash chip to a new one, but needs to find all the obfuscated serial number tests, 99.9% of the "Cloners" will not take the risk.

    Andy
  • Besides the "best method" I mentioned earlier the other way is to make a product dependent upon being up-to-date in that a cloned product does not have support and commercial products always need updates and need to be compatible with the latest other updated devices etc. I have found that anyone who wants to copy something will find a way to copy it, and copying the hardware is dead simple. However they don't have the source code, so they can't support or update it so why would somebody buy that product, even if it's cheaper? I wouldn't.

    A product has to be commercially viable for a cloner and when they have to discount their me2 product to bargain basement prices it's not worth it any longer. A smart cloner will see the writing on the wall before they start. If however there is so much profit margin in your product that there is still fat for the cloner despite having an "older model" then they still have to compete with the distributors and support channels. Despite the P1 FPGA source being readily available I still don't see any clone chips, it's not worth it.
  • A product has to be commercially viable for a cloner...

    Indeed. I think people frequently over-value the software they write.
  • tonyp12tonyp12 Posts: 1,950
    edited 2017-10-23 14:56
    Why not leave the fuses in, If u need to use them apply 4-5V, load a small routine that will spit out the result of the key on a pin.
    If intended key was not successful, no big deal, you got a different one to use just for this board as firmware is encrypted on a case by case to be installed on SPI flash.

    Use another master key to encrypt this key, and print it as a label on the board, if in the field firmware is needed and you don't want to rely on a data base.


  • Master keys tend to become public at some point. Initially only a few people have access to the master key. After some time more people in engineering, manufacturing and field service know the master key. And then a sales guy that needs to do an urgent update for his special customer needs the key immediately. Once the sales guy gets it the master key spreads like wild fire. And then there's always the possibility of a disgruntled former employee that will post the key for the public to view.
  • potatoheadpotatohead Posts: 10,253
    edited 2017-10-23 15:32
    Once the sales guy gets it the master key spreads like wild fire.

    True story:

    In the early 2000's, I was working for a firm that handled sales, service and support for a very expensive, high end entertainment and styling software company. Good seats of this stuff started at $5-7k, and would top out over $30k.

    Then there was this sales push, and they sent some slick guy out to show and tell us all about it. :D He had some trouble with his setup, pulled out a CD-ROM, did a little bit of work, and was up and running. Can anyone guess what his trouble was?

    So we took him to lunch, did the usual talking, sharing of stories, hype. When it all ended, a buddy and I were talking, and there it was! That CD-ROM. :D

    Turns out it contained a license generator, including the master vendor key for a well known license manager software! It also contained a template file, populated with all the feature names possible. (this is amazing, as it opens up specialized, customer specific features unavailable to a normal unlimited file as those must be specified explicitly)

    We made a quick copy to play, because why not? It's not like mortals get to play with that kind of software, and we wondered how it all worked.

    In about an hour, we had a world wide, unlimited license, all features, any host, floating 5000 seats! !!! And we had that for every version there ever was, and could be for a considerable time, unless the vendor key were to change. Turns out it did, but not for many years, and an acquisition.

    We never shared the actual generator, nor the license files we created, but... I'm quite sure someone did.

    What were did find strange was the guy never contacted us. He had to know he left it. The question was deliberate, or just shame as reason for no contact.

  • And then there's always the possibility of a disgruntled former employee that will post the key for the public to view.

    Pastebin.com



  • I'm glad that the fuses are dead. Good call, Chip! :)

    As for the FLASH, I wonder if that:
    - Is possible (I hope not, because I wish it to be external);
    - How much silicon area will it occupy?

    Kind regards, Samuel Lourenço
  • ElectrodudeElectrodude Posts: 1,614
    edited 2017-10-23 16:39
    tonyp12 wrote: »
    Why not leave the fuses in, If u need to use them apply 4-5V, load a small routine that will spit out the result of the key on a pin.
    If intended key was not successful, no big deal, you got a different one to use just for this board as firmware is encrypted on a case by case to be installed on SPI flash.

    Use another master key to encrypt this key, and print it as a label on the board, if in the field firmware is needed and you don't want to rely on a data base.

    Yes, why not do this?

    Wouldn't it be more secure anyway if every chip got its own key? That way, extracting the key for one chip only lets you reprogram that one chip and not all the other ones in the same product.

    EDIT: You don't even need 4-5V. Just try blowing random fuses at 3.3V until enough are blown. If a randomly chosen fuse blows, good. If it refuses to blow, try another one until, say 40%-60%, are blown. Roughly what is the mean and variance of the number of blowable fuses on a chip at 3.3V as it stands now?

    Can you just leave the fuses in, and only people who are willing to do it this way will be able to use them?
  • cgraceycgracey Posts: 14,133
    edited 2017-10-23 17:01
    tonyp12 wrote: »
    Why not leave the fuses in, If u need to use them apply 4-5V, load a small routine that will spit out the result of the key on a pin.
    If intended key was not successful, no big deal, you got a different one to use just for this board as firmware is encrypted on a case by case to be installed on SPI flash.

    Use another master key to encrypt this key, and print it as a label on the board, if in the field firmware is needed and you don't want to rely on a data base.

    Yes, why not do this?

    Wouldn't it be more secure anyway if every chip got its own key? That way, extracting the key for one chip only lets you reprogram that one chip and not all the other ones in the same product.

    EDIT: You don't even need 4-5V. Just try blowing random fuses at 3.3V until enough are blown. If a randomly chosen fuse blows, good. If it refuses to blow, try another one until, say 40%-60%, are blown. Roughly what is the mean and variance of the number of blowable fuses on a chip at 3.3V as it stands now?

    Can you just leave the fuses in, and only people who are willing to do it this way will be able to use them?

    For a random fuse pattern to be used for code protection, it must be known by the one doing the encrypting. What you are describing would have to be discoverable to be useful, but in being discoverable, it's no longer secret - it would just be a device ID. That's why having the user pick the pattern is important. He sets it and the device conceals it. Then, he exploits the known-to-him pattern for encryption.

    So, blowing a random pattern would only be good for giving a unique ID number to each Prop2.

    The other thing that worried me about the fuses was if they might partially re-heal over time and look unblown. That would be a huge problem.
  • tonyp12tonyp12 Posts: 1,950
    edited 2017-10-23 16:59
    User would load a short program to make it discoverable (part of the fuse burning software), once the regular encrypted firmware is installed there is now way possible to get the key to the outside again.
  • cgraceycgracey Posts: 14,133
    tonyp12 wrote: »
    User would load a short program to make it discoverable (part of the fuse burning software), once the regular encrypted firmware is installed there is now way possible to get the key to the outside again.

    What about removing the flash chip and just re-running that short program?
  • Bean wrote: »
    Speaking for myself only. I don't need SHA256 encryption or anything like that. I just would like something that a customer cannot just copy the EEPROM contents and duplicate the hardware.

    Right now, I would use a 1-Wire "unique serial number" only device and have the code check for that serial number. It works, but it is a pain. And requires the code to talk to a 1-wire device.

    I'm not worried about the customer getting the code, because it wouldn't be worth their time to learn about the propeller, then look for the code that checks the serial number, etc, etc. They would just buy another board instead of going thru all that work.

    Basically just keeping the honest people honest. Any protection scheme can be cracked if someone is willing to do the work.

    At one time I thought of using a scheme where I would damage one of the I/O pins (maybe by shorting it to ground when it is HIGH) then connecting it to another pin in some way, so that it would act different from a normal propeller chip. But I never tried it.

    Bean
    Ariba wrote: »
    Modern SPI Flash chips have a factory programmed unique serial number and an area to store user configuration data independently from the normal memory sectors (SFDP, 256 bytes).

    From Winbond Datasheet:
    "The Read Unique ID Number instruction accesses a factory-set read-only 64-bit number that is unique to each W25Q32FV device. The ID number can be used in conjunction with user software methodes to help prevent copying or cloning of a system."

    Such a Flash chip is anyway required for the P2, so there is no additional chip necessary to install some simple protection against cloning.

    Andy

    With P1 I used Ramtron FM31L278 to replace the 32K eeprom. Beside the watchdog and RTC it have also writable serial number with one-time lock and two 16bit counters (chainable to one 32 bit) that operate also under battery backup. I used to have partially encrypted image in the 32K FRAM. The first part of code read the counter values and used this together with the serial number to decrypt the hub. If by opening the box the counter values was changed the decryption key has gone.
    It can be hacked, of course ... but it take some time to understand how is working. And when understood at least you need another new product to experiment your learning.
  • tonyp12tonyp12 Posts: 1,950
    edited 2017-10-23 19:34
    >What about removing the flash chip and just re-running that short program?

    You would not get the short program to install and run again, unless you encrypt it with the key that only you know, nothing will ever get installed again without key encrypted firmware.
    Routine is not in ROM, Keys are not spit out because it don't see a spi flash, routine is wiped out by the actual firmware.

    It would be good if this routine survives a brownout reset though, in case you did not catch the data it uarted out (though it will repeated 6 times)
    or when blowing a fuse caused P2 in to low power reset.

  • Phil is correct - you should only trust the advice of someone who has recently cracked several protection schemes.
  • TonyB_TonyB_ Posts: 2,105
    edited 2017-10-23 19:22
    Would it be possible to add a 32-bit register to each of four smart pins with the same VIO and use a battery to keep these 128 bits alive?
  • TonyB_ wrote: »
    Would it be possible to add a 32-bit register to each of four smart pins with the same VIO and use a battery to keep these 128 bits alive?

    And what happens when the battery dies?
  • You call your vendor.
  • tonyp12tonyp12 Posts: 1,950
    edited 2017-10-23 22:08
    I'm with Electrodude, send in a program to randomly burn-the-bridges from inside.
    When done, it tell you the result.

    This program can also do your bed-of nails testing etc.

    It have a "run-me-again" header and checksum, so P2 will run again it in case of a reset, so no bricking.
    I think run-again feature would be good for quick boot up's, maybe it's the 2nd stage bootloader & gpio initializer etc.
    Though no self-mod code would be allowed.
  • tonyp12 wrote:
    I'm with Electrodude, send in a program to randomly burn-the-bridges from inside.
    When done, it tell you the result.
    If it can tell you the result, it can tell anyone else the result. Hence, no security.

    -Phil
  • tonyp12 wrote:
    I'm with Electrodude, send in a program to randomly burn-the-bridges from inside.
    When done, it tell you the result.
    If it can tell you the result, it can tell anyone else the result. Hence, no security.

    -Phil
    If you are willing to have only a single shot at programming the fuses you could have the boot ROM check to see if they are all in their default state. If so, it would load an unencrypted program over serial and allow that program to read/write the fuses. If any fuse was not in its default state the boot ROM would assume a key had been programmed and would load a program from either the attached flash or the serial port and authenticate it with the key. It would then set a bit that disallowed reading/writing the fuses before starting the loaded program. Would that work?

  • jmgjmg Posts: 15,140
    David Betz wrote: »
    If you are willing to have only a single shot at programming the fuses you could have the boot ROM check to see if they are all in their default state. If so, it would load an unencrypted program over serial and allow that program to read/write the fuses. If any fuse was not in its default state the boot ROM would assume a key had been programmed and would load a program from either the attached flash or the serial port and authenticate it with the key. It would then set a bit that disallowed reading/writing the fuses before starting the loaded program. Would that work?
    Such schemes could work, but Chip was worried about false/accidental programming of fuses, and fuse-healing, causing field issues.
    To me, those concerns are valid reasons to remove fuses from the boot-tree.

    I'm not sure there is enough hard data on actual fuse reliability, before the test chips are here, but some call is made.

    However, what you describe could be used to store unique serial numbers, which is a corner stone to at least anti-clone security.

    Note in another thread, a NXP part is discussed that mentions

    "High security enabled by AES-128 cryptography, high assurance boot (HAB), TRNG and on-the-fly QSPI flash decryption"

    the on-the-fly QSPI flash decryption sounds impressive.
  • tonyp12tonyp12 Posts: 1,950
    edited 2017-10-23 23:20
    >If it can tell you the result, it can tell anyone else the result. Hence, no security.

    It will only tell you once, just after you blow the fuses and you are ready to program the SPI Flash to hold the firmware that will be encrypted on the fly with this key.

    If P2 have run-again-from-ram-after-reset (anti-bricking) after enough fuses have been blown (40-60%) it will delete that run-again header-id,
    maybe also after confirmation from uart communication that keys was received, but as you write this code you can make what ever rule you want.

    After you reboot it will load the encrypted firmware, this firmware will never allow to send that key to the outside (you wrote this code)
    You can never get another program in, to reveal the key, unless you already know the key.

    Only problem is fuse-healing, redundancy would even be hard with a mirror version as some fuses will not blow, so you can not initially set it up as Raid5 with 2/3 the key length.
  • The fuses have gone - just let go.
  • Heater.Heater. Posts: 21,230
    I agree. Let it go.

    The number of people that will want to protect their P2 code is indistinguishable from zero.

    The number of those that actually need to protect their P2 code is vanishingly smaller than that.

Sign In or Register to comment.