Nishchal wrote: While evaluating licensing using the Java client API, I noticed the following in the Java client class.
[1] It exposes 4 out of 5 vendor keys that are provided by Acresso, in the getVendorKeys method. The same vendor keys are used in lmcode.h to generate other licensing components(vendor daemon, lmcrypt.exe) [2] It exposes the 2 TRL keys that are provided by Acresso, in the getCroKeys. The same keys are used in lmcode.h to generate other licensing components(vendor daemon, lmcrypt.exe) [3] It exposes some encryption seeds in the getEncryptionSeeds method, but none match the ones that we use in lmcode.h
This class also exposes the public keys used in TRL.
I want to know if there is any security risk because that original vendor keys and TRL keys getting exposed?
Since Java class files can be easily de-compiled and hence 4 out of 5 vendor keys and the TRL keys can get exposed, how difficult is it for someone to impersonate licenses generated by original software publisher by finding the 5th key?
Are there any better methods apart from using C API and JNI to increase security in while using the Java APIs?
Also, while searching on the Acresso site I cam across the following link, which mentions in security functionality section "Tamper-resistant applications are not supported. This is called a notr toolkit." while in notes section it mentions "Requires tamper-resistant Licenses (TRL) to be enabled". Can some one explain the difference between the 2?
For the second question: "tamper-resistant" is used in two different ways: there's the TRL sense of a particular digital signature algorithm (which is used in FLEXnet Java), and also in a native-toolkit sense of being able to use a feature called Secure Data Types (which are not used in the Java toolkit).
My understanding is that the important thing to ensure that licenses are not forged is that the private encryption seeds (encoded in LM_SEED values in lm_code.h) not be exposed. The chapter "Tamper-Resistant Licenses" in the native toolkit documentation file ProgRef-LF.pdf has more information, as does devenv.pdf...
