module-file format and signing

Sean Mullan sean.mullan at oracle.com
Thu Jun 30 12:09:55 PDT 2011


Here is a list of issues and suggested changes to the module-file format [1]
that I encountered while adding digital signatures to module-files [2].

1) The csize field of the Module file header cannot be properly calculated when
signing a module-file, because the length of the signature cannot be
pre-determined before the signature is applied. Thus, once the signature has
been applied, the csize field cannot be updated to include the length of the
signature without invalidating the signature.

Suggested Change: change the csize field to be the size of the "rest" of the
file (i.e. the contents after the module-info or signature section (if specified))

2) (Similar issue as #1) The sections field of the Module file header needs to
be incremented by one when signing a module-file. It may be possible to do that,
but it would result in the implementation being much more complex. Ideally, when
a signature is generated over an existing module-file, none of the contents of
that module file should need to be modified.

Suggested change: remove the sections field. It is not strictly necessary.

3) The location of the hash field in the Module file header makes it impossible
to calculate the hash while you write the contents of the module-file. This is
because the Module file header is at the beginning of the file, and some of its
fields (ex: csize) cannot be determined until the rest of the file has been
written. Although this isn't a showstopper, it does seem wasteful to have to go
back and re-read all of the module-file contents in order to calculate the hash.

Suggested change: don't include the Module file header in the hash of the entire
file. Also, add another field that contains just a hash of the Module file
header itself.

4) Do we need the hashLength fields? This seems like redundant information,
since this can be determined from the algorithm specified in the hashType field.

Suggested change: remove the hashLength fields in the Module file and Section
headers.

5) The hash field in the Section header only covers the section content, and not
the header itself. This means the integrity of this data cannot be verified
until the entire file is processed and the Module file header hash is verified.

For example, one could change the compressor field or the number of subsections.
These modifications would eventually be detected before the module was
installed, but may cause unpredictable behavior before that, since the
implementation is acting on the contents of what is in the header before the
data can be verified with what is protected by the signature.

If you change the hash to cover the Section header as well as the content then
you introduce the same problem as in #3 and you will not be able to hash the
section content as you write it.

Suggested change: Add a hash field that just covers the Section Header.

--Sean

[1] http://cr.openjdk.java.net/~mr/jigsaw/notes/module-file-format/
[2] http://cr.openjdk.java.net/~mullan/jigsaw/signed-module-file-format



More information about the jigsaw-dev mailing list