A short tutorial on what custom fields and device variables are, and how they can be used within your application.
Providing vendors with the ability to amply secure their software is one of LicenseSpring’s priorities. Although LicenseSpring provides a default cryptographic service provider, software vendors are able to change it to tailor to their needs. In this guide we will cover how to change crypto providers, why you might want to change, and a thorough security best practice tutorial.
- Crypto Provider
- Security Best Considerations
Default Crypto Provider
Some LicenseSpring SDKs use a local license file stored on the device to validate a user's license status. This file also holds important information concerning the license, and the user's data. Because of this, whenever a license file is created, it is encrypted using our implemented crypto provider. Then, during our program, the crypto provider decrypts our license file, making the data usable within our program. For security reasons, we cannot disclose information on our default crypto provider algorithm, but we offer ways to ensure the crypto provider feels more secure for users.
How to Change it
Our C++ and .NET SDKs offer multiple ways to change the default crypto provider for added security. You can change the default crypto provider by implementing the interface provided in the C++ and .NET SDKs, however, an easier way is to simply use the default crypto provider, and change the salt and key. For a quick definition, a key is used to encrypt/decrypt data much like a password, while salt is appended to your data to make it more difficult to decrypt. This will allow you to differentiate your encryption from the default encryption in a simple manner.
We will leave implementing the interface to the developer, as it varies depending on how a developer wants to encrypt their data, but we will show here how to set the salt and key for a default crypto provider. You will need to have crypto provider set within your application before activation to encrypt your local license file, so it is generally a good idea to set it at the beginning of application along with the rest of your license configuration.
Reasons to Change
If a vendor desires total autonomy over their software, it is possible to implement a personalized encrypting/decrypting algorithm. For example, you may already have an encryption algorithm in your product, and you may want to keep it consistent, even in your license. In that case, you may want to override the default crypto provider with your own implementation. Furthermore, developers can use it if they do not feel safe using an outside encryption algorithm, and would rather implement their own algorithm.
Security Best Practices Guide
In C++, it is possible to extract Strings after an application has been compiled. This can put your valuable Strings such as your API key, Shared key, Management Key, Product Code, and other Strings at risk. Luckily, the C++ SDK comes with a method that encrypts these strings at compile-time, and decrypts them at run-time. It is recommended to use this method on any constant Strings that you do not want users to have access to.
Although logging is useful for debugging, it is very important to turn off logging for your release build. If not, then users will be able to see any information recorded in their logs. To see what kind of information this could be, see our Logging Tutorial.
It is recommended to use license checks (offline or online) at application open and application close. These checks make sure the license is still valid, and that it has not been tampered with, such as moving the date backwards to extend the amount of time before a license expires, or transferring one activated license file to another device that does not have a license file activated.
Air Gapped Licensing
For activating licenses in zero trust networks, using air gapped licensing will prove beneficial. To see more on air gapped licensing, click here.
In this tutorial we went through some of the basic security considerations when creating your application using LicenseSpring. LicenseSpring SDKs in it of itself are already secure, but knowing how to create a secure application is always beneficial for developers.
Where do I contact if I have safety/security concerns?
If you have questions about LicenseSpring and our security, please contact us.