commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bear Giles <bgi...@coyotesong.com>
Subject Re: [COMPRESS] pkware header id for crypto extensions
Date Fri, 04 Sep 2015 04:12:26 GMT
I've forked at github.com/beargiles/commons-compress and committed some
initial work - five new ExtraHeader classes, their registration, two test
files and four unit tests.

One test file uses certificate encryption and signature but does not
encrypt filenames. The second test file uses certificate encryption and
signature and encrypts filenames. I am using my Symantec certificate for
bgiles@coyotesong.com and can verify that information is present with
'strings'.

The results of the tests are a little confusing. The good:

- the use of strong encryption is recognized
- the substitution of an encrypted filenames is recognized. (recorded
filename is 1, not LICENSE.txt).

The bad:

- I'm only seeing the headers loaded in one unit test. I don't know if the
rest should be reading the headers or not so I don't know if I'm properly
handling them or if they're quietly handled by the default handler.

- one unit test blows up due to missing central directory (it's encrypted).

I guess the next step is either finding a way to have the unit tests
trigger reading the extra headers or confirm that it's not possible.

Bear

On Wed, Sep 2, 2015 at 3:58 PM, Bear Giles <bgiles@coyotesong.com> wrote:

> Hi, I know that the implementation of the PKWARE AES crypto is subject to
> license restrictions but is it possible to recognize the extension fields
> so anyone scanning an unfamiliar file will at least know what the extra
> field headers contain?
>
> I don't know if code to parse the contents (solely using the standard JCE)
> would trigger export restrictions. This would NOT be decrypting the data,
> just adding a thin layer of code to parse a standardized ASN.1 object.
>
> (BTW there are some other header types documented but except for a few I
> don't know what they are.)
>
> The header IDs (per
> https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT) are:
>
>       0x0014        PKCS#7 Store for X.509 Certificates
>       0x0015        X.509 Certificate ID and Signature for
>                     individual file
>       0x0016        X.509 Certificate ID for Central Directory
>       0x0017        Strong Encryption Header
>       0x0019        PKCS#7 Encryption Recipient Certificate List
>
> The definitions are:
>
>    4.5.9 -PKCS#7 Store for X.509 Certificates (0x0014):
>
>         This field MUST contain information about each of the certificates
>         files may be signed with. When the Central Directory Encryption
>         feature is enabled for a ZIP file, this record will appear in
>         the Archive Extra Data Record, otherwise it will appear in the
>         first central directory record and will be ignored in any
>         other record.
>
>
>         Note: all fields stored in Intel low-byte/high-byte order.
>
>         Value     Size     Description
>         -----     ----     -----------
> (Store) 0x0014    2 bytes  Tag for this "extra" block type
>         TSize     2 bytes  Size of the store data
>         TData     TSize    Data about the store
>
>
>    4.5.10 -X.509 Certificate ID and Signature for individual file (0x0015):
>
>         This field contains the information about which certificate in
>         the PKCS#7 store was used to sign a particular file. It also
>         contains the signature data. This field can appear multiple
>         times, but can only appear once per certificate.
>
>         Note: all fields stored in Intel low-byte/high-byte order.
>
>         Value     Size     Description
>         -----     ----     -----------
> (CID)   0x0015    2 bytes  Tag for this "extra" block type
>         TSize     2 bytes  Size of data that follows
>         TData     TSize    Signature Data
>
>    4.5.11 -X.509 Certificate ID and Signature for central directory (0x0016):
>
>         This field contains the information about which certificate in
>         the PKCS#7 store was used to sign the central directory structure.
>         When the Central Directory Encryption feature is enabled for a
>         ZIP file, this record will appear in the Archive Extra Data Record,
>         otherwise it will appear in the first central directory record.
>
>         Note: all fields stored in Intel low-byte/high-byte order.
>
>         Value     Size     Description
>         -----     ----     -----------
> (CDID)  0x0016    2 bytes  Tag for this "extra" block type
>         TSize     2 bytes  Size of data that follows
>         TData     TSize    Data
>
>    4.5.12 -Strong Encryption Header (0x0017):
>
>         Value     Size     Description
>         -----     ----     -----------
>         0x0017    2 bytes  Tag for this "extra" block type
>         TSize     2 bytes  Size of data that follows
>         Format    2 bytes  Format definition for this record
>         AlgID     2 bytes  Encryption algorithm identifier
>         Bitlen    2 bytes  Bit length of encryption key
>         Flags     2 bytes  Processing flags
>         CertData  TSize-8  Certificate decryption extra field data
>                            (refer to the explanation for CertData
>                             in the section describing the
>                             Certificate Processing Method under
>                             the Strong Encryption Specification)
>
>         See the section describing the Strong Encryption Specification
>         for details.  Refer to the section in this document entitled
>         "Incorporating PKWARE Proprietary Technology into Your Product"
>         for more information.
>
>    4.5.14 -PKCS#7 Encryption Recipient Certificate List (0x0019):
>
>         This field MAY contain information about each of the certificates
>         used in encryption processing and it can be used to identify who is
>         allowed to decrypt encrypted files.  This field should only appear
>         in the archive extra data record. This field is not required and
>         serves only to aid archive modifications by preserving public
>         encryption key data. Individual security requirements may dictate
>         that this data be omitted to deter information exposure.
>
>         Note: all fields stored in Intel low-byte/high-byte order.
>
>          Value     Size     Description
>          -----     ----     -----------
> (CStore) 0x0019    2 bytes  Tag for this "extra" block type
>          TSize     2 bytes  Size of the store data
>          TData     TSize    Data about the store
>
>          TData:
>
>          Value     Size     Description
>          -----     ----     -----------
>          Version   2 bytes  Format version number - must 0x0001 at this time
>          CStore    (var)    PKCS#7 data blob
>
>          See the section describing the Strong Encryption Specification
>          for details.  Refer to the section in this document entitled
>          "Incorporating PKWARE Proprietary Technology into Your Product"
>          for more information.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message