SIGN2 and its future with FNP tolkit

[#1]

Question:

I read in a 11.14.0 release note that SIGN2 keyword is deprecated, but  SIGN= is seen as the original public key signature system and SIGN2= the new improved system. So if I remove SIGN2 the license will not be less secured ? 

Answer:

1. ) SIGN2 will be used in license file to support old clients which are built with different algorithm.
2. ) Presently, We have two algorithms to generate the sign value in license file:-
   1. TRL1 which is deprecated now and
   2. TRL2 is the enhanced and latest version with understanding as more robust to crack.
3. ) Consider old client is built with TRL1. In that case, we need to mention both the SIGN keywords and each will have exclusive sign value related to particular TRL key.
4. ) If there is just one SIGN keyword mentioned in FEATURE line then default SIGN value will be enhanced one and on the basis of TRL2 algorithm.
5. ) As there is expectation that all the publishers should move to more secured algorithm(TRL2) with time, it diminishes the need of extra SIGNs in feature line.
6. If we have only one SIGN value(it means SIGN) as part of license file then it is with TRL2 and linked to SIGN. But   
7. But if two SIGN values(it means SIGN,SIGN2) are required to be part of license file then SIGN will get TRL1 value and SIGN2 will get TRL2 value.

Also, below details should help you have more understanding on this case.

Signature Configuration	#1	#2	#3	#4	#5	#6	#7	#8 (best practice)	#9 (second best practice)
ENCRYPTION_SEEDS	Set	Set	Set	Not set	Set	Set	Not set	Not set	Set
LM_SEEDS	Not set	Set	Not set	Set	Not Set	Set	Set	Set	Set
TRL_KEYS / CRO_KEYS (Pre 8.1)	Not set	Not set	Not set	Not set	Set	Set	Set	Set	Set
LM_STRENGTH	LICENSE_KEY	LICENSE_KEY	DEFAULT	DEFAULT	113/163/239BIT	113/163/239BIT	113/163/239BIT	113/163/239BIT	113/163/239BIT
Signature keyword	None	None	SIGN	SIGN	SIGN	SIGN andSIGN2	SIGN	SIGN	SIGN andSIGN2
Signature type	Bespoke symmetric	Bespoke symmetric	Bespoke symmetric	Bespoke symmetric	TRL1	SIGN: TRL1 SIGN2: TRL2	TRL2	TRL2	SIGN: TRL1 SIGN2: TRL2
Signature length (chars)	12 or 20	12 or 20	12	12	60/84/120	2 x 60/84/120	60/84/120	60/84/120	2 x 60/84/120
Client version	Pre-8.1	8.1+	7.1 - 8.1	8.1+	7.1 - 8.1	8.1+	8.1+	10.8.6+	10.8.6+
Library linkage	lmgr.lib	lmgr.lib	lmgr.lib	lmgr.lib	lmgr.lib	lmgr.lib	lmgr.lib	lmgr_trl.lib	lmgr_trl.lib

Note:

• TRL1 = ECDSA signature
• TRL2 = Improved ECDSA signature
• FNP docs refer to these TRL1 and TRL2 signatures when discussing SIGN2

Configuration 6 clients require licenses with the SIGN2 keyword: changing a served license file from configuration 6 to 7 or 8 would break these existing clients. Therefore, in order to move on from SIGN2, producers needs to retire or upgrade their SIGN2-based production client base. In light of this, Flexera will maintain SIGN2 support until further notice to maintain license-server backward compatibility with 'recent' SIGN2 clients. Please review FNP release notes for notifications of changes to this policy.

When producers update their clients, they should prefer configuration 8, which is the most secure and simplest license signature configuration. This will allow (eventual) retiring of SIGN2. If SIGN2 is still required, then at least move to configuration 9.

Note: The standard lmgr.lib allows verification of all signature types, whereas the recommended lmgr_trl.lib allows verification only of TRL signatures. There are multiple known cases of a binary patch in a configuration 6 client which cause it to allow verification of a legacy symmetric signature presented as SIGN and/or SIGN2 signatures in a rogue license file. Clients based on configurations 5 and 7 are vulnerable to a similar attack vector. The keys used in the old symmetric signatures are easily brute forced, allowing rogue license files like this to be widely generated. This is why Flexera strongly recommends configuration 8 (or 9), where clients can verify only a TRL signature.