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 prerequisites completed the getting started docid\ lsfy9tq3vfq4roow9shkd 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 cryptographic 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 cryptographic 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 docid 5rgmpnpkksypdlzawvlhz changing cryptographic provider 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 extendedoptions options; options getcryptoprovider() >setkey( "key" ); options getcryptoprovider() >setsalt( "salt" ); auto configuration = configuration create( encryptstr( "xxxxxxxx xxxx xxxx xxxx xxxxxxxxxxxx" ), encryptstr( "xxxxxxxxx xxxxx xxxxxxxxxxxxx xxxxxx xxxxxx" ), encryptstr( "xxxxxx" ), "name", "version", options ); auto licensemanager = licensemanager create( pconfiguration );var options = new licensespring extendedoptions(); var configuration = new licensespring configuration( apikey "xxxxxxxx xxxx xxxx xxxx xxxxxxxxxxxx", sharedkey "xxxxxxxxx xxxxx xxxxxxxxxxxxx xxxxxx xxxxxx", productcode "xxxxxx", appname "name", appversion "version", extendedoptions options ); configuration cryptoprovider key = "key"; configuration cryptoprovider salt = "salt"; var licensemanager = licensemanager getinstance(); licensemanager initialize( configuration );/// 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()## setup (only once) from licensespring licensefile default crypto import defaultcryptoprovider from licensespring licensefile config import configuration from licensespring licensefile license manager import licensemanager password = "your password" salt = "your salt" crypto = defaultcryptoprovider() key = crypto derive key(password=key password,salt=key salt) iv = crypto generate random iv() conf = configuration(product="your product key",api key="your api key", shared key="your shared key",file key=key,file iv=iv, is guard file enabled=true) manager = licensemanager(conf)// go sdk v2 	storage = \&data handler defaultfilestorage{} 	crypto = crypto provider defaultcryptoprovider{} 	if useoauth { 	 crypto setkey(config file cryptoproviderkey) 	} else { 	 crypto setkey(config file sharedkey) 	} 	storage setcryptoprovider(\&crypto) 	c = license handler licensehandlerconfig{ 	 apikey config file apikey, 	 sharedkey config file sharedkey, 	 productcode productcode, 	 authdata auth fromkey(productauth licensekey), 	 oauth useoauth, 	 verbose logger verbose, 	 storage storage, 	} 	lh, err = license handler newlicensehandler(c) 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 options overridecryptoprovider( cryptoprovider ); note if the crypto provider is not set, then the default crypto provider will be used why change cryptographic 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 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 docid\ xph0cdnbqdfjm1kyooptz 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 docid\ cgpsvoymm4d4c4iohilhs 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