Path: utzoo!attcan!uunet!cs.utexas.edu!news-server.csri.toronto.edu!qucdn!leek From: LEEK@QUCDN.QueensU.CA Newsgroups: comp.sys.amiga Subject: Re: ID (P)ROMs (was: Pirates and swapware) Message-ID: <90178.141419LEEK@QUCDN.BITNET> Date: 27 Jun 90 18:14:19 GMT References: <1990Jun22.183227.2638@cbnewsl.att.com> <1990Jun24.075559.13459@zorch.SF-Bay.ORG> <90U702Unb2ZK01@amdahl.uts.amdahl.com> Organization: Queen's University at Kingston Lines: 66 In article , Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) says: >problem could be overcome if C= simply provided a _socket_ for an ID (P)ROM >and sold the (P)ROM separately. Then, if you bought a new machine, you >could simply move the old (P)ROM to the new machine. Maybe C= and the new >league of C= developers could coordinate something. If C= puts in a socket, someone can put in a gadget to sort of bypass the system. One can make a battery backed RAM replacement for the ID PROM. If a program ABC needs ID 12345678, one simply program the RAM chip to give ID# 12345678. To make an illegal distribution of the program, one can copy the disk and also read off the PROM ID. (remember the ID has to be readable by m applications) This is the biggest flaw in the scheme. There is no way to provide secured access to the contents of the ROM. 2nd way to crack the system is to install a Bus Error exception upon access of PROM ID space (by a few TTL chips). The exception handler program can then supply whatever ID it wants. >If you've got a non-trial-and-error algorithm to reverse DES, please post. >;-) Believe it or not, there are some fairly sophisticated ways to >obfuscate encryption, how keywords are accessed, and how they are >validated. Of course, you can always reverse engineer the whole program... If I am not mistaken, the only problem with DES is that you can only sell it in U.S.A. (Canada too ??) (If I had a good algorithm for DES, I would not post it. I can probably make mega bucks using the algorithm for illegal things - illegal fund transfers etc) > >Kim> The ONLY effective method of combatting piracy is to sell *support*, >Kim> which includes continually improving and upgrading the products. And >Kim> of course, you only provide support to registered owners. That's one very good way for protection. Make the program cheap as possible. If you need help, you have to pay for it. Sounds fair. > >I don't agree with "only", but this is certainly _my_ favorite form of copy >protection! My second favorite would have to be a (P)ROM based system. Sorry PROM do not work too well. A better solution is a encryption based system which can be implemented on a microcontroller with security features. Break up the encryption function into tiny subroutines in EPROM or MASK ROM. Put the main program that do a whole bunch of calls to EPROM and the key on EEPROM with security bit set. (This is to save space in EEPROM. By dividing up the code into tiny subroutines makes it a bit harder to figure out the actual code sequence that gets called and also make it possible to update new encryption function 5 years down the road.) Both the application program and the microcontroller has to be able to answer challenges posted by the other as a form of verification. In this case, it will be a bit harder to duplicate the microcontroller as the encryption algorithm and the key are harder to get at. What happens if one of the software developer leaks the secret ??? > >Chuck Phillips MS440 >NCR Microelectronics Chuck.Phillips%FtCollins.NCR.com >Ft. Collins, CO. 80525 uunet!ncrlnk!ncr-mpd!bach!chuckp K. C. Lee P.S. In the LIKELY event that I am wrong about data encryption system and microcontroller, please feel free to correct me.