Abstract:
A developer writing a software program provides security for the program being prepared by interposing a special security layer in front of the standard library being utilized for writing the program. A security header and security file are incorporated in the software which automatically reroutes standard library calls through the special security layer prior to putting the calls through to the standard library files.

Description:
This application is a continuation of U.S. patent application Ser. No. 08/137,838 filed Oct. 15, 1993 now abandoned. 
    
    
     BACKGROUND OF THE INVENTION 
     This invention relates to a method for providing security for a developer&#39;s software, and more particularly to such a method which requires no special knowledge or experience with respect to security systems on the part of the developer and requires no source code modifications. 
     One of the problems facing a developer in writing a software program on which security is desired to be provided is the lack of experience of the developer in security systems. If the developer has no special knowledge or experience or if such knowledge is limited with respect to security systems, then the security which is incorporated in the program will be inadequate or weak. In addition, the provision of security has in the past required source code modification. Such knowledge and/or modifications require considerable time and effort which might better be spent by the developer in writing the program to solve the problems to which the program is directed. 
     SUMMARY OF THE INVENTION 
     Accordingly, it is an object of this invention to provide a new and improved method of protecting a developer&#39;s software requiring no special security systems knowledge by the developer. 
     Another object of this invention is to provide a new and improved method of protecting a developer&#39;s software requiring no modification of the original developer&#39;s source code. 
     In carrying out this invention in one illustrative embodiment thereof, a method of protecting a developer&#39;s software is provided by interposing a special security layer between the standard library files being utilized for writing the software program, automatically rerouting standard library calls through the special security layer prior to putting the calls to the library files and incorporating a security header and a file in said software to implement security for said software utilizing said special security layer. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     The invention, together with further advantages, objects, aspects and features thereof, will be more clearly understood from the following description taken in connection with the accompanying drawings. 
     FIG. 1 is a block diagram illustrating the use of standard libraries by a software developer. 
     FIG. 2 is a block diagram of the present invention in which standard library calls are first routed through a security layer. 
    
    
     DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     Referring now to FIG. 1, when a developer is preparing a program, reference is made to the library facilities 10 and in particular library routines as, for example, Microsoft&#39;s, Borland&#39;s, Watcom&#39;s, etc. Programs are thus developed using and adapting a variety of existing sub-routines. No security or protection for the program being written is provided. To provide protection, the developer must originate some type of security system, then change the source code to incorporate the originated security system. This procedure not only requires special knowledge of security systems but also requires changes in the source code which are costly in time consumption and might better be spent in developing the program directed to the problems to be solved thereby. 
     In accordance with the present invention, as exemplified in FIG. 2 a security layer 11 is interposed between the standard library files 10 and the developer&#39;s source code. In such a case, all standard library calls are in effect automatically rerouted through the security system prior to the placement to the standard library 10. All that is required on the part of the developer is the inclusion of a security header and file which is part of the security layer at the beginning of the source code used with the standard library 10. No modification of the original developer&#39;s source code associated with the standard library 10 is required. 
     The purpose of the security layer 11 is to provide protection of a particular software package from unauthorized use. One such security layer 11 might comprise a cryptological algorithm implemented with a combination of software and hardware. An example of such a system is disclosed in U.S. Pat. No. 5,222,133 marketed by Software Security, Inc. of Stamford, Conn. 
     For example, a hardware security device which may be installed in the computer or plugged into a computer part contains a unique and unalterable number referred to as a first key. A second key is installed in memory at the time of sale of the software package whose library also contains an algorithm which combines the two keys to create a third key used to unlock the software. The security layer 11 shown in FIG. 2 in block form activates the algorithm in the software, retrieves the first and second keys and unlocks the software by creating the third key. If the hardware device is not present or the third key is incorrect, a security violation occurs preventing the program to proceed. 
     An another example of a simpler security layer 11 is based on using a hardware device produced by Software Security of Stamford, Connecticut which contains a plurality of numbers. The library of the software to be protected also contains the same plurality of numbers. During execution of the protected software package, the security layer 11 activates special routines which send particular numbers to the hardware device which returns an acknowledge signal if the numbers match. If no acknowledge signal is provided, a security violation results which stops the protected program. 
     With the security layer 11 interposed as shown in FIG. 2, all that is required on the part of the developer is to provide a security header and library file to implement security. Merely as an example, one such implementation using ANSI C standard functions could be as follows: 
     A. Developer&#39;s source code should contain a line: 
     #include &lt;security --  header.h&gt; 
     B. &#34;security --  header.h&#34;file fragment: 
     #ifdef SECURITY --  ON 
     #ifdef USES --  SECURED --  GETS 
     #define gets(a) SECURED --  GETS (password, a) 
     char * SECURED --  GETS (long password, char * a); 
     #endif 
     #endif 
     C. What this does is during compiling, a test is made to see if SECURITY --  ON has been previously defined and protection for function gets () is allowed (USES --  SECURED --  GETS was defined). If so, then the standard ANSI C function gets (a) is replaced automatically by the compiler with the special security function SECURED --  GETS (password, a). The function SECURED --  GETS () has the following form: 
     
         ______________________________________//     Security library function example  char * SECURED.sub.-- GETS (long password, char * s)  SECURITY.sub.-- START ( );  count++;  if (count == HOW.sub.-- OFTEN.sub.-- TO.sub.-- CHECK)   SECURITY.sub.-- CHECK.sub.-- RESULT =   CHECK.sub.-- SECURITY.sub.-- DEVICE ( );   COUNT = 0  if (SECURITY.sub.-- CHECK.sub.-- RESULT == OK)   gets (s);  else   SECURITY.sub.-- ERROR.sub.-- HANDLER ( );  SECURITY.sub.-- END ( )}______________________________________ 
    
     D. This macro can be repeated for any standard library function call which is secured, thus allowing developer selection of the scope and frequency of security checking. 
     An example for a Security --  Header H file and a Security Library Fragment are as follows: 
     
         ______________________________________SECURITY.sub.-- HEADER.H file example#ifdef Uses.sub.-- strlen.sub.-- ssi#define strlen strlen.sub.-- ssisize.sub.-- t strlen.sub.-- ssi (const char * str);#endif#ifdef Uses.sub.-- strcpy.sub.-- ssi#define strcpy(a,b) strcpy.sub.-- ssi(510, (void *)0, b+5, a-10)char * strcpy.sub.-- ssi (int conv.sub.-- type, void * dummy, char *src, char * dest);#endifSECURITY LIBRARY FRAGMENT EXAMPLE#include &lt;string.h&gt;#include &lt;stdio.h&gt;size.sub.-- t  strlen.sub.-- ssi(const char * str)puts(&#34;SSI Function works - STRLEN.sub.-- SSI&#34;);if (SECURITY.sub.-- CHECK( ) == OK)  return strlen (str);else  return ERROR;} /* strlen.sub.-- ssi */char * strcpy.sub.-- ssi(int conv.sub.-- type, void * dummy, char *src, char * dest){puts (&#34;SSI Function works - STRCPY.sub.-- SSI&#34;);if (conv.sub.-- type == ssiCONV5.sub.-- 10) (  src -= 5;  dest += 10; ) /* if */if (SECURITY.sub.-- CHECK( ) == OK)  return strcpy (dest, src);else  return ERROR)   /* strcpy.sub.-- ssi */______________________________________ 
    
     In using the above example, the developer&#39;s source code would include: 
     # define Uses --  strlen --  ssi 
     # define Uses --  strcpy --  ssi 
     # include &#34;security --  header.h&#34; 
     The ssi represents the Software Security, Inc. security layers which have been referred to above. 
     Accordingly, a method is provided in which a developer can incorporate a security system with little or no knowledge of security systems. This may be implemented without altering the original source code or C-libraries used. 
     The security system can perform security functions on a random, periodic or other basis, such as: 
     1. Check for the presence of a security hardware device. 
     2. Encrypt/Decrypt data. 
     3. Read/Write parameters from security device memory. 
     4. Perform calculations. 
     When a security function is exercised, if a violation has occurred, e.g., removal, non-presence, or use of improper hardware security device, a security alarm will result and the software operation will be automatically halted. 
     The developer can create the application and test it without any thought given to security. When it is desired to incorporate security functions, this can be accomplished by a single directive to turn security on and requires no special knowledge on the part of the developer. The developer simply incorporates a security system already developed by experts in the security field. The developer can control the frequency of security checking. Again, it should be noted no modification of the original developer&#39;s source code is required except for a single statement for the inclusion of the security header file at the beginning of the source code. This security header can be included at the beginning of the development cycle because security can be turned on or off with an external compiler directive. 
     Since other modifications and changes varied to fit particular operating requirements and environments will be apparent to those skilled in the art, the invention is not considered limited to the examples chosen for purposes of disclosure and covers all modifications and changes which do not constitute departures from the true spirit and scope of the invention.