Security and Cryptographic Providers
LicenseSpring prioritizes software security and empowers 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 cryptographic providers, reasons for the change, and a comprehensive security best practices tutorial.
- 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.
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.
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.
Our C++ and .NET SDKs offer diverse options for enhancing security by customizing the default cryptographic provider. You have the flexibility to modify the default cryptographic 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 cryptographic 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.
We highly recommend setting a unique salt for all new products that are using LicenseSpring. This way, encryption will be different for each product.
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 cryptographic provider. It's advisable to configure the cryptographic 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 cryptographic provider.
The following can be used to specifically set the key and salt:
Note: After this code snippet, the rest of your program that uses licenseManager, including activation and file reading, will use this cryptographic provider for encryption/decryption.
In the C++ SDK, there is a setter for CryptoProvider:
Note: If the crypto provider is not set, then the default crypto provider will be used.
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.
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.
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.
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.
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.
