Re: [gentoo-dev] on the matter of security and cryptography

[Daniel Mettler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 04 August 2002 18:55, Spider wrote:
> Well, I was browsing around the other day checking into the
> "behind the scenes" work of gnupg and keyservers when I
> stumbled on this link..
>
>
> http://www.cryptnet.net/fdp/crypto/strong_distro.html

i've just read it (though not very carefully). to me this looks
like a description of the "usual" package signing procedure
(based on asym/pubkey crypto).

as a part of a semester thesis (thus do not take that stuff too
seriously, ok? ;) i've developed such a package signing concept
for portage and hacked a tiny prototype portage extension too.
(btw. i've sent it to a couple of core devs once. that's when
ryan told me about his package signing tool.)

here's a quick overview of some concepts behind it:

* usual package signing concept (asym crypto, pubkey instead of
x509)
* leverage as many of existing technologies as possible (portage,
gnupg, web of trust). -> traditional open source/unix approach.
* backwards compatibility (usage of the extension is optional)
* should be as easy as possible to use for both users and core
devs. reasonable defaults, but customizable.
* ensure scalability of the gentoo development process (each core
dev signs "his" ebuild submissions, no bottleneck)
* security through a loosely coupled, modular design with a
clearly defined interface to portage ("hooks" into portage).
k-i-s-s -> traditional security approach.
* fine-grained levels of trust through gnupg and most
importantly: the user defines himself, whom he trusts or not.
* no need to ship public keys. keys get fetched automatically
from public key servers. "single point of failure" conscious.

it comes down that trust (from the user's point of view) is
required at the following places:

* the user must trust the security of his own box
* the user defines wether he trusts the authenticity of a core
devs openpgp key.

each core dev is responsible for the security of his own private
key. however, if a key gets compromised, he can revoke it as
usual etc.

issues:

* establishing a trusted key chain from the user to one or more
valid keys in the core devs keyring. establishing trusted key
chains between core devs. this is the common issue with the web
of trust/open pgp in contrary to hierarchical, centralized trust
models (well, there the same issue exists but at a place where
the user usually does not notice it -> faked trust). see section
iii.10 of the paper for possible "solutions".
* integration with portage and its frontends. a good package
signature verification process should/will require some user
intervention which is opposite to the current batch processing
concept of portage. if so, it has to be implemented in a way
that allows frontends to handle it too.
* _security_ of ebuilds, patches, tarballs etc.

the first two issues are pretty tough stuff. the third one is
minor, just to recall that trust != security (there will never
be security, only trust_)

i've implemented the prototype using procedural python (an oo
approach would have been better) in a typical rad manner (code
not fully functional, not optimized, ...) -> it is a
proof-of-concept only and i _do not_ recommend to use it _any_
further.

nevertheless i think that the concept behind it is fine. as it is
basically a simple package signing concept based on open pgp
(see section iii.10) it probably can not be improved much unless
one takes a completely different approach (for example by mixing
in some zero-knowledge-proof stuff ;).

for those interested, the paper and the sources are available
here:

http://www.icu.unizh.ch/~mettlerd/semesterthesis/

in my view, implementing a mechanism to ensure the authenticity
and integrity of the portage tree is crucial for gentoo's future
(think of all the portage tree mirrors out there). however,
it's not a trivial thing.

regards

dan

- --
      ...::: Daniel Mettler | http://www.numlock.ch :::....

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9UF39SLYjgrGjnWQRAk1jAJ9jWtJmG/KDyiq+rEZlK3YkaSnA2ACfc//s
0sncgx6z7SOQsmrPxEoqRFY=
=rSfV
-----END PGP SIGNATURE-----