A COMPUTER-IMPLEMENTED METHOD AND SYSTEM FOR EMBEDDING AND AUTHENTICATING ANCILLARY INFORMATION IN DIGITALLY SIGNED CONTENT
A computer-implemented system and method for embedding and authenticating ancillary information in digitally signed content are disclosed. The method and system include loading digital content containing a digitally signed executable into memory for execution, while checking for the integrity of a digital signature and the contents of the executable; and erasing any non-authenticated regions of the digital content by zeroing out or value-filling memory locations corresponding to the non-authenticated regions.
This application is a continuation-in-part of U.S. patent application Ser. No. 11/395,194, filed Mar. 31, 2006, entitled, “A Computer-Implemented Method and System for Embedding Ancillary Information Into the Header of a Digitally Signed Executable,” which claims the benefit of the filing date of U.S. Provisional Patent Application Ser. No. 60/683,190, filed May 20, 2005, and entitled, “Method and Apparatus for Tracking Digitally Signed Files for Digital Distribution,” all of which are incorporated herein by reference.
BACKGROUND1. Technical Field
This disclosure relates to distribution of digital content. More particularly, the present disclosure relates to embedding and authenticating ancillary information in digitally signed content.
2. Related Art
The advent of digital distribution has created new business models for the delivery of software over the internet. In the “try and buy” a digital distribution model, consumers may sample “try and buy” versions of software before making a purchase decision. Such “try and buy” versions consist of locked down versions of software executables that get unlocked after purchase. In a common scenario, an end-user or potential customer may download a freely available, “try and buy” software application (the installer, henceforth) from the publisher website or general-purpose web portals (e.g. www.download.com, www.yahoo.com, etc., portals, henceforth). Typically, a percentage of the users that download and install the “try and buy” installers purchase the software (or services, or subscriptions associated with it) to obtain a full version of the software product. As such, software manufacturers have an incentive to make “try and buy” software available for download by end-users. Software manufacturers do so by placing such “try and buy” versions on their own websites for end users to download. In addition, software manufacturers may distribute these installers across portals, that are not necessarily controlled by software manufacturers. The motivation behind the “try and buy” business model for the software publishers lies in the fact that they get compensated when the consumer makes a purchase related to the “try and buy” software. In addition, portals arrange business deals with software manufacturers, publishers, or aggregators so that the portals are compensated when “try and buy” installers are downloaded from the portal sites and generate revenue. Typically, portals get a revenue share of the price paid by the consumer.
The “try and buy” installers contain means for end users to purchase the full version of the software application. As part of the purchase transaction, the end-users may be instructed to perform various steps in the online purchase transaction. Such instructions may include, for example, 1) textual descriptions to complete an economic transaction, e.g. send a check to P.O. Box xyz, and receive instructions to obtain the full version of the software application, 2) a URL that contains instructions or means for carrying out online e-commerce transactions (e.g. credit card payments), 3) a purchase mechanism built into the application itself, 4) a purchase mechanism built into a wrapper around the software application, or 5) any combination of these instructions. Because the same software product is normally distributed across multiple distribution networks (e.g. multiple portals), a way of tracking, which distribution network was responsible for a particular purchase is required. One way of determining which distribution network was responsible for a particular purchase is to create traceable versions of the software product. One way of creating traceable versions consists of creating different installers that contain information to identify the distribution network in the purchase instructions. For example, a software product may have a purchase URL embedded containing a value identifying a particular distribution network, for example:
http://my.trymedia.com/buy?sku=0123&affiliate=abc
Such a URL can be used for software distribution across a distribution network identified by the parameter, “affiliate=abc”. If the same software product is to be distributed across another distribution network (e.g. “affiliate=xyz”), then another version of the same software product must be created having a purchase URL embedded that identifies the other distribution network, for example:
http://my.trimedia.com/buv?sku=0123&affiliate=xyz
Software publishers may create different, traceable versions of a software product by a variety of means that are known to those of ordinary skill in the art. For example, 1) recompiling the software executables containing different ancillary information to identify a distribution channel, 2) including such information in an auxiliary file, resource, or data referenced by the instructions of the purchasing process, or 3) any combination of the above. In most cases, it is advisable to create different traceable versions of the same software product without involving the software manufacturer, so the process can be scaled as efficiently as possible. One possible way to do so is to embed distribution related information in a predefined location in the installer or in a predefined location in the registry of a filesystem when an installer is first executed. One benefit of the embedding distribution related information in the installer is that this method does not require the software manufacturer to create a specific version of the software for each distribution network. Nevertheless, creating and managing different installers for each of a growing number of distribution networks has become a very difficult task.
The introduction of digital signatures in executables provides security benefits for software manufacturers and end-users. For end users, digital signatures of executables provide a tool to ensure that the executable has not been modified in any way since it was signed, typically by the software manufacturer. For software manufacturers, the benefit translates in less chances of having their software modified or altered without permission (e.g. by a computer virus that infects the executable), resulting in less support calls and more user confidence in the software. In the Microsoft™ Windows operating system executables, digital signatures are implemented in the form of certificates. In the header of an executable, a certificate table is provided, which contains information to access various attributes of the digital certificate. Once the software manufacturer has signed an executable file, the contents of the executable cannot be easily changed without rendering the certificate invalid or causing the digital signature of the file to mismatch with the digital certificate of the file. In addition, the growing threats of viruses, spyware, and other malware is making operating systems and Internet browser vendors more likely to issue warnings when executable files are not digitally signed. This will surely result in further adoption and widespread use of digital signatures with executables.
However, as described above, it is inefficient to create different versions of software products for different distribution networks. Further, it is very difficult to modify the contents of executables without destroying the integrity of the digital signature of the executable. As such, it is very difficult for someone other than a software manufacturer to create traceable copies of software products; because modifying the ancillary distribution-related information for a traceable copy would invalidate the digital signature.
Thus, a computer-implemented system and method for embedding and authenticating ancillary information in digitally signed content are needed.
Embodiments illustrated by way of example and not limitation in the figures of the accompanying drawings, in which:
A computer-implemented system and method for embedding and authenticating ancillary information in digitally signed content are disclosed. In the following description, numerous specific details are set forth. However, it is understood that embodiments may be practiced without these specific details. In other instances, well-known processes, structures and techniques have not been shown in detail in order not to obscure the clarity of this description.
Referring to
The use of digital signatures in downloaded executables is becoming increasingly more common. However, once the software manufacturer has signed an executable file, the contents of the executable cannot be easily changed without rendering the certificate invalid or causing the digital signature of the file to mismatch with the digital certificate of the file. As such, it has become difficult to insert ancillary information into the installer for a particular software product download. Nevertheless, various embodiments described herein solve this problem, as will be described in more detail below.
Referring to
Referring to
In an alternative embodiment, the data in CRC block 510 can be overwritten with ancillary data. Because the CRC value in block 510 is not included in the computation of digital signature 520, the modification of the CRC data in block 510 does not invalidate digital signature 520. However, the size of CRC block 510 is very restrictive. In typical implementations of the structure of file 501, a very small amount of information can be stored in block 510. A pointer, link, or index to a larger block of ancillary data could be stored in block 510, such ancillary data being stored in a local or remote location (e.g. a server)
Referring to
An optional data storage device 228 such as a magnetic disk or optical disk and its corresponding drive may also be coupled to computer system 200 for storing information and instructions. Computer system 200 can also be coupled via bus 216 to a display device 204, such as a cathode ray tube (CRT) or a liquid crystal display (LCD), for displaying information to a computer user. For example, image, textual, video, or graphical depictions of information may be presented to the user on display device 204. Typically, an alphanumeric input device 208, including alphanumeric and other keys is coupled to bus 216 for communicating information and/or command selections to processor 220. Another type of user input device is cursor control device 206, such as a conventional mouse, trackball, or other type of cursor direction keys for communicating direction information and command selection to processor 220 and for controlling cursor movement on display 204.
A communication device 226 may also be coupled to bus 216 for accessing remote computers or servers, such as a web server, or other servers via the Internet, for example. The communication device 226 may include a modem, a network interface card, or other well-known interface devices, such as those used for interfacing with Ethernet, Token-ring, wireless, or other types of networks. In any event, in this manner, the computer system 200 may be coupled to a number of servers via a conventional network infrastructure.
The system of an example embodiment includes software, information processing hardware, and various processing steps, as described above. The features and process steps of example embodiments may be embodied in machine or computer executable instructions. The instructions can be used to cause a general purpose or special purpose processor, which is programmed with the instructions to perform the steps of an example embodiment. Alternatively, the features or steps may be performed by specific hardware components that contain hard-wired logic for performing the steps, or by any combination of programmed computer components and custom hardware components. While embodiments are described with reference to the Internet, the method and apparatus described herein is equally applicable to other network infrastructures or other data communications systems.
It should be noted that the methods described herein do not have to be executed in the order described, or in any particular order. Moreover, various activities described with respect to the methods identified herein can be executed in repetitive, simultaneous, recursive, serial, or parallel fashion. Information, including parameters, commands, operands, and other data, can be sent and received in the form of one or more carrier waves through communication device 226.
Upon reading and comprehending the content of this disclosure, one of ordinary skill in the art will understand the manner in which a software program can be launched from a computer-readable medium in a computer-based system to execute the functions defined in the software program described above. One of ordinary skill in the art will further understand the various programming languages that may be employed to create one or more software programs designed to implement and perform the methods disclosed herein. The programs may be structured in an object-orientated format using an object-oriented language such as Java, Smalltalk, or C++. Alternatively, the programs can be structured in a procedure-orientated format using a procedural language, such as assembly or C. The software components may communicate using any of a number of mechanisms well known to those of ordinary skill in the art, such as application program interfaces or inter-process communication techniques, including remote procedure calls. The teachings of various embodiments are not limited to any particular programming language or environment, including HTML and XML.
Thus, other embodiments may be realized. For example,
Various embodiments are described. In particular, the use of embodiments with various types and formats of user interface presentations may be described. It will be apparent to those of ordinary skill in the art that alternative embodiments of the implementations described herein can be employed and still fall within the scope of the claims set forth below. In the detail herein, various embodiments are described as implemented in computer-implemented processing logic denoted sometimes herein as the “Software”. As described above, however, the claimed invention is not limited to a purely software implementation.
As described above, ancillary data can be embedded within a signed executable file, the ancillary data being modifiable without breaking the already existing digital signature. The technique described above involved embedding such ancillary data into the digital signature directory, which is not computed as a part of the verified message. As a result, the described technique provides an effective way of individualizing installers for digital distribution at the time of download (or manufacture) with ancillary information (e.g. the source of distribution, etc.). One benefit of the described technique is that ancillary information can be dynamically injected into the executable at download time. This allows tracking of the distribution channels in a digital distribution business model consisting of multiple distributors. In such a business model, it is very desirable to be able to identify the source of a particular file to be able to compensate such source in the event of monetary or advertisement transactions or events related to a particular file. It is also very desirable for a digital distribution provider to store just one version of the downloadable assets and to create a tagged copy of such assets in an efficient manner. Dynamic (affiliate) tracking allows one to efficiently create a distribution network in which a single copy of a digital asset can be dynamically personalized at download or fulfillment time to identify the source distribution for crediting, reporting or tracking purposes.
U.S. Pat. Nos. 5,892,904 and 6,367,012 describe a method to ensure the authenticity and integrity of a computer program or code received over a computer network. However, the methods described in the referenced patents do not ensure the authenticity and integrity of the transmitted executable file, which contains the signed program or code, the digital signature, and possibly some other data and padding.
For example, the Microsoft Windows operating system implements signed executables by adding an, “Attribute Certificate Table” and a, “Certificate Data” section containing the Authenticode signature. The image hash used to generate the Authenticode signature is generated from all sections in the file, except (according to Microsoft documentation) the following sections:
-
- i. The file checksum field of the Windows-specific fields of the optional header;
- ii. Information related to attribute certificates; and
- iii. Information located in a section past the end of the last section.
Because the image hash used to generate the Authenticode signature is not generated from the sections in the file referenced above (denoted herein as non-authenticated sections), modifications to these non-authenticated sections will not change or affect the hash and this will not affect the Authenticode signature. Thus, the authenticity and integrity of the transmitted executable file can be affected in the non-authenticated sections if the file or transmission without affecting the Authenticode signature of the file. In fact, the invention disclosed in published U.S. Patent Application No. 20060265591 exploits this fact to effectively change the executable file or transmission in useful ways without breaking the digital signature.
In various embodiments described in detail below, the authenticity and integrity of a file or transmission containing a digitally signed executable is verified by checking the regions of the file or transmission that are not included in the generation of the file or transmission's digital signature (i.e. the non-authenticated regions). A process described below is used to verify that the non-authenticated regions do not contain non-required data and that required data in the non-authenticated regions has unequivocally specified values.
This verification of the content of the non-authenticated regions can be performed by the operating system resident in the machine receiving the transmission or manipulating the file, 1) when the file or transmission's digital signature is verified, 2) when the file or transmission is downloaded, or 3) at execution time by the executable file itself. If the verification process is performed at execution time by the executable file itself, the execution of the executable file is terminated if the verification should fail. Although performing the verification process at execution time by the executable file itself may not be an ideal solution in all circumstances, the process may be safe enough for many applications; because, the executable code is properly protected by the existing digital signature.
In a particular embodiment described in detail below, the authenticity and integrity of a file or transmission containing a digitally signed executable is verified using an implementation for Microsoft Windows PE (Portable Executable) files. In this particular embodiment, the verification process may include the following operations:
-
- i. Check and verify that the checksum field in the Windows-specific fields of the optional header matches the image file checksum;
- ii. Check and verify to make sure there is no information past the end of the last section of the file or transmission;
- iii. Check and verify to make sure the attribute certificate table contains one single entry and does not contain padding or padding with fixed data; and
- iv. Check and verify to make sure the certificate actually fills the whole space allocated to it in the attribute certificate table, except for possible fixed-data padding to the next octaword boundary.
The verification process described above may require changes to the Portable Executable standard already deployed in millions of executables for consumption and binary creation or modification tools (e.g. forensic tools, linkers, compilers, etc.). As a result of such potentially needed changes to the Portable Executable standard, the verification process described above may not be optimal for some applications.
In another particular embodiment described in detail below, the authenticity and integrity of a file or transmission containing a digitally signed executable is verified using an implementation for Microsoft Windows PE (Portable Executable) files. In this particular embodiment, an operating system (OS) vendor or provider (e.g. Microsoft) can implement a verification process to mitigate or eliminate the security risk of executing a digitally signed file or transmission that contains non-authenticated regions. In this embodiment, the verification process prevents or monitors access to the non-authenticated regions when the executable is loaded into memory. The verification process of a particular embodiment may include the following operations:
-
- i. Load a file or transmission containing a digitally signed executable into memory for execution, while checking for the integrity of the digital signature and the contents of the executable;
- ii. Erase any non-authenticated regions of the file or transmission by zeroing out or value-filling the memory locations of the non-authenticated regions; and
- iii. Optionally, virtualize access to the contents of such executable file on disk and erase any non-authenticated regions of the virtualized file or transmission as described above. The virtualizing of the access to the contents of such executable file can be performed if the executable attempts to load itself (e.g. or from another executable module related to it, such as a DLL or COM object) using file input/output calls such as Win32 CreateFile.
In another particular embodiment described in detail below, the authenticity and integrity of a file or transmission containing a digitally signed executable is verified using an implementation for Microsoft Windows PE (Portable Executable) files. In this particular embodiment, an operating system (OS) vendor or provider (e.g. Microsoft) can implement a verification process to mitigate or eliminate the security risk of executing a digitally signed file or transmission that contains non-authenticated regions. In this embodiment, the verification process prevents or monitors access to the non-authenticated regions when the executable is loaded into memory. The verification process of a particular embodiment may include the following operations:
-
- i. Virtualize access to the contents of a digitally signed executable file on disk; and
- ii. Erase, for the virtualized files in memory, any non-authenticated regions of the file or transmission by zeroing out or value-filling the locations of the virtualized files corresponding to the contents of the non-authenticated regions, including:
- 1. The checksum field of the Windows-specific fields of the optional header;
- 2. Information past the end of the last section of the file or transmission;
- 3. Information related to attribute certificates; and
- 4. Locations where the certificate does not fill the whole space allocated to it in the attribute certificate table.
Referring to
Thus, a computer-implemented system and method for embedding and authenticating ancillary information in digitally signed content are disclosed. While the present invention has been described in terms of several example embodiments, those of ordinary skill in the art will recognize that the present invention is not limited to the embodiments described, but can be practiced with modification and alteration within the spirit and scope of the appended claims. The description herein is thus to be regarded as illustrative instead of limiting.
Claims
1. A method comprising:
- loading digital content containing a digitally signed executable into memory for execution, while checking for the integrity of a digital signature and the contents of the executable; and
- erasing any non-authenticated regions of the digital content by zeroing out or value-filling memory locations corresponding to the non-authenticated regions.
2. The method as claimed in claim 1 wherein the non-authenticated regions of the digital content include regions past the end of the last section of the digital content.
3. The method as claimed in claim 1 including verifying that a checksum field in a header of the digital content matches an image file checksum.
4. The method as claimed in claim 1 including verifying that the attribute certificate table contains one single entry and does not contain padding.
5. The method as claimed in claim 1 including verifying that the digital signature actually fills the whole space allocated to the digital signature in an attribute certificate table.
6. The method as claimed in claim 1 wherein the digital content is a file.
7. The method as claimed in claim 1 wherein the digital content is a digital transmission.
8. The method as claimed in claim 1 including virtualizing access to the digital content and erasing any non-authenticated regions of the virtualized digital content.
9. The method as claimed in claim 1 wherein the erasing is performed by a loader.
10. The method as claimed in claim 1 wherein the erasing is performed by the executable.
11. An article of manufacture embodied in a machine storage medium including data that, when accessed by a machine, causes the machine to:
- load digital content containing a digitally signed executable into memory for execution, while checking for the integrity of a digital signature and the contents of the executable; and
- erase any non-authenticated regions of the digital content by zeroing out or value-filling memory locations corresponding to the non-authenticated regions.
12. The article of manufacture as claimed in claim 11 wherein the non-authenticated regions of the digital content include regions past the end of the last section of the digital content.
13. The article of manufacture as claimed in claim 11 being further operable to verify that a checksum field in a header of the digital content matches an image file checksum.
14. The article of manufacture as claimed in claim 11 being further operable to verify that the attribute certificate table contains one single entry and does not contain padding.
15. The article of manufacture as claimed in claim 11 being further operable to verify that the digital signature actually fills the whole space allocated to the digital signature in an attribute certificate table.
16. The article of manufacture as claimed in claim 11 wherein the digital content is a file.
17. The article of manufacture as claimed in claim 11 wherein the digital content is a digital transmission.
18. The article of manufacture as claimed in claim 11 being further operable to virtualize access to the digital content and erase any non-authenticated regions of the virtualized digital content.
19. The article of manufacture as claimed in claim 11 wherein the erasing is performed by a loader.
20. The article of manufacture as claimed in claim 11 wherein the erasing is performed by the executable.
21. A method comprising:
- loading digital content containing a digitally signed executable into memory for execution, while checking for the integrity of a digital signature and the contents of the executable; and
- performing verification operations on the executable to verify integrity of the executable.
22. The method as claimed in claim 21 wherein the verification operations include a checksum verification.
23. The method as claimed in claim 21 wherein the verification operations include verifying that there is no information past the end of the last section of the executable.
24. The method as claimed in claim 21 wherein the verification operations include verifying that an attribute certificate table contains one single entry and does not contain padding or padding with fixed data.
25. The method as claimed in claim 21 wherein the verification operations include verifying that a certificate actually fills the whole allocated space in an attribute certificate table.
26. An article of manufacture embodied in a machine storage medium including data that, when accessed by a machine, causes the machine to:
- load digital content containing a digitally signed executable into memory for execution, while checking for the integrity of a digital signature and the contents of the executable; and
- perform verification operations on the executable to verify integrity of the executable.
27. The article of manufacture as claimed in claim 26 wherein the verification operations include a checksum verification.
28. The article of manufacture as claimed in claim 26 wherein the verification operations include verifying that there is no information past the end of the last section of the executable.
29. The article of manufacture as claimed in claim 26 wherein the verification operations include verifying that an attribute certificate table contains one single entry and does not contain padding or padding with fixed data.
30. The article of manufacture as claimed in claim 26 wherein the verification operations include verifying that a certificate actually fills the whole allocated space in an attribute certificate table.
Type: Application
Filed: Feb 14, 2008
Publication Date: Jun 5, 2008
Inventors: Andres M. Torrubia (Alicante), Jordi Salvat (Alicante)
Application Number: 12/031,104
International Classification: H04L 9/00 (20060101);