Cryptography and Security in Protection PLUS 5 SDK

Security is a layered discipline. Rather than relying on a single cryptographic mechanism, the Protection PLUS 5 SDK is designed around multiple independent protections that work together to safeguard license data from tampering, forgery, and reverse engineering.

This article explains the cryptographic protections used by the Protection PLUS 5 SDK and addresses common questions about our use of SHA‑1 for digital signatures in the context of license file validation.

For a complete technical overview, see our security documentation.

Defense‑in‑Depth: Our Core Security Principle

Protection PLUS does not rely on a single cryptographic control. Instead, it follows a defense‑in‑depth approach, where multiple independent safeguards must all be compromised before a license file could be successfully forged or altered.

At a high level, a Protection PLUS license file is protected by:

Strong encryption
Asymmetric cryptography (RSA)
Digital signatures for integrity verification
Runtime validation within the licensing library

Each layer serves a different purpose, and together they significantly raise the bar for any attack.

License File Encryption with RSA‑4096

All Protection PLUS 5 SDK license files are encrypted, not stored in plaintext.

Key characteristics of this encryption include:

RSA public‑key cryptography
4096‑bit key length
Encryption performed by SOLO Server using private key when generating a read-only license file

RSA‑4096 is widely regarded as extremely strong by modern cryptographic standards. Compromising this layer would require access to the corresponding private key or a breakthrough attack against RSA itself—neither of which is feasible with current computing capabilities.

This encryption ensures that:

License data cannot be meaningfully inspected
License values cannot be modified without decryption
Any tampering renders the file unusable

Digital Signatures and Integrity Validation

In addition to encryption, Protection PLUS applies a digital signature to the license file.

This signature allows the library to verify:

The license file was created by a trusted source
The encrypted contents have not been altered
The file has not been substituted or corrupted

If the signature validation fails, the license file is rejected.

The PLUSManaged library uses SHA-1, and the PLUSNative library uses OpenSSL.

Why SHA‑1 Is Used for the Digital Signature Hash

Customers are sometimes concerned when they see references to SHA‑1 in security discussions, so it’s important to explain how and where SHA‑1 is used in Protection PLUS.

Scope matters

In the PLUSManaged library:

SHA‑1 is used only as the hashing algorithm for the digital signature
It is not used for encryption
It is not used to protect plaintext data
It is not used in network communications or certificates

The license file itself remains fully encrypted using RSA‑4096.

Why SHA‑1 Is Reasonable in This Context

While SHA‑1 is no longer recommended for general‑purpose cryptographic signing (such as TLS certificates), risk must be evaluated in context.

In Protection PLUS, an attacker would need to successfully complete multiple independent steps to exploit the signature mechanism:

Break or bypass RSA‑4096 encryption to access the license contents
Construct a valid alternative encrypted payload
Generate a meaningful SHA‑1 collision for a specific encrypted license structure
Produce a matching digital signature accepted by the library

This combination makes a practical attack extraordinarily unlikely.

In other words, the security of the system does not depend solely on SHA‑1. SHA‑1 is only one component in a multi‑layered design where stronger cryptographic protections already prevent access to the underlying data.

Risk Assessment and Real‑World Impact

It is important to distinguish between:

High‑risk uses of SHA‑1 (e.g., publicly trusted certificates, code signing)
Constrained, internal integrity checks within an encrypted system

In the context of Protection PLUS license files:

The attack surface is extremely limited
The encrypted payload prevents meaningful collision exploitation
Any modification invalidates both encryption and signature checks

As a result, SHA‑1 does not represent a practical security risk in this specific implementation.

Ongoing Security Review

We continuously evaluate cryptographic best practices and platform capabilities.

Protection PLUS 5 SDK:

Uses FIPS‑compliant algorithms where applicable
Employs strong asymmetric encryption
Is designed to evolve alongside security standards

Security is not a static checkbox—it’s an ongoing process, and our architecture reflects that philosophy.

Planned migration: We are evaluating migration to SHA-256 for signature hashing in a future SDK release, consistent with evolving cryptographic guidance.

Summary

License files are encrypted using RSA‑4096
Digital signatures ensure integrity and authenticity
SHA‑1 is used only for signature hashing, not encryption
Multiple independent protections must be defeated to compromise a license
The overall design follows a defense‑in‑depth security model

For additional technical details, see our security documentation.