[OLPC Security] [Techteam] Crypto export and python-crypto

[Jameson "Chema" Quinn]

I just sent this message to cscott privately by mistake.

---------- Forwarded message ----------
From: Jameson Chema Quinn <jquinn at cs.oberlin.edu>
Date: Tue, Jun 3, 2008 at 11:54 AM
Subject: Re: [OLPC Security] [Techteam] Crypto export and python-crypto
To: "C. Scott Ananian" <cscott at laptop.org>


Thanks again for responding; while I still disagree, I am definitely
learning from this conversation.

On Tue, Jun 3, 2008 at 8:41 AM, C. Scott Ananian <cscott at laptop.org> wrote:

> On Tue, Jun 3, 2008 at 9:30 AM, Jameson Chema Quinn
> <jquinn at cs.oberlin.edu> wrote:
> > On formats, I agree in principle. But as your own email points out, there
> > are already two different signature formats invented for the XO, because
> of
> > specifics about what is to be signed. If these do not work for my needs,
> I
> > do not see why I should not invent another.
>
> Exactly because we already have two, we should avoid having *three*!
>
> It would be better to patch one of these so we only have *one*.  (And
> what are the two formats you are referring to?)
>

 http://wiki.laptop.org/go/Firmware_Key_and_Signature_Formats<http://wiki.laptop.org/go/Firmware_Key_and_Signature_Formats#Antitheft.2FActivation_Lease>
and
http://wiki.laptop.org/go/Contents_manifest_specification



> > The OpenPGP attack you mention has to do with encryption, not signatures.
>
> Please read page 25 of
> ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf.  Although
> there is (yet) no practical attack, it (like MD5) is not recommended
> for new applications.


This is true, but totally separate from the attack you mentioned, which is
in fact a practical (though limited) attack. Without reading the references,
the implication is that v2.1 is better than v1.5 only in terms of its
provability; not only are there no practical attacks on v1.5, there is not
even any intimation of any theoretical/incomplete ones, just the theoretical
possibility that such might exist.


>
> > I did look at JAR files, and decided that their format lacked some
> desirable
> > features. They are based on md5 hashes, which are close to broken; they
> do
>
> You are wrong.
> http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Digital%20Signatures


My reading of this is that there are three stages to a signature.
1. manifest file: each subfile is signed by an arbitrary set of hashes
including md5
2. .sf file: an arbitrary subset of the files in manifest. Each entry in the
manifest, including hashes, is signed by md5 alone.
3. digital signature: an RSA (+md5), DSA, or PGP signature on the .sf file.

Thus md5 appears 2 or 3 times in this chain, and in step 2 there are no
options or redundancy. While a naive view would say that the constraints on
the manifest entry format are tight enough to make it more difficult to
forge a signature by breaking step 2, a meet-in-the-middle
attack<http://en.wikipedia.org/wiki/Meet-in-the-middle_attack>could
theoretically break it in as little as twice the time needed to break
md5. Also, step 3 does not allow for a simple rsa+shaxxx signature without
using pgp.

<http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Digital%20Signatures>
>
> > not allow for granting privileges to secondary keys, which means that
>
> You can have any number of .SF signature files, signing any
> combination of the contents.


You are right. So it is possible to abuse the format to allow this by
signing signatures. However, the metadata on signatures must then be
separate - either in separate files or as magic attributes in the manifest.
This feels like an ugly hack to me.

(Sorry, I realize that I am not fully explaining my thoughts here, because
it is beside the point. I assert that there is a way, but there is no good
way, within this format, for a master key to say "Signatures from key xxx
are valid, as long as their signed metadata states that they were requested
by activity yyy". Explaining the details of the bad way I can imagine is
unimportant; if you have a good way, let's talk about that instead.)

>
>
> > user; they interact poorly with differential versioning storage; and they
> do
>
> They in fact interact quite well.  See
> http://wiki.laptop.org/go/XO_updater#Application_updater
>

Ouch. This is somewhat of a monster of a year-old unimplemented
specification. It definitely has its attractions, but does not address the
problem I was attempting to refer to: compressed files will have much
noisier diffs from version to version. On a compressing, versioning file
system like jffs + olpcfs, storage should be in an uncompressed archive
format like tar IMO. Note that, with Develop, there may be dozens of
versions of one activity on the same machine; the redundancy between
versions dominates the redundancy within a given version (and the latter is
taken care of by jffs2 at the lowest level anyway.)


>
> > not allow for unsigned content in a signed bundle, which makes
> localization
>
> I do not believe this to be the case.
>

You are correct, I was mistaken.

>
> > more of a pain. Any one of those problems I could have lived with, the
> three
> > together seem to me like a good enough reason for changing a format. And
>
> And in the absence of any of the three?
>
> > The contents manifest specification does not fit my needs either.
>
> I'll let this pass, for now, but I explicitly designed it to fit both
> the OS and activity update case, so I find this statement puzzling.  I
> think what you mean is, "it does not solve *all* my problems for me",
> and this is because it is not designed to.  It is just one part of a
> solution.  But I prefer the JAR file format for activities anyway, so
> I don't think it's worth belaboring this.


Obviously, I need to state my design goals more clearly and explicitly; it
is my fault you are puzzled. I will begin to compose an email to do that
now, meanwhile I will send this off.

Jameson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/security/attachments/20080603/7f7a476e/attachment-0001.htm