# Secure software licensing

Tauren Mills (tauren@groovee.com)
Tue, 19 May 1998 03:20:23 -0700

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Mike Oothoudt: "Client-side security"
- Previous message: Andy: "Trusted applets..."

    From: "Tauren Mills" <tauren@groovee.com>

    To: <java-security@web1.javasoft.com>

    Subject: Secure software licensing

    Date: Tue, 19 May 1998 03:20:23 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_003A_01BD82D5.0F5ADD60
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I am new to security concepts in general, but I'm reading everything I can
and trying to grasp them.

I want to somehow encode a message (actually several pieces of information)
into a "unique string". I do not want this "unique string" to be able to be
edited to change any of the contents. This "unique string" should be signed
by my private key. The information contained in the "unique string" should
be able to be decoded with my public key. If the "unique string" has been
tampered with, it should be obvious in the decoding phase.

Furthermore, I want to be able to include the decoder in my software
products, which I plan to sell it overseas. Export controls are an issue.
Also, I'd like to be able to use JDK1.1 only, and not need to use the JCE or
JDK1.2. Lastly, I'd like the classes necessary for decoding to be small,
fast, and distributable.

I'm sure that I need to be dealing with the java.security package. I'm just
not sure which parts of it. I'm not clear if I need to deal with digital
certificates or not, or if I can even embed all the information into the
certificate itself.

The data that is being encoded into the "unique string" is not confidential
and does not require encryption.

Here's how I envision it working:

Someone has already downloaded and used a free trial version of one of my
products on their web server. They liked it so much that they now want to
purchase the full version. The trial software is actually the full version,
but needs to be unlocked with a "key" (the "unique string" I referred to
above).

To get this key, the user needs to fill out a form on my web site. The form
might ask for the following information:
Serial Number of product (this was obtained when first downloading the
product)
Web Server Name (www.yourdomain.com)
Web Server IP Number (207.100.100.1)
Web Server Port Number (80)

My web server will then create generate a key based upon that information
and some other information. The following things will probably need to be
encoded into the key:
Serial Number of product
Web Server Name
Web Server IP Number
Web Server Port Number
Product Name (derived from the Serial Number)
Expiration Date (no expiration date should be possible, say by making
the value of this a zero)

The web form will probably also ask for standard other information (name,
company, address, etc.), but I do not think this information needs to be
included in the key. I'd like the ability to be able to include it too, if
it is deemed necessary.

Once this information has been encoded into a key, using my private key to
encode it, the "unique string", or key will be given to the user. I'm
envisioning the key appearing to be a string of random numbers, letters, and
symbols. Something like this:

MSADFLJIJAS;LDFJAL;JSFLAJDFASDFJ8392JALSDJFALV899JAVASLDFJA
ASDF8U9-3JJ;LSADKJF9J29JF;LKSDJFA0-JSDFAJSDF;LAJF8AJO3JL;SJF8A
AS83J;A38JFA;8S3JF8;S3URF;AJ8F3J;JFJA98;3JFJF98FJA983JFJFD;LKFJA9

The user then takes this key and enters it into the software that they just
purchased from me. They already have the trial version running. They
simply open the registration area of the software and paste the key into it.
They then have a fully functioning version of the software.

It seems like this is the same kind of thing that happens with SSL, although
I do not need the encryption (I don't think, at least :). It looks like
version 3 of X.509 certificates includes ways to extend the contents of the
certificate. Would extending a certificate be a good way to go? If I use
certificates, does this mean that my users would need a certificate too?
Also, it looks like the Expiration field of a certificate cannot be "No
expiration" -- it must be as little as a few seconds or as much as a century
(from the document I read at least).

Is what I'm trying to do simply a "digital signature"? Or is a signature
something that is encoded based upon the data, but doesn't encapsulate the
data within itself? If so, how is the data sent?

It doesn't seem like a Message Digest would do the trick since I need to
extract information out of the key. It looks like using a Message Digest is
kind of like using the UNIX crypt command. For instance, you can compare a
previously crypt-ed password with a newly entered password that you just
crypt-ed to see if the result is the same.

Thanks for any insights on how to accomplish this,
Tauren

------=_NextPart_000_003A_01BD82D5.0F5ADD60
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
I am=20 new to security concepts in general, but I'm reading everything I can = and trying=20 to grasp them.
I want=20 to somehow encode a message (actually several pieces of information) = into a=20 "unique string". I do not want this "unique = string" to=20 be able to be edited to change any of the contents. This = "unique=20 string" should be signed by my private key. The information = contained=20 in the "unique string" should be able to be decoded with my = public=20 key. If the "unique string" has been tampered with, it = should be=20 obvious in the decoding phase.
Furthermore, I want to be able to include the decoder in my = software=20 products, which I plan to sell it overseas. Export controls are an = issue. Also, I'd like to be able to use JDK1.1 only, and not need = to use=20 the JCE or JDK1.2. Lastly, I'd like the classes necessary for = decoding to=20 be small, fast, and distributable.
I'm=20 sure that I need to be dealing with the java.security package. I'm = just=20 not sure which parts of it. I'm not clear if I need to deal with = digital=20 certificates or not, or if I can even embed all the information into the = certificate itself.
The=20 data that is being encoded into the "unique string" is not=20 confidential and does not require encryption.
Here's=20 how I envision it working:
Someone has already downloaded and used a free trial version of = one of my=20 products on their web server. They liked it so much that they now = want to=20 purchase the full version. The trial software is actually the full = version, but needs to be unlocked with a "key" (the = "unique=20 string" I referred to above).
To get=20 this key, the user needs to fill out a form on my web site. The = form might=20 ask for the following information:
Serial Number of product (this was obtained = when first=20 downloading the product)
Web = Server Name=20 (www.yourdomain.com)<= /DIV>
Web Server IP Number=20 (207.100.100.1)
Web Server Port Number=20 (80)
My web=20 server will then create generate a key based upon that information and = some=20 other information. The following things will probably need to be = encoded=20 into the key:
Serial Number of=20 product
Web Server=20 Name
Web Server IP Number
Web Server Port = Number
Product Name (derived from the = Serial=20 Number)
Expiration Date (no expiration = date should=20 be possible, say by making the value of this a zero)
The=20 web form will probably also ask for standard other information (name, = company,=20 address, etc.), but I do not think this information needs to be included = in the=20 key. I'd like the ability to be able to include it too, if it is = deemed=20 necessary.
Once=20 this information has been encoded into a key, using my private key to = encode it,=20 the "unique string", or key will be given to the user. = I'm=20 envisioning the key appearing to be a string of random numbers, letters, = and=20 symbols. Something like this:
MSADFLJIJAS;LDFJAL;JSFLAJDFASDFJ8392JALSDJFALV899JAVASLDFJA
ASDF8U9-3JJ;LSADKJF9J29JF;LKSDJFA0-JSDFAJSDF;LAJF8AJO3JL;SJF8A
AS83J;A38JFA;8S3JF8;S3URF;AJ8F3J;JFJA98;3JFJF98FJA983JFJFD;LKFJA= 9
The=20 user then takes this key and enters it into the software that they just=20 purchased from me. They already have the trial version = running. They=20 simply open the registration area of the software and paste the key into = it.=20 They then have a fully functioning version of the = software.
It=20 seems like this is the same kind of thing that happens with SSL, = although I do=20 not need the encryption (I don't think, at least :). It looks like = version=20 3 of X.509 certificates includes ways to extend the contents of the=20 certificate. Would extending a certificate be a good way to = go? If I=20 use certificates, does this mean that my users would need a certificate=20 too? Also, it looks like the Expiration field of a certificate = cannot be=20 "No expiration" -- it must be as little as a few seconds or as = much as=20 a century (from the document I read at least).
Is=20 what I'm trying to do simply a "digital signature"? Or = is a=20 signature something that is encoded based upon the data, but doesn't = encapsulate=20 the data within itself? If so, how is the data = sent?
It=20 doesn't seem like a Message Digest would do the trick since I need to = extract=20 information out of the key. It looks like using a Message Digest = is kind=20 of like using the UNIX crypt command. For instance, you can = compare a=20 previously crypt-ed password with a newly entered password that you just = crypt-ed to see if the result is the same.
Thanks=20 for any insights on how to accomplish this,
Tauren
------=_NextPart_000_003A_01BD82D5.0F5ADD60--

- Next message: Mike Oothoudt: "Client-side security"
- Previous message: Andy: "Trusted applets..."