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.
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.
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.
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. 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.
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.
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?
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.
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.
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?
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.
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.
>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.
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.
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?
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.
>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.
Comments
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!
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/
We can all move on now, right?
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
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.
Indeed. I think people frequently over-value the software they write.
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.
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.
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.
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.
Pastebin.com
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
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.
What about removing the flash chip and just re-running that short program?
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.
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.
And what happens when the battery dies?
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.
-Phil
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.
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 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.