Method for strongly encrypting .ZIP files

Abstract

The present invention provides a method of integrating existing strong encryption methods into the processing of a .ZIP file 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 electronically storing and transferring confidential data.

Claims

1. A method of retrieving a desired data file from a .zip file format data container, said method including: receiving a data container constructed in accordance with a .Zip file format, wherein said data container includes: an encrypted data file; encrypted random data; a first asymmetric key data; and a second asymmetric key data; receiving one of a first asymmetric key and a second asymmetric key, wherein, when said first asymmetric key is received, said first asymmetric key is used to decrypt said first asymmetric key data to determine a second symmetric key, wherein, when said second asymmetric key is received, said second asymmetric key is used to decrypt said second asymmetric key data to determine said second symmetric key; decrypting said encrypted random data using said second symmetric key to determine a first symmetric key; and decrypting said encrypted data file using said first symmetric key to determine a desired data file.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) FIG. 1 is a record layout of a prior art .ZIP file prior to the present invention.

(2) FIG. 2 is a record layout of a .ZIP file in accordance with the present invention.

DETAILED DESCRIPTION OF THE INVENTION

(3) 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.

(4) The newly modified ZIP file format specification according to the present invention, as published by PKWARE, Inc., is described in a document entitled APPNOTE.TXT, which is incorporated herein by reference. 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.

(5) 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.

(6) 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.

(7) A new General Purpose Bit Flag having a hexadecimal value of 0x0040 to be set in both the Local and Central Record Headers when strongly encrypting a file.

(8) A new Decryption Header to be located immediately ahead of and adjacent to the compressed data stored for each file.

(9) A new Extra Field record definition with an ID having a hexadecimal value of 0x0017 to be inserted into the Central Record Header for each file.

(10) When using these new fields for strongly encrypting files, the following actions are indicated.

(11) 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.

(12) 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.

(13) 3. The contents of the field labeled Version Needed to Extract 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 Version Needed to Extract in both the Local and Central Record Headers should preferably be set to the decimal value 51 or greater.

(14) 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 stored in the .ZIP file.

(15) 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.

(16) Record Definitions:

New Decryption Header (NDH)

(17) TABLE-US-00001 Size Value (bytes) Description IV size 2 Size of custom initialization vector/salt, if 0 then CRC32 + 64-bit File Size should be used to decrypt data. IV variable Initialization vector/salt (file specific) which should be used in place of CRC32 + 64-BIT File Size Original 4 Original (uncompressed) size of the Size following data Decryption variable Decryption Information Info.

(18) Decryption Information (Details)

Decryption Information (Details)

(19) TABLE-US-00002 Size Value (bytes) Description Version (3) 2 Version/Format of decryption information. AlgID 2 Encryption Algorithm ID BitLen 2 Bit length of the key Flags 2 Processing flags ERD size 2 Size of Encrypted Random Data (ERD) ERD variable Encrypted Random Data Recipient Count 4 Number of Recipients Hash Algorithm 2 Hash algorithm to be used to calculate Public Key hash (absent for password based encryption) Hash Size 2 Size of Public Key hash (absent for password based encryption) Recipient List Variable Recipient List Element (absent for Element password based encryption) Password 2 Size of random password validation data Validation (Includes CRC32 of PVD; >4) MUST be Data size multiple of encryption block sizes Password, Variable Password Validation Data (PVD) Validation Data CRC32 of PVD 4 CRC32 of PVD, used for password verification when decrypting data

(20) Encryption Algorithm ID (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.

(21) Hash Algorithm 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.

(22) Flags

(23) The following values are defined for the processing Flags.

(24) TABLE-US-00003 Name Value Description PASSWORD_KEY 0x0001 Password is used CERTIFICATE_KEY 0x0002 Recipient List is used COMBO_KEY 0x0003 Either a password or a Recipient List can be used to decrypt a file. DOOUBLE_SEED_KEY 0x0007 Both password and Recipient List are required to decrypt a file. ERD is encrypted twice by 2 separate keys. DOUBLE_DATA_KEY 0x000f Both a password and a Recipient List are required to decrypt a file. File data is encrypted twice using 2 separate keys. MASTER_KEY_3DES 0x4000 Specified 3DES algorithm is used for MSK

(25) Recipient List Element

(26) TABLE-US-00004 Size Value (bytes) Description Recipient Element 2 Combined size of Hash of Public size Key and Simple Key Blob Hash Hash Size Hash of Public Key Simple key Blob variable Simple Key Blob

New Decryption Central Record Extra Field (NDCEF)

(27) TABLE-US-00005 Size Value (bytes) Description 0x0017 2 Signature of NDCEF Data Size 2 Size of the following data (at least 12 bytes) Version (2) 2 Version/Format of this extra field. AlgID 2 Encryption Algorithm ID. BitLen 2 Bit length of the key Flags 2 Processing flags Recipient Count 4 Number of Recipients Hash Algorithm 2 Hash algorithm to be used to calculate Public Key hash (absent for password based encryption) Hash Size 2 Size of Public Key hash (absent for password based encryption) Simplified variable Simplified Recipient List Element Recipient List (absent for password based encryption) Element

(28) Simplified Recipient List Element

(29) TABLE-US-00006 Size Value (bytes) Description Hash Hash Size Hash of Public Key
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.

(30) Process Flow:

(31) 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.

(32) Encryption: 1. Validate public/private key 2. Calculate file digital signature and time-stamp 3. Compress or Store uncompressed file data 4. Generate a File Session Key (FSK) (see below) 5. Calculate Decryption Information size 6. Adjust Compressed Size to accommodate Decryption Information and padding 7. Save Decryption Information to .ZIP file 8. Encrypt Compressed or Stored File Data 9. Encrypt file characteristics

(33) Decryption: 1. Decrypt file characteristics 2. Read Decryption Information from .ZIP file 3. Generate FSK (see below) 4. Verify Decryption Information (see below) 5. If Decryption Information is valid, then decrypt Compressed or Stored File Data 6. Decompress compressed data 7. Validate file time-stamp and digital signature

(34) Generating Master Session Key (MSK) 1. If MASTER_KEY_3DES is set, use 3DES 3-key as MSK algorithm, otherwise use specified algorithm. 2. If encrypting or decrypting with a password. 2.1.1. Prompt user for password 2.1.2. Calculate hash of the password 2.1.3. Pass calculated hash as argument into a cryptographic key derivation function or its equivalent. 3. When encrypting using a public key(s). 3.1.1. Call a cryptographic key generation function or its equivalent to generate random key 4. When decrypting using a private key(s). 4.1. Using Recipient List information, locate private key, which corresponds to one of the public keys used to encrypt MSK. 4.2. Decrypt MSK

(35) Salt and/or Initialization Vector (IV) 1. For algorithms that use both Salt and IV, Salt=IV

(36) 2. IV can be completely random data and placed in front of Decryption Information 3. Otherwise IV=CRC32+64-bit File Size

(37) Adjusting Keys 1. Determine Salt and/or Initialization Vector size of the key for the encryption algorithm specified. Usually salt is compliment to 128 bits, so for 40-bit key Salt size will be 11 bytes. Initialization Vector is usually used by block algorithms and its size corresponds to the block size. 2. If Salt size>0 or Initialization Vector size is >0 then set IV.sup.1 to be used by the specified encryption algorithm. .sup.1When adjusting MSK, if IV 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.

(38) Generating File Session Key (FSK) 1. FSK<-SHA1(MSK(IV)). Adjust MSK with IV, and decrypt ERD (Encrypted Random Data). Calculate hash of IV+Random Data. Pass calculated hash as argument into a cryptographic key derivation function or its equivalent to obtain FSK.

(39) Verifying Decryption Information 1. Decryption Information contains variable length Password Validation Data (PVD). 2. First Password Validation Data Size—4 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.

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

(41) Multi-File Encryption: 1. Generate MSK. 2. For each file follow Encryption steps.

(42) Multi-File Decryption: 1. Generate MSK from the file Decryption Information 2. For each file follow Decryption steps 3. If Decryption Information verification fails go to step 1

(43) 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.

(44) 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.

(45) 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 the spirit or intent of the invention. Accordingly, the foregoing description is meant to be exemplary only, the invention is to be taken as including all reasonable equivalents to the subject matter of the invention, and should not limit the scope of the invention set forth in the following claims.