Security and Crypto Providers

16min
LicenseSpring prioritizes empowering vendors to bolster their software security. 
While offering a default cryptographic service provider, we enable software vendors to adapt it according to their needs. 
This guide outlines changing crypto providers, reasons for the change, and a comprehensive security best practices tutorial.
Prerequisites
Completed the Getting Started﻿ Tutorial, specifically:
Initialized LicenseManager (or LicenseHandler) with your configuration using the appropriate settings.
Created a LicenseID using either LicenseID::fromKey or LicenseID::fromUser function, depending on the activation method you prefer.
Implemented basic license management, including license activations, deactivations, and both online and local license checks.
Crypto Providers
A cryptographic provider, often referred to as a cryptographic library or module, is a software component that offers a collection of cryptographic algorithms and functions to secure data through encryption, decryption, digital signatures, hashing, and more.
Default Crypto Provider
Certain LicenseSpring SDKs utilize a license file stored locally on the user's device for the purpose of validating their license status. This file serves as a repository for crucial license-related information as well as user data. 
To maintain the security of this data, every time a license file is generated, it undergoes encryption through our proprietary cryptographic provider. 
Subsequently, during the program's execution, the cryptographic provider facilitates the decryption of the license file, rendering the enclosed data usable within the program.
For security considerations, we are unable to divulge specifics about the underlying algorithm of our default cryptographic provider. However, we do offer mechanisms to enhance the sense of security for users, ensuring their confidence in the robustness of the cryptographic provider.
For information on when default encryption and decryption occurs, see Custom License Storage﻿.
Changing Crypto Provider
Our C++ and .NET SDKs offer diverse options for enhancing security by customizing the default crypto provider. You have the flexibility to modify the default crypto provider by implementing the designated interface found in both the C++ and .NET SDKs. However, for a more straightforward approach, you can maintain the default crypto provider and instead alter the salt and key used.
In simpler terms, a key functions similarly to a password, enabling data encryption and decryption. On the other hand, a salt is appended to your data to increase the complexity of decryption. This adjustment lets you distinguish your encryption method from the default approach in a straightforward manner.
While we entrust the implementation of the interface to developers, as it depends on their encryption preferences, we will demonstrate here how to establish the salt and key for the default crypto provider. It's advisable to configure the crypto provider early in your application, alongside the other license settings, to ensure that it's in place before activation. This proactive approach ensures the encryption of your local license file using the designated crypto provider.
The following can be used to specifically set the key and salt:
C++
C#
Swift
|
/// LicenseCryptor is protocol declared in SDK to implement custom license encryption routines.
///
/// ```
/// @objc
/// public protocol LicenseCryptor {
///     func encrypt(_ data: Data) -> Data?
///     func decrypt(_ data: Data) -> Data?
/// }
/// ```

struct MyCryptor: LicenseCryptor {
    func decrypt(_ data: Data) -> Data? {
        ...
        return decrypted
    }
    
    func encrypt(_ data: Data) -> Data? {
        ...
        return encrypted
    }
}
configuration.licenseCryptor = MyCryptor()
/// LicenseCryptor is protocol declared in SDK to implement custom license encryption routines.
///
/// ```
/// @objc
/// public protocol LicenseCryptor {
///     func encrypt(_ data: Data) -> Data?
///     func decrypt(_ data: Data) -> Data?
/// }
/// ```

struct MyCryptor: LicenseCryptor {
    func decrypt(_ data: Data) -> Data? {
        ...
        return decrypted
    }
    
    func encrypt(_ data: Data) -> Data? {
        ...
        return encrypted
    }
}
configuration.licenseCryptor = MyCryptor()
﻿
Note: After this code snippet, the rest of your program that uses licenseManager, including activation and file reading, will use this crypto provider for encryption/decryption.
In the C++ SDK, there is a setter for CryptoProvider:
C++
|
options.overrideCryptoProvider( cryptoProvider );
options.overrideCryptoProvider( cryptoProvider );
﻿
Note: If the crypto provider is not set, then the default crypto provider will be used.
Why Change Crypto Provider?
Introducing a customized encryption and decryption algorithm is relevant if your product already employs a specific encryption algorithm that you wish to maintain uniform across your software, including licensing components. 
Moreover, developers have the liberty to adopt this approach if they hold reservations about utilizing an external encryption algorithm and instead prefer to develop and integrate their own encryption methodology. 
This level of autonomy empowers developers to align encryption practices with their individual security considerations and preferences.
Other Security Features
Encrypting Strings
In C++, the potential exists to extract strings from an application after it has been compiled. 
This can potentially expose sensitive information, such as API keys, shared keys, management keys, product codes, and various other strings of value. This vulnerability underscores the importance of safeguarding these strings. 
Fortunately, the C++ SDK offers a solution: the EncryptStr() method encrypts these strings during compile-time and decrypts them during run-time.
Embracing this method is highly advisable for constant strings that necessitate shielding from user access. 
By employing this approach, you can significantly enhance the security of your application's sensitive information, ensuring that these strings remain well-protected throughout the application's lifecycle.
C++
|
auto configuration = Configuration::Create(
        EncryptStr( "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" ),
        EncryptStr( "XXXXXXXXX-XXXXX-XXXXXXXXXXXXX_XXXXXX_XXXXXX" ), 
        EncryptStr( "XXXXXX" ),
        "NAME", "VERSION", options );
auto configuration = Configuration::Create(
        EncryptStr( "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" ),
        EncryptStr( "XXXXXXXXX-XXXXX-XXXXXXXXXXXXX_XXXXXX_XXXXXX" ), 
        EncryptStr( "XXXXXX" ),
        "NAME", "VERSION", options );
﻿
Logging
While logging serves as a valuable tool for debugging purposes, it holds utmost significance to disable logging in your release build. Failing to do so could potentially expose users to any information that has been logged. The nature of this information can encompass a wide array of data. 
For a comprehensive understanding of the type of information that could be at risk, we recommend referring to our Logging Tutorial﻿.
By deactivating logging in your release build, you take a crucial step toward safeguarding user privacy and preventing unintended exposure of sensitive data. This practice contributes to the overall security and integrity of your software product.
License Security
Implementing license checks, whether conducted offline or online, during both application opening and closing is highly advisable. 
These checks play a pivotal role in verifying the ongoing validity of a license and ensuring its integrity remains intact. 
Such measures are especially effective in thwarting potential tampering attempts, such as altering the date to extend license validity artificially or transferring an activated license file to an unauthorized device lacking the corresponding license.
Air-Gapped Licensing
In zero-trust networks, where security is a top priority and trust assumptions are minimized, adopting Air-Gapped Licensing﻿ can offer substantial advantages. 
Air-gapped licensing involves keeping the licensing process entirely isolated from external networks and internet connectivity. This approach enhances security by reducing the potential attack surface and preventing unauthorized access to licensing components.
Updated 05 Sep 2023
Did this page help you?
Custom License Storage
Extended Configuration
Docs powered by
Archbee
TABLE OF CONTENTS
Prerequisites
Crypto Providers
Default Crypto Provider
Changing Crypto Provider
Why Change Crypto Provider?
Other Security Features