Patent Publication Number: US-9847880-B2

Title: Techniques for ensuring authentication and integrity of communications

Description:
RELATED APPLICATION 
     This application is a continuation of and claims priority to U.S. application Ser. No. 12/146,520, filed on Jun. 26, 2008, entitled “TECHNIQUES FOR ENSURING AUTHENTICATION AND INTEGRITY OF COMMUNICATIONS,” at least some of which may be incorporated herein. 
    
    
     BACKGROUND 
     Messages may be communicated between a client, or entity originating a request, and a server, or entity responding to the request. The client may send a request message to the server, and the server may send a response message to the client. The client and server may be, for example, two computer systems, two modules on the same computer system, and the like. A problem exists regarding the data integrity and authenticity of messages exchanged between the client and the server. One or both of the client and the server may be concerned regarding the data integrity and authenticity of the messages exchanged. Data integrity may relate to the message content and ensuring that the message received is not a modified version of an original message. Authenticity may relate to the authentication of the sender in that a message received may have been generated by an entity other than the expected sender. In connection with a response received by a client, an attacker may intercept and modify a response originally sent from the server. Thus, the client receives a response having content that has been modified. Rather than intercept a response originally sent by the server, an attacker may also introduce another entity purporting to be the server which generates the response. The latter may occur, for example, if the attacker introduces a module which sends and receives messages in place of the server. Similarly, in connection with requests received by a server, an attacker may intercept and modify an original request or the attacker may otherwise introduce a module which sends and receives messages in place of the requester. 
     SUMMARY 
     This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. 
     Techniques are described for ensuring authenticity and data integrity of a communication received by a first module from a second module. In accordance with one aspect of the invention, the first module encrypts a shared secret using a public key of an asymmetric key pair and sends the encrypted shared secret to the second module. The second module retrieves the private key of the asymmetric key pair from a secure and trusted information store, such as a license information store, and uses the private key to obtain the shared secret to generate authentication data for a message sent from the second module to the first module. The first module performs verification processing using the shared secret. In accordance with another aspect of the invention, the second module uses a private key of an asymmetric key pair obtained from the license information store or other secure and trusted information store to generate a digital signature for a message sent from the second module to the first module. The first module performs verification processing using the public key of the asymmetric key pair. 
    
    
     
       DESCRIPTION OF THE DRAWINGS 
       Features and advantages of the present invention will become more apparent from the following detailed description of exemplary embodiments thereof taken in conjunction with the accompanying drawings in which: 
         FIG. 1  is an example of an environment that may be utilized in an embodiment in connection with the techniques described herein; 
         FIG. 2  is an example of components that may be included in an embodiment and used in connection with performing the techniques herein; 
         FIG. 3  is an example representation of a request that may be used in an embodiment performing the techniques herein; 
         FIG. 4  is an example representation of a response and how authentication data included the response may be determined in an embodiment using the techniques herein; 
         FIGS. 5 and 6  are flowcharts of processing steps that may be performed in an embodiment using the techniques herein; 
         FIG. 7  is an example representation of another request that may be used in an embodiment performing the techniques herein; 
         FIG. 8  is an example representation of another response and how authentication data included the response may be determined in an embodiment using the techniques herein; and 
         FIGS. 9 and 10  are flowcharts of processing steps that may be performed in another embodiment using the techniques herein. 
     
    
    
     DETAILED DESCRIPTION 
     Referring to  FIG. 1 , illustrated is an example of a suitable computing environment in which embodiments utilizing the techniques described herein may be implemented. The computing environment illustrated in  FIG. 1  is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the techniques described herein. Those skilled in the art will appreciate that the techniques described herein may be suitable for use with other general purpose and specialized purpose computing environments and configurations. Examples of well known computing systems, environments, and/or configurations include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like. 
     The techniques set forth herein may be described in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, and the like, that perform particular tasks or implement particular abstract data types. Typically the functionality of the program modules may be combined or distributed as desired in various embodiments. 
     Included in  FIG. 1  are a computer  12 , a network  14 , and a server  16 . The computer  12  may include a standard, commercially-available computer or a special-purpose computer that may be used to execute one or more program modules. Described in more detail in following paragraphs and figures are program modules that may be executed by the computer  12  in connection with ensuring the integrity and authentication of a received communication using the techniques described herein. The computer  12  may operate in a networked environment and communicate with other computers, such as a server  16 , as well as others not shown in  FIG. 1 . 
     It will be appreciated by those skilled in the art that although the computer  12  is shown in the example as communicating in a networked environment, the computer  12  may communicate with other components utilizing different communication mediums. For example, the computer  12  may communicate with one or more components utilizing a network connection, and/or other type of link known in the art including, but not limited to, the Internet, an intranet, or other wireless and/or hardwired connection(s). 
     As illustrated in  FIG. 1 , the computer  12  may include one or more processing units  20 , memory  22 , storage  30 , and a system bus  32  used to facilitate communications between the components of the computer  12 , as well as other components not illustrated in  FIG. 1 . 
     Depending on the configuration and type of computer  12 , memory  22  may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.) or some combination of the two. Additionally, the computer  12  may also have additional storage (removable and/or non-removable) including, but not limited to, USB devices, magnetic or optical disks, or tape. Such additional storage is illustrated in  FIG. 1  by storage  30 . The storage  30  may include one or more removable and non-removable storage devices having associated computer-readable media that may be utilized by the computer  12 . The storage  30  in one embodiment may include a hard disk and/or CD-ROM drive. By way of example, and not limitation, memory  22  and storage  30  are examples of computer readable media. Computer readable media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer readable media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by the computer  12 . The foregoing media typically embodies computer readable instructions, data structures, program modules or other data. 
     In one embodiment as described herein, the computer  12  may operate in a networked environment as illustrated in  FIG. 1  using logical connections to remote computers, such as the server  16 , through a network. One or more software modules and/or data files may be included in storage  30  of the computer  12 . During operation of the computer  12 , one or more of these modules included in the storage  30  may also reside in a portion of memory  22 , such as, for example, RAM for controlling the operation of the computer  12 . 
     The server  16  may represent a server computer system connected to the network  14 . The server computer system may include software modules to service requests and one or more processors, memory, storage, and the like, similar to that as described herein with respect to the computer  12 . The techniques herein may be used in an embodiment in which the computer  12  and the server  16  may communicate over the network  14 . The computer  12  and the server  16  may perform operations in connection with processing communications exchanged therebetween. For example, the computer  12  may send a request to the server  16  and the server  16  may provide a response. The techniques herein may be used to ensure the integrity and authenticity of a received communication, such as the response received by the computer  12  from the server  16 , or such as the request received by the server  16  from the computer  12 . Data integrity may relate to the communication content and ensuring that the communication received is not a modified version of the original communication. Authenticity may relate to the authentication of the sender in that a communication received may have been generated by an entity other than the expected sender. 
     The techniques herein may also be used in an embodiment in connection with communications exchanged between two modules on the same computer system, such as two modules on computer  12 . More generally, the techniques herein may be used in connection with ensuring the authentication and integrity of a message received from a sender. The techniques herein may be used in connection with communications transmitted in one direction, such as from the server  16  to the computer  12 , as well as in connection with communications transmitted in both directions, such as from the server  16  to the computer  12  and also from the computer  12  to the server  16 . 
     For purposes of illustration, exemplary embodiments are set forth in more detail below in which processing is performed using the techniques herein to ensure the integrity and authentication of a response received by a first module from a second module in which the first and second modules may be located on the same computer, such as on computer  12 . However, as will be appreciated by those skilled in the art and also more generally described elsewhere herein, the techniques may be used in connection with communications transmitted between entities on different computer systems rather than the same computer system, communications received by the first and second modules rather than just those received by the first module, and the like. 
     Referring to  FIG. 2 , shown is an example  100  of modules that may be included on the computer  12  of  FIG. 1  for use in connection with the techniques herein. The example  100  includes an application  102 , software protection services (SPS)  104  and license information store  106 . The application  102  may be an installed program on the computer  12 . License information store  106  may include licensing information for one or more software products licensed for use on the computer. The store  106  may be any one of a variety of different data storage entities including the licensing information. For example, store  106  may be a file, database, or other data container. Element  108  illustrates a logical representation of license information for the application  102  that may be included in the license information store  106 . The information of  108  may, for example, specify expiration dates, identify the computer licensed to execute the application  102 , identify the rights granted by the license, and the like. The store  106  may also include information associated with individual rights granted in the license. For example, as will be described in more detail in following paragraphs, a license may grant a right to “run” the application  102 . The license information store  106  may also associate information with the right to run. As an example, a private key of an asymmetric key pair may be encrypted and stored in  106 . The private key may be associated with the “run” right as well as other rights for the license of application  102 . It should be noted that the license information store  106  may include license data obtained in connection with prior software installations and activations performed in any of a variety of different ways. 
     As known in the art, an asymmetric key pair is used in connection with different asymmetric cryptography techniques in which different keys are used for encryption and decryption, such as use of public/private key pairs with PKI (Public Key Infrastructure). A message encrypted using the public key cannot be decrypted except by a recipient possessing the corresponding private key. The use of the asymmetric key pair in embodiments performing the techniques herein is described in more detail in following paragraphs. 
     The SPS  104  may manage licenses for one or more software products, such as application  102 , on the computer system. The SPS  104  may perform functions related to the use of licenses and expose the functions through an API. The SPS  104  may perform functions such as obtaining licenses, storing and managing licenses, protecting licenses from tampering, evaluating the validity of a license, evaluating whether a license is correctly bound to a machine (e.g., license indicates that a software product can execute on the machine), evaluating whether the license grants a particular right for the software product, and the like. The application  102  may use the API to send a request  110  to the SPS  104 . In response to receiving request  110 , the SPS  104  may send a response  112  to the application  102 . The application  102  may issue request  110  to obtain information regarding the license for the application  102 . For example, a user may issue a request to run the application  102 . “Run” may be right associated with the application indicating that the user has the right to run the application. The request  110  may be sent to SPS  104  in order to determine if the license indicates that there is an existing and valid license granting a right to run the application  102  on the computer. In response to receiving the request, SPS  104  may perform license validation and verification processing with respect to the license for the application  102  and the requested right. For example, SPS  104  may retrieve license information for the application  102  from the license information store  106  and perform processing to determine whether there is a valid license for the application  102 , whether the license indicates that the application  102  is correctly bound to the computer  12 , and whether the license indicates that the specified right is granted per the license. The response  112  returned from SPS  104  may indicate whether the foregoing validation and verification processing has been successful with respect to a currently valid license granting the requested right (e.g., the right to “run” the application in this example). 
     A license, such as may be expressed in an electronic form or document that may be stored in the license information store  106 , specifies rights in a software product. A caller, such as the application  102 , may use the API to call a “consume” method in order to “consume” a right for a software product, such as the application  102 . After successful consumption of a right for the software product, additional data associated with a right may be retrieved from the license information store  106 . With reference to element  108  as described above, after successful consumption of the run right, the private key associated with the run right may be retrieved from the license information store  106 . Consumption of a right for a software product may be characterized as processing steps performed to verify and validate a license and right for the software product as mentioned above. The license, such as expressed as an electronic document included in the license information store  106 , may include information used in connection with the consumption processing. The consumption processing may include, for example, checking whether the software product is licensed to execute on the machine on which the software is running, checking license validity such as whether the license has expired, and the like. For the software application, the license may also specify different rights which are allowed to be performed in connection with the application. For example, as just described, “run” may be a right indicating that the user has the right to run the software product. The consume rights API may be invoked to determine whether there is currently a valid license with a right to run the software product. If so, the license and right are successfully consumed. As a subsequent step after successful consumption processing, additional information, such as the private key, associated with the consumed right may be retrieved from the license for the application  102  as included in the license information store  106 . US Patent Publication 2005/0091168 A1 (&#39;168 publication), U.S. patent application Ser. No. 10/692,868, filed Oct. 24, 2003, PROGRAMMING INTERFACE FOR LICENSING, Gunyakti et al., which is hereby incorporated by reference, describes an exemplary software licensing service and API that allows other modules to use a license management functionality of a common service. The licensing management facility and API in the foregoing &#39;168 publication are similar to that as just described in connection with SPS  104 . 
     As will be described in following paragraphs, the private key retrieved from the license information store  106  upon successful consumption of a specified right may be used in connection with the techniques herein to ensure the data integrity and authenticity of the response  112  as received by the application  102  from SPS  104 . 
     In connection with one embodiment, the application  102  may establish a session with SPS  104  through an exchange of other communications between the application  102  and SPS  104  prior to the application  104  issuing the request  110 . In connection with establishing the session, the application  102  may indicate a particular public key of an asymmetric key pair that the application  102  will use in connection with subsequent communications for the session. The application  102  may also generate a session key characterized as an identifier which is unique per session. The session key may be associated with communications exchanged between the application  102  and SPS  104  for the associated session. The session key may be generated using any one of a variety of different techniques which ensures a sufficient level of uniqueness for each session. For example, the session key may have a size in the range of 16 to 64 bytes and may be generated using a random number based on the public key, current time, and the like. The session key may be more generally referred to herein as one type of shared secret representing an identifier having a different value for each session. 
     The application  102  encrypts the shared secret using the public key of the asymmetric key pair as specified when establishing the session with SPS  104 . The application  102  constructs the request  110  that includes the encrypted shared secret and any other data for the particular request. Such other data may, for example, identify a right for which the request  110  is being issued. As described above, the request  110  may be a query as to whether a right, such as the “run” right, included in the request is granted in a valid license indicating that application  102  is allowed to execute on the computer  12 . 
     It should be noted that the shared secret may be “shared” with respect to the application  102  and as communicated in encrypted form to the SPS  104 . 
     Referring to  FIG. 3 , shown is an example representation of a request  110  as may be sent from the application  102  to SPS  104 . The request  602  includes request data  604 , the encrypted shared secret  606 , and optionally other information  608  for the request. The request data  604  may, for example, identify a particular operation to be performed by SPS  104 , identify one or more rights, identify the application  102 , and the like. Element  606  may represent the shared secret which is encrypted using any one of a variety of different asymmetric encryption techniques, such as RSA, using the public key associated with the current session. 
     SPS  104  receives the request  110  and performs processing to consume the specified right in the request with respect to the license for the application  102 . As described above, the consumption of rights may include performing validation and verification processing with respect to the license and specified right for application  102  based on information included in the license information store  106 . For example, SPS  104  may retrieve license information for the application  102  from the store  106  to determine whether the license has expired, whether the license indicates that the application  102  is authorized to execute on the particular computer  12 , whether the right specified in the request  110  is granted in the license, and the like. If processing determines that the specified right is granted in connection with a valid license for use on the computer  12 , the right has been successfully consumed. Upon successful consumption of a right, additional information associated with that right may be subsequently retrieved from the license information store  106 . In connection with an embodiment in accordance with the techniques herein, a private key may be associated with the specified consumed right and retrieved from the store  106 . The private key may correspond to the public key of the asymmetric private/public key pair used by the application  102  to encrypt the shared secret. Upon successful consumption of the specified right for the request  110 , SPS  104  retrieves the private key from the license information store  106 , and decrypts the encrypted shared secret  606  as included in the request from the application  102 . SPS may also perform other processing in connection with the request. 
     It should be noted that SPS  104  may perform processing to determine whether a private key retrieved from the license information store  106  is the mated asymmetric key for the public key specified when the session was established. For example, the license information store  106  may include both the private key and the corresponding public key of the asymmetric pair and both may be retrieved from  106 . SPS  104  may determine whether the public key retrieved from the store  106  matches the public key specified when the session was established. If the public keys do not match, SPS  104  may take appropriate steps such as terminating processing and returning an appropriate status in the response. Also, there may be multiple private keys retrieved upon successful consumption and SPS may perform processing by matching public keys to select the appropriate private key. 
     Referring to  FIG. 4 , shown is an example illustrating processing that may be performed to determine data included in the response  112  to be sent to the application  102 . The response  704  may include a version number  702   a , optional response data  702   b , an optional nonce  702   c , and authentication data  702   d . As described below, the version number  702   a , and optionally the response data  702   b  and/or the nonce  702   c , may be used as an input to processing which generates the authentication data  702   d . A nonce may be referred to as a “number used once” that changes with each message that is authenticated as described below in more detail in connection with element  702 . 
     The version number  702   a  may be a version number associated with SPS  104 . The version number  702   a  may be obtained by SPS  104  in a variety of different ways. For example, the version number may be coded within the module SPS  104 , retrieved from the license information store  106  or other predetermined location on the computer  12 . An embodiment may select a suitable size for the version number  702   a . For example, an embodiment may use a version number  702   a  which may have a maximum size of 4 bytes. The response data  702   b  may be optional, for example, if the particular request  110  does not have any information that is returned to the caller. Nonce  702   c  may be characterized as a number or other token that is unique for each response communication. For example, nonce  702   c  may be a random or pseudo-random number generated by SPS  104 . The nonce  702   c  may be used in an embodiment to assist in the prevention of replay attacks. A replay attack may be characterized as an attack in which a valid data transmission may be intercepted and then repeated or retransmitted. Such a replay attack may be prevented since a different nonce  702   c  is included in each response thus causing the message data  702  and generated authentication data  702   d  to also change for each response. 
     As illustrated, the message data to be authenticated  702  may include  702   a  and may also include  702   b  and/or  702   c . The message data  702  may be formed by concatenating  702   a  and optionally  702   b  and/or  702   c . The message data  702  is a first input to an envelope function  712  which uses the shared secret  710  in determining the authentication data  702   d . In one embodiment, the envelope function  712  may be processing performed to determine an HMAC (keyed-hash message authentication code) value as the authentication data  702   d . An HMAC value may be calculated using a cryptographic hash function in combination with a key, which in this example is the shared secret  710 . As described above, the shared secret  710  may be obtained by decrypting a portion of the request using the private key obtained from the license store  106 . The HMAC value may be used as authentication data  702   d  to verify both data integrity and authentication of message data  702  used to generate the HMAC value. HMAC may be defined as:
 
 HMAC   KEY ( M )= h ((KEY XOR opad∥ h  ((KEY XOR ipad)∥ m ))  EQUATION 1
 
     Where h is a selected cryptographic hash function, KEY is a key, such as the shared secret obtained by decrypting a portion of the request, where KEY is padded with extra zeroes for the particular block size of the hash function, h, and M is the message  702  to be authenticated. It should be noted that “∥” denotes concatenation, XOR denotes the logical exclusive OR operation, and the outer padding “opad” is a hexadecimal constant 0x 5c5c5c . . . 5c5c and inner padding “ipad” is also a hexadecimal constant 0x363636 . . . 3636. In this example, M may be represented as  702  formed as a result of concatenating the version number  702   a , and optionally, the response data  702   b  and/or the nonce  702   c . Any one of a variety of different cryptographic hash functions, such as SHA-1, or MD-5, may be used as the hash function, h, in the above-referenced expression for HMAC. The cryptographic strength of the HMAC value may depend on the underlying hash function, size and quality of the key, and size of the hash output length in bits. 
     In connection with HMAC, the KEY is used in forming the content which is hashed by the hashing algorithm, h. As an alternative, rather than determine authentication data using EQUATION 1 (HMAC) as the envelope function, an embodiment may use a symmetric cryptographic technique such as AES (Advanced Encryption Standard) as the envelope function which uses the shared secret as the symmetric key. In other words, rather than use an envelop function  712  that is a keyed hash algorithm based on a hash function to generate an HMAC value as the authentication data, an embodiment may alternatively use as the envelope function  712  a keyed hash algorithm based on a symmetric cryptographic technique, such as AES to generate authentication data  702   d . In connection with symmetric cryptographic techniques such as AES, the key is used as a first input and the content forming the message is a second input. It should be noted that a symmetric cryptographic technique uses a same key for encryption and decryption operations. 
     It will be appreciated by those skilled in the art that the envelope function may be more generally any algorithm that generates authentication data based on inputs including the message and key. The HMAC algorithm and symmetric cryptographic techniques as described herein are examples of the envelope function that may be used in an embodiment. 
     The nonce  702   c  may be determined in a variety of different ways and made known to both the application  102  and SPS  104  in a variety of different ways. For example, SPS  104  may use a time-based value, random number generator, and the like, to generate a value used as the nonce. The response  112  sent to the application from SPS may include this nonce, or a value from which the application can determine/derive the nonce. As another example, the application may determine the nonce, or value used to derive the nonce, and may include this in the request sent to SPS. SPS may then use this nonce to form the message  702  used in determining the HMAC value. More generally, an embodiment using a nonce  702   c  may generate the nonce in any way that is understood by SPS and the application. 
     Once the authentication data  702   d  has been determined, SPS  104  constructs the response  704  as illustrated and transmits the response  704  to the application  102 . It should be noted that the response data  702   b  and other portions of the response may be optionally encrypted in an embodiment. An embodiment may select to encrypt the response data  702   b , for example, if the response data  702   b  includes valuable content or content which SPS  104  does not want to transmit in a readable form. 
     Upon receipt of the response, the application  102  performs any decryption necessary, for example, if SPS  104  encrypted the response data  702   b . The application  102  then performs verification processing. More specifically, the application  102  computes its own copy of authentication data in the same way that SPS  104  computed authentication data included in the response. The application  102  computes its own copy of authentication data using the shared secret, which is already known to the application  102 , as well as the version number  702   a , and response data  702   b  and/or nonce  702   c , if any, as included in the received response. The application  102  performs processing for determining an HMAC value or other envelope function as may be used in an embodiment to determine authentication data. The application  102  compares its own computed copy of the authentication data to the authentication data  702   d  included in the response. If the two match, then verification processing is successful. Otherwise, verification processing fails. 
     It should be noted that an embodiment may also perform additional steps in connection with verification processing. For example, the application  102  may also perform an additional check in connection with the version number  702   a  received in the response. The application  102  may retrieve an expected value of the version number and compare the expected value to the version number  702   a  included in the response. The application  102  may obtain the expected version number in a variety of different ways such as those described elsewhere herein in connection with SPS  104 . 
     In connection with the exemplary embodiment just described, the application wants to ensure that the response received has been sent by SPS  104 , and not another entity purporting to be SPS  104 . The application  102  also wants to ensure that the received response has not been modified. To ensure the authenticity and data integrity of the received response, the application  102  generates a challenge, which is the shared secret, encrypts the challenge with the public key, and sends the encrypted challenge to SPS  104 . SPS  104  then performs processing to prove that it is in possession of the private key stored in connection with the license information for the application  102 . SPS  104  proves it is in possession of the private key by decrypting the challenge (e.g., shared secret) and using the decrypted value to form the authentication data. The application  102  verifies the response by computing expected authentication data and comparing the received authentication data in the response to the expected authentication data. 
     Referring to  FIGS. 5 and 6 , shown are flowcharts of processing steps that may be performed in an embodiment in accordance with the techniques herein. The steps of  FIGS. 5 and 6  summarize processing just described above. At step  302 , the application establishes a session with SPS and indicates the public key to be used during the session. SPS will use this public key to determine the matching asymmetric private key to be retrieved from the license stored in subsequent processing. As described above, the session may be established, for example, by one or more communications exchanged between the application and SPS. At step  304 , the application generates the shared secret and encrypts the shared secret with the public key associated with the session in step  302 . At step  305 , the application sends the encrypted shared secret to SPS as part of the request. At step  308 , SPS receives the request. At step  310 , SPS performs processing to consume a specified right as may be indicated in the request with respect to the license for the application. At step  312 , a determination is made as to whether consumption processing was successful. If not, control proceeds to step  314  where steps associated with unsuccessful consumption processing may be performed. Step  314  may include SPS returning a code indicating the status of step  310  processing. If step  312  evaluates to yes, control proceeds to step  316  where SPS obtains the private key of the asymmetric key pair for the public key of step  302 . Step  316  may include the SPS retrieving the private key from the license information store including license information for the application. From step  316  of  FIG. 5 , control proceeds to step  402  of  FIG. 6  where SPS uses the private key to decrypt data of the request and obtain the shared secret. At step  404 , SPS uses the version number, nonce (optional), and response data (optional) to form a message for which authentication data is determined using the shared secret as the key. SPS constructs a response including the version number, nonce (optional), response data (optional), and authentication data. An embodiment of the SPS may also optionally encrypt the response data and/or other information included in the response. At step  406 , SPS sends the response to the application. The application decrypts the response, if necessary, and computes authentication data. The application performs verification processing by comparing the computed authentication data to the authentication data received in the response. An embodiment may also perform other comparisons in connection with verification processing such as, for example, comparing the received version number in the response to an expected version number. At step  408 , a determination is made as to whether the authentication data values of step  406  match. Step  408  may also include determining whether comparisons between other data values, such as expected and received version numbers, indicate a match. If step  408  evaluates to yes, the application determines that verification processing is successful. Otherwise, if step  408  evaluates to no, the application determines that verification processing has failed. Successful verification processing ensures the application regarding the authenticity and integrity of the received response. 
     What will now be described is another embodiment using the techniques herein in which SPS uses the private key retrieved from the license information store for generating the authentication data, which is a digital signature, using an asymmetric cryptographic technique, such as RSA. The private key retrieved from the license may be used to form the digital signature. The application may receive the response including the authentication data (digital signature) and then use the public key in connection with performing verification processing. In connection with verification processing, the application receives the encrypted hash value which is the digital signature, computes a newly generated hash value formed by the application, and uses the public key to verify the newly generated hash value against the digital signature. In this embodiment, the “message” used by SPS to generate the hash value which is then encrypted (by SPS as the “signature”) using the private key may include the following concatenated together: module version number, response data (if any) and/or nonce (if any). The nonce may be determined and made known to SPS and the application in a variety of different ways similar to that as described above. In connection with this latter embodiment using digital signatures, the request doesn&#39;t need to include a shared secret. Rather, the application may specify the public key to use, for example, when the session is initially established. SPS may retrieve the private key corresponding to this public key which it uses to form the digital signature in the response. The application may then perform verification processing using the public key before accepting the response as valid. 
     What will now be described in more detail are representations of the request and response and flowcharts of processing steps that may be used in an embodiment using digital signatures as just described. 
     Referring to  FIG. 7 , shown is an example of a request that may be used in an embodiment in which the authentication data is a digital signature. The request  1002  includes request data  1004  and optionally other information  1006 . In contrast to the request of  FIG. 3 , the encrypted shared secret is omitted from the request in this latter embodiment. Other portions of the request are similar to as described above in connection with  FIG. 3 . 
     Referring to  FIG. 8 , shown is an example illustrating processing that may be performed to determine data included in the response  1130  sent to the application  102 . The response  1130  may include a version number  1102   a , optional response data  1102   b , an optional nonce  1102   c , and authentication data  1102   d . Elements  1102   a ,  1102   b  and  1102   c  may be as described above in connection with  FIG. 4 . The response  1130  also includes authentication data  1102   d  but the authentication data  1102   d  in this embodiment is the digital signature in contrast to the authentication data  702   d  of  FIG. 4 . In the example  1100 , the message data  1102  may be input to a cryptographic hash function  1104  which generates a hash value  1106  which is then encrypted using encryption processing  1110  using the private key  1112  to obtain the digital signature  1102   d  as the authentication data  1102   d . In connection with this embodiment, the components included in  1120  may form processing performed by the envelope function generally described above and, for example, as illustrated in  FIG. 4 . 
     Referring to  FIGS. 9 and 10 , shown are flowcharts of processing steps that may be performed in connection with another embodiment using the techniques herein.  FIGS. 9 and 10  summarize processing just described in an embodiment in which the authentication data is a digital signature. In connection with steps of  FIGS. 9 and 10 , it will be appreciated that some processing steps are similar to that as described in connection with  FIGS. 5 and 6 . At step  802 , the application establishes a session with SPS and indicates a public key to be used during the session. Step  802  is similar to step  302  of  FIG. 5 . In step  804 , the application forms and sends the request to SPS. An example of such a request is illustrated in  FIG. 7 . In step  806 , SPS receives the request and performs consumption processing in step  808 . In step  810 , a determination is made as to whether consumption processing is successful. If not control proceeds to step  812 . If so, control proceeds to step  814  where SPS retrieves the private key from the license information store. Steps  808 ,  810 ,  812 , and  814  are respectively similar to steps  310 ,  312 ,  314  and  316  of  FIG. 5 . 
     In step  902 , SPS determines the digital signature as authentication data. The version number and optionally the response data and/or nonce are used to form the message data for which a hash value is determined. The hash value is then encrypted using the private key and the resulting encrypted data is the digital signature included in the response as the authentication data. In step  904 , SPS constructs the response including the version number, response data (optional), nonce (optional), and authentication data. The response data and/or other information in the response may be optionally encrypted as described in connection with step  404  of  FIG. 6 . In step  906 , the response is sent to, and received by, the application. The application decrypts the response data or other portions of the response as needed. In step  908 , the application verifies the digital signature by computing a hash value of the message and using the public key to verify the computed hash value against the digital signature. At step  910 , a determination is made as to whether verification processing is successful. If so, verification processing is successful and control proceeds to step  912 . Otherwise, verification processing fails and control proceeds to step  914 . As described in connection with step  406  of  FIG. 6 , step  908  may also include comparing other values, such as the received and expected version number, as part of verification processing. In such a case, step  910  may include determining whether the version numbers match. Successful verification processing may be determined in accordance with the authentication data verification, version number comparison, and other comparisons that may be performed in an embodiment. 
     As described above such as in connection with an embodiment using a digital signature as authentication data, a message may be digitally signed by first determining a hash value for the message content using a hash function to generate a cryptographic hash value. A hash function is an algorithm which creates a digital representation or “fingerprint” in the form of a “hash value” or “hash result” of a standard length. Any change to the message content produces a different hash result when the same hash function is used. The hash value computed for the message content is then encrypted. As part of signing, the message sent to another party may include the message content and the encrypted hash value. The encrypted hash value may also be referred to as the digital signature. Any one of a variety of different hash functions and encryption techniques known in the art may be used in an embodiment. The receiver of the message may then compute a new hash value for the message content received using the same hashing algorithm as the sender and perform verification processing of the new hash value against the digital signature using the public key. 
     The exemplary embodiments described herein may be used in connection with preventing software piracy. As an example, an unauthorized copy of application  102  may be installed for use on a computer. An attacker may, for example, substitute another module in place of SPS  104  which the application  102  communicates with as described herein when a user attempts to run the unauthorized copy of the application. An attacker may also intercept and modify a response sent by SPS  104 . An embodiment may use the techniques herein so that the application  102  may communicate with SPS to determine whether the license is valid and grants the necessary rights to perform a requested operation. The techniques herein may be used to ensure the integrity and authenticity of the response received by the application  102  so that the application  102  may detect a received communication which has been compromised by an attacker such as described above. 
     In connection with the exemplary embodiments described herein, the private key may be stored in connection with license information associated with a particular software application. For example, as described above, the private key may be included as part of the license information associated with an application and the license information may be included in a license information store. It will be appreciated by those skilled in the art that the license information for an application is one particular type of application specific information. Other embodiments using the techniques herein may store and associate the private key in connection with other types of application specific information other than license information. Furthermore, the private key and application specific information associated with an application may be stored in other types of repositories or data stores besides a license information store. More generally the application specific information, including the private key, may be stored in any type of secure and trusted information store. The secure and trusted information store may be a data store for storing one or more different types of application specific information including the private key. Also, as described herein in connection with license information, the private key may not be retrieved unless there has been successful consumption processing where the consumption processing includes, for example, determining that there is a valid license for the application and that specified rights are granted by the license. Thus, the license information store provides security and access control in connection with the private key in that the private key cannot be obtained unless consumption processing is successful. In an embodiment in which a different type of secure and trusted information store is used rather than the license information store, other verification and/or validation processing may be required to be successfully performed other than consumption processing prior to providing access to the private key. Such verification and/or validation processing may vary with embodiment and may include, for example, verifying that required data is provided by the application or other module attempting to obtain the private key, verification and/or validation of other data included in the application specific information, verification regarding hardware and/or software information such as, for example, that the application is executing on a particular computer system using a particular operating system, and the like. 
     Described above are just two examples illustrating use of the techniques herein. It will be appreciated by those skilled in the art that the techniques herein may more generally be used in connection with communications transmitted from any sender to any receiver on the same or different computer systems. Furthermore, the techniques may be used in connection with communications sent in one direction with respect to two modules or other entities, or communications sent in both directions. With respect to the examples herein, the techniques are illustrated in connection with communications sent in one direction from SPS  104  to the application  102 . However, the techniques herein may also be used in connection with communications sent from the application  102  to SPS  104 , alone, or in combination with using the techniques herein in connection with communications sent from SPS to the application. 
     Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.