Project Protection Using Encryption

Practically every piece of software processes data in some way or antoher. Depending on the actual application, the data may contain a large amount of the software vendor’s or user’s know-how and intellectual property. This article shows how you, the software vendor, can protect the data. Not only do you benefit from this, but it also provides your customer with added value.

Automation with AxProtector

AxProtector’s file encryption tool provides a quick and effective way to map simple requirements. To protect your application, first of all you need to enable file encryption. You can think of AxProtector as a guard between your protected application and the file to be read. If the data file to be protected has also been encrypted using AxProtector, your protected application automatically checks whether a valid license exists for this data file. If it does, the file is automatically decrypted.

If the license is missing, the protected application will refuse to read the data file. And here you face the first restriction associated with automatic file encryption: error handling. Your original application processes this error and might therefore need to be modified slightly.

Writing to the data file is the second challenge the protected application faces. You can use a set of rules to very precisely define how to write to the file, including even the file extension.

Manual encryption

If the simple automation does not meet all your requirements or you prefer to control the system yourself, you can use the powerful functions of the CodeMeter Core API to manually integrate encryption and decryption into your application.

Each combination of Firm Code and Product Code provides a unique key which is available for you to use. CmAccess2 opens a handle to the license entry. CmCrypt2 encrypts your data and CmRelease releases the handle. CmGetLastErrorCode can be called to fetch detailed information about the last error.

Besides the Firm Code and Product Code, an encryption code is also needed to decide which key to use. You can choose any value for the encryption code but it must be a constant value stored in the source code of your software. The secret is now spread across several locations. The actual key is located in the CodeMeter license, together with all the other keys and the secret encryption code is stored in your software. The latter determines which key in the CodeMeter license is the valid one. Consequently only your software can decrypt the data. A fake or replica of your software doesn’t know the code and which key to use.

The “Create CRC” option should be enabled during encryption. Store the generated checksum together with the Firm Code and Product Code in your data file. Enable the “Check CRC” option during decryption to verify the data file has been correctly decrypted. We recommend using AES in CBC mode for the encryption. This allows data of any length to be encrypted into a single block (minimum length 16 bytes). With CodeMeter, only the first 16 bytes are transferred to the CmDongle. The remaining bytes are stored in encrypted format in the computer’s main memory so as not to compromise security. This method also guarantees high performance with large amounts of data.

Permissions management

If you want to sell data file encryption as added value to your customers, you’ll need a management strategy to access the data. There are two main methods in use:

• License-based permissions management (Firm Code and Product Code)
• Identity-based permissions management

License-based encryption

Each combination of Firm Code and Product Code produces a unique key which can be used as an individual privilege. The technical implementation is described in the “Manual encryption” section of this article. In the software you also offer the possibility of using the Firm Code and Product Code for the encryption.

If your customer, the user, wants to allocate the privileges himself, he will need his own Firm Code and an infrastructure to generate the licenses (CodeMeter License Central). This solution involves a lot of work to implement but the result is a truly flexible system for allocating access privileges, including time-limited access privileges, and for transferring licenses online.

Identity-based encryption

In many situations, the allocation of permissions is based on identity. Each person is assigned a unique identity. A data file is encrypted specifically for the specified identities which ensures that only recipients with these identities can access the data. The system is similar to the encrypted communication used for emails. Here also emails are encrypted for specific recipients. The person who encrypts the data file can also sign the data to guarantee its authenticity and integrity.

In comparison to license-based encryption, this method brings the benefits of integrity and authenticity, plus straightforward implementation. A CmDongle already has a unique identity and can easily acquire another one. The user does not need a special infrastructure to generate and manage the licenses and privileges.

Implementation is based on asymmetric cryptography. Each identity has its own private and public key pair. The private key is used to create a signature and decrypt data. The public is used to verify a signature and encrypt data. The implementation presents two challenges. First, the data must be readable by more than one recipient. Using the recipient’s public key to encrypt the data means, however, each recipient is sent different data. Second, asymmetric cryptography is unsuitable for encrypting large amounts of data.

Hybrid encryption solves both challenges. You begin by selecting a random AES and ­encrypting the relevant data with this key. Next you encrypt the random AES key with the public key of each recipient and append the results, together with the recipients’ IDs, to the data. You can also decide whether to sign the data with the sender’s private key before the data is encrypted, or to sign the whole message after the message has been encrypted. The data is usually signed before it is encrypted to guarantee its authenticity. If you sign the data after it has been encrypted, the authenticity of the whole message is guaranteed but you have no legally binding verification of actual data.

You can optionally combine this hybrid scheme with your own password blueprint for downward compatibility with your existing solution.

The protected data now contains the following information: the encrypted data, the individually encrypted key for each recipient plus the recipient’s ID, and the signature verifying the authenticity and integrity of the data.

You use the recipient’s private key to decrypt the data and the sender’s public key to verify its authenticity and integrity.

The entire process is based on the assumption that each participant knows the correct (authentic) public key of the other participant. If, for example, you have defined your public key as a constant in the source code of your software, you can verify whether the data files belong to you and reject them if they don’t. If the sender has a database with the public keys of all recipients, he can generate a data file for each recipient without having the corresponding CmDongles.

Best of both worlds

Group keys can be used to extend identity-based encryption to include the features of license-based encryption. As well as an identity, a person can be allocated a group or data-specific key which is stored as a license entry in a CmDongle. All possible license options are now available, but the private key stored as hidden or secret data is used for encryption.

CodeMeter License Central can then generate and distribute both permanent and temporary privileges. Only CodeMeter offers you this flexibility, as only CodeMeter combines asymmetric and symmetric methods in a CmDongle.

CmActLicenses, which are tied to a specific computer, offer exactly the same functionality as CmDongles. In this case encrypted versions of the keys are stored in the license file on the computer.

CodeMeter, the key monster

You may have heard the term RSA in connection with asymmetric cryptography. This is an outdated encryption method which requires a long sequence of bits to generate a key considered sufficiently secure. Calculation of the public and private key is also complicated. Successful attacks in the past which managed to crack RSA were often focused on this calculation.

For this reason CodeMeter deliberately uses the new ECC standard. A 224 bits ECC key provides the same level of protection as a 2048 bits RSA key. This means more than 2,000 different keys/identities can be stored in a CmDongle.

Compared to RSA, ECC provides an additional benefit. The private key is a pure random number which can be used to calculate the public key. This makes the process of generating key pairs easier and more robust. CodeMeter offers you support here too. Each CmDongle contains an FIPS 140 conform random number generator which you can use to generate private keys.

Summary

Whether you want to protect your data using license-based methods, identity-based methods or a mixture of both, you can be sure that CodeMeter provides an easy-to-use and secure solution for your application.

Glossary
AES	Advanced Encryption Standard (a symmetric encryption method)
CBC	Cipher Block Chaining Mode (concatenation of blocks to encrypt large amounts of data)
RSA	Rivest, Shamir and Adleman (an asymmetric cryptographic method)
ECC	Elliptic Curve Cryptography (an asymmetric cryptographic method)
FIPS	Federal Information Processing Standard
CRC	Cyclic Redundancy Check (checksum)
Hash	Cryptographic checksum

 

KEYnote 24 – Edition Fall 2012