[sword-devel] what problem are you trying to solve? (Re: encryption and integrity checking.)

[Greg Hellings]

A few technical observations about your problem

On Wed, Mar 11, 2009 at 2:47 PM, Peter von Kaehne <refdoc at gmx.net> wrote:
> Karl's question is probably the one I will need to answer first:
>
> What problem do I want to solve?
>
> a) A bible which has not been (will not be) distributed sufficiently on
> paper to allow recipients to compare with known good texts.

Electronic distribution can solve this - but if the people don't have
access to enough Internet to download the very-small libsword source
code, they probably don't have enough connection to download the
modules either.

>
> b) A hostile environment in which the Bible is considered a societal evil.

Not sure how having it installed on a computer helps the person in this regard.

>
> c) A hostile environment where cults will try and undermine genuine
> Christian growth by producing a counterfeit "Christianity"

Computing a hash of the module and signing it with a public/private
key setup, where the private key is held by only one or a very small
number of people (e.g. Chris) for signing the versions that come out
of the SWORD repository.  There are a few things to worry about here,
though: if we select a particular small passage to compute the hash
over, the cult could just modify other portions and leave the hash and
tested text untouched.  Computing the hash over the entire module
could easily run performance issues on even fast, modern hardware
depending on the size of the data to say nothing of older hardware
that has performance issues.  Choosing a good but fast hash would
certainly be required - something that can be done.

>
> On the plus side:
>
> d) An environment in which genuine computing knowledge is rare and not
> by necessity in the hand of those who oppose.

Security by obscurity like this is no security at all.  It only takes
one person with technical knowledge somewhere to publish a, "This is
how you hack the SWORD Project's modules" and even the non-technical
user could probably accomplish it.

>
> e) An environment where Bibles are ripped out of your hand due to
> genuine hunger.

Not sure there's any technical matters to address here. =)

>
> f) An environment where theoretical access to source code will not
> significantly allow subversion of whatever scheme we chose as the source
> code on our servers is essentially not accessible due to slow internet
> connections.

Again - see point (d).  Also, someone with more knowledge of the GPL
will have to comment on the legality of distributing the binaries in
this type of environment without also providing the source code in a
matter at least as accessible as the binaries.  If there are no
Internet connections of reliable natures there, presumably the
binaries are being distributed with the modules on some other type of
media (CD, DVD, pen drive) and the stipulations of the GPL, as I
understand them, require that the source code either already be part
of the distribution or that the person giving out the binaries offer a
way to distribute the source code.  Short of re-licensing the SWORD
Project under a different license for this particular situation,
relying on the method you mention for security smacks of illegality in
the face of the GPL to me, but I might be mistaken there.

>
> This is not a theoretical scenario, but one which affects in this or
> similar form several areas of this sad world.

Sadly - but this is what we are told to expect and "rejoice and be
exceedingly glad" during, is it not?

>
> The challenge is to create sufficient protection to the text to make it
> easier to distribute an intact module then to mess with it. Easier for
> someone with less knowledge than me, a non programmer. Someone who is
> used to ripped Windows XP, has possibly some tools, but can neither
> compile nor is mentally capable of learning this within sufficient time
> scale. Someone with evil intent but not sufficient stamina to copy 66
> books per chapter by hand, re-insert encoding and produce an equivalent
> but distorted module.

Due to the nature of the SWORD Library being open source, writing a
tool to do exactly that is very straightforward, only a few lines of
code when only a single module is being targeted, and no bigger than
the mod2osis.cpp already included in the source tree.  As I mention
above, it only takes one person with the knowledge of how to bring up
a simple ./configure --enable-utilities && make && make install to
have the mod2osis already available to them which they could then
distribute to their heart's content and render the above point.

However, signing the module with a hash/private key and distributing
the public key with the source and executable would at least allow
anyone who wanted to test the integrity of a module to do so.  Again,
with a very limited knowledge of programming someone could comment out
the checks and build a binary that didn't check the content of the
module.  And I daresay that front-ends would probably demand there be
a flag to indicate possible tampering but still have the text
available to show the user after having alerted them to the
possibility of tampering.  So you can't stop people from altering the
material, but you can make it much easier for a user to check that the
module is as CrossWire intended.

>
> The challenge is to do this while maintaining the ease of copying a
> module + programme allowing viral redistribution.

This isn't an issue - the issue is allowing ease of creating a signed
module by anyone who wants it.  If we do the public/private key
signing, then either we must distribute the keys to anyone or any
organization who wants to create a signed module - which diminishes
the security of that approach - or we must provide a mechanism for
supporting multiple sources of authentication which leaves the task of
whose modules to believe up to the user and increases the possibility
of any one of those modules being corrupted, leading to a need for us
to deauthorize keys lest any compromised key pair become available to
a party wishing to tamper with the module.  We can build something
like this, but it becomes a massive undertaking in computer security
infrastructure which is well beyond the scope of this project.

Of course, the simple and straightforward alternative is we only
program in a key pair from CrossWire and if other parties want to sign
modules themselves let them rebuild the program from source with their
key.  But then you couldn't use their modules with our build or our
modules with their build.

Clearly the signing issue is the tough one.  It falls to policy makers
to decide which method to implement - the hash and signing is
relatively straightforward to implement.  Is that a decent description
of the technical aspects of your problem?  Implementing is rather
simple if we decide to do a single signing source (us) and are happy
with our encryption algorithm.  It will allow us to distribute the
source with the public key and rest assured that our modules we have
signed will hold their integrity (at least to the extent we trust the
hash and encryption we've used).

--Greg