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 Sat, 05 Sep 2015 21:15:09 GMT
I was just reminded of the risks of making assumptions. There's two
separate implementations of AES strong encryption - WinZip AES and PKWare.
I've been focused on the latter but we should recognize both types of
headers.

I've pushed a bit more code that partially parses the PKWare headers. It's
enough to identify the encryption and hash algorithms used but a lot is
left unparsed.

Bear

On Fri, Sep 4, 2015 at 12:17 PM, Bear Giles <bgiles@coyotesong.com> wrote:

> 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