Product Activation Based on RSA Signatures

Tuesday Dec 5th 2006 by Jeffrey Walton

Share:

Learn how to create a Signing of Product Keys to validate activations.

Introduction

This article will present the reader with a framework for Product Activation. It is a logical conclusion to Product Keys Based on the Advanced Encryption Standard and Product Keys Based on Elliptic Curve Cryptography. The final portion of the series will discuss the following:

RSA Cryptography

Compiling and Integrating Crypto++ into the Microsoft Visual C++ Environment

Product Activation

Named Pipe Client/Server

Generating and Serializing RSA Keys

RSA Signing and Verification Functions

Product Key Signing

RSA Cryptography

RSA is the work of Ron Rivest, Adi Shamir, and Leonard Adleman. The system was developed in 1977 and patented by the Massachusetts Institute of Technology. Although Rivest, Shamir, and Adleman are generally credited with the discovery, Clifford Cocks (Chief Mathematician at GCHQ—the British equivalent of the NSA) described the system in 1973. However, Cocks did not publish (the work was considered classified), so the credit lies with Rivest, Shamir, and Adleman.

The RSA patent expired in September of 2000, and was subsequently placed in Public Domain. See RSA Security's Press Release.

Compiling and Integrating Crypto++ into the Microsoft Visual C++ Environment

Please see the related article, "Compiling and Integrating Crypto++ into the Microsoft Visual C++ Environment." This article is based upon basic assumptions presented in the previously mentioned article. It also addresses most problems encountered with projects from Command Line to MFC (Errors C1083, C1189, LNK1104, LNK2001, and LNK2005). Additionally, it provides some tips and other nicities for using the Crypto++ Library.

Product Activation

Product Activation is the process of validating the Product Key. Software authors may desire activation for any number of reasons. The two most prevalent appear to be thwarting piracy and developing end user demographics.

In the Piracy arena, an Activation Server can:

Detect circulated Product Keys using statistical methods

Enforce renewal periods by removing the system time functions from the end user's computer

Product Activation works by validating that the software's product key, required as part of product installation, has not been used on more PCs than is allowed by the software's end user license agreement (EULA).

... Microsoft designed Product Activation as a simple way to verify the software license and thwart the spread of software piracy.

This implies Product Activation is an ongoing or recurring process. For the purposes of this article, Product Activation workflow will proceed as depicted below.

[image02.gif]

Named Pipe Client/Server

To provide a realistic implementation, this article will use Named Pipes in blocking mode as the underlying communication. Named Pipes is an interprocess communication mechanism thatch is easy to implement so the reader can focus on the cryptographic functions without the distraction of asynchronous socket programming. Note that Q177696, How To Use Named Pipes in a Visual Basic 32-bit Program is the most concise documentation for using Named Pipes the author has found.

The author chose a single Workspace with two projects: a Client Project and a Sever Project.

[image04.gif]

At times, it is a bit inconvenient because a switch must occur to the 'Active Project' (by way of the Project menu shown below).

[image05.gif]

The first step in the Product Activation Server implementation is developing an echo server based on Named Pipes. The following points should be observed with respect to the following code:

Named Pipe Client/Server (continued)

[image06.gif]

The Client program is very similar to the Server—the difference being the Client uses PipeOpen() rather than PipeCreate(). The perceptive reader will realize that the communication portion of the Proof of Concept is complete. Recall that the Client must send the Product Key to the Server, and the Server must send the Signed Product Key back to the Client.

RSA keys are generated for use in the Signing function. Should the user want to encrypt the Product Key before transmission for Signing by the Server (and return to the Client), the reader should: 1) use a Symmetric Ciper such as AES; or 2) use SSL.

[image07.gif]

Most operations on the RSA Keys will be perform by way of Crypto++'s RSAFunction class. The inheritance diagram is shown above. The reader is encouraged to view rsa.h at this point. Functions of interest in the class include:

Generating and Serializing RSA Keys (continued)

Retrieving the key from the keyfile would be accomplished as follows. patest3 loads the previously saved Public and Private Key pairs. Prior to running the sample code, the reader should copy key.pb and key.pv to the current working directory. It is noteworthy that the keys are not encrypted on the disk. It is left as an exercise for the reader.

RSA Signing and Verification Functions

The Crypto++ Library provides the user with sample code by way of the validation routines. Two such samples are RSASignFile and RSASignFile (located in test.cpp). The provided code will be the base for the Signing and Verification. However, rather than operating on Files, patest4 will operate on an in memory Message string. Note that the Signature is still written to a file.

Product Key Signing

The software author will have to determine what to send, and how to send it. Just as previous examples have interpreted the string based on a predefined format, so must the vendor's implementation. This would include control messages and data. For simplicity, it is recommended that control messages be sent in band (in other words, as a string concatenation).

Unique installations can be tracked by way of a hashing of end user hardware components. To provide tolerance, the Activation logic should allow for hardware changes (in other words, allow X components to change before invoking a reactivation).

Additionally, no personally identifiable or private information should be sent. Current systems implement this by discarding portions of each hash. This has the net effect of lessening the collision domain, but the probabilistic chance of hardware changes mapping to themselves are very small. For example, suppose one creates a 32-bit digest of the Network Adapter MAC Address, IDE Adapter, and Display Adapter. Discard the high-order 26 bits of each hash, and use the low order 6 bits for identification purposes. Given that one knows the low order-6 bits, one cannot determine the Adapter because many Adapters will obtain a similar hash.

The reader should also consider assigning a relative weight to the value of each hash. For example, RAM amount probably changes more frequently than CPU speed. So, a change in RAM should affect the system less than a change in CPUs.

Much has been written on Windows Product Activation with the release of Windows Vista. WPA employs these techniques. The reader should further investigate the Microsoft Scheme to increase his or her understanding. The author is aware of papers circulating which was considered an accurate Reverse Engineering attempt by GmbH in July, 2001. Note that this was with respect to Windows XP RC1.

For the purposes of this article, only the Product Key will be sent to the Server to be Signed. The Signature is sent back to the Client, not the {Key, Signature} tuple.

Product Key Signing (continued)

The following two outputs show the results of patest5. patest5 Base64 Encodes the Product Key; and receives the same product key from the server. The changes to the Client are listed below (the Server is similar).

Product Key Signing (continued)

patest6 culminates this article. The Server program uses the Private Key to Sign the Product Key (not Encrypt), and the Client program uses the Public Key to Verify the Signature. The source code is a melding of the previous examples presented.

[image17.gif]

Client: Successful Product Activation

[image18.gif]

Server: Successful Product Activation

Should the user desire to test a failed Activation, set bool Valid = true. This will cause the Server to sSign a NULL Key ( literally "NULL-NULL-NULL-NULL-NULL-NULL-NULL"). When the Client Verifies the Signature, S(M) ≠ S(NULL), so the Activation fails.

[image19.gif]

Failed Activation

Both the Client and the Server share common function implementations. For example, Base64Encode() and Base64Decode(). The Server solely uses SignMessage(), whereas the same is true for VerifySignature() with respect to the Client.

Summary

Product Activation can be a useful tool for software vendors to both decrease losses due to pircay and increase their understanding of their user base. As with any technology, it should be used in moderation.

Acknowledgements

Wei Dai for Crypto++ and his invaluable help on the Crypto++ mailing list