rej@cornell.UUCP (Ralph Johnson) (11/09/83)
From: rej (Ralph Johnson) To: net-crypt Since this is supposed to be a newsgroup about cryptography, I would have thought that some of the software copy protection schemes would have relied on cryptography, but none that I have seen here have. Here are a couple of my favorite schemes. None have been implemented, for obvious reasons. 1) Encase processor and memory in an impenatrable box (i.e. VLSI). Processor can be given two commands, read in plain-text program, and read in encrypted program. Each processor has a public key which is used to encrypt programs. It uses its private key to get an executable version. The owner of this program must give the public key when buying encrypted software, as a special version must be made for each processor. While there are no overpowering technical problems to this approach, the economic problems are devastating. 2) Processor and memory are as before. Processor decodes encrypted function with fuction f. Program is encoded with function g. Purchaser of software dials up software manuafacturers computer and gives f, and is given in return a function h such that f(h(g(x)))=x. Purchaser performs h(g(x)) using a utility program to make customized program. Ideally these functions should be such that knowing h for one machine will not give any clues in learning it for another. First I will show a simple way to build f, h and g which has the drawback of being easily broken, and then I will show how to make it very safe. All three functions will be a permutation of bytes. As there are 256! of these functions, they will be hard to guess. The software manufacturer creates his own version of g. Each processor has its own version of f. Given f, it is very easy for the software manufacturer to build h. It is easy to transmit f and h over the phone, as each is specified by 256 bytes. The only problem is that if someone knows both f and h, they can guess g, thus breaking the code. The weak link is the transmittal of f and h. This transmital can be made secure by encrypting f and h before they are sent. A standard public key encryption system can be used for this. As you might have noted, a public key encryption system could have been used to transmit the whole program (i.e. the entire encrypted program could have been sent) but this might take a long time causing very high phone bills. This technique ensures that every program is different, that no two processors can run the same program, that there are no expensive communication costs, and that the system is as secure as the public key encryption system. Ralph Johnson