Method of strongly encrypting .zip files

The present invention relates generally to a method of using standard .ZIP files and strong encryption technology to securely store files, and more particularly to a method of integrating existing strong encryption methods into the processing of .ZIP files to provide a highly secure data container which provides flexibility in the use of symmetric and asymmetric encryption technology.

The present invention adapts the well established and widely used .ZIP file format to support higher levels of security and multiple methods of data encryption and key management, thereby producing an efficient, highly secure and flexible digital container for electronically storing and transferring confidential data.

Compression of computer files has been available for many years. Compressing files can save large amounts of disk space, and can reduce transfer time when downloading files from the Internet or transferring files through email. Almost any file one downloads from the Internet is compressed in some way. A standard compressed file or folder as it is sometimes called contains one or more files that were compressed into a single file or folder. Many different compression formats have been developed over the years. The .ZIP format, created by the assignee of the present invention, is perhaps the most common compressed file format for the personal computer. Any file with a ".zip" extension most likely contains one or more files of data archived, that is, each either compressed or stored, in the .ZIP format. "Zipping" a file has become a commonly used term meaning to compress the file into the .ZIP format archive so that it occupies less disk space, and similarly, "unzipping" a file means decompressing a compressed file in the .ZIP format.

A .ZIP file is generally recognized as a data compression and archiving format invented by PKWARE, Inc. The .ZIP format is a file format designed for combining data compression technology with file archiving techniques. Many commercially available software products are available for compressing or "zipping" files or other data into the .ZIP format. These .ZIP files can then be used to reconstruct the original data through the "unzipping" process. Data compression converts the contents of a file into an encoded format requiring less computer storage space or in the case of transmission less network bandwidth than the original uncompressed file.

Archiving, in the context of a .ZIP file, is a method of storing information about the characteristics of a file in a catalogue of files, known as the Central Directory, inside the .ZIP file, allowing each file to be retrieved individually by its characteristics. This capability is widely used. These characteristics include, but are not limited to, file name, file size, and file creation date and time.

Software programs such as PKZIP® written by PKWARE, Inc. are used to process files in the .ZIP format. Such programs allow one or more files of any type to be compressed and archived into a file of the .ZIP format type for efficient file storage and transmission over computer and communication networks. This format and the software programs that process .ZIP files have become ubiquitous.

Data encryption is used by many software programs to provide data privacy. Data encryption is a method of encoding data so that it cannot be reproduced in its original form unless an associated key is provided. Decryption uses this key to convert the encrypted data back into its original state. The key is known only to the person encrypting the data or by those other people with whom the person encrypting the data chooses to share the key. The key is used to "unlock" the data so that it can again be used in its original form.

Keys are uniquely generated using data known to the person encrypting a file or other data associated with recipients and users of the file. This data can be a user-defined password or other random data. Several methods are commonly used for processing the keys used for data encryption. Encryption using a key generated from a password is an example of symmetric encryption. Encryption using a public/private key pair is an example of asymmetric encryption. An example of one method for processing encryption keys supported by this invention uses a public/private key pair commonly associated with digital certificates as defined by the document Internet X.509 Public Key Infrastructure Certificate and CRL Profile (RFC <i>2459)</i>. A digital certificate is a unique digital identifier associating a public and private key pair to an assigned individual, a group, or an organization. When used for encrypting data, the public key of an individual is used to process an encryption key which only the individual in possession of the corresponding private key can use for decryption. A digital certificate is issued to an individual, a group, or an organization for a fixed period of time and can only be used during this time period. After the time period has elapsed, the digital certificate will be considered to have expired and must be reissued for a new time period.

The strength of a data encryption method is determined at least in part by its key size in bits. The larger the key size a data encryption method uses, the more resistant it is to cryptanalysis. Cryptanalysis, or popularly "cracking", is the unauthorized access to encrypted data. Strong encryption is a type of data encryption that uses key sizes of 128 bits or more. A number of encryption encoding methods are known today. Examples supported by the present invention include but are not limited to Advanced Encryption Standard (AES), Data Encryption Standard (DES), 2DES, 3DES, and others. A number of key sizes are commonly used today. Examples supported by the present invention include but are not limited to 128 bits, 192 bits, and 256 bits.

Many software programs available today that process .ZIP files use data encryption to encrypt files after compression as they are written to the .ZIP file. The data encryption method used by these software programs uses a key size of 96 bits or less and is considered weak or moderate encryption by today's standards. These software programs use keys generated using user-defined password data. Weak data encryption may not provide sufficient security to computer users that store and transfer their confidential data files using the .ZIP format.

Password-based key generation has been a commonly used method of applying data encryption, however, known vulnerabilities to cracking methods such as "brute force password cracking" make this method of encryption insufficient to meet today's more advanced security needs. Another known limitation of password-based security is the lack of non-repudiation. Non-repudiation is the ability to be certain that the person or program that created an encrypted .ZIP file cannot deny that fact and that their identity is bound to the .ZIP file they created. This cannot be achieved with symmetric encryption methods. Today, non-repudiation is an important aspect of security related to the implementation of digital certificates and digital signatures. It is critically important to be able to prove that a creator or sender of an encrypted file did in fact create the file, i.e. not repudiate his/her action.

Therefore, a need exists to extend the options for levels of security available to programs that process .ZIP files. This extended of security capability makes use of the encryption technologies available today or others that may gain acceptance in the future.

The present invention provides a method of using a .ZIP file as a flexible secure data container, the method comprising the steps of: <ul id="ul0001" list-style="none" compact="compact"><li>modifying the standard .ZIP file format by defining records and fields in the .ZIP file to indicate the security level of the file; and</li><li>selecting and applying strong encryption algorithms to the data in the file.</li></ul>

The invention further provides a file created in a .ZIP file format, comprising compressed data;    wherein the standard .ZIP file format is modified by defining records and fields in the .ZIP file to indicate the security level of the file; and    wherein the data is encrypted using strong encryption algorithms.

The invention further provides a method for improved file compression and encryption comprising: <ul id="ul0002" list-style="none" compact="compact"><li>compressing a file having a data portion and file characteristics using a ZIP-based compression technique;</li><li>encrypting the data portion of the file to form an encrypted data portion; encrypting the file characteristics portion of the file to form an encrypted file characteristics portion; and</li><li>forming an improved data container including said encrypted data portion and said encrypted file portion.</li></ul>

Another way of looking at the present invention is that the present invention provides a method of integrating multiple strong encryption methods into the processing of .ZIP files to provide a highly secure data container which provides flexibility in the use of symmetric and asymmetric encryption technology. The present invention adapts the well established .ZIP file format to support higher levels of security and multiple methods of data encryption and key management, thereby producing a highly secure and flexible digital container for storing and transferring confidential electronic data.

The present invention provides a method of integrating multiple strong encryption methods into the processing of .ZIP files to provide a highly secure data container which provides flexibility in the use of encryption technology. The present invention supports existing weak encryption methods available in .ZIP software programs used today to ensure backward compatibility with existing software programs that use the .ZIP file format. Strong encryption methods are made available to computer users as configurable options to select when compressing and encrypting their files or other data into a .ZIP file.

The method of the present invention provides the capability of using strong encryption when creating .ZIP files. It is flexible in that it provides that different encryption methods can be applied to a single .ZIP file to meet the security needs of a given computer user or application. Strong encryption algorithms are preferably used in conjunction with either password (symmetric) or any form of public/private key (asymmetric) encryption methods. The symmetric method preferably includes a password defined by the user, while the asymmetric method preferably includes a public/private key associated with digital certificates to process encryption keys. The invention allows one or more passwords and one or more public keys to be used individually, or in combination at the same time when archiving any file of any type of data into a secure .ZIP file. This capability is useful since secure .ZIP files are frequently distributed, or otherwise made accessible, to multiple recipients for decryption. Some of those recipients may require password access while others may require certificate access.

The method of the present invention also supports the four basic security functions to be associated with encrypted files: confidentiality, message authentication, sender or creator authentication, and non-repudiation.

Specifically, the present invention supports non-repudiation to uniquely bind a .ZIP file with the identity of its creator, and prevent that creator from denying the creation of that .ZIP file. One method of non-repudiation used by this invention is the identity support available with digital signatures that can be generated using public/private key technology. The non-repudiation function provided by the present invention also preferably supports time-stamping methods for fixing the creation of a digital signature in time, as well as time-stamped audit trails providing transaction history.

As indicated, the method of the present invention also supports message authentication. Message authentication ensures the data has not been altered since being encrypted. The present invention supports message authentication techniques that employ public/private key forms of message authentication, as well as other methods of message authentication that do not require the use of public/private keys. One example of an alternative method that does not use a public/private key is a cryptographic checksum.

The method of the present invention further supports the encryption of file characteristics for each file inside a .ZIP file. Current ZIP software programs encrypt only the contents of the files in a .ZIP file. The additional characteristics for each file, such as its name, size, etc., remain unencrypted. To remove the possibility that this unencrypted data for a file could be made available to an unauthorized user, this information may preferably also be encrypted as an option. This additional encryption further increases the level of security available to .ZIP file users.

Public keys such as those associated with digital certificates used for encrypting .ZIP file data preferably resides on a user's local computer in a file or a database, on an external device such as a Smart Card or other removable device, or in a shared data repository such as a directory service served by an LDAP server.

The present invention also provides multiple methods of checking whether a digital certificate is valid for use. These methods preferably include, but are not limited to standard methods of certificate validation, such as searching certificate revocation lists (CRL), certificate trust lists (CTL), and online checking via the internet using Online Certificate Status Protocol (OCSP) or Simple Certificate Validation Protocol (SCVP).

The method of the present invention also preferably defines data storage locations within the established .ZIP file format specification for storing information on the encryption parameters used when a file was encrypted and on the keys needed when a file is to be decrypted. One such example of these data storage locations includes a field to identify that a new strong encryption method has been applied to a file in the .ZIP file. The strong encryption record will be defined within a Central Directory storage area for each encrypted file. The Central Directory is a storage location defined in the .ZIP file format which serves as a table of contents for the entire .ZIP file. An entry is made into the Central Directory for each file added to a .ZIP file. A decryption record will be defined for storing the information needed to initialize and start the decryption process. This decryption record will be placed immediately ahead of the encrypted data for each file in a .ZIP file. This example is not the only method of storing this data as other storage methods can be defined.

The present invention provides many advantages or benefits over the prior art. One benefit is the ability to use multiple encryption methods instead of supporting only a single encryption method. A second benefit is the ability to use a mixture of symmetric and asymmetric encryption in a single, secure .ZIP file. A third benefit is that the encryption of individual files using advanced public/private keys provides a significantly higher level of security to computer users. A fourth benefit is that encryption of .ZIP file data can be implemented using a range of commonly available cryptographic toolkits. A fifth benefit is that the present invention supports using packaged or readily available encryption algorithms to provide state-of-the-art security. A sixth benefit is the availability of non-repudiation using digital signatures through the use of public/private key technology. A seventh benefit is that the invention ensures a high degree of interoperability and backward compatibility by extending the current .ZIP file format.

An embodiment of the invention will now be described, by way of example, with reference to the accompanying drawings, in which: <ul id="ul0003" list-style="none"><li>FIG. 1 is a record layout of a prior art .ZIP file prior to the present invention; and</li><li>FIG. 2 is a record layout of a .ZIP file in accordance with the present invention.</li></ul>

Referring now to the drawings, FIG. 1 shows the file format for the standard .ZIP file, in existence prior to the present invention. FIG. 2 illustrates the preferred general record layout of a .ZIP file in accordance with the present invention.

The new version of the .ZIP file format provides an implementation of the use of strong encryption based on a key generated using a password. This implementation constitutes one example of a structure and layout of the records and fields suitable for processing secure .ZIP files as defined by the present invention. The complete description of the conventional or standard .ZIP file format will not be included here since this information is generally well known. Only the portions pertaining to the new records and fields defined by the new format, capable of storing data using strong encryption, will be discussed in detail.

The present invention extends the original .ZIP file format with the addition of new storage records to support the use of strong encryption methods including, as described above, both public/private key, or asymmetric, methods and password-based, or symmetric, methods, and the capability to use a mixture of symmetric and asymmetric methods.

In the general format of a .ZIP file, files are stored in an arbitrary order. Large .ZIP files can span multiple diskette media or be split into user-defined segment sizes

The Archive Decryption Header (EFS) is introduced in the new ZIP format specification. This record exists in support of the Central Directory Encryption Feature implemented as part of the Strong Encryption Specification as described herein. When the Central Directory Structure is encrypted, this decryption header will precede the encrypted data segment. The encrypted data segment will consist of the Archive extra data record (if present) and the encrypted Central Directory Structure data. The format of this data record is identical to the Decryption header record preceding compressed file data. If the central directory structure is encrypted, the location of the start of this data record is determined using the Start of Central Directory field in the Zip64 End of Central Directory record.

The Archive Extra Data Record is introduced in the new ZIP format specification. This record exists in support of the Central Directory Encryption Feature implemented as part of the Strong Encryption Specification as described in this document. When present, this record immediately precedes the central directory data structure. The size of this data record will be included in the Size of the Central Directory field in the End of Central Directory record. If the central directory structure is compressed, but not encrypted, the location of the start of this data record is determined using the Start of Central Directory field in the Zip64 End of Central Directory record.

The Archive extra data record (EFS) structure is set out as: <tables id="tabl0001" num="0001"><table frame="all"><tgroup cols="2" colsep="1" rowsep="0"><colspec colnum="1" colname="col1" colwidth="78.75mm" /><colspec colnum="2" colname="col2" colwidth="78.75mm" /><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left">archive extra data signature</entry><entry namest="col2" nameend="col2" align="left">4 bytes (0x08064b50)</entry></row><row><entry namest="col1" nameend="col1" align="left">extra field length</entry><entry namest="col2" nameend="col2" align="left">4 bytes</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left">extra field data</entry><entry namest="col2" nameend="col2" align="left">(variable size)</entry></row></tbody></tgroup></table></tables>

And the Central Directory structure as: <ul id="ul0004" list-style="none" compact="compact"><li>[file header 1]</li><li>.</li><li>.</li><li>.</li><li>[file header n]</li></ul>

[digital signature]

The Central Directory has the file header structure: <tables id="tabl0002" num="0002"><table frame="all"><tgroup cols="2" colsep="1" rowsep="0"><colspec colnum="1" colname="col1" colwidth="78.75mm" /><colspec colnum="2" colname="col2" colwidth="78.75mm" /><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left">central file header signature</entry><entry namest="col2" nameend="col2" align="left">4 bytes (0x02014b50)</entry></row><row><entry namest="col1" nameend="col1" align="left">version made by</entry><entry namest="col2" nameend="col2" align="left">2 bytes</entry></row><row><entry namest="col1" nameend="col1" align="left">version needed to extract</entry><entry namest="col2" nameend="col2" align="left">2 bytes</entry></row><row><entry namest="col1" nameend="col1" align="left">general purpose bit flag</entry><entry namest="col2" nameend="col2" align="left">2 bytes</entry></row><row><entry namest="col1" nameend="col1" align="left">compression method</entry><entry namest="col2" nameend="col2" align="left">2 bytes</entry></row><row><entry namest="col1" nameend="col1" align="left">last mod file time</entry><entry namest="col2" nameend="col2" align="left">2 bytes</entry></row><row><entry namest="col1" nameend="col1" align="left">last mod file date</entry><entry namest="col2" nameend="col2" align="left">2 bytes</entry></row><row><entry namest="col1" nameend="col1" align="left">crc-32</entry><entry namest="col2" nameend="col2" align="left">4 bytes</entry></row><row><entry namest="col1" nameend="col1" align="left">compressed size</entry><entry namest="col2" nameend="col2" align="left">4 bytes</entry></row><row><entry namest="col1" nameend="col1" align="left">uncompressed size</entry><entry namest="col2" nameend="col2" align="left">4 bytes</entry></row><row><entry namest="col1" nameend="col1" align="left">file name length</entry><entry namest="col2" nameend="col2" align="left">2 bytes</entry></row><row><entry namest="col1" nameend="col1" align="left">extra field length</entry><entry namest="col2" nameend="col2" align="left">2 bytes</entry></row><row><entry namest="col1" nameend="col1" align="left">file comment length</entry><entry namest="col2" nameend="col2" align="left">2 bytes</entry></row><row><entry namest="col1" nameend="col1" align="left">disk number start</entry><entry namest="col2" nameend="col2" align="left">2 bytes</entry></row><row><entry namest="col1" nameend="col1" align="left">internal file attributes</entry><entry namest="col2" nameend="col2" align="left">2 bytes</entry></row><row><entry namest="col1" nameend="col1" align="left">external file attributes</entry><entry namest="col2" nameend="col2" align="left">4 bytes</entry></row><row><entry namest="col1" nameend="col1" align="left">relative offset of local header</entry><entry namest="col2" nameend="col2" align="left">4 bytes</entry></row><row><entry namest="col1" nameend="col1" align="left">file name</entry><entry namest="col2" nameend="col2" align="left">(variable size)</entry></row><row><entry namest="col1" nameend="col1" align="left">extra field</entry><entry namest="col2" nameend="col2" align="left">(variable size)</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left">file comment</entry><entry namest="col2" nameend="col2" align="left">(variable size)</entry></row></tbody></tgroup></table></tables>

And the Digital signature is set out as: <tables id="tabl0003" num="0003"><table frame="all"><tgroup cols="2" colsep="1" rowsep="0"><colspec colnum="1" colname="col1" colwidth="78.75mm" /><colspec colnum="2" colname="col2" colwidth="78.75mm" /><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left">header signature</entry><entry namest="col2" nameend="col2" align="left">4 bytes (0x05054b50)</entry></row><row><entry namest="col1" nameend="col1" align="left">size of data</entry><entry namest="col2" nameend="col2" align="left">2 bytes</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left">signature data</entry><entry namest="col2" nameend="col2" align="left">(variable size)</entry></row></tbody></tgroup></table></tables>

With the introduction of the Central Directory Encryption feature, the Central Directory Structure may be stored both compressed and encrypted. Although not required, it is assumed when encrypting the Central Directory Structure, that it will be compressed for greater storage efficiency. Information on the Central Directory Encryption feature can be found in the section describing the Strong Encryption Specification. The Digital Signature record will be neither compressed nor encrypted.

The general purpose bit flag is 2 bytes long. If Bit 0 is set then the file is encrypted. If Bit 6 is set then strong encryption is used. Bit 13 is used when encrypting the Central Directory to indicate selected data values in the Local Header are masked to hide their actual values. See the section describing the Strong Encryption Specification for details.

The other bits in this flag indicate such attributes as the compression method used.

The new .ZIP format introduces encryption data changes to support interoperability with SmartCard and USB Token certificate storage methods which do not support the Optimal Asymmetric Encryption Padding (OAEP) strengthening standard.

The new .ZIP format introduces support for encrypting metadata by compressing and encrypting the central directory data structure to reduce information leakage. Information leakage can occur in legacy ZIP applications through exposure of information about a file even though that file is stored encrypted. The information exposed consists of file characteristics stored within the records and fields defined by this specification. This includes data such as a files name, its original size, timestamp and CRC32 value.

Central Directory Encryption provides greater protection against information leakage by encrypting the Central Directory structure and by masking key values that are replicated in the unencrypted Local Header. ZIP compatible programs that cannot interpret an encrypted Central Directory structure cannot rely on the data in the corresponding Local Header for decompression information. Extra Field records that may contain information about a file that should not be exposed should not be stored in the Local Header and should only be written to the Central Directory where they can be encrypted. This design currently does not support streaming. Information in the End of Central Directory record, the ZIP64 End of Central Directory Locator, and the ZIP64 End of Central Directory record are not encrypted. Access to view data on files within a ZIP file with an encrypted Central Directory requires the appropriate password or private key for decryption prior to viewing any files, or any information about the files, in the archive.

Single Password Symmetric Encryption Method: The Single Password Symmetric Encryption Method using strong encryption algorithms operates similarly to the traditional encryption defined in previous .ZIP formats. Additional data structures are added to support the processing needs of the strong algorithms.

The Strong Encryption data structures are: <ul id="ul0005" list-style="none"><li>1. General Purpose Bits - Bits 0 and 6 of the General Purpose bit flag in both local and central header records. Both bits set indicates strong encryption. Bit 13, when set indicates the Central Directory is encrypted and that selected fields in the Local Header are masked to hide their actual value.</li><li>2. Extra Field 0x0017 in central header only.Fields to consider in this record are: <ul id="ul0006" list-style="none"><li>Format - the data format identifier for this record</li><li>AlgId - integer identifier of the encryption algorithm from a range of encryption options, for example DES, RC2, AES.</li></ul><ul id="ul0007" list-style="none" compact="compact"><li>Flags - Indicates the processing flags needed for decryption, which include: <ul id="ul0008" list-style="none" compact="compact"><li>0x0001 - Password is required to decrypt</li><li>0x0002 - Certificates only</li><li>0x0003 - Password or certificate required to decrypt</li><li>Values &gt; 0x0003 reserved for certificate processing</li></ul></li></ul></li><li>3. Decryption header record. This precedes the compressed file data. The Decryption Header is described in detail elsewhere. Provision is also made for certificate processing. </li><li>4. Single Password Central Directory Encryption. Central Directory Encryption is achieved within the .ZIP format by encrypting the Central Directory structure. This encapsulates the metadata most often used for processing .ZIP files. Additional metadata is stored for redundancy in the Local Header for each file. The process of concealing metadata by encrypting the Central Directory does not protect the data within the Local Header. To avoid information leakage from the exposed metadata in the Local Header, the fields containing information about a file are masked. Masking replaces the true content of the fields for a file in the Local Header with false information. When masked, the Local Header is not suitable for streaming access and the options for data recovery of damaged archives is reduced. Extra Data fields that may contain confidential data should not be stored within the Local Header. The value set into the Version needed to extract field should be the correct value needed to extract the file without regard to Central Directory Encryption. For the new .ZIP format under consideration, Encryption of the Central Directory does not include encryption of the Central Directory Signature data, the ZIP64 End of Central Directory record, the ZIP64 End of Central Directory Locator, or the End of Central Directory record. The ZIP file comment data is never encrypted. Alternative embodiments may support the encryption of such data and records. Before encrypting the Central Directory, it may optionally be compressed. Compression is not required, but for storage efficiency it is assumed this structure will be compressed before encrypting. Similarly, this specification supports compressing the Central Directory without requiring that it also be encrypted. Early implementations of this feature will assume the encryption method applied to files matches the encryption applied to the Central Directory. Encryption of the Central Directory is done in a manner similar to that of file encryption. A decryption header precedes the encrypted data. The decryption header is known as the Archive Decryption Header. The fields of this record are identical to the decryption header preceding each encrypted file. The location of the Archive Decryption Header is determined by the value in the Start of the Central Directory field in the ZIP64 End of Central Directory record. When the Central Directory is encrypted, the ZIP64 End of Central Directory record will always be present. Decrypting and decompressing the Central Directory is accomplished in the same manner as decrypting and decompressing a file. Strong Encryption is always applied to a file after compression. The block oriented algorithms all operate in Cypher Block Chaining (CBC) mode. The block size used for AES encryption is 16. All other block algorithms use a block size of 8. Two ID's are defined for RC2 to account for a discrepancy found in the implementation of the RC2 algorithm in the cryptographic library on Windows XP SP1 and all earlier versions of Windows. A pseudo-code representation of the encryption process is as follows: <ul id="ul0009" list-style="none" compact="compact"><li>Password = GetUserPassword()</li><li>RD = Random()</li><li>ERD = Encrypt(RD,DeriveKey(SHA1(Password)))</li><li>For Each File    IV = Random()    VData = Random()    FileSessionKey = DeriveKey(SHA1(IV + RD))    Encrypt(VData + VCRC32 + FileData,FileSessionKey)</li><li>Done</li></ul> The function names and parameter requirements will depend on the choice of the cryptographic toolkit selected. Almost any toolkit supporting the reference implementations for each algorithm can be used. The RSA BSAFE(r), OpenSSL, and Microsoft CryptoAPI libraries are all known to work well. </li><li>5. Certificate Processing - Central Directory Encryption. Central Directory Encryption using Digital Certificates operate in a manner similar to that of Single Password Central Directory Encryption. This record will only be present when there is data to place into it. Currently, data is placed into this record when digital certificates are used for either encrypting or signing the files within a ZIP file. When only password encryption is used with no certificate encryption or digital signing, this record is not currently needed. When present, this record will appear before the start of the actual Central Directory data structure and will be located immediately after the Archive Decryption Header if the Central Directory is encrypted. The Archive Extra Data record will be used to store the following information. Additional data may be added in future versions. Extra Data Fields include: <ul id="ul0010" list-style="none" compact="compact"><li>0x0014 - PKCS#7 Store for X.509 Certificates</li><li>0x0016 - X.509 Certificate ID and Signature for central directory</li><li>0x0019 - PKCS#7 Encryption Recipient Certificate List</li></ul> The 0x0014 and 0x0016 Extra Data records that otherwise would be located in the first record of the Central Directory for digital certificate processing. When encrypting or compressing the Central Directory, the 0x0014 and 0x0016 records must be located in the Archive Extra Data record and they should not remain in the first Central Directory record. The Archive Extra Data record will also be used to store the 0x0019 data. When present, the size of the Archive Extra Data record will be included in the size of the Central Directory. The data of the Archive Extra Data record will also be compressed and encrypted along with the Central Directory data structure. </li><li>6. Certificate Processing Differences. The Certificate Processing Method of encryption differs from the Single Password Symmetric Encryption Method as follows. Instead of using a user-defined password to generate a master session key, cryptographically random data is used. The key material is then wrapped using standard key-wrapping techniques. This key material is wrapped using the public key of each recipient that will need to decrypt the file using his or her corresponding private key. The locations and values of the fields and records described above illustrate only one specific embodiment of the new .ZIP file format and it is possible to choose other, alternative locations and values to carry out the methods herein described. An example of implementing a new strong encryption method is discussed below. This example identifies several new records and fields that must be defined within the .ZIP file format. A new <b><i>General Purpose Bit Flag</i></b> having a hexadecimal value of <b>0x0040</b> to be set in both the Local and Central Record Headers when strongly encrypting a file. A new <b><i>Decryption Header</i></b> to be located immediately ahead of and adjacent to the compressed data stored for each file. A new <b><i>Extra Field</i></b> record definition with an ID having a hexadecimal value of <b>0x0017</b> to be inserted into the Central Record Header for each file. When using these new fields for strongly encrypting files, the following actions are indicated. <ul id="ul0011" list-style="none"><li>1. If the General Purpose Bit Flag value of 0x0040 is set to indicate strong encryption was applied to a file, the General Purpose Bit Flag value of 0x0001 will also generally be set.</li><li>2. Files having a size of zero bytes (an empty file) should not generally be encrypted. As indicated, however, the file characteristics of the archived files may be encrypted, even if the file is of zero length and is not itself encrypted.</li><li>3. The contents of the field labeled <b><i>Version Needed to Extract</i></b> in both the Local and Central Record Headers should preferably be set to the decimal value of 50 or greater. If the AES encryption method is used, the contents of the field labeled <b><i>Version Needed to Extract</i></b> in both the Local and Central Record Headers should preferably be set to the decimal value 51 or greater.</li><li>4. Data encryption should preferably be applied after a file is compressed, but encryption can be applied to a file if compression is not used. If compression is not applied to a file, it is considered to be <b>stored</b> in the .ZIP file.</li><li>5. If encryption is applied using digital certificates, a list of intended recipients will be constructed. Each entry in the recipient list identifies a person whose public key has been used in the encryption process for a file and who is allowed to decrypt the file contents using their private key.</li></ul></li></ul>

Record Definitions:

<i>New Decryption Header (NDH)</i>

<tables id="tabl0004" num="0004"><table frame="all"><tgroup cols="3" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="52.50mm" /><colspec colnum="2" colname="col2" colwidth="52.50mm" /><colspec colnum="3" colname="col3" colwidth="52.50mm" /><thead valign="top"><row><entry namest="col1" nameend="col1" align="left">Value</entry><entry namest="col2" nameend="col2" align="left">Size (bytes)</entry><entry namest="col3" nameend="col3" align="left">Description</entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left"><b>IV</b> size</entry><entry namest="col2" nameend="col2" align="left">2</entry><entry namest="col3" nameend="col3" align="left">Size of custom initialization vector/salt, if 0 then <b>CRC32</b> + 64-bit <b>File Size</b> should be used to decrypt data.</entry></row><row><entry namest="col1" nameend="col1" align="left"><b>IV</b></entry><entry namest="col2" nameend="col2" align="left">variable</entry><entry namest="col3" nameend="col3" align="left">Initialization vector/salt (file specific) which should be used in place of <b>CRC32</b> + 64-bit <b>File Size</b></entry></row><row><entry namest="col1" nameend="col1" align="left">Original Size</entry><entry namest="col2" nameend="col2" align="left">4</entry><entry namest="col3" nameend="col3" align="left">Original (uncompressed) size of the following data</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left"><b><i>Decryption Info.</i></b></entry><entry namest="col2" nameend="col2" align="left">variable</entry><entry namest="col3" nameend="col3" align="left"><b><i>Decryption Information</i></b></entry></row></tbody></tgroup></table></tables>

<b>Decryption Information (details)</b>

<tables id="tabl0005" num="0005"><table frame="all"><tgroup cols="3" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="52.50mm" /><colspec colnum="2" colname="col2" colwidth="52.50mm" /><colspec colnum="3" colname="col3" colwidth="52.50mm" /><thead valign="top"><row><entry namest="col1" nameend="col1" align="left">Value</entry><entry namest="col2" nameend="col2" align="left">Size (bytes)</entry><entry namest="col3" nameend="col3" align="left">Description</entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left">Version (3)</entry><entry namest="col2" nameend="col2" align="left">2</entry><entry namest="col3" nameend="col3" align="left">Version/Format of decryption information.</entry></row><row><entry namest="col1" nameend="col1" align="left">AlgID</entry><entry namest="col2" nameend="col2" align="left">2</entry><entry namest="col3" nameend="col3" align="left">Encryption Algorithm ID</entry></row><row><entry namest="col1" nameend="col1" align="left">BitLen</entry><entry namest="col2" nameend="col2" align="left">2</entry><entry namest="col3" nameend="col3" align="left">Bit length of the key</entry></row><row><entry namest="col1" nameend="col1" align="left"><i><b>Flags</b></i></entry><entry namest="col2" nameend="col2" align="left">2</entry><entry namest="col3" nameend="col3" align="left">Processing flags</entry></row><row><entry namest="col1" nameend="col1" align="left"><b>ERD</b> size</entry><entry namest="col2" nameend="col2" align="left">2</entry><entry namest="col3" nameend="col3" align="left">Size of <b>Encrypted Random Data (ERD)</b></entry></row><row><entry namest="col1" nameend="col1" align="left"><b>ERD</b></entry><entry namest="col2" nameend="col2" align="left">variable</entry><entry namest="col3" nameend="col3" align="left"><b>Encrypted Random Data</b></entry></row><row><entry namest="col1" nameend="col1" align="left"><b><i>Recipient</i></b> Count</entry><entry namest="col2" nameend="col2" align="left">4</entry><entry namest="col3" nameend="col3" align="left">Number of <b><i>Recipients</i></b></entry></row><row><entry namest="col1" nameend="col1" align="left">Hash Algorithm</entry><entry namest="col2" nameend="col2" align="left">2</entry><entry namest="col3" nameend="col3" align="left">Hash algorithm to be used to calculate Public Key hash (absent for password based encryption)</entry></row><row><entry namest="col1" nameend="col1" align="left"><b><i>Hash Size</i></b></entry><entry namest="col2" nameend="col2" align="left">2</entry><entry namest="col3" nameend="col3" align="left">Size of Public Key hash (absent for password based encryption)</entry></row><row><entry namest="col1" nameend="col1" align="left"><b><i>Recipient List Element</i></b></entry><entry namest="col2" nameend="col2" align="left">variable</entry><entry namest="col3" nameend="col3" align="left"><b><i>Recipient List Element</i></b> (absent for password based encryption)</entry></row><row><entry namest="col1" nameend="col1" align="left">Password, Validation Data Size</entry><entry namest="col2" nameend="col2" align="left">2</entry><entry namest="col3" nameend="col3" align="left">Size of random password validation data (Includes CRC32 of PVD; &gt; 4) MUST be multiple of encryption block sizes</entry></row><row><entry namest="col1" nameend="col1" align="left">Password, Validation Data</entry><entry namest="col2" nameend="col2" align="left">variable</entry><entry namest="col3" nameend="col3" align="left">Password Validation Data (PVD)</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left">CRC32 of PVD</entry><entry namest="col2" nameend="col2" align="left">4</entry><entry namest="col3" nameend="col3" align="left">CRC32 of PVD, used for password verification when decrypting data</entry></row></tbody></tgroup></table></tables>

<b>Encryption Algorithm ID</b> (AlgID) identifies which of several possible strong encryption algorithms was used for encrypting a file in the .ZIP file. The strong encryption algorithms that can be used include but are not limited to AES, 3DES, 2DES, DES, RC2 and RC4. The use of other unspecified strong algorithms for encryption is supported by the present invention.

<b>Hash Algorithm</b> identifies which of several possible hash algorithms was used for the encryption process for a file in the .ZIP file. The algorithms that can be used include but are not limited to MD5, SHA1 - SHA512. The use of other unspecified algorithms for hashing is supported by the present invention.

Encrypted Random Data (ERD) - Encrypted random data is used to generate a file session key for encrypting each file. SHA1 is used to calculate hash data used to derive keys. File session keys are derived from a master session key generated from the user-supplied password. If the Flags field in the decryption header contains the value 0x4000, then the ErdData field must be decrypted using 3DES.

<i>Flags</i>

The following values are defined for the processing <b><i>Flags</i>.</b><tables id="tabl0006" num="0006"><table frame="all"><tgroup cols="3" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="52.50mm" /><colspec colnum="2" colname="col2" colwidth="52.50mm" /><colspec colnum="3" colname="col3" colwidth="52.50mm" /><thead valign="top"><row><entry namest="col1" nameend="col1" align="left">Name</entry><entry namest="col2" nameend="col2" align="left">Value</entry><entry namest="col3" nameend="col3" align="left">Description</entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left"><b>PASSWORD KEY</b></entry><entry namest="col2" nameend="col2" align="left">0x0001</entry><entry namest="col3" nameend="col3" align="left">Password is used</entry></row><row><entry namest="col1" nameend="col1" align="left"><b>CERTIFICATE KEY</b></entry><entry namest="col2" nameend="col2" align="left">0x0002</entry><entry namest="col3" nameend="col3" align="left"><b><i>Recipient List</i></b> is used</entry></row><row><entry namest="col1" nameend="col1" align="left"><b>COMBO_KEY</b></entry><entry namest="col2" nameend="col2" align="left">0x0003</entry><entry namest="col3" nameend="col3" align="left">Either a password or a <b><i>Recipient List</i></b> can be used to decrypt a file</entry></row><row><entry namest="col1" nameend="col1" align="left"><b>DOUBLE_SEED_KEY</b></entry><entry namest="col2" nameend="col2" align="left">0x0007</entry><entry namest="col3" nameend="col3" align="left">Both password and <b><i>Recipient List</i></b> are required to decrypt a file. <b>ERD</b> is encrypted twice by 2 separate keys.</entry></row><row><entry namest="col1" nameend="col1" align="left"><b>DOUBLE_DATA_KEY</b></entry><entry namest="col2" nameend="col2" align="left">0x000f</entry><entry namest="col3" nameend="col3" align="left">Both a password and a <b><i>Recipient List</i></b> are required to decrypt a file. File data is encrypted twice using 2 separate keys</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left"><b>MASTER KEY 3DES</b></entry><entry namest="col2" nameend="col2" align="left">0x4000</entry><entry namest="col3" nameend="col3" align="left">Specifies 3DES algorithm is used for MSK</entry></row></tbody></tgroup></table></tables>

<i>Recipient List Element</i>

<tables id="tabl0007" num="0007"><table frame="all"><tgroup cols="3" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="52.50mm" /><colspec colnum="2" colname="col2" colwidth="52.50mm" /><colspec colnum="3" colname="col3" colwidth="52.50mm" /><thead valign="top"><row><entry namest="col1" nameend="col1" align="left">Value</entry><entry namest="col2" nameend="col2" align="left">Size (bytes)</entry><entry namest="col3" nameend="col3" align="left">Description</entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left">Recipient Element size</entry><entry namest="col2" nameend="col2" align="left">2</entry><entry namest="col3" nameend="col3" align="left">Combined size of Hash of Public Key and Simple Key Blob</entry></row><row><entry namest="col1" nameend="col1" align="left">Hash</entry><entry namest="col2" nameend="col2" align="left"><b><i>Hash Size</i></b></entry><entry namest="col3" nameend="col3" align="left">Hash of Public Key</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left">Simple key Blob</entry><entry namest="col2" nameend="col2" align="left">variable</entry><entry namest="col3" nameend="col3" align="left">Simple Key Blob</entry></row></tbody></tgroup></table></tables>

New Decryption Central Record Extra Field <i>(NDCEF)</i>

<tables id="tabl0008" num="0008"><table frame="all"><tgroup cols="3" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="52.50mm" /><colspec colnum="2" colname="col2" colwidth="52.50mm" /><colspec colnum="3" colname="col3" colwidth="52.50mm" /><thead valign="top"><row><entry namest="col1" nameend="col1" align="left">Value</entry><entry namest="col2" nameend="col2" align="left">Size (bytes)</entry><entry namest="col3" nameend="col3" align="left">Description</entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left">0x0017</entry><entry namest="col2" nameend="col2" align="left">2</entry><entry namest="col3" nameend="col3" align="left">Signature of <b><i>NDCEF</i></b></entry></row><row><entry namest="col1" nameend="col1" align="left">Data Size</entry><entry namest="col2" nameend="col2" align="left">2</entry><entry namest="col3" nameend="col3" align="left">Size of the following data (at least 12 bytes)</entry></row><row><entry namest="col1" nameend="col1" align="left">Version (2)</entry><entry namest="col2" nameend="col2" align="left">2</entry><entry namest="col3" nameend="col3" align="left">Version/Format of this extra field.</entry></row><row><entry namest="col1" nameend="col1" align="left">Alg ID</entry><entry namest="col2" nameend="col2" align="left">2</entry><entry namest="col3" nameend="col3" align="left">Encrytion Algorithm ID.</entry></row><row><entry namest="col1" nameend="col1" align="left">BitLen</entry><entry namest="col2" nameend="col2" align="left">2</entry><entry namest="col3" nameend="col3" align="left">Bit length of the key</entry></row><row><entry namest="col1" nameend="col1" align="left"><b><i>Flag s</i></b></entry><entry namest="col2" nameend="col2" align="left">2</entry><entry namest="col3" nameend="col3" align="left">Processing flags</entry></row><row><entry namest="col1" nameend="col1" align="left"><b><i>Recipient</i></b> Count</entry><entry namest="col2" nameend="col2" align="left">4</entry><entry namest="col3" nameend="col3" align="left">Number of <b><i>Recipients</i></b></entry></row><row><entry namest="col1" nameend="col1" align="left">Hash Algorithm</entry><entry namest="col2" nameend="col2" align="left">2</entry><entry namest="col3" nameend="col3" align="left">Hash algorithm to be used to calculate Public Key hash (absent for password based encryption)</entry></row><row><entry namest="col1" nameend="col1" align="left"><b><i>Hash Size</i></b></entry><entry namest="col2" nameend="col2" align="left">2</entry><entry namest="col3" nameend="col3" align="left">Size of Public Key hash (absent for password based encryption)</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left"><b><i>Simplified Recipient List Element</i></b></entry><entry namest="col2" nameend="col2" align="left">variable</entry><entry namest="col3" nameend="col3" align="left"><b><i>Simplified Recipient List Element</i></b> (absent for password based encryption)</entry></row></tbody></tgroup></table></tables>

Simplified Recipient List Element

<tables id="tabl0009" num="0009"><table frame="all"><tgroup cols="3" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="52.50mm" /><colspec colnum="2" colname="col2" colwidth="52.50mm" /><colspec colnum="3" colname="col3" colwidth="52.50mm" /><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left">Value</entry><entry namest="col2" nameend="col2" align="left">Size (bytes)</entry><entry namest="col3" nameend="col3" align="left">Description</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left">Hash</entry><entry namest="col2" nameend="col2" align="left"><b><i>Hash Size</i></b></entry><entry namest="col3" nameend="col3" align="left">Hash of Public Key</entry></row></tbody></tgroup></table></tables>

A simplified recipient list element is defined as a subset of a recipient list element and is stored to provide redundancy of the recipient list data for the purposes of data recovery.

Process Flow:

The following is a description of the most preferred encryption/decryption process for a single file using the storage format defined by this example. Any programs, software or other processes available to suitably perform the encryption/decryption process may be used.

Encryption:

<ul id="ul0012" list-style="none" compact="compact"><li>1. Validate public/private key</li><li>2. Calculate file digital signature and time-stamp</li><li>3. Compress or Store uncompressed file data</li><li>4. Generate a <b>File Session Key (FSK)</b> (see below)</li><li>5. Calculate <b>Decryption Information</b> size</li><li>6. Adjust <b>Compressed Size</b> to accommodate <b>Decryption Information</b> and padding</li><li>7. Save <b>Decryption Information</b> to .ZIP file.</li><li>8. Encrypt <b>Compressed or Stored File Data</b></li><li>9. Encrypt file characteristics</li></ul>

Decryption:

<ul id="ul0013" list-style="none" compact="compact"><li>1. Decrypt file characteristics.</li><li>2. Read <b>Decryption Information</b> from .ZIP file</li><li>3. Generate <b>FSK</b> (see below)</li><li>4. Verify <b>Decryption Information</b> (see below)</li><li>5. If Decryption Information is valid, then decrypt <b>Compressed or Stored File Data</b></li><li>6. Decompress compressed data.</li><li>7. Validate file time-stamp and digital signature</li></ul>

Generating

Master Session Key (MSK)

<ul id="ul0014" list-style="none" compact="compact"><li>1. If <b>MASTER_KEY_3DES</b> is set, use 3DES 3-key as <b>MSK</b> algorithm, otherwise use specified algorithm.</li><li>2. If encrypting or decrypting with a password.</li><li>2.1.1. Prompt user for <i>password</i></li><li>2.1.2. Calculate <i>hash</i> of the <i>password</i></li><li>2.1.3. Pass calculated <i>hash</i> as argument into a cryptographic key derivation function or its equivalent.</li><li>3. When encrypting using a public key(s).</li><li>3.1.1. Call a cryptographic key generation function or its equivalent to generate random key</li><li>4. When decrypting using a private key(s).    4.1. Using <b>Recipient List</b> information, locate private key, which corresponds to one of the public keys used to encrypt <b>MSK</b>.    4.2. Decrypt <b>MSK</b></li></ul>

Salt

and/or

Initialization Vector (IV)

<ul id="ul0015" list-style="none" compact="compact"><li>1. For algorithms that use both <b><i>Salt</i></b> and <b><i>IV</i>, Salt = IV</b></li><li>2. <b>IV</b> can be completely random data and placed in front of <b><i>Decryption Information</i></b></li><li>3. Otherwise <b>IV CRC32</b> + 64-bit <b>File Size</b></li></ul>

Adjusting Keys

<ul id="ul0016" list-style="none"><li>1. Determine <b><i>Salt</i></b> and/or <b><i>Initialization Vector</i></b> size of the key for the encryption algorithm specified. Usually salt is compliment to 128 bits, so for 40-bit key <b>Salt</b> size will be 11 bytes. <b>Initialization Vector</b> is usually used by block algorithms and its size corresponds to the block size.</li><li>2. If <i><b>Salt</b></i> size &gt; 0 or <b><i>Initialization Vector</i></b> size is &gt; 0 then set IV to be used by the specified encryption algorithm. When adjusting <b>MSK,</b> if <b>IV</b> is smaller then required Initialization Vector (or Salt) size it is complimented with 0, if it is larger it is truncated. For all other operations IV is used as is without any modifications.</li></ul>

Generating

File Session Key (FSK)

<ul id="ul0017" list-style="none" compact="compact"><li>1. <b>FSK</b> &lt;- <b>SHA1 (MSK(IV)).</b> Adjust <b>MSK</b> with <b>IV,</b> and decrypt <b>ERD (Encrypted Random Data).</b> Calculate <i>hash</i> of <b>IV</b> + <b>Random Data.</b> Pass calculated <i>hash</i> as argument into a cryptographic key derivation function or its equivalent to obtain <b>FSK.</b></li></ul>

Verifying

Decryption Information

<ul id="ul0018" list-style="none" compact="compact"><li>1. <b>Decryption Information</b> contains variable length <b>Password Validation Data (PVD).</b></li><li>2. First <b>Password Validation Data Size - 4</b> bytes are random data, and last 4 bytes are CRC32 of that random data. This allows verification that the correct key is used and deters plain text attacks.</li></ul>

The following modifications are used for encrypting and decrypting multiple files.

Multi-file encryption:

<ul id="ul0019" list-style="none" compact="compact"><li>1. Generate <b>MSK</b>.</li><li>2. For each file follow <b>Encryption</b> steps.</li></ul>

Multi-file decryption:

<ul id="ul0020" list-style="none" compact="compact"><li>1. Generate <b>MSK</b> from the file <b>Decryption Information</b></li><li>2. For each file follow <b>Decryption</b> steps</li><li>3. If <b>Decryption Information</b> verification fails go to step 1</li></ul>

Alternate storage formats can be defined for implementing the flexible security support within ZIP files. One such alternative is to use other fields, either existing or newly defined to denote that a strong encryption method was applied to a .ZIP archive. Another alternative could be to use additional storage fields in addition to those defined in the above example, or to use the fields as defined, but ordered differently within each record. Still other implementations may use fewer, or more, records or fields than are defined by the above example or the records and fields may be placed in other physical locations within the .ZIP file.

Alternate processing methods can also be defined for implementing the flexible security support within .ZIP files. One such alternative is to implement the encryption process for each file using another public/private key technology such as that defined by the OpenPGP Message Format as documented in RFC 2440. Another alternative could be to use a more direct form of encryption key generation where the file session key is directly used for encrypting each file. This method would not use the indirect form described in the above example where the file session key is derived from a master key.

While the invention has been described with reference to preferred embodiments, it is to be understood that the invention is not intended to be limited to the specific embodiments set forth above. Thus, it is recognized that those skilled in the art will appreciate that certain substitutions, alterations, modifications, and omissions may be made without departing from scope of the invention.