[sword-devel] Printing an encrypted module?

[David Haslam]

It's not really like using SSL or SSH to protect monetary transactions or
other secrets which both parties in the communication session have a vested
interest (and often a legal or moral obligation) to keep secure, [before],
during, and after the session. Ultimately, the security of https depends on
the authenticity of security certificates. There is no such parallel in the
case we are considering.

Consider how some proprietary software vendors take rigorous steps to ensure
that the risk of illicit copying of their programs is minimised.

To prevent abuse by (or abuse of) the customer who pays to unlock a module
would require a more complex infrastructure.

(1) Locked modules would require an encryption key unique to each customer.
(2) The unlocking procedure would have to be tied to a registration
procedure, requiring the maintenance of a secure database of registered
users by the provider.
(3) The registration procedure would also require the formal acceptance of a
EULA.
(4) The registration/unlocking process would encrypt the customer's properly
authenticated username into the module, to provide traceability.
(5) The unlocking key should never be stored in memory in plain text, such
that a memory dump could be used to retrieve it.
(6) .....?

Even this would not prevent the copying of an unlocked module from an
unattended or stolen computer, without the knowledge of the paying customer.
Such abuse could only be prevented by requiring the customer to enter a
strong password to use the module every time he opens the application, and
somehow enforcing the obligation that the password should never be revealed
to anyone. AFIK, there are no neat solutions to this part of the problem
that can be done without involving dedicated extra hardware.

Encryption on its own, that we presently have to offer (and as barely
described in the CrossWire wiki) may go nowhere near as far as satisfying
the requirements of potential content providers who want to generate an
income stream from their copyrighted content.

That's probably why they rarely come on board with permissions.

cf.  What's the next in the following series?

 TIV = Totally Insecure Version
 SIV = Sacred Imprimatur Version
 RIV = Really Ingenious Version
 QIV = Quite Interesting Version
 PIV = Private Interpretation Version
....

- David


Jonathan Marsden wrote:
> 
> David Haslam wrote:
> 
>> ... Since printer drivers abound that can print to PDF or other
>> electronic formats, the whole text of a locked module could therefore
>> be output to a PDF file, with no security properties preventing
>> further copying.
> 
> I think it's much easier than that, there should be no need to downgrade
> to a PDF, or have a special new SWORD application, if you have the
> decryption key in the .conf file:
> 
>   mkdir newfoo && osis2mod newfoo <(mod2osis foo)
> 
> in a bash shell should be all it takes to create an unencrypted SWORD
> module newfoo from an already-installed encrypted foo.  And that is as
> it should be...
> 
> Encryption protects against use of information by people who do not have
> the decryption key, not against particular kinds of use (or abuse) by
> the person (or people) having the key.
> 
> The above is true for the information in an SSH stream to a remote
> machine, and true for SWORD modules, too.
> 
> Jonathan
> 
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
> 
> 

-- 
View this message in context: http://www.nabble.com/Printing-an-encrypted-module--tp25167239p25185614.html
Sent from the SWORD Dev mailing list archive at Nabble.com.