Protection PLUS 5 SDK uses the latest in cryptographic technology to secure your application's license files and its communication with SOLO Server. Here, we provide you with a high-level understanding of the technology and how it is used. This helps you understand how Protection PLUS 5 SDK works, and how the technologies used benefit you.
The first and most important thing to understand about cryptography, and security in general, is that nothing is impervious to attack. With enough effort and/or resources, any system may be compromised. The purpose is to simply make it unreasonable for most people to take the time to successfully break or compromise a system and to keep honest people honest.
Furthermore, security generally needs to be balanced with accessibility/ease-of-use. An example of this is the option to use read-only license files (which must be issued by SOLO Server) and writable/self-signed license files (which may be written and signed by your application). The latter is less secure, but has advantages in certain scenarios.
There are many different types of cryptographic algorithms, all of which have their own advantages and disadvantages. Understanding the different types of algorithms used in Protection PLUS 5 SDK at a high level helps you understand how each one serves different purposes/functions.
A hash algorithm is a one-way cryptographic algorithm (meaning it cannot be decrypted) that takes some data and generates a fixed-size "digest." Hash algorithms are ideal for tasks like authentication and integrity verification.
Perhaps the most common use of hash algorithms is with authentication. Storing passwords in plain-text in a database or system which holds sensitive data is bad practice, but you need some kind of data to ensure the user entered a valid password. In this scenario, the solution is to store a password hash instead. Here is how this works:
Of course, the example above is a simple one, and is not perfect. If two users have the same password, they would have the same hash. In these scenarios, we use what is known as a "salt", which helps make the hash unique. Let's say the user enters a unique username with the password for authentication. As an example, one could add (or concatenate) with the password to act as the "salt." In other words, "bobtopsecret" would result in a different hash digest from "alicetopsecret."
Integrity verification is not much different from the authentication shown above. As an example, let's say you went to download the latest FreeBSD operating system ISO file. In the FTP folder you see from the web site, you notice there are some CHECKSUM files present. Here is how these work:
Protection PLUS 5 SDK leverages hash algorithms to:
Asymmetric cryptography, also known as "public-key" cryptography, is where two keys are used with your application. This type of cryptography is widely used, and perhaps the best example is that your web browser uses this type of cryptography to encrypt data you access from and send to web sites (SSL). The drawback to this type of encryption is that it generally requires more resources from your computer to use than symmetric algorithms, but that is also what gives these algorithms their strength. In other words, the longer it takes to encrypt and decrypt data using an algorithm, the more impractical it becomes to guess the key used by an application by simply trying all possibilities.
The real strength in these types of algorithms, however, is that two separate keys (also referred to as a "key pair") are typically used. A flowchart showing how the SoftwareKey System uses this type of cryptography is below, and illustrates how your application only knows part of the server key (it does not know the server key's private data). The result is that your application only has enough of the server key to verify that it has been signed with the correct private key data, but lacks the key data necessary to sign data itself.
Using activation as an example, here is what happens when utilizing 1024-bit Encryption Keys:
Protection PLUS 5 SDK supports both 1024-bit and 4096-bit Encryption Keys (as of version 5.21.4.0).
As you can see from the chart above, your application does not have access to the private data of the "Server Key." Since this data is not even available to your application, it is difficult to compromise the key in a way that allows a hacker to generate their own, arbitrary responses and/or license files. Of course, all of the cryptographic operations performed by your application are handled for you through one of the Protection PLUS 5 SDK APIs (PLUSManaged or PLUSNative).
Symmetric cryptography, also known as "secret-key" cryptography, is where a single cryptographic "key" is used to encrypt and decrypt data. This is often used where performance is critical. The disadvantage to symmetric algorithms is that the key must be known to all parties, or in the case of the SoftwareKey System, the same key data must be fully disclosed to both SOLO Server and your application. If the "secret-key" is compromised (meaning someone finds it and publishes or uses it without authorization), then the security is compromised.
Protection PLUS 5 SDK does make it possible to use "writable license files." These license files offer you an added level of flexibility for your application, as it enables your application to write to and sign license files itself. In this scenario, only the Client Key is used for all cryptographic operations, which means it operates like a symmetric or "secret-key" algorithm.
Even though the writable license is encrypted and signed by your application, measures should be taken (such as using an obfuscation tool if you code in .NET) to hide and protect the Client Key so that hackers cannot use it to write their own license files for your application.
The steganography feature is presently a beta, and changes may be applied which could require minor source code modifications to be made in order to use a future release. Please keep in mind that your testing should be very thorough. Also, use your own images distributed with your application such as a splash screen image. Do not use an existing image such as the desktop wallpaper since another product could share that license location.
Steganography is the practice of concealing data within a file, image, or video. Protection PLUS 5 SDK allows the use of steganography to conceal a license within a supported image format. When the license is written within the image, the image is still valid and may be viewed without any noticeable changes or degradation to the image data. Both PLUSManaged and PLUSNative support stenography for storage of licenses within images.
Any time a "back door" mechanism is put in place for "the good guys," that same mechanism is technically available to "the bad guys" as well. Consequently, it does not make sense to add any such mechanisms, as it would inevitably do more harm than good. The SoftwareKey System is not (and will not be) designed to include any such mechanisms. Furthermore, since we are not in the business of implementing cryptographic functions, we do feel it is very important for you to know which underlying libraries are used by Protection PLUS 5 SDK for cryptography.
The PLUSNative library uses OpenSSL for cryptographic functions. This is a widely used and trusted toolkit, which is also open source (meaning it's possible for you to review its source code).
The PLUSManaged library uses the Microsoft .NET Framework's built-in classes for cryptography, which often either has its own implementation, or uses Microsoft's CryptoAPI. If your .NET application is run using the Mono framework, then its own cryptographic functions are used in place of Microsoft's APIs (and Mono's implementation is also open source).