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 18:17:21 GMT
I just came across a press release that suggests that it is possible to
support AES encryption for zip files:

http://www.prnewswire.com/news-releases/pkware-announces-free-licensing-program-for-secure-ziptm-and-pkzip-reader-technologies-72382192.html

(We might have discussed this several years ago...)

Bear

On Thu, Sep 3, 2015 at 10:12 PM, Bear Giles <bgiles@coyotesong.com> wrote:

> 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