Software Authorization r
`Systems
`
`Paul A. Suhler, Nader Bagherzadeh,
`Miroslaw Malek, and Neil Iscoe
`University of Texas at Austin
`
`For every piece of
`t has been estimated that for every
`I piece of business software sold for a
`business sofltwatZe t microcomputer, at least one other
`sold, at least one ille-
`copy was obtained illegally.' Software ven-
`gal copy exists. This dors and industry associations perceive the
`software pirate as a major threat to the
`article descrbes and production of quality software and are
`classIfies software- making efforts to deter piracy. These
`protection methods. efforts are educational (telling people it is
`wrong and harmful not to pay for soft-
`ware), legal (taking unauthorized distribu-
`tors and users to court), and technical
`(implementing programs and devices to
`prevent unauthorized use).
`
`Software theft environment. Technical
`protection of software has gained impor-
`tance as the installed base of microcom-
`puters has increased. Although protection
`schemes do exist for mini and mainframe
`computer programs, the distribution
`method for this software generally requires
`that license agreements be signed before
`the software is transferred to the user. Fur-
`thermore, mainframe software usually
`
`requires a lot of support, updates, and
`other items that require users to stay in con-
`tact with the vendor. Consequently, theft
`in the mini and mainframe marketplace is
`not considered a problem that requires a
`technical solution.
`However, the high-volume, mass-market
`nature of microcomputer software distri-
`bution has resulted in a substantial amount
`of theft.
`The first players in the software game
`werethe softwarevendors,thedistributors,
`and theusers. Thevendors wrote software
`and sold it, sometimes through distributors
`and sometimes directly, to the users. How-
`ever, pirates soon came on the scene: either
`companies intent on mass-producing and
`selling software without permission or
`users who copy and distribute programs to
`other (nonpaying) users, either directly or
`indirectly via network bulletin boards. Fig-
`ure 1 shows the flow of legal and illegal
`copies of software.
`The motivations for pirates vary. Com-
`mercial pirates, who make a profit from
`
`l~~~~~~~~ME
`
`l
`
`DIST~~~~~~~~~~~~~REETIN
`
`34
`
`0740-7459/86/0900/0034/$O1.OO © 1986 IEEE
`
`IEEE SOFTWARE
`
`Figure 1. Software distribution.
`
`DISH-Blue Spike-602
`Exhibit 1014, Page 0001
`
`

`

`execution of programs. The systems have
`required special devices: either special pro-
`gram disks or extra hardware.
`
`ing Service Organizations (ADAPSO)
`presents a fairly comprehensive history of
`personal computer software protection
`efforts.
`The report says that an application pro-
`approaches
`gram for Apple computers, VisiCalc, was AuhfiZation
`the first software to be protected against
`To protect software from unauthorized
`use, there are three basic authorization
`unauthorized copying. Since then, there
`techniques and several ways of implement-
`have been several variations on this scheme,
`ing those techniques. The techniques are
`which we will discuss in detail.
`based on general principles: copy protec-
`In 1980, Business Professional Indus-
`tion, validation, and encryption. The
`trial used a hardware device to protect its
`implementations are based on hardware
`accounting package for the Apple II. This
`devices: floppy disks, special microproces-
`scheme required the user to open the com-
`puter and insert the security-key device in
`sors, and devices attached to the system bus
`or an I/O port. More than one technique
`the game-paddle port.
`can be employed in a single software
`Although it provided sophisticated pro-
`authorization system, while seldom will
`tection, this scheme prevented the user
`more than one implementation method be
`from using the paddles without removing
`used.4
`the device. The problem proved to be more
`
`Software authorization
`has three criterki: to be
`inexpensive, compatible
`with other systems, and
`ea
`to implen
`t
`sy
`plment.
`
`Authorization techniques. Authoriza-
`tion can rely on either of two basic princi-
`ples: making it impossible for an
`unauthorized person to obtain a copy of a
`program or preventing unauthorized
`copies from executing on any but the
`licensed system. The former is done with
`various techniques called copy protection
`and the latter is done either by encrypting
`the program or by checking authorization
`during execution (validation). Each tech-
`nique has inherent strengths and weak-
`nesses, as summarized in TAble 1.
`
`selling a program without investing in it,
`are vulnerable to legal action (although
`enforcement is more difficult in the case of
`foreign-based pirates). The noncommer-
`cial pirate has different motivations, such
`as getting a program for free or evaluating
`an expensive piece of software without
`paying the full price.2 Because they are so
`inconspicuous, these pirates have been dif-
`ficult to detect and stop.
`The result has been a self-perpetuating
`system of theft and high software prices.
`Piracy reduces the sales of any particular
`program, so the vendors must maintain
`high prices to recoup their investment on
`fewer sales. The higher price is then a
`greater motivation to obtain a pirated copy,
`which reduces sales even further.
`The problem can reach the point where
`software developers are less willing to invest
`the time to produce sophisticated programs
`because they fear they will never make a
`profit. The losers are both the vendors who
`lose profits and the users who are never
`offered the improved programs.
`In response to the need felt by many soft-
`ware vendors to protect themselves from
`pirates, a new player has entered the game:
`the protection vendor, who offers techni-
`cal solutions to prevent unauthorized use.
`Their systems are sold to software vendors
`who incorporate them in their products.
`Some software vendors have their own pro-
`prietary protection schemes.
`
`than a mere inconvenience, as reports came
`in of pins bent by repeated insertion and
`Authorization system goals. The goals
`Copy protection. Copy protection
`removal of the protection device. In early
`of software authorization systems are sim-
`means making the disk on which the pro-
`1982, the company discontinued the sys-
`ple: to prevent the unauthorized copying or
`gram is provided (the master disk) uncopy-
`tem and eventually resorted to disk-based
`execution of software that has been legally
`able by the usual microcomputer operating
`protection methods.
`sold, or to make the piracy at least as dif-
`Sensor-Based Systems also used a
`system utilities. This can be done by insert-
`ing dummy file segments having erroneous
`ficult as writing the software from scratch.
`hardware-based method, for their Metafile
`In doing this, software vendors must view
`product on a Vector Graphics computer,
`CRCs or invalid control codes in the pro-
`the customer not only as a potential pirate
`that required the installation of a PROM gram file. These segments, while not nor-
`but also as a friendly customer who may
`chip in the system. Again, this functioned
`mally read in the course of loading and
`purchase more software.
`well but was an inconvenience. For the IBM
`executing the program, will be read by the
`Thus, a software authorization system PC version of Metafile, the company used
`operating system copy utility, which will
`must meet three criteria: (1) It must be inex-
`the PROM and Xedex's Baby Blue Card.
`not copy the intentionally placed "bad"in-
`pensive and easy to use. (2) It must be com-
`A major drawback was the lack of port-
`formation. When run, the copied version
`patible with existing unprotected programs
`ability, so in August 1982, Sensor-Based
`of the program will look for the missing
`and with programs protected by other
`Systems introduced an 8086-based version
`information and abort execution.
`authorization systems. (3) It must be easy
`-of Metafile for the IBM PC. This version
`Some versions permit one copy to be
`used a special protection device that was
`made: the copy process modifies the origi-
`for the software vendor to incorporate in
`nal disk so that it cannot be copied again.
`his production and distribution system.
`attached to the RS-232 port.
`VisiCalc for the Apple computer was one
`These examples illustrate the evolution
`of the first commercial programs to be dis-
`of systems for what has become known as
`tributed on copy-protected disks.
`software authorization:
`preventing
`Software vendors using copy protection
`unauthorized copying and unauthorized
`
`Software protection history. A report3
`written by the Software Protection Coin-
`mittee of the Association of Data Process-
`
`September 1986
`
`DISH-Blue Spike-602
`Exhibit 1014, Page 0002
`
`

`

`typically provide main and backup disks
`ware device attached to the system bus or
`with their programs and then offer free
`an I/O port, or in a detached device that
`replacement of worn disks. Copy protec-
`the user must query in response to a pro-
`tion requires no extra devices or operations
`gram prompt. In a disk-based system, the
`and does not noticeably slow down execu-
`key can also be data in sectors or tracks
`written in an unusual location or format.
`tion of the program. It has the advantage
`of usually being transparent to the user,
`Absence of the unusual format indicates
`although this depends on the implemen-
`an unauthorized copy.
`tation.
`If the key is located on the disk, the vali-
`Unfortunately, copy protection is rela-
`dation is usually invisible to the user, who
`tively easy to evade. Instead of using the
`may or may not notice a degradation in
`performance. Unfortunately for the ven-
`standard copy routine, a pirate can use a bit
`dor, this is no more secure than copy pro-
`copier, a program that copies a disk bit for
`tection, because it can be evaded by the
`bit without interpreting CRCs, protection
`bits, or other information for its meaning.
`same methods. If the key is in a device, it
`is much more difficult to copy, but the
`Another way around the protection is to
`execute the program under a debugger,
`device presents an inconvenience to the
`interrupt execution, and copy the memory
`user, who must attach it and who will lose
`the use of the port for I/O if the device is
`image of the program to an unprotected
`disk.
`not transparent. Finally, if the user must
`manually query a detached key device and
`The desire for a quick backup method
`enter the resulting key, he will have to toler-
`has prompted the creation of several com-
`mercially available programs that copy
`ate interruptions to his processing.
`these protected disks. Such programs are
`A variation on validation is used with
`advertised for making only legal backup
`programs distributed on ROMs that try to
`copies, but they can be abused.
`determine if the program has been copied
`into RAM. The validation code uses
`Validation.
`Protected software can
`hardware-dependent operations to deter-
`check the user's right to execute it. Valida-
`mine if the program is being executed from
`tion systems usually feature blocks of code
`embedded in the program to locate a ROM or RAM, and aborts in case of the
`latter. This method is uncommon, as rela-
`unique key in the system. If the key is not
`found, the program is assumed to be on an
`tively little software is distributed on
`ROMs.
`unlicensed system and execution is
`aborted.
`In general, validation systems can be
`The key can be a number stored on the
`defeated by removing the validation code
`from the program, by duplicating the key,
`program disk (in a location not normally
`copied), in a read-only register in a hard-
`or by simulating its presence. This has led
`
`Table 1.
`Comparision of authorization techniques.
`
`Technique
`Copy protection
`
`Validation
`
`Advantages
`No additional hardware
`Can be totally transparent
`Medium security
`Relatively inexpensive
`
`Encryption
`
`Potentially highest security
`
`_
`
`_
`
`Disadvantages
`Can be defeated with bit-copy
`program or debugger
`Can be defeated by patching out
`validation code
`Usually requires additional
`hardware
`Requires execution time overhead
`Usually requires additional
`hardware
`Can require long execution times
`May require complex distribution
`system for keys
`
`to a war of wits between vendors and
`pirates.
`Using a debugger and a disassembler,
`pirates can remove validation code or
`modify it to never abort. But vendors can
`place validation code in several places in
`the program, so if the pirate misses even
`one routine, the program will abort.
`Validation code can be written in a
`Byzantine manner, with its instructions
`scattered through the program and con-
`nected with goto statements, so it will be
`more difficult to recognize than a cleanly
`written routine.
`Multiple validation routines can also be
`made not to function every time the pro-
`gram is executed, so a pirated program with
`some validation routines removed may
`function for a while and then suddenly fail,
`causing frustration among the pirate and
`his customers.
`Recent microprocessors with memory
`protection that requires accessing I/O
`devices through system calls have been a
`boon to the pirate, who now must look
`only at the exception vector to locate the
`routines communicating with the key
`device. (This has been named the 286 prob-
`lem by vendors trying to protect programs
`for systems such as the IBMPC ATs which
`use the Intel iAPX 286.) Pirates with access
`to test equipment can learn the key by
`mntrnd
`transfer
`key
`Sse
`r
`w
`p
`Systemswcth a processor in the key
`e andrthe deceto
`ing in thev
`at
`generate not just one, but a sequence of
`keys, which is more difficult to understand.
`Thus, the battle continues, with vendors
`trying to push the price of defeating their
`systems beyond the skill, patience, and
`resources of most pirates.
`Encryption. The program can be en-
`crypted so that before being executed it
`must first be decrypted according to a
`unique key available only on the licensed
`system. In this scheme, the buyer provides
`an encryption key (possibly based on his
`system's serial number) to the vendor when
`ordering a program. The vendor in turn
`produces a version of the program that can
`be decrypted only according to the key
`unique to the purchaser's system.
`Decryption can be done at load time by
`~~~~~~~~~~~~~the
`CPU or by a device attached to the bus
`
`DISH-Blue Spike-602
`Exhibit 1014, Page 0003
`
`

`

`or an I/O port. In these cases, the key is
`usually handled as it is in validation sys-
`tems. The decryption can also be per-
`formed at runtime by a cryptoprocessor
`that replaces the computer's standard
`microprocessor and decrypts instructions
`internally during the instruction fetch
`phase. Only in systems using a cryp-
`toprocessor does the plaintext code never
`appear in a form readable by the user.
`The basic problem with encryption is
`that the more secure the encryption algo-
`rithm (the longer it takes a pirate to break
`the code without having the key), the more
`
`processing is required to perform the
`decryption even with the key. This can
`degrade the instruction execution rate sig-
`nificantly.
`Furthermore, encryption systems can be
`defeated in three ways: by determining the
`key and decrypting the program, by using
`a debugger to copy the program after it has
`been decrypted, or by copying the vendor
`or distributor's master, nonencrypted copy
`of the program.
`Using a hardware device for decryption
`means the key can be hidden from the user.
`However, if the same key is used for encryp-
`
`tion and decryption, as in the Data En-
`cryption Standard,5 the key must be
`available for encoding programs as they are
`purchased - and is thus susceptible to
`theft and use in unauthorized decryption.
`
`By using an algorithm such as that of
`Rivest, Shamir, and Adleman,6 in which
`the decryption key cannot be determined
`from the encryption key, a user can know
`his encryption key to order new software
`without knowing his decryption key. How-
`ever, key distribution can be an administra-
`tive problem for the software vendor.
`
`PERIPHERAL
`
`VO PORT
`DEVICE
`
`FPROECTED
`DISK
`
`UNPROTECTED
`DISK
`
`MEMORY
`
`I/O
`CONTROLLER
`
`DISK
`DRIVE
`
`SYSTEM
`BUS
`
`BUS
`CPU
`L~~~~~JII~~DEVICE
`1CRYPTOPROCESSOR
`
`TERMINAL
`
`:U
`
`DETACHED|
`DEVICE
`
`AUTHORIZATION
`DEVICE
`
`1
`1
`L J
`
`SYSTEM
`COMPONENT
`
`- INDIRECT
`CONNECTION
`
`DIRECT
`,,,,,CONNECTION _____
`
`Figure 2. Authorization device attachment. (Not all devices would be attached simultaneously.)
`
`DISH-Blue Spike-602
`Exhibit 1014, Page 0004
`
`

`

`however, each can be used with copy-
`protected disks.
`
`the
`
`unusual data formats, such as extra tracks
`per disk, extra sectors per track, precisely
`defined sector alignment, tracks that fol-
`low a spiral (rather than circular) path,
`Detached devices. As mentioned with
`extra-wide tracks, and even tracks contain-
`validation schemes, the validation key can
`reside in a device not physically attached to
`ing weak bits that are sometimes read as
`ones and sometimes as zeroes. Some of
`the computer. As Figure 2 shows, the
`detached device connection is an indirect
`these require the user's computer to have
`a disk drive with nonstandard capabilities,
`one, via the keyboard and screen.
`Such devices typically are about the size
`such as stepping in half-track increments
`of a pocket calculator and have a small key-
`or to extra sectors, and therefore have not
`board and a one-line alphanumeric display.
`been applicable to all systems.
`Disk-basedauthorizationsystemspre-
`The validation routine in the protected pro-
`authorgamiprsenttaiquryscdetonthepcree
`Disk-based
`gram presents a query code on the screen
`sent a problem when the program is used
`on a computer with a hard disk or a RAM to the user, who types the code into the
`device, reads the key it displays, and enters
`(virtual) disk. It is unreasonable to expect
`that into the computer, which continues
`the user to insert the floppy disk for each
`execution if the key is correct.
`nthe
`program he is o
`The validation routine and device some-
`times simultaneously execute an algorithm
`Copying a key from the floppy to the
`to generate new query/key pairs each time,
`so the user cannot easily anticipate what
`hard disk and obtaining authorization
`the key will be. The main problem with
`from the new copy may not be possible
`and would certainly be insecure. And it
`detached devices is that they are incon-
`would be unreasonable for the floppy to be
`venient to the user because they increase his
`workload. The user can also err when
`made unreadable after the program is first
`transferring the query and key codes.
`copied to the hard disk: the floppy is neces-
`sary as a backup in case of a hard disk
`crash.
`The four remaining implementation
`techniques involve hardware devices and
`are seldom combined with one another;
`
`Implementation techniques. Implemen-
`tation techniques are categorized accord-
`ing to the hardware involved in the
`authorization process. There are five main
`categories: disks, detached devices, I/O
`port devices, internal bus devices, and
`cryptoprocessors. Each device can contain
`a unique key for validation or decryption
`of the protected program, and some can
`produce sequences of keys or perform the
`decryption. Figure 2 shows how these types
`of devices are attached to a typical personal
`computer. Table 2 gives a brief com-
`parison.
`
`Floppy disks. Floppy disks are now the
`standard means of distributing microcom-
`puter software.
`In copy protection
`schemes, it is the difficulty of copying the
`disk itself that is intended to deter
`unauthorized use. In validation schemes,
`the disk contains the validation key. Such
`systems are essentially no more difficult to
`use than are copy-protected programs.
`However, they are the easiest to defeat
`usually by using a bit copier. Nevertheless,
`due to their ease of use, they are also the
`most common protection means in use
`today.
`A recent article in IEEE Spectrum7
`presents details of various disk-based
`schemes. Typically they involve the use of
`
`Table 2.
`Comparison of implementation methods.
`
`Convenience
`
`Implementatio Convenienc Instal
`
`Installation
`
`Can be totally transparent
`Requires user actions
`during every program
`execution
`Operation can be
`transparent
`Requires space at back of
`computer
`May interfere with I/O
`device
`Operation can be
`transparent
`
`Operation totally
`transparent
`
`-
`
`No special operation
`No special operation
`
`Relatively easy-plugged into port
`
`Difficult-may require opening
`cabinet
`Very difficult-cabinet must be
`opened and chip replaced
`_____
`
`Implementation
`Method
`Floppy disk
`Detached device
`
`I/O port device
`
`Bus device
`
`Cryptoprocessor
`
`38
`
`I/O port devices. Key devices attached
`to the computer via an I/O port are iden-
`tical in principle to detached devices but are
`relatively transparent to the user, who need
`never be aware when validation takes place
`and who cannot introduce errors because
`he is not acting as a communication
`channel.
`In theory, such a device could be used to
`decrypt programs, but the low bandwidth
`of the link would make this a time-
`consuming operation. The drawback to
`these devices is that the I/O port is usually
`needed for a peripheral, so the device must
`be transparent to peripheral data transfers,
`as Figure 2 shows.
`In multitasking systems, an intelligent
`peripheral attached to the port may try to
`use the port at the same timethe validation
`software is accessing the peripheral - and
`the peripheral's data will be lost.
`Both serial port devices and parallel port
`devices are included in this category,
`because they have the same advantages and
`disadvantages. In practice, most I/O port
`authorization devices now available attach
`
`to serial ports. ADAPSO's proposed Soft-
`ware Authorization Standard defines com-
`~~~~~~~~~~~~~~~~~munications
`through RS-232 serial ports
`
`IEEE SOFTWARE
`
`DISH-Blue Spike-602
`Exhibit 1014, Page 0005
`
`

`

`and addresses the issue of multikey
`authorization systems.
`
`Bus devices. Both validation and
`decryption can be implemented in a device
`attached directly to the computer's bus.
`This has the advantages of providing a
`higher bandwidth link and of not interfer-
`ing with communications between the
`peripheral and its controller. Yet it is more
`inconvenient to install and takes up a bus
`slot. Because of the limited number of bus
`slots on most personal systems, a lack of
`standardization would make having mul-
`tiple bus devices even more inconvenient
`than having multiple I/O port devices. Bus
`devices are relatively rare.
`
`Cryptoprocessors. In 1979, Best8'9
`presented the idea of a crypto-micro-
`processor that would read in encrypted
`instructions, decrypt them according to an
`internal key, and execute them. In such a
`system, the code would never appear in
`nonencrypted form, and the
`key would be unreadable. The processor
`could also execute plain code, switching
`modes via privileged instructions. Each
`user's processor would have a different key
`and all protected programs would be
`encrypted specifically for him. Albert and
`Morse have presented a complete key dis-
`tribution system for doing this using pub-
`lic key encryption. 10
`In a similar vein, Kent" has proposed
`building secure systems using tamper-
`resistant modules (TRMs), which cannot
`be examined without destroying their con-
`tents. His approach is to connect these
`TRMs with a bus transferring encrypted
`data. However, details of TRM designs are
`not presented.
`In terms of authorization techniques,
`only encryption is involved in crypto-
`processor-based authorization systems. In
`theory, this could be the most secure sys-
`tem. When implemented with a public key
`system, the software vendor could encrypt
`the program directly for the user or issue
`the program in an encrypted form that
`would be further encrypted during instal-
`lation. In either case, the user would never
`obtain a program in plaintext.
`However, there are three main disadvan-
`tages to the use of cryptoprocessors. (1) It
`is inconvenient to open the computer and
`install the device. (2) When the processor
`
`September 1986
`
`is damaged and must be replaced, either
`the replacement CPU must have the origi-
`nal key programmed into it or all of the
`user's protected software must somehow
`be reencrypted for the replacement proces-
`sor's key. (3) The decryption is time-
`consuming.
`There is also a fourth consideration. The
`security of the encryption algorithm
`depends on the length of the block of data
`encrypted; the Data Encryption Standard
`uses a 56-bit key to encrypt and decrypt
`64-bit blocks of data. Modern micro-
`processors obtain higher performance by
`
`licensing: If one copy of a program is pur-
`chased, can it be executed on every com-
`puter in the network, or must a separate
`copy be purchased for each? What hap-
`pens if the network is connected to another
`network that allows further sharing of
`programs?
`The technical solution to networks will
`reflect the desires of both software vendors
`and users. Easiest for vendors and least
`convenient for users would be restricting a
`copy of a program to a particular machine.
`This could be implemented by placing an
`authorization device at each licensed
`computer.
`More difficult would be having authori-
`zation devices at only some of the com-
`puters, with validation messages routed
`have
`through the network. This would be better
`Crporcsosfor theusers, although whenthecomputers
`three dawbacks: they
`with the devices were down, none could run
`protected software.
`are inconvenient, are df-
`ficult to repair, and1 slow
`Most difficult would be systems using
`downat
`cryptoprocessors. With only one copy of
`applations
`each program, every CPU would have to
`have the same key, which would create a
`problem in obtaining more identical CPUs
`as the network expands.
`
`pipelining instruction fetching, decoding,
`and execution. If an entire eight-byte block
`must be fetched and decrypted before any
`of them can even begin to be decoded, then
`pipelining becomes difficult.
`Trying to alleviate the problem by
`prefetching even further ahead of the cur-
`rently executing instruction will result in a
`higher percentage of fetched instructions
`that will not be executed because of
`branches, thus increasing memory traffic
`with useless fetches. However, these effects
`will be small compared with the time to
`perform the decryption for any reasonably
`secure algorithms.
`
`Other issues. There are several other
`issues that, while not affecting the classi-
`fication of a product, do affect its use.
`They are support for networks, the process
`of installing protected programs on a sys-
`tem, and the need to standardize authori-
`zation systems.
`
`Networks. Networks of computers
`where programs stored at one location may
`be transferred to and executed at any other
`location raise questions about the intent of
`
`Program installation. When an authori-
`zation system uses a key unique to each
`user, be it for validation or decryption, the
`authorization code in the program must be
`modified to recognize that key. This can be
`done by the distributor, to whom the user
`can provide his authorization system's
`serial number or his public encryption key.
`The distributor then would have his com-
`puter system process the purchased pro-
`gram according to the serial number or key,
`producing a copy that would execute only
`on the purchaser's system. The disadvan-
`tages of this to the distributor are the work-
`load and the need to have a system to
`process every vendor's software.
`An alternative is for the user to perform
`the installation on his own system before
`the first execution of the program, thus dis-
`tributing the workload to the user. The dis-
`advantage for the vendor is that before
`installation the program is in a form that
`can be installed on any system of the same
`type as the purchaser's. While it is in that
`form, copy protection is its only protection
`against unauthorized distribution.
`An authorization device requiring a sep-
`arate hardware key for each program would
`
`39
`
`DISH-Blue Spike-602
`Exhibit 1014, Page 0006
`
`

`

`IMPLEMENTATION
`METHODS
`
`AUTHORIZATION
`TECHNIQUES
`
`C
`
`COPY
`PROTECTION
`
`V
`
`VALIDATION
`
`E
`
`ENCRYPTION
`
`DETACHED
`
`1/0 PORT
`
`INTERNAL
`BUS
`
`CRYPTO-
`PROCESSOR
`
`p
`
`B
`
`C
`
`Figure 3. Implementation and technique combinations.
`
`* ADAPSO's proposed standard sup-
`ports serial port devices that can use vali-
`dation, encryption, or both. These are
`classified as P.V, P.E, or P.VE (port device,
`validation and encryption). If the software
`were supplied on a copy-protected disk,
`these would become PYC and the like.
`* Advanced Computer Security Con-
`cepts markets a system using validation
`with the key on a fingerprinted disk and a
`device installed on the system bus to
`decrypt programs. This is classified as B.VE
`(bus device, validation and encryption).
`* Some vendors have their protected pro-
`gram, which is stored in ROM, attempt to
`overwrite itself. If it succeeds (because it
`has been transferred to RAM), it cannot
`execute. This is classified B.V (bus device,
`validation).
`As shown in the second example, if copy UT nauthorized use of programs has
`protection is used in addition to a non-disk-
`become a major problem for the
`computer software industry. On
`one hand, many software vendors rely only
`on low price or free service and updates to
`encourage users to purchase their pro-
`grams rather than use bootleg copies. On
`the other hand, a number of techniques
`have been devised to prevent unauthorized
`copying, execution, or both. Implementa-
`tions of these techniques vary from
`attempting to defeat copying to using hard-
`~~~~~~~~~~~~~waredevices for validation or decryption
`
`Table 3.
`Protection taxonomy.
`
`Authorization Techniques
`
`Code
`
`Copy Protection
`Validation
`Encryption
`
`C
`V
`E
`
`help to address this because the key would
`be much more difficult to duplicate than
`the program disk.
`
`Standardization. A general problem for
`validation and decryption devices is stan-
`dardization. If software vendors adopt
`different devices, the user must obtain
`them all and daisy-chain them, with all of
`the electrical problems and inconvenience
`that would entail. With bus devices and
`cryptoprocessors, even having only two
`different standards among one user's pro-
`grams would be unmanageable. ADAPSO
`is attempting to standardize a protocol for
`communication with RS-232 serial port
`devices having multiple keys.
`
`Taxonomy
`As explained earlier, there are three basic
`authorization techniques: copy protection,
`validation, and encryption. Copy protec-
`tion is used only on the disk used to distrib-
`ute the program, but the other two can be
`implemented in a number ofways, each of
`which has certain advantages and disad-
`vantages.
`The following taxonomy is proposed to
`provide software vendors, users, and others
`a framework for understanding authoriza-
`tion systems and their characteristics. To
`show the possible combinations clearly, the
`taxonomy has two basic elements: an
`implementation part and a technique part.
`Table 3 shows the abbreviations used for
`both basic elements.
`The classification of a particular system
`is represented by the implementation part,
`a period, and the techniques parts, as in the
`following examples:
`* Copy-protected disks are in common
`use today with no other authorization.
`These are classified as D.C (disk implemen-
`tation, copy protected).
`
`Implementation Methods
`
`Code
`
`Disk
`Detached device
`I/O port device
`Internal bus device
`
`D
`X
`P
`B
`CryptoprocessorC
`
`based technique, the D is not added.
`While it would be possible for an
`authorization system to use all these
`implementations and techniques, it would
`be unusual to find a system that used both
`validation and encryption - and it would
`be very expensive to use more than one
`device.
`Figure 3 shows the reasonable combina-
`tions of implementations and techniques
`as a network. Copy protection is imple-
`mented with disks only. Validation can be
`implemented with the key residing on a
`disk or in a detached device, I/O port
`device, or bus device. Encryption can be
`implemented with any device directly
`attached to the computer: port device, bus
`device, or cryptoprocessor.
`
`of the program.
`
`__
`
`_
`
`_
`
`__
`
`_
`
`_
`
`_
`
`__
`
`_
`
`_
`
`_
`
`__
`
`_
`
`_
`
`_
`
`__
`
`_
`
`_
`
`__
`
`_
`
`_
`
`_
`
`__
`
`_
`
`_
`
`_ __-_ _
`
`40
`
`IEEE SOFTWARE
`
`DISH-Blue Spike-602
`Exhibit 1014, Page 0007
`
`

`

`guage multiprocessors, VLSI-based parallel
`processors, and interconnection issues for mul-
`tiprocessors. His experience includes five years
`~~with AT&T Bell Laboratories in Holmdel, New
`Jerey
`Jesy
`Bagherzadeh received the BS and MS in elec-
`trical engineering from the University of Texas
`at Austin. He is a member of IEEE and ACM.
`
`7. J. Voeckler and P. Wallich, "How Disks are
`'Padlocked,' " IEEE Spectrum, Vol. 23,
`No. 6, June 1986, pp. 32-40.
`8. R. Best, "Microprocessor for Executing
`Enciphered Programs,' US Patent
`Encieirued Sept.18r 1979U
`,1,3,
`9. R.M. Best, "Preventing Software Piracy
`with Cryptomicroprocessors:' Proc. Corn-
`pcon Spring 1980, IEEE-CS Press, Los
`Alamitos, Calif., pp. 466-469.
`10. D.J. Albert and S.P. Morse, "Combatting
`Software Piracy by Encryption and Key
`Management,' Computer, Vol. 17, No. 4,
`Apr. 1984, pp. 68-73.
`S.T. Kent, Protecting Externally Supplied
`Software in Small Computers,