Software protection device and method

Abstract

A method and apparatus for protecting computer software from unauthorized execution or duplication using a hardware key is disclosed. The apparatus comprises a means for communicating with the computer to receive command messages from the computer in the hardware key and to provide response messages to the computer, a memory for storing data for translating command messages into response messages enabling software execution, and a processor coupled to the interface port for translating command messages into response messages using the data stored in the memory. The processor further comprises a memory manager, for logically segmenting the memory storing the data into at least one protected segment, and for controlling access to the protected segment.

Claims

What is claimed is:

1. A method of securing software executable on a computer, comprising the steps of:

(a) segmenting the software into a first and a second software segment;

(b) transmitting the first software segment to a first hardware key communicatively coupled to a developer computer, the first hardware key comprising a first hardware key processor and a first hardware key memory, the first hardware key memory having a secure segment with a first encryption key stored therein;

(c) encrypting the first software segment using the first encryption key and the first hardware key processor; and

(d) receiving an encrypted first software segment from the first hardware key.

2. The method of claim 1, further comprising the steps of:

(a) storing the encrypted first software segment and the second software segment in a host computer communicatively coupled to a second hardware key comprising a second hardware key processor and a second hardware key memory having the first encryption key stored therein;

(b) transmitting the encrypted first software segment to the second hardware key;

(c) decrypting the encrypted first software segment using the first encryption key to produce flint software segment instructions;

(d) storing the first software segment instructions in a secure portion of the second hardware key memory;

(e) performing the first software segment instructions by the second hardware key processor to produce a response message; and

(f) transmitting the response message to the host computer.

3. The method of claim 2, wherein the response message is encrypted before transmission to the host computer.

4. The method of claim 1 further comprising the steps of:

(a) transmitting the encrypted first software segment from the first hardware key to a second hardware key, the second hardware key comprising a second hardware key processor and a second hardware key memory having a secure segment with the first encryption key stored therein; and

(b) storing the encrypted first software segment in the secure segment.

5. The method of claim 1, further comprising the steps of:

(a) storing the second software segment in a host computer communicatively coupled to a second hardware key comprising a second hardware key processor and a second hardware key memory having the first encryption key securely stored therein;

(b) decrypting the encrypted first software segment using the first encryption key to produce first software segment instructions;

(c) storing the first software segment instructions in a secure portion of the second hardware key memory;

(d) performing the first software segment instructions by the second hardware key processor to produce a response message; and

(e) transmitting the response message to the host computer.

Description

BACKGROUND OF THE INVENTION

1. Field of Invention

The present invention relates generally to devices and methods for protecting computer software and in particular to devices and methods for protecting software by secure transmission and execution of encrypted software in a hardware key.

2. Description of Related Art

In the last decade, the use of computers in both the home and office have become widespread. The growing use of computers has resulted in extensive unauthorized use and copying of computer software, costing software developers substantial revenue. Although unauthorized copying of computer software is a violation of the law, the widespread availability of pirated software and enforcement difficulties have limited the effectiveness of this means of preventing software piracy.

Software developers and computer designers alike have sought technical solutions to attack the problem of software piracy. One solution uses an external device called a hardware key, or "dongle," coupled to an input/output (I/O) port of the host computer. One such device is disclosed in U.S. Pat. No. 4,599,489, issued to Cargile on Jul. 8, 1986. The Cargile device executes a prescribed algorithm to produce a code which the computer receives and affords access to the software code if the code is correct. Another such device is disclosed in U.S. Pat. No. 4,446,519, issued to Thomas on May 1, 1984. This system also uses a hardware key coupled to the I/O port of a host computer. Software locks inserted into unprotected software programs cause the host computer to transmit a code to the hardware key. The hardware key processes the code to generate a response message. The software lock receives the response message, and compares the response to the expected response. If the received response is as expected, execution of the software is permitted to continue. If not, execution is terminated. A similar device is shown in U.S. Pat. No. 4,458,315, issued Jul. 3, 1984 to Uchenik.

Devices such as those disclosed in the Thomas and Uchenik references are not impervious to software piracy. Computer hackers can interrogate the dongle/host computer interface to determine query/response pairs, and could emulate the presence of a dongle with non-approved devices or software. In addition, computer hackers can obtain access to the protected software, find the software locks, and simply patch around them.

One solution to this problem is to perform selected software instructions in a secure hardware key, as disclosed in U.S. Pat. No. 4,634,807, issued Jan. 6, 1987 to Chorley et al. The Chorley device allows execution of portions of the protected software in a secure dongle coupled to a host computer I/O port. In the Chorley device, portions of the unprotected software, called software modules, are encrypted by a data encryption standard (DES) algorithm, producing a DES key and an encrypted module. The DES key is again encrypted, using a private/public encryption technique. The private key needed to decrypt the DES key is stored in the dongle. When the host computer requires execution of the software module, the encrypted software is transmitted to the secure dongle, and stored in its memory. The dongle processor decrypts the DES key using the private key, and uses the DES key to decrypt the software module. The software module is then stored in unprotected memory, where it can be operated on by a processor within the dongle. Access to the private and DES keys is controlled by a switch means which allows the dongle processor to access the memory in which the keys are stored only when the hardware key is initially activated. Upon activation, the private key is used to decrypt the DES key, and the DES key is used to decrypt the software module. Thereafter, the switching means prevents the dongle processor from accessing these keys.

While the Chorley device makes unauthorized access to the keys by the dongle processor difficult, it also prevents authorized access at any other time, and does not allow the memory in which the keys are stored to be used for other purposes. Also, the Chorley device is still not impervious to software piracy, because the unencrypted software module is eventually stored in the hardware key in an unprotected memory, where it can be accessed by the host computer. This may be prevented by enforcing encrypted and decrypted communications between the host computer and the dongle, such as disclosed in U.S. Pat. No. 4,596,898, issued on Jun. 24, 1986, to Permmaraju or U.S. Pat. No. 4,864,494, issued on Sep. 5, 1989, to Kobus, but this cannot be implemented with the Chorley device, because access to the keys is temporally limited.

Additional software protection devices are disclosed in U.S. Pat. No. 4,817,140, issued Mar. 28, 1989 to Chandra et al., and in U.S. Pat. No. 5,146,575, issued to Nolan et al. The Chandra and Nolan devices use a physically and logically secure co-processor to decrypt and execute software. Encryption and decryption keys and the algorithms using these keys are stored in the device in a secure non-volatile random access memory (RAM). Unlike Chorley, unauthorized access to plaintext software and the encryption/decryption keys is prevented by firmware-implemented functions rather than by a hardware switch. However, the Chandra and Nolan devices have practical limitations which limit their usefulness to prevent software piracy. First, the ultimate security of software protected by the Chandra and Nolan devices relies on the secrecy of a set of co-processor supervisor keys (CSKs) which must be pre-stored in all co-processors supplied by a given hardware vendor, and requires that the eventual software customer employ a use-once token cartridge to configure the co-processor to operate the protected software. The Chandra and Nolan devices also do not permit flexible access to other portions of the RAM which do not contain sensitive data. Because the Chandra device must be usable with a wide variety of software applications, it must employ an "open architecture," and to prevent unauthorized access to sensitive information, is incapable of acquiring and transferring the right to execute the protected software. The Nolan device solves this problem by using a separate supervisor processor to implement a privilege structure and an open-architecture application processor to implement security functions. However, using two separate processors unnecessarily complicates the design and provides the potential software hacker with more opportunities to circumvent the software protection schemes employed in the device. The Nolan and Chandra devices are not immune from hacking by monitoring the co-processor/host interface, and using this data to emulate the hardware key.

Another problem with current software protection devices is that they are not backwards-compatible, and are not flexible enough to implement a wide variety of software protection algorithms within a single hardware key. For example a single host computer may store two separate software applications, the first protected with simple software locks, such as those described in the Thomas patent, and the second protected with encrypted computer/hardware key communications. Prior art software protection devices are incapable of supporting both of these software protection schemes, and two hardware keys would be required.

SUMMARY OF THE INVENTION

To overcome the limitations in the prior art described above, and to overcome other limitations that will become apparent upon reading and understanding the present specification, the present invention discloses a method and apparatus for protecting software executable on a computer.

The apparatus comprises a hardware key with a communicating means coupled to the computer for receiving command messages and providing response messages to the computer, a memory for storing data used in translating command messages into response messages to enable execution of software on the computer, and a processor coupled to the communicating means and the memory. The processor includes a means for interpreting command messages to generate processor command functions, a translator for generating response messages from the processor commands, and a memory manager to protect data from unauthorized access. The memory manager logically segments the memory into at least one protected segment and controls access to this protected segment. This is accomplished with an instruction mapper which selectively maps processor commands to memory address locations. The hardware key also employs a means for decrypting coded software and performing the decrypted instructions, and supports encrypted communications between the hardware key and the host computer. Additional capabilities are provided by programming interface module, command class dispatcher, and a license manager. The programming interface module allows secure programming of the hardware key without compromising its contents. The command class dispatcher provides for backwards compatibility of the present invention with other software protection devices. The license manager allows a software developer to use the hardware key to implement secure licensing schemes.

The present invention also discloses a method of securing executable software. The method comprises the steps of segmenting the software into a first and second software segment, transmitting the first segment to a first hardware key (the software developer's hardware key), encrypting the first software segment in the first hardware key, and receiving the encrypted software segment from the hardware key. Because the keys used to encrypt the first software segment are securely stored in the software developer's hardware key, they remain protected from unwanted disclosure. The encrypted segment can be stored in a magnetic medium along with the second (unencrypted) software segment or in a second hardware key that is provided to the software end-user.

BRIEF DESCRIPTION OF THE DRAWINGS

Referring now to the drawings in which like reference numbers represent corresponding parts throughout:

FIG. 1 is a diagram showing the interface between a host computer and the present invention;

FIG. 2 is a block diagram describing the overall architecture of the present invention;

FIG. 3 is a diagram describing the memory structure for the present invention;

FIG. 4 is a diagram showing the operation hierarchy and communication flow of the present invention;

FIG. 5 is a diagram showing the operational relationships between elements of hardware key of the present invention;

FIG. 6 is a flow chart illustrating the license management capabilities of the present invention;

FIG. 7 is a diagram showing the memory structure implemented by the memory manager of the present invention;

FIGS. 8A-8D are flow charts showing the operation of the present invention; and

FIG. 9 is a flow chart illustrating the hardware key programming aspects of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

In the following description of the preferred embodiment, reference is made to the accompanying drawings which form a part hereof, and which is shown by way of illustration a specific embodiment in which the invention may be practiced. It is understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the present invention.

Overview

The present invention provides a high degree of security and flexibility to protect software in both stand-alone and networked applications enabling users to develop a single security strategy, using a common Application Program Interface (API) for both stand-alone and networked applications across all platforms. It features a cross-platform API, allowing software developers to easily port software across a wide variety of platforms. The present invention supports all current parallel printer ports, RS-232 and RS-423 serial ports, and Macintosh.TM. Apple Desktop Bus (ADB) ports, thus providing for product interoperability and local or remote access across a network. The present invention also permits flexible secure licensing schemes and tools for system administrators for networked applications.

As shown in FIG. 1, the present invention is used in conjunction with a host computer 100. The host computer 100 may include a keyboard 102, display 104, a mouse 106 and an external storage device 108. The host computer 100 may be networked with other computers via an external communications link 110. A hardware key, or dongle 114, is coupled to the host computer 100 via an I/O port 112.

System Architecture

FIG. 2 presents a block diagram describing the overall architecture of the present invention. The host computer 100 is coupled to a hardware key 114 providing a host computer/hardware key communications link 138. This communications link may be any computer I/O link, including a parallel printer port, an RS-232 or RS-423 serial port, a Macintosh.TM. ADB port, or any port used for remote or network communications.

The host computer 100 responds to the instructions in one or more application programs 120 to process data and provide output results. The present invention prevents unauthorized use or copying of application programs 120 in the host computer 100, or any other processor coupled via the external communications link 110. Application programs 120 communicate with the hardware key 114 via an application program interface 121 (API), client library 123, and an interface driver 122.

The hardware key 114 includes a custom designed application-specific integrated circuit (ASIC) 128. The ASIC 128 is coupled to the host computer 100 via the hardware key interface port 126 and host computer/hardware key communications link 138. ASIC 128 contains a microprocessor 130, and associated microprocessor RAM 131, a firmware read only memory (F/W ROM) 136, random access memory (RAM) 132 and a developer-configurable electronically erasable programmable read only memory (EEPROM) 134. Of course, EEPROM 134 can be replaced by any programmable non-volatile memory technology, including anti-fuse read only memory technologies. These anti-fuse technologies offer one-time write capability and do not allow external inspection of data bit states. Co-locating these elements in a single ASIC 128 allows critical security-related values to be stored in memories such as the EEPROM 134 which are difficult to penetrate from outside the chip.

FIG. 3 presents a diagram of the memory of the hardware key 114. Microprocessor RAM 131 includes input/output control address space 142 and CPU register address space 144. Instructions contained in the I/O control address space 142 are always available to respond to messages transmitted over the host computer/hardware key communications link 138. F/W ROM address space 136 includes modules with instructions to implement the present invention. The operation of these modules is described in more detail herein.

RAM address space 148 includes a user RAM address space segment 150, and a system variable address space segment 152. The user RAM address space segment 150 is available to software developers for data storage or execution of pre-compiled programs. RAM 132 may also be used as a buffer for incoming/outgoing data from and to the host computer. It also contains a stack for variable, expression evaluation, function addresses and system temporary data.

EEPROM address space 154 is segmented into a system configuration address space 156, a code address space 158, an algorithm address space 160, a data address space 162, and a license address space 163, in which user/developer program instructions, algorithms, data, and license information, respectively, may be stored. The present invention also provides for extended EEPROM 164. As will be described herein, access to segments of the EEPROM 134 are controlled by a memory manager 318, thereby preventing unauthorized access to data stored in EEPROM 134. A portion of EEPROM address space 154 can also be configured by the developer for code 158, algorithms 160, data 162, or license information 163. The EEPROM 134 can be programmed at development time or with APIs 121 during run-time. Similarly, although address space limits are generally preconfigured, APIs 121 are also available to configure the code 150, algorithm 160, data 162, and license information 163 address space limits during run-time. This provides additional flexibility to the programmer to implement software security techniques, to allocate memory as required for each security technique, and to support field updates. Routines may be stored in the EEPROM 134 to be interpreted and executed by the hardware key 114 during run-time, or the routines can be encrypted during development and downloaded and executed during application run-time.

In one embodiment, the hardware key 114 includes 4,096 instructions of F/W ROM 136, 128 bytes of RAM 132, and 128 bytes of the EEPROM 134 with 90 bytes of EEPROM 134 customer-configurable. External EEPROM 164 may also be coupled to the ASIC 128 to provide additional memory for code, data, or algorithms.

System Communications

FIG. 4 presents a diagram showing the operation hierarchy and communication flow of the present invention. The software developer protects the software by embedding API calls 212 in the application. These calls may include functions to query information from the hardware key 114, read or write data to/from the hardware key 114, or load and/or execute programming in the hardware key 114. Although APIs 121 need not be language-specific, multiple language-specific APIs 121 are provided to accommodate various development languages and techniques.

The client library 123 translates API 121 calls into hardware key 114 commands. These commands are then sent from the client library 123 to the driver 216 and from the driver 216 to the hardware key 114. The client library 123 also implements dynamic, or message (CC1) encryption when required, and constructs data packets for the hardware key 114.

The driver 216 can be linked either statically or dynamically with the application program to be protected or used as a system driver. The driver 216 implements low-level communications 244 between the host computer 100 and the hardware key 114. The driver 216 also provides support for the client library 123 to find a device, transfer a data packet, or obtain a response message from the hardware key 114.

Communications between the host computer 100 and the hardware key 114 operate as an open systems interconnection (OSI) module using a layered architecture divided into three hierarchical levels corresponding to three command types. This communication architecture provides a peer-to-peer link or virtual path between the indicated layers.

The lowest hierarchical layer provides the sole physical communications link between the host computer 100 and the hardware key 114, linking the driver 216 with the low level hardware key driver 230. This communications link is depicted as the low level communication path 244. Key control functions, which are unencrypted, are transmitted via the low level communication path 244, and are processed by the low level hardware key driver 230 directly.

Other communication layers, including the high level virtual communication path 232 and the mid-level virtual communication path 242 discussed below, use the low-level communication path 244. Of course, the present invention could be implemented with a two-level communication architecture, or other levels in addition to the three described above. The client library 123 and the driver 216 build the appropriate command format with parameter packets for each individual command. Each parameter packet is specific to the individual API function call. The APIs 121 also use a session buffer in a designated system memory area to hold parameter blocks for function requests.

Memory and command management functions are transmitted between the host computer 100 and the hardware key 114 at the medium-level virtual communication path 242 using a dynamic (CC1) encryption algorithm. Memory and command functions and other selected messages are encrypted with the CC1 encryption algorithm and key, and passed as packets from the host computer 100 along the mid-level virtual communications path 242. These packets are then decrypted and processed in the hardware key 114 using the CC1 decryption key stored in the hardware key 114. A CC1 key is stored in the client library 214 and in a secure portion of the hardware key 114. The size of the CC1 key is determined by the level of protection desired.

Programmatic functions including transfer of encrypted software modules representing selected portions of the application to be protected are communicated between the host computer 100 and the hardware key 114 at the highest level virtual communications path 232. Programmatic functions are normally pre-encrypted by the software developer during development using compiler 200 and CC0 encryption key 202. Encrypted program packets are either downloaded to the hardware key 114 along the high level virtual communication path 232 during run-time to be decrypted and executed by the firmware in the hardware key 114 or pre-loaded in EEPROM 134 and interpreted during run-time. As with the CC1 key, the size of the CC0 key depends on the level of security desired.

FIG. 4 also shows the structure of the low level and medium level virtual communication data packets 246, 236. Each includes a header 238 and 248.

The separate CC0 and CC1 encryption mechanisms provide secure communications to allow a software developer to use the hardware key 114 to (1) locate and verify the existence of the hardware key 114, (2) read/write/query the key, using algorithms and traps, or (3) execute pre-encrypted programs or subroutines during application run-time in a manner that prevents recognition of algorithms, commands, or responses.

System Functions

Protected applications 120 access the hardware key 114 through one or more security sessions using API 121 functions. API 121 functions are typically written in the same language as the application, but may be written in other languages and implemented by dynamic linking. API 121 functions include:

        INITIALIZE         Initializes client library data
                           structures and prepare library for
                           calls, each session requires an
                           initialized command.
        CONFIGURE          Determines behavior about the client
                           library 123, the hardware key 114, or
                           the linked-in driver 216.
        OPEN               Establishes a session for the
                           application, and search for an I/O port
                           112 with the hardware key 114.
        ACCESS             Submits a query/read/write/modify
                           request, download a program or traps,
                           or reset the hardware key 114.
        INQUIRY            Returns status and configuration
                           information about a session.
        CLOSE              Closes a session created by "OPEN".
        TERMINATE          De-initializes the client library 123
                           and prepare for termination.

        READ               Reads one or more adjacent cells.
        WRITE              Writes into one or more adjacent cells.
        QUERY              Scrambles data with a designated
                           algorithm descriptor.
        IOXCHG             Changes data by the associated
                           procedural trap.
        SET/GETLimits      Define data/code limits in hardware key
                           114 EEPROM 134 for use in session.

        LOADCONTEXT        Loads a set of traps and procedures
                           into the EEPROM 134. This function
                           operates on context data objects which
                           contain both code and trap descriptors
                           encrypted with the CC0 key. This
                           function also stores code that is
                           callable by the LOADEX command.
        SETALGO            Defines a new query algorithm
                           descriptor.
        LOADEX             Runs codes, which was encrypted during
                           development, in RAM 132.

    OPC_SRVRESET             Frees all licenses. This
                             command is usually called
                             after a server boot.
    OPC_OPENLIC              Requests a base license from
                             the key. Includes a
                             transaction identification
                             number (TRANS_ID)
    OPC_GETCNTX              Passes a copy of the current
                             license information to the
                             server, including BOOT_ID,
                             TRANS_ID, and LICNSNUM.
                             These values are encrypted
                             before being sent to the
                             server.
    OPC_SETCNTX              Reloads the license
                             information back to the
                             hardware key.
    OPN_OPENSUB              Issued by clients, and opens
                             a sublicense. Argument
                             includes an application
                             identification (APP_ID) and a
                             debit number.
    READ/WRITE/QUERY         These operations can be performed
                             if a base license is open.
                             Results from these operations are
                             CC1 encrypted before being sent to
                             the host.
    OPC_CLOSESUB             Issued by clients, and releases
                             used license. Includes (APP_ID)
                             and credit number.
    OPC_CLOSELIC             Issued by clients to release base
                             license.
    License manager command class module 334 variables
    include:
    HARDLIMIT                Maximum base license limit imposed by
                             hardware key. If set to 0, allows a
                             single user only.
    SOFT_LIMIT               Maximum base license set by software
                             developer
    BASE_COUNT               Number of base licenses remaining.
                             This is modified when the server is
                             reset or when a base license is opened
                             or closed.
    APP_ID                   Identification numbers for sub-
                             licenses. This is set by the software
                             developer.
    APP_COUNT                Number of sublicenses remaining. This
                             is modified when the server is reset or
                             when a base license is opened or
                             closed.
    BITMAP                   Indicates whether license is open or
                             closed. This is modified when the
                             server is reset or when a base license
                             is opened or closed.
    BOOT_ID                  This value is randomly selected when
                             server resets.
    TRANS_ID                 Transaction identification set by the
                             client. This value is modified when a
                             base license is opened or when the
                             SET_CNTX command is issued.

• Inventors
  Pavlin, Dominique Vincent; Sotoodeh, Mehdi; Tibbetts, Reed H.; Godding, Patrick N.; Spiewek, Alain Raymond; Nixon, Roger Graham;
• Assignee
  Rainbow Technologies, Inc. (Irvine, CA)
• Published
  Feb-18-2003
• Current US Classes:
  705/55
  713/192
  713/193
• Application #
  760648
• International Classes
  G06F 011/30; G06F 012/14; H04L 009/32
• Field of Search
  380/4
• Examiner
  Barron; Gilberto
• Agent
  Gates & Cooper LLP
• US Patent References:
  4278837
  4446519
  4458315
  4596898
  4599489
  4634807
  4817140
  4864494
  4903296
  4916738
  5081675
  5146575
  5224166
  5343524
  5666411
  5734908
  5742512
  5754646
  5754761
  5812662
  5883956
  5915017
  5970143
  6266416