Unlocking & stuff (was Re: [sword-devel] Cool idea: Commercial Linux /Windows Bible program based on Sword)

[Paul Gear]

Bill Schuh wrote:
> 
> I have been following this thread and love some of the ideas..
> 
> Why not continue to use Sword as is and allow modules to be purchased in an
> individual manner for the cost of the module....
> 
> How about using a key where you can download the module that you have
> purchased..  The key code can be used only two or three times using the
> install manager and then a new code would have to be purchased..

So restrict the modules at point of download.  Hmmm...  That might just
work.  Only people who have paid for the modules can download them. 
That way, even though the key management cannot be 100% secure, at least
you've got someone to blame if the module pops up in places where it
shouldn't.  :-)

Actually, there is a way that we could make the key management
reasonably secure.  Each installation of the program could generate an
installation asymmetric key pair, and the user would be required to
enter a passphrase with which to encrypt it (using a symmetric cipher). 
Unlocks would be done in such a way that the (symmetric) module key is
(asymmetrically) encrypted to the installation key of the user, and
stored in a "keyring" on the user's PC.

Thus, in order to access an encrypted module the program would have to
obtain the user's password for their (symmetrically) encrypted private
key, and then decrypt and use that private key to (asymmetrically)
decrypt the module key, which provides the ability to decrypt the text.

This system could still be programmed around (e.g. by writing an unlock
client that presents a false or insecure public key, or intercepting the
output of the decrypted module text), but it would require that the user
be involved in the fraudulent activity (something which we all appear to
agree that we can't and shouldn't try to protect against), and the
installation keys could easily be generated on the unlock server to get
rid of the false public key problem.  However, it has the disadvantage
that the user would have to enter their password for every session where
they want to access a locked module.

This approach would also be vulnerable to security flaws in the client
program.  For example, if the keyring key is stored in plain text in
memory during the session and the program has a buffer overflow exploit,
then conceivably someone could write some code that snarfed the key,
along with a copy of the keyring, and then sent it to their hotmail
email address or something.

Far fetched, but certainly a vulnerability of this approach, and because
it is free software, any such buffer overflow exploits are easier to
find than in a proprietary program (since one would not have to spend
hours reverse-engineering code in order to look for exploits).  However,
this is probably a sufficiently remote possibility that we could
convince publishers not to worry about it (since the same exploits could
be available in proprietary programs and are much less likely to get
found and fixed).

I hope that all made sense.  Please tell me if it wasn't clear.

Paul
---------
"He must become greater; i must become less." - John 3:30
http://www.bigfoot.com/~paulgear