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 <bgi...@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 <bgi...@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 >> bgi...@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 <bgi...@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. >>> >>> >> >
