cancel
Showing results for 
Search instead for 
Did you mean: 

SIGN2 and its future with FNP tolkit

No ratings

SIGN2 and its future with FNP tolkit

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.

Labels (2)
Was this article helpful? Yes No