Search Images Maps Play YouTube News Gmail Drive More »
Sign in
Screen reader users: click this link for accessible mode. Accessible mode has the same essential features but works better with your reader.

Patents

  1. Advanced Patent Search
Publication numberUS20050086476 A1
Publication typeApplication
Application numberUS 10/946,273
Publication date21 Apr 2005
Filing date20 Sep 2004
Priority date16 Jul 2003
Also published asCA2473481A1, EP1515445A1, US7793099, US7895434, US8090942, US8225108, US9098721, US20050015608, US20050081031, US20050081034, US20050086196, US20050086474, US20050086475, US20050091489, US20050091517, US20050091519, US20050094817, US20050097113, US20050097344, US20050120234, US20080046761, US20090144562, US20090240952, US20100119070, US20120284536, US20160026816
Publication number10946273, 946273, US 2005/0086476 A1, US 2005/086476 A1, US 20050086476 A1, US 20050086476A1, US 2005086476 A1, US 2005086476A1, US-A1-20050086476, US-A1-2005086476, US2005/0086476A1, US2005/086476A1, US20050086476 A1, US20050086476A1, US2005086476 A1, US2005086476A1
InventorsJames Peterson
Original AssigneePkware, Inc.
Export CitationBiBTeX, EndNote, RefMan
External Links: USPTO, USPTO Assignment, Espacenet
Method and system for multiple symmetric decryption of .ZIP files
US 20050086476 A1
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.
Images(3)
Previous page
Next page
Claims(70)
1. A method of providing access to data in a .Zip file format data container, said method including:
receiving a data container constructed in accordance with a .Zip file format, said data container including:
first symmetric key data;
second symmetric key data; and
an encrypted data file,
wherein said first symmetric key data was derived by symmetrically encrypting, using a first symmetric key, an intermediate symmetric key that was used to encrypt said encrypted data file,
wherein said second symmetric key data was derived by symmetrically encrypting, using a second symmetric key, said intermediate symmetric key that was used to encrypt said encrypted data file
receiving a decryption key input;
providing the option of:
using said first symmetric key data in combination with said decryption key input to recover said intermediate symmetric key to symmetrically decrypt said encrypted data file to form a decrypted data file when said decryption key is a desired first symmetric key; and
using said second symmetric key data in combination with said decryption key input to recover said intermediate symmetric key to symmetrically decrypt said encrypted data file to form a decrypted data file when said decryption key is a desired second symmetric key; and
providing access to said decrypted data file.
2. The method of claim 1 further including decompressing said decrypted data file.
3. The method of claim 2 wherein said decompressing employs a Lempel-Ziv (LZ)-type data decompression algorithm.
4. The method of claim 2 wherein said decompressing employs a Deflate-type data decompression algorithm.
5. The method of claim 2 wherein said decompressing employs a Burrows-Wheeler Transform (BWT)-type data decompression algorithm.
6. The method of claim 1 wherein said decrypted data file is not decompressed.
7. The method of claim 1 wherein at least part of one of said first symmetric key, said second symmetric key, and said intermediate symmetric key is composed of random data.
8. The method of claim 7 wherein at least part of said first symmetric key is composed of a first set of random data and at least part of said second symmetric key is composed of a second set of random data.
9. The method of claim 8 wherein said first set of random data is not equal to said second set of random data.
10. The method of claim 1 wherein at least part of said decryption key is received from a user.
11. The method of claim 10 wherein at least part of said decryption key is a password.
12. The method of claim 1 wherein said desired first symmetric key input is different from said desired second symmetric key input.
13. The method of claim 1 wherein at least one of said first symmetric key, said second symmetric key, and said intermediate symmetric key has a key length of at least 128 bits.
14. The method of claim 1 wherein at least one of said first symmetric key, said second symmetric key, and said intermediate symmetric key has a key length of at least 192 bits.
15. The method of claim 1 wherein at least one of said first symmetric key, said second symmetric key, and said intermediate symmetric key has a key length of at least 256 bits.
16. The method of claim 1 wherein said symmetrically decrypting said encrypted data file uses an AES decryption decoding operation.
17. The method of claim 1 wherein said symmetrically decrypting said encrypted data file uses a 3DES decryption decoding operation.
18. A method of providing access to data in a .Zip file format data container, said method including:
receiving a data container constructed in accordance with a Zip file format, said data container including:
first symmetric key data;
second symmetric key data; and
an encrypted data file,
wherein said first symmetric key data was derived from a first symmetric key that was used to symmetrically encrypt said encrypted data file,
wherein said second symmetric key data was derived from a second symmetric key that was used to symmetrically encrypt said encrypted data file,
receiving a decryption key input;
providing the option of:
using said first symmetric key data in combination with said decryption key input to recover said first symmetric key to symmetrically decrypt said encrypted data file to form a decrypted data file when said decryption key is a desired first symmetric key; and
using said second symmetric key data in combination with said decryption key input to recover said second symmetric key to symmetrically decrypt said encrypted data file to form a decrypted data file when said decryption key is a desired second symmetric key; and
providing access to said decrypted data file.
19. The method of claim 18 further including decompressing said decrypted data file.
20. The method of claim 19 wherein said decompressing employs a Lempel-Ziv (LZ)-type data decompression algorithm.
21. The method of claim 19 wherein said decompressing employs a Deflate-type data decompression algorithm.
22. The method of claim 19 wherein said decompressing employs a Burrows-Wheeler Transform (BWT)-type data decompression algorithm.
23. The method of claim 18 wherein said decrypted data file is not decompressed.
24. The method of claim 18 wherein at least part of one of said first symmetric key and said second symmetric key is composed of random data.
25. The method of claim 24 wherein at least part of said first symmetric key is composed of a first set of random data and at least part of said second symmetric key is composed of a second set of random data.
26. The method of claim 25 wherein said first set of random data is not equal to said second set of random data.
27. The method of claim 18 wherein at least part of said decryption key is received from a user.
28. The method of claim 27 wherein at least part of said decryption key is a password.
29. The method of claim 18 wherein said desired first symmetric key input is different from said desired second symmetric key input.
30. The method of claim 18 wherein at least one of said first symmetric key and said second symmetric key has a key length of at least 128 bits.
31. The method of claim 18 wherein at least one of said first symmetric key and said second symmetric key has a key length of at least 192 bits.
32. The method of claim 18 wherein at least one of said first symmetric key and said second symmetric key has a key length of at least 256 bits.
33. The method of claim 18 wherein said symmetrically decrypting said encrypted data file uses an AES decryption decoding operation.
34. The method of claim 18 wherein said symmetrically decrypting said encrypted data file uses a 3DES decryption decoding operation.
35. A method of providing access to data in a data container, said method including:
receiving a data container designed for containing compressed files, said data container including:
first symmetric key data;
second symmetric key data; and
an encrypted data file,
wherein said first symmetric key data was derived by symmetrically encrypting, using a first symmetric key, an intermediate symmetric key that was used to encrypt said encrypted data file
wherein said second symmetric key data was derived by symmetrically encrypting, using a second symmetric key, said intermediate symmetric key that was used to encrypt said encrypted data file
receiving a decryption key input;
providing the option of:
using said first symmetric key data in combination with said decryption key input to recover said intermediate symmetric key to symmetrically decrypt said encrypted data file to form a decrypted data file when said decryption key is a desired first symmetric key; and
using said second symmetric key data in combination with said decryption key input to recover said intermediate symmetric key to symmetrically decrypt said encrypted data file to form a decrypted data file when said decryption key is a desired second symmetric key; and
providing access to said decrypted data file.
36. The method of claim 35 further including decompressing said decrypted data file.
37. The method of claim 36 wherein said decompressing employs a Lempel-Ziv (LZ)-type data decompression algorithm.
38. The method of claim 36 wherein said decompressing employs a Deflate-type data decompression algorithm.
39. The method of claim 36 wherein said decompressing employs a Burrows-Wheeler Transform (BWT)-type data decompression algorithm.
40. The method of claim 35 wherein said decrypted data file is not decompressed.
41. The method of claim 35 wherein at least part of one of said first symmetric key, said second symmetric key, and said intermediate symmetric key is composed of random data.
42. The method of claim 41 wherein at least part of said first symmetric key is composed of a first set of random data and at least part of said second symmetric key is composed of a second set of random data.
43. The method of claim 42 wherein said first set of random data is not equal to said second set of random data.
44. The method of claim 35 wherein at least part of said decryption key is received from a user.
45. The method of claim 44 wherein at least part of said decryption key is a password.
46. The method of claim 35 wherein said desired first symmetric key input is different from said desired second symmetric key input.
47. The method of claim 35 wherein at least one of said first symmetric key, said second symmetric key, and said intermediate symmetric key has a key length of at least 128 bits.
48. The method of claim 35 wherein at least one of said first symmetric key, said second symmetric key, and said intermediate symmetric key has a key length of at least 192 bits.
49. The method of claim 35 wherein at least one of said first symmetric key, said second symmetric key, and said intermediate symmetric key has a key length of at least 256 bits.
50. The method of claim 35 wherein said symmetrically decrypting said encrypted data file uses an AES decryption decoding operation.
51. The method of claim 35 wherein said symmetrically decrypting said encrypted data file uses a 3DES decryption decoding operation.
52. The method of claim 35 wherein said data container is constructed in accordance with a .Zip file format.
53. A method of providing access to data in a data container, said method including:
receiving a data container designed for containing compressed files, said data container including:
first symmetric key data;
second symmetric key data; and
an encrypted data file,
wherein said first symmetric key data was derived from a first symmetric key that was used to symmetrically encrypt said encrypted data file,
wherein said second symmetric key data was derived from a second symmetric key that was used to symmetrically encrypt said encrypted data file,
receiving a decryption key input;
providing the option of:
using said first symmetric key data in combination with said decryption key input to recover said first symmetric key to symmetrically decrypt said encrypted data file to form a decrypted data file when said decryption key is a desired first symmetric key; and
using said second symmetric key data in combination with said decryption key input to recover said second symmetric key to symmetrically decrypt said encrypted data file to form a decrypted data file when said decryption key is a desired second symmetric key; and
providing access to said decrypted data file.
54. The method of claim 53 further including decompressing said decrypted data file.
55. The method of claim 54 wherein said decompressing employs a Lempel-Ziv (LZ)-type data decompression algorithm.
56. The method of claim 54 wherein said decompressing employs a Deflate-type data decompression algorithm.
57. The method of claim 54 wherein said decompressing employs a Burrows-Wheeler Transform (BWT)-type data decompression algorithm.
58. The method of claim 53 wherein said decrypted data file is not decompressed.
59. The method of claim 53 wherein at least part of one of said first symmetric key and said second symmetric key is composed of random data.
60. The method of claim 59 wherein at least part of said first symmetric key is composed of a first set of random data and at least part of said second symmetric key is composed of a second set of random data.
61. The method of claim 60 wherein said first set of random data is not equal to said second set of random data.
62. The method of claim 53 wherein at least part of said decryption key is received from a user.
63. The method of claim 62 wherein at least part of said decryption key is a password.
64. The method of claim 53 wherein said desired first symmetric key input is different from said desired second symmetric key input.
65. The method of claim 53 wherein at least one of said first symmetric key and said second symmetric key has a key length of at least 128 bits.
66. The method of claim 53 wherein at least one of said first symmetric key and said second symmetric key has a key length of at least 192 bits.
67. The method of claim 53 wherein at least one of said first symmetric key and said second symmetric key has a key length of at least 256 bits.
68. The method of claim 53 wherein said symmetrically decrypting said encrypted data file uses an AES decryption decoding operation.
69. The method of claim 53 wherein said symmetrically decrypting said encrypted data file uses a 3DES decryption decoding operation.
70. The method of claim 53 wherein said data container is constructed in accordance with a .Zip file format.
Description
    BACKGROUND OF THE INVENTION
  • [0001]
    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.
  • [0002]
    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.
  • [0003]
    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.
  • [0004]
    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.
  • [0005]
    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.
  • [0006]
    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.
  • [0007]
    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 2459). 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.
  • [0008]
    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.
  • [0009]
    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.
  • [0010]
    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.
  • [0011]
    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.
  • SUMMARY OF THE INVENTION
  • [0012]
    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.
  • [0013]
    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.
  • [0014]
    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.
  • [0015]
    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.
  • [0016]
    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.
  • [0017]
    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.
  • [0018]
    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.
  • [0019]
    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.
  • [0020]
    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).
  • [0021]
    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.
  • [0022]
    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.
  • [0023]
    Various other features, objects, and advantages of the invention will be made apparent to those skilled in the art from the following detailed description, claims, and accompanying drawings.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • [0024]
    FIG. 1 is a record layout of a prior art .ZIP file prior to the present invention.
  • [0025]
    FIG. 2 is a record layout of a .ZIP file in accordance with the present invention.
  • DETAILED DESCRIPTION OF THE INVENTION
  • [0026]
    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.
  • [0027]
    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 attached hereto and 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.
  • [0028]
    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.
  • [0029]
    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.
  • [0030]
    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.
  • [0031]
    A new Decryption Header to be located immediately ahead of and adjacent to the compressed data stored for each file.
  • [0032]
    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.
  • [0033]
    When using these new fields for strongly encrypting files, the following actions are indicated.
  • [0034]
    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.
  • [0035]
    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.
  • [0036]
    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.
  • [0037]
    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.
  • [0038]
    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.
  • [0039]
    Record Definitions:
    New Decryption Header (NDH)
    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 Size 4 Original (uncompressed) size of
    the following data
    Decryption Info. variable Decryption Information
  • [0040]
    Decryption Information (details)
    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 password
    Element based encryption)
    Password 2 Size of random password validation data
    Validation Data (Includes CRC32 of PVD; >4) MUST
    size be 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
  • [0041]
    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.
  • [0042]
    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.
  • [0000]
    Flags
  • [0043]
    The following values are defined for the processing Flags.
    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
    DOUBLE_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 Specifies 3DES algorithm is used
    for MSK
  • [0044]
    Recipient List Element
    Size
    Value (bytes) Description
    Recipient 2 Combined size of Hash of Public
    Element size Key and Simple Key Blob
    Hash Hash Size Hash of Public Key
    Simple key Blob variable Simple Key Blob
  • [0045]
    New Decryption Central Record Extra Field (NDCEF)
    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
  • [0046]
    Simplified Recipient List Element
    Size
    Value (bytes) Description
    Hash Hash Hash of Public Key
    Size
  • [0047]
    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.
  • [0000]
    Process Flow:
  • [0048]
    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.
  • [0000]
    Encryption:
  • [0000]
    • 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
      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
      Generating Master Session Key (MSK)
    • 1. If MASTER_KEY3DES 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 (MSK)
    • 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
        Salt and/or Initialization Vector (IV)
    • 1. For algorithms that use both Salt and IV, Salt=IV
    • 2. IV can be completely random data and placed in front of Decryption Information
    • 3. Otherwise IV=CRC32+64-bit File Size
      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 IV1 to be used by the specified encryption algorithm.
      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 TV is used as is without any modifications.

      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
      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.
  • [0083]
    The following modifications are used for encrypting and decrypting multiple files.
  • [0000]
    Multi-File Encryption:
  • [0000]
    • 1. Generate MSK
    • 2. For each file follow Encryption steps.
      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
  • [0089]
    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.
  • [0090]
    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.
  • [0091]
    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.
Patent Citations
Cited PatentFiling datePublication dateApplicantTitle
US4041284 *7 Sep 19769 Aug 1977The United States Of America As Represented By The Secretary Of The NavySignal processing devices using residue class arithmetic
US4156922 *27 Jan 197829 May 1979Instytut Maszyn MatematyeznychDigital system for computation of the values of composite arithmetic expressions
US4377846 *7 Oct 198022 Mar 1983Hitachi, Ltd.Arithmetic unit for generating constants in an electronic computer of the microprogram-controlled type
US4521866 *17 Aug 19814 Jun 1985Petit Jean PDistributed arithmetic oversampling recursive digital filter
US4542453 *19 Feb 198217 Sep 1985Texas Instruments IncorporatedProgram patching in microcomputer
US4862167 *24 Feb 198729 Aug 1989Hayes Microcomputer Products, Inc.Adaptive data compression method and apparatus
US4891643 *15 Sep 19862 Jan 1990International Business Machines CorporationArithmetic coding data compression/de-compression by selectively employed, diverse arithmetic coding encoders and decoders
US4905297 *18 Nov 198827 Feb 1990International Business Machines CorporationArithmetic coding encoder and decoder system
US4933883 *3 May 198812 Jun 1990International Business Machines CorporationProbability adaptation for arithmetic coders
US4935882 *20 Jul 198819 Jun 1990International Business Machines CorporationProbability adaptation for arithmetic coders
US4939639 *15 Jun 19873 Jul 1990Northern Telecom LimitedMethod of facilitating computer sorting
US4947318 *15 Nov 19847 Aug 1990Hitachi, Ltd.Data processing security system for automatically transferring software protection data from removable store into internal memory upon mounting of stores
US4989000 *19 Jun 198929 Jan 1991Chevion Dan SData string compression using arithmetic encoding with simplified probability subinterval estimation
US5003307 *6 Oct 198926 Mar 1991Stac, Inc.Data compression apparatus with shift register search means
US5016009 *13 Jan 198914 May 1991Stac, Inc.Data compression apparatus and method
US5025258 *1 Jun 198918 Jun 1991At&T Bell LaboratoriesAdaptive probability estimator for entropy encoding/decoding
US5051745 *21 Aug 199024 Sep 1991Pkware, Inc.String searcher, and compressor using same
US5091955 *29 Jun 199025 Feb 1992Fujitsu LimitedVoice coding/decoding system having selected coders and entropy coders
US5099440 *5 Jan 199024 Mar 1992International Business Machines CorporationProbability adaptation for arithmetic coders
US5126739 *27 Nov 199030 Jun 1992Stac ElectronicsData compression apparatus and method
US5142283 *19 Jul 199025 Aug 1992International Business Machines CorporationArithmetic compression coding using interpolation for ambiguous symbols
US5146221 *27 Nov 19908 Sep 1992Stac, Inc.Data compression apparatus and method
US5179555 *21 Jan 199212 Jan 1993Microcom Systems, Inc.High speed data compression and transmission for wide area network connections in LAN/bridging applications
US5218700 *30 Jan 19908 Jun 1993Allen BeechickApparatus and method for sorting a list of items
US5298896 *15 Mar 199329 Mar 1994Bell Communications Research, Inc.Method and system for high order conditional entropy coding
US5404315 *30 Apr 19924 Apr 1995Sharp Kabushiki KaishaAutomatic sound gain control device and a sound recording/reproducing device including arithmetic processor conducting a non-linear conversion
US5414425 *9 May 19949 May 1995StacData compression apparatus and method
US5440504 *18 Feb 19948 Aug 1995Matsushita Electric Industrial Co., Ltd.Arithmetic apparatus for digital signal processor
US5481713 *6 May 19932 Jan 1996Apple Computer, Inc.Method and apparatus for patching code residing on a read only memory device
US5485411 *30 Nov 199316 Jan 1996Texas Instruments IncorporatedThree input arithmetic logic unit forming the sum of a first input anded with a first boolean combination of a second input and a third input plus a second boolean combination of the second and third inputs
US5493524 *24 Apr 199520 Feb 1996Texas Instruments IncorporatedThree input arithmetic logic unit employing carry propagate logic
US5506580 *6 Dec 19949 Apr 1996Stac Electronics, Inc.Data compression apparatus and method
US5517439 *2 Feb 199514 May 1996Matsushita Electric Industrial Co., Ltd.Arithmetic unit for executing division
US5532694 *7 Jul 19952 Jul 1996Stac Electronics, Inc.Data compression apparatus and method using matching string searching and Huffman encoding
US5535300 *2 Aug 19949 Jul 1996At&T Corp.Perceptual coding of audio signals using entropy coding and/or multiple power spectra
US5546080 *3 Jan 199413 Aug 1996International Business Machines CorporationOrder-preserving, fast-decoding arithmetic coding arithmetic coding and compression method and apparatus
US5592162 *23 Mar 19947 Jan 1997Digital Equipment International, Ltd.Interval width update process in the arithmetic coding method
US5594674 *27 Oct 199514 Jan 1997Digital Equipment CorporationCode point update device in the arithmetic coding method
US5596763 *30 Nov 199321 Jan 1997Texas Instruments IncorporatedThree input arithmetic logic unit forming mixed arithmetic and boolean combinations
US5600847 *7 Jun 19954 Feb 1997Texas Instruments IncorporatedThree input arithmetic logic unit with mask generator
US5627995 *1 Jun 19946 May 1997Alfred P. GnadingerData compression and decompression using memory spaces of more than one size
US5634065 *7 Jun 199527 May 1997Texas Instruments IncorporatedThree input arithmetic logic unit with controllable shifter and mask generator
US5640578 *30 Nov 199317 Jun 1997Texas Instruments IncorporatedArithmetic logic unit having plural independent sections and register storing resultant indicator bit from every section
US5654702 *16 Dec 19945 Aug 1997National Semiconductor Corp.Syntax-based arithmetic coding for low bit rate videophone
US5715470 *27 Sep 19933 Feb 1998Matsushita Electric Industrial Co., Ltd.Arithmetic apparatus for carrying out viterbi decoding at a high speed
US5734119 *19 Dec 199631 Mar 1998Invision Interactive, Inc.Method for streaming transmission of compressed music
US5734880 *7 Jun 199531 Mar 1998Texas Instruments IncorporatedHardware branching employing loop control registers loaded according to status of sections of an arithmetic logic unit divided into a plurality of sections
US5737345 *21 Aug 19957 Apr 1998Robert Bosch GmbhMethod for arithmetic decoding
US5745756 *24 Jun 199628 Apr 1998International Business Machines CorporationMethod and system for managing movement of large multi-media data files from an archival storage to an active storage within a multi-media server computer system
US5771355 *21 Dec 199523 Jun 1998Intel CorporationTransmitting electronic mail by either reference or value at file-replication points to minimize costs
US5774081 *11 Dec 199530 Jun 1998International Business Machines CorporationApproximated multi-symbol arithmetic coding method and apparatus
US5778374 *3 Aug 19957 Jul 1998International Business Machines CorporationCompressed common file directory for mass storage systems
US5781901 *21 Dec 199514 Jul 1998Intel CorporationTransmitting electronic mail attachment over a network using a e-mail page
US5857035 *19 May 19975 Jan 1999Hewlett-Packard CompanyArithmetic coding compressor for encoding multiple bit values
US5867600 *8 Nov 19962 Feb 1999Nec CorporationImage coding method and system for providing reduced bit rate arithmetic codes
US5881225 *14 Apr 19979 Mar 1999Araxsys, Inc.Security monitor for controlling functional access to a computer system
US5903723 *21 Dec 199511 May 1999Intel CorporationMethod and apparatus for transmitting electronic mail attachments with attachment references
US5907703 *8 May 199625 May 1999Mijenix CorporationDevice driver for accessing computer files
US5911776 *18 Dec 199615 Jun 1999Unisys CorporationAutomatic format conversion system and publishing methodology for multi-user network
US5912636 *26 Sep 199615 Jun 1999Ricoh Company, Ltd.Apparatus and method for performing m-ary finite state machine entropy coding
US5918002 *14 Mar 199729 Jun 1999Microsoft CorporationSelective retransmission for efficient and reliable streaming of multimedia packets in a computer network
US5926208 *6 Sep 199620 Jul 1999Noonen; MichaelVideo compression and decompression arrangement having reconfigurable camera and low-bandwidth transmission capability
US5937188 *16 May 199510 Aug 1999British Telecommunications Public Limited CompanyInstruction creation device
US6018747 *26 Nov 199725 Jan 2000International Business Machines CorporationMethod for generating and reconstructing in-place delta files
US6028541 *12 Mar 199822 Feb 2000Liquid Audio Inc.Lossless data compression with low complexity
US6032200 *30 Sep 199629 Feb 2000Apple Computer, Inc.Process scheduling for streaming data through scheduling of disk jobs and network jobs and the relationship of the scheduling between these types of jobs
US6041147 *15 Oct 199621 Mar 2000Hughes Electronics CorporationContent-based indexing of images by coding levels defined as a function of reduced entropy
US6043763 *12 Mar 199828 Mar 2000Liquid Audio, Inc.Lossless data compression with low complexity
US6049630 *27 Oct 199711 Apr 2000America Online, Inc.Data compression using adaptive bit allocation and hybrid lossless entropy encoding
US6049671 *18 Apr 199611 Apr 2000Microsoft CorporationMethod for identifying and obtaining computer software from a network computer
US6061732 *30 Apr 19989 May 2000U. S. Philips CorporationData streaming system utilizing an asynchronous technique for retrieving data from a stream server
US6078921 *3 Mar 199820 Jun 2000Trellix CorporationMethod and apparatus for providing a self-service file
US6083279 *10 Oct 19964 Jul 2000International Business Machines CorporationPlatform independent technique for transferring software programs over a network
US6088717 *31 Aug 199811 Jul 2000Onename CorporationComputer-based communication system and method using metadata defining a control-structure
US6091777 *26 May 199818 Jul 2000Cubic Video Technologies, Inc.Continuously adaptive digital video compression system and method for a web streamer
US6094453 *16 Jan 199725 Jul 2000Digital Accelerator CorporationDigital data compression with quad-tree coding of header file
US6098163 *30 Nov 19931 Aug 2000Texas Instruments IncorporatedThree input arithmetic logic unit with shifter
US6112211 *25 Nov 199729 Aug 2000International Business Machines CorporationReconfiguration an aggregate file including delete-file space for optimal compression
US6173317 *14 Mar 19979 Jan 2001Microsoft CorporationStreaming and displaying a video stream with synchronized annotations over a computer network
US6173394 *11 Aug 19999 Jan 2001Texas Instruments IncorporatedInstruction having bit field designating status bits protected from modification corresponding to arithmetic logic unit result
US6188334 *5 May 200013 Feb 2001At&T Corp.Z-coder: fast adaptive binary arithmetic coder
US6195026 *14 Sep 199827 Feb 2001Intel CorporationMMX optimized data packing methodology for zero run length and variable length entropy encoding
US6198412 *20 Jan 19996 Mar 2001Lucent Technologies Inc.Method and apparatus for reduced complexity entropy coding
US6217234 *7 Jun 199517 Apr 2001Discovision AssociatesApparatus and method for processing data with an arithmetic unit
US6225925 *13 Mar 19981 May 2001At&T Corp.Z-coder: a fast adaptive binary arithmetic coder
US6229463 *15 Mar 19998 May 2001U.S. Philips CorporationArithmetic encoding/decoding of a multi-channel information signal
US6233017 *30 Jun 199715 May 2001Microsoft CorporationMultimedia compression system with adaptive block sizes
US6236341 *16 Mar 200022 May 2001Lucent Technologies Inc.Method and apparatus for data compression of network packets employing per-packet hash tables
US6275848 *21 May 199714 Aug 2001International Business Machines Corp.Method and apparatus for automated referencing of electronic information
US6345288 *15 May 20005 Feb 2002Onename CorporationComputer-based communication system and method using metadata defining a control-structure
US6356937 *6 Jul 199912 Mar 2002David MontvilleInteroperable full-featured web-based and client-side e-mail system
US6381742 *19 Jun 199830 Apr 2002Microsoft CorporationSoftware package management
US6415435 *18 Mar 19992 Jul 2002International Business Machines CorporationMethod and apparatus for determining compatibility of parent classes in an object oriented environment using versioning
US6434561 *9 May 199813 Aug 2002Neomedia Technologies, Inc.Method and system for accessing electronic resources via machine-readable data on intelligent documents
US6526574 *15 Jul 199825 Feb 2003Pocket Soft, Inc.System for finding differences between two computer files and updating the computer files
US6546417 *27 Jun 20008 Apr 2003Intellinet, Inc.Enhanced electronic mail system including methods and apparatus for identifying mime types and for displaying different icons
US6594822 *8 Jun 200015 Jul 2003Nortel Networks LimitedMethod and apparatus for creating a software patch by comparing object files
US6914985 *14 Dec 19995 Jul 2005International Business Machines CorporationMethod and system for presentation and manipulation of PKCS enveloped-data objects
US6934836 *27 Dec 200123 Aug 2005Protasis CorporationFluid separation conduit cartridge with encryption capability
Referenced by
Citing PatentFiling datePublication dateApplicantTitle
US9246889 *12 Aug 201026 Jan 2016Google Technology Holdings LLCLayered protection and validation of identity data delivered online via multiple intermediate clients
US20110213957 *12 Aug 20101 Sep 2011General Instrument CorporationLayered protection and validation of identity data delivered online via multiple intermediate clients
Classifications
U.S. Classification713/170
International ClassificationH04L9/06, H03M7/40, H04L9/28, H04L9/32, G06F12/14, G06F7/00, H04L9/00, H04L9/30, H04K1/00, H03M7/30, G06F21/00, G06F11/30
Cooperative ClassificationG06F17/30153, G06F21/6218, H04L2209/30, G06F2221/2153, G06F2221/2107, G06F21/6209, H04L9/088
European ClassificationG06F21/62B, H04L9/00
Legal Events
DateCodeEventDescription
17 Jan 2005ASAssignment
Owner name: PKWARE, INC., WISCONSIN
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:PETERSON, JAMES C.;REEL/FRAME:015599/0624
Effective date: 20050107
18 Aug 2009ASAssignment
Owner name: MARANON CAPITAL, L.P., AS AGENT, ILLINOIS
Free format text: SECURITY AGREEMENT;ASSIGNOR:PKWARE, INC.;REEL/FRAME:023107/0510
Effective date: 20090817
Owner name: MARANON CAPITAL, L.P., AS AGENT,ILLINOIS
Free format text: SECURITY AGREEMENT;ASSIGNOR:PKWARE, INC.;REEL/FRAME:023107/0510
Effective date: 20090817
19 Aug 2009ASAssignment
Owner name: MARANON CAPITAL, L.P., AS AGENT, ILLINOIS
Free format text: SECURITY AGREEMENT;ASSIGNOR:PKWARE, INC.;REEL/FRAME:023107/0952
Effective date: 20090817
Owner name: MARANON CAPITAL, L.P., AS AGENT,ILLINOIS
Free format text: SECURITY AGREEMENT;ASSIGNOR:PKWARE, INC.;REEL/FRAME:023107/0952
Effective date: 20090817
23 Dec 2010ASAssignment
Owner name: PKWARE, INC., WISCONSIN
Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:MARANON CAPITAL, L.P., AS AGENT;REEL/FRAME:025525/0230
Effective date: 20101217
Owner name: PKWARE, INC., WISCONSIN
Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:MARANON CAPITAL, L.P., AS AGENT;REEL/FRAME:025525/0223
Effective date: 20101217