Legacy licensing implementation is brittle and relies on AES-CBC with implicit IV handling

[alexskr]

The current licensing implementation is a legacy, custom hybrid RSA/AES design that has remained largely unchanged for several years. While it continues to function for its original purpose (registration and basic license validation), the cryptographic approach has some structural shortcomings that make it brittle and hard to reason about going forward.

In particular, the implementation uses AES-CBC, which is generally discouraged in modern designs due to how easy it is to misuse. The current code does not explicitly manage or transmit an initialization vector (IV), and instead relies on default library behavior. This may work in our current environment, but it is sensitive to Ruby/OpenSSL version changes and could behave differently across platforms or future upgrades.

Additionally, the implementation relies on legacy RSA primitives (private-key encryption / public-key decryption) as a proxy for authenticity, rather than using a standard digital signature scheme. As a result, license validity is inferred from whether decryption succeeds, rather than from explicit signature verification.

This is not a security vulnerability in the traditional sense, since the licensing mechanism is used primarily for registration rather than access control. However, it does create maintainability and reliability risks over time.

Proposed direction:

• Treat the current licensing mechanism as legacy and keep it for backward compatibility.
• For new licenses, introduce a simpler and more robust format based on a standard digital signature (signed payload, public-key verification).