| ??? 02/26/08 07:40 Read: times |
#151469 - the value... again... Responding to: ???'s previous message |
Lynn Reed said:
Still, the code is in a flash, and any die can be cut open and its memory read by any failure analysis lab in a few weeks for a few thousand dollars. It's worse than that. There appear to be "labs" building up expertise on particular chips to be routinely "unlocked" by low-cost non-intrusive techniques. Also, these "services" are often run in countries where the cost of labour is low. This all might decrease the value of the common lockbit maybe an order of magnitude lower. The trouble (for the user, but maybe even for the manufacturer) is to get an appropriate assesment on this value for a given chip/design. Lynn Reed said:
But if I synthesize the program into gates, and use a few other layout encryption tricks, I can raise the cost of reverse engineering the code into years and millions of dollars. Can you? I do respect your expertise, but, from the viewpoint of a (potential) customer, what are the assurances there is no single point of vulnerability in your scheme? As with a new firmware the layout would be presumably completely different, this should potentially be reviewed for each new design. This does not sound to be too cheap. Also, does the mega$ pricetag apply also to 1:1 copy of the chip (by selective removal of layers and "OCR"ing)? Below, you mentioned also some checksumming scheme. Would you, as the chip manufacturer, take some guarantee that this step won't leak out the code? Etc.etc.etc. Lynn Reed said:
The disadvantages for this approach are that the code is now hard encoded, it takes 8 weeks to get parts, and that it gets expensive for low volumes < 3K. At 10K units, it would probably add $2 to the unit cost. This is not quite a correct statement as far as security is concerned. This is an new approach - and new modes of failure of the whole scheme will emerge. Just an example - the mcu would now represent the value of the product, i.e. it's not the $$ part anymore, it's value is suddenly $$$-$$$$. So, it has to be handled appropriately, each individual piece. And the manufacturer suddenly has to deal with a stock of 10k or so of the mcus, with a lump value easily reaching up to mega$s - this certainly represents a personal, logistical and - again - security problem. All this said, I don't say this is not an option. And, I would like to thank you for throwing it up, although - sitting on the "garage" side of the business - it's unlikely I will ever be able to use it. However, at the end of the day, it has to be understood that there is nothing like absolute security, and that equation of many variables and unknowns has to be solved for each and every individual case, again and again. Jan Waclawek |
| Topic | Author | Date |
| Obtaining maximum code security | 01/01/70 00:00 | |
| Worth it ? | 01/01/70 00:00 | |
| Protection with Patents | 01/01/70 00:00 | |
| the value... again... | 01/01/70 00:00 | |
| "OCR"ing a Design | 01/01/70 00:00 | |
| It's a brave man | 01/01/70 00:00 | |
| Specialist secure micros | 01/01/70 00:00 | |
| this is a different form of security | 01/01/70 00:00 | |
| Huge NREs? | 01/01/70 00:00 | |
| What if you don't bond out nPSEN? | 01/01/70 00:00 | |
| why not drop !EA | 01/01/70 00:00 | |
| Don't Drop !EA! | 01/01/70 00:00 | |
| Couldn\'t you do that in another way | 01/01/70 00:00 | |
| Eliminating /EA | 01/01/70 00:00 | |
| The value of PSEN | 01/01/70 00:00 | |
| not only... | 01/01/70 00:00 | |
| Brute-force copying | 01/01/70 00:00 | |
| well, maybe... | 01/01/70 00:00 | |
| Erase on tamper detect | 01/01/70 00:00 | |
| Make the chip hard to access | 01/01/70 00:00 | |
| It's quite impractical... | 01/01/70 00:00 | |
few thousand dollars ... Not at all | 01/01/70 00:00 |