Version 7.1 enhancements are significant, and have many interdependent
features, some of which are supported but undocumented for now, including:
o SIGN=, SIGN2= ... SIGNn=
o v7.1 SIGN= non-CRO format, which is 12 character, but
a bit different/improved from license-key.
o CRO format in 3 strengths.
o Ability to use a phase2-like filter on the license-key (may not
be supported in the future).
o In total there are 6 different types of keys available (5 new):
- license-key
- SIGN= without CRO, which is very similar to the license-key
- LM_STRENGTH_113BIT
- LM_STRENGTH_163BIT
- LM_STRENGTH_239BIT
- phase-2 callback. (undocumented now)
The phase-2 business may be phased-out.
There is a lot of flexibility in this:
o Every checkout call can specify/override it is required LM_STRENGTH.
o Similarly, every FEATURE line can specify to lmcrypt what
LM_STRENGTH it is SIGN= should be.
This way a company could decide to have one app at one strength and
others at another.
The reason for SIGN<n> is so that a vendor can migrate to
another set of seeds or a different key-filter (a la phase2).
The discussion is mostly about CRO. I will discuss non-cro last.
WHAT IS NOT DOCUMENTED and WHY
_____________________________
1) The SIGN<n>= is not documented for now, but I think this is an important
feature that may well bail out some important companies in the future.
2) The ability to use a different strength per feature is not documented.
If there is no demand for this, we may well remove it in the future.
3) The business about "key-filters" is likely to go away. It is there for
several reasons. First, because this was the initial way we were going to
do CRO. Second, because we were concerned that companies might demand
extra security without wanting to pay for it, but we are charging for this
anyway. Finally, the only possible valid reason now, is because companies
may want additional security without the added length of public-key.
BUILD
_____
During the build a number of key files get created, and it is worth
explaining these steps in detail.
The first set of dependencies are
$(DAEMON) depends on
lsvendor.o depends on
lm_new.o/c is made by and depends on
lmnewgen depends on
lmcode.o/c is made by lmrand1, and depends on
lm_code.h
These dependencies are the same as v6.1, and the only change is that
more information is put in lm_new.o. Essentially, the lm_code.h file
is transformed into the lm_new.o file, in an obfuscated format.
The information in lm_new.o is turned into the VENDORCODE struct in
lc_new_job().
Here is what is new in the VENDORCODE struct that gets filled in by lc_new_job():
int pubkeysize[LM_PUBKEYS];
unsigned char pubkey[LM_PUBKEYS][LM_MAXPUBKEYSIZ];
int strength;
int (*pubkey_fptr)();
LM_PUBKEYS is 3, so, if CRO is used, information for 3 different CRO
strengths is stored in the VENDORCODE struct.
pubkeysize, pubkey and strength are the required
parameters for calculating public key values: the size, the key and
the strength.
pubkey_fptr is l_pubkey_verify() everywhere except the license-generator,
where it is l_prikey_sign().
(The format of this was originally designed to able to be used with any
license-key "filter", like we did in v6 with phase2. This would still work,
and is tested in the servtest, but we may never support it.)
lm_new.o then contains all of the client-side public-key info.
PUBLIC/PRIVATE KEYS
___________________
But how does lm_code.h, which contains only SEEDs and VENDORKEYs turn into
the public/private keys?
The public-key pair is generated when lmnewgen runs. The SEEDs 3 and 4
are used as seeds to create the public-key pair. You can recreate
them as often as you want and you will get the public-key pair same
numbers every time. If you were to change 1 bit in the seeds, on every
half the resulting bits in the public-key pair would change -- that is,
the change would be impossible to trace. There is theoretically no way
to derive SEEDs3 and 4 from the public-key pair.
Therefore, we do not store the public-key pair in a way that the ISV is
particularly conscious of. The only thing they need to keep track of
the SEEDs 3 and 4. In addition, a license-generator like gtlicense
can, theoretically, only ask for the seeds in order to generate licenses.
Note that ENCRYPTION_SEED3 and 4 appear nowhere in the companies
product, only the public-key appears in the app/vendor daemon, and the
private-key appears only in license-generators.
lmcode.o contains the info in lm_code.h (it is generated by lmrand1).
This gets linked, with lmnewgen.o, into lmnewgen. This generates
lm_new.c. It calls l_gen_pkey_headers() to generate lm_new.o (which
has the public-key) and lmprikey.h (which has the private key).
l_gen_pkey_headers() eventually calls the Certicom routine
sb_genKeyPair() to generate the public-key pairs.
In summary: lmnewgen uses the seeds 3 and 4 to make the public-key
pair. The public-key is obfuscated in lm_new.c and the private
key goes into lmprikey.h, which is included in the license
generator source code.
LICENSE GENERATOR
_________________
lmprikey.h is included, and is used by LM_CODE_GEN_INIT to initialize the
VENDORCODE struct. Once the struct is initialized, it is just like the client
except that the pubkey info is only the private-key, and the callback
pubkey_fptr is l_prikey_sign().
When generating licenses, the strength is used, unless
SIGN=strength:<n> override is used in the license, in which case that
strength is used. This is done with L_CONF_STRENGTH_OVERRIDE field in the
CONFIG struct. (Note that, for security reasons, the name of this field
is a macro defined in h/l_privat.h)
The license-generator has a number of choices: You have a choice of
having a license-key, and/or any number of SIGN<n>= attributes, but you will
need at least one of the above. The client specifies which one of these
it needs, and it needs exactly one.
CLIENT/VDAEMON
______________
Theoretically, a job can have more than one LM_STRENGTH, and different
checkouts might use different strengths. I believe this works, but
we do not document it, and we may never support it. I mention this
because the design is such that this *could* work.
lc_new_job() calls l_init(). In this function, the pubkey info from
the VENDORCODE struct in the job (that was initialized in lm_new.o)
is used to call l_add_key_filter(). This adds an L_KEY_FILTER to
the job->key_filters list of possible key-filters. Each L_KEY_FILTER
applies to a different SIGN<n> level.
CLIENT
______
The client has 2 override possibilities:
1) what strength it requires,
LM_A_STRENGTH_OVERRIDE which sets job->L_STRENGTH_OVERRIDE
2) what SIGN= level it requires.
LM_A_SIGN_LEVEL which sets job->L_SIGN_LEVEL
The default strength is set in lm_code.h and is in strength in the
VENDORCODE struct. The default key-level is 1. A L_SIGN_LEVEL of 0 means
use the license-key, and no SIGN=.
VDAEMON
_______
The vendor-daemon has to authenticate all of the license-key/signatures
in the license. Upon checkout client specifies which one it requires.
In order for the server to authenticate all of them, it needs parameters
for all 3 CRO strengths as well as all the usual stuff for the license-key
and non-cro SIGN= key.
SEE ALSO
________
testsuite/st_vers.c: test 49.
The testsuite tests all of these features, and is probably the ultimate
authority for how to use any of these features from an API perspective.
utils/lmnewgen.c:
This generates the public-keys and generates lm_new.c which has the hidden
public-key.
#endif /* COMMENT */
#ifdef V8_1_COMMENT
To: danielbirns@hotmail.com, slangford@certicom.com, bolson@certicom.com, David Znidarsic <davidz@globes.com>, Matt Christiano <matt@globes.com>
Subject: Summary of review
Cc: richard Mirabella <rich@globes.com>
Security holes discovered
o Reusing Seeds3 and 4 for handshake. We can defeat this in about
a day on a fast machine.
o If the milliseconds does not change between signature generation,
then the first *half* if the signature for 2 signatures. If true,
a knowledge hacker can immediately determine the private key.
This happens on certain fast systems for 113-bit, including my own
PC.
Setup.
o 96-bit seed S.
o provide optional utility to ISVs to generate reliably random
96-bit seed, or the customer makes it up.
o Generate from S, n more seeds using FIPS186 random number
generator: called Tn, where each Tn is 96-bit.
o Generating T must be done in one "session".
o New customers will use T2 and T3 for Seeds 1-4, so they only type
in S (LM_SEED1-3).
Public/Private Keypair Generation
o Use T1 for generating the public and private key
o Use T1 and append the number 113 to generating the 113-bit keypair
o Similarly append 163 and 239 for those keypairs.
o Ensure that keypairs are generated with seeds that are not
identical, but they dont have to differ randomly, they could
differ by 1.
Signing
o Take time out of algorithm
o Seed with Private key, hash of message
o Signature will be guaranteed repeatable given the same FEATURE data.
o Requires a different certicom "context" for each signature.
Testing
o Add a test to prevent the 2nd discovered problem -- 113-bit
with duplicated first half of signature.
o Sign f1-f100 and look for dups in signatures in first half.
Protect ISVs use of kit
o Brian Olson expressed concern about the way the private keys
and seeds3-4 are secured on the client side. The state of
the art in this area is a hardware unit which is looks and
acts something like a dongle, *except* that the seeds and the
actual signing take place in the hardware unit. This is
believed to be secure and "relatively" convenient. Were
certainly not ready to implement something like this today,
and it would probably be unacceptable to all but a small minority.
o Its my opinion that any other attempt at "real" security
would lack security, or would be so inconvenient that in
practice ISVs wouldnt be willing to use it, or theyd find
ways to circumvent it. For example, imagine that every time
you generate licenses you have to type in a password. This
password would have to have 96-bits, or be an English phrase
that is equivalent, which, given available hacks on phrases,
would have to be a phrase of something like 100 or more
characters in length. Both of these are too long to realistically
remember and type in every time you use it. So, the password
would ultimately wind up on disk, or a user would "login" and
never log out or something which would effectively destroy the
security.
o That said there is one step we can take today: improve the
documentation, explaining what needs to be protected. Today,
there are many files left on disk which are not explained, and
which contained S, or the private keys.
Conclusion
o The only likely candidate for the hack remains our (my) first
guess, reusing Seeds3-4 for the handshake security. Unless
the hacker explains himself soon, we are probably going to have
to presume this is it.
o Two more steps could be taken:
1) A Macrovision senior engineer could look at the kit
and try to find some other hole that the hacker found.
If we do this, we should give it some time limit and
stop then unless we find something. It usually takes
the hackers some period of months to find this stuff,
and its often a concerted effort for many hackers all
over the planet.
2) All of the Certicom code is one one C file. I could
send the finalized revision to Certicom for review for
obvious flaws.
