Re: Executing Encrypted Code
At 9:52 PM 12/19/1996, Bill Frantz wrote:
At 12:08 PM -0800 12/19/96, Peter Hendrickson wrote:
If each chip has a unique public/secret key pair, and executes authenticated code only, there are some interesting implications.
Software piracy becomes difficult, if not impossible. Code is sold on a processor by processor basis. Code for a different physical processor cannot be decrypted or executed.
This makes backup hard. That is the rock the routine copy protection hit up against. There were many, me included, who simply said, "If your product is copy protected then I will buy from your competitor."
No, you can backup just as much as many times as you like. The code isn't stored on the chip permanently, it is only decrypted there. There is a similar problem, though. If your processor dies you could lose your software library. There are ways to mitigate this. One is for the vendors to just trust people and reissue the code to a new processor. Of course, you track how often you have to do this. Or, you could turn in the broken processor and have the manufacturer certify that it was turned in to the software vendors and that a new version of the software should be generated. This might not be so important if you generally pay for metered software.
Viruses are not feasible if the authentication is strong.
So is user written code, public domain code etc. If there is an un-encrypted mode for that kind of code, then viruses again become possible.
User written code is harder to arrange, it is true. You might have a way to execute non-authenticated code but at a speed comparable to an emulator. Or, you might just have another computer for running your own code. Right now it is not uncommon for a software library to exceed the value of the machine. It might actually be economical to have two machines if one of them can support a rich software library which doesn't cost as much money because it can't be pirated. Free software is still possible to run at full speed, but it has to be authenticated. The free software writer just has to do whatever the software vendor had to do to get it okayed. This makes it harder to release free software, but the effort is still a small fraction of the work required to build a significant application. Getting it to execute for particular processors is easy. You could release a piece of software which takes code and encrypts it for your particular hunk of silicon. If you could offer otherwise free software for, say, $20 and know that everybody using it will pay, many people might consider that to be a great deal. Right now the mechanisms of moving the software are too expensive to really make it feasible for something under $20. Development might be a bit tricky, but there are workable solutions. The manufacturer could release special processors which have an additional authentication mechanism for software developers which is specific to each developer. They could authenticate code to run on their own machine, but not on anybody else's. This does make it possible for software developers to pirate software (if the can get a secret key), but if the number of development processors is low, this could be manageable. If the environment was well defined, you could conceivably develop in a high level language on one platform, but deploy for sale on the decrypting-processor platform. Peter Hendrickson ph@netcom.com
At 11:16 PM -0800 12/19/96, Peter Hendrickson wrote:
At 9:52 PM 12/19/1996, Bill Frantz wrote:
At 12:08 PM -0800 12/19/96, Peter Hendrickson wrote:
If each chip has a unique public/secret key pair, and executes authenticated code only, there are some interesting implications.
Software piracy becomes difficult, if not impossible. Code is sold on a processor by processor basis. Code for a different physical processor cannot be decrypted or executed.
This makes backup hard. That is the rock the routine copy protection hit up against. There were many, me included, who simply said, "If your product is copy protected then I will buy from your competitor."
No, you can backup just as much as many times as you like. The code isn't stored on the chip permanently, it is only decrypted there.
There is a similar problem, though. If your processor dies you could lose your software library. There are ways to mitigate this. One is for the vendors to just trust people and reissue the code to a new processor. Of course, you track how often you have to do this.
Or, you could turn in the broken processor and have the manufacturer certify that it was turned in to the software vendors and that a new version of the software should be generated.
I meant processor backup of course. When my processor breaks at 2AM and I need to get the report out by 8AM, I'm going to call the software support line and get help. Or the friendly hardware manufacturer is going to come right out and certify my processor is dead. Come on and get real. With most software vendors I can't even submit a bug report. Note that I am not saying there is a technical problem here. I do see big problems with infrastructure and marketing. The last time software companies tried to market copy protection, it failed in the market place. I predict that encyphered instruction streams will too, and for the same reasons. ------------------------------------------------------------------------- Bill Frantz | I still read when I should | Periwinkle -- Consulting (408)356-8506 | be doing something else. | 16345 Englewood Ave. frantz@netcom.com | It's a vice. - R. Heinlein | Los Gatos, CA 95032, USA
participants (2)
-
Bill Frantz -
ph＠netcom.com