KR101085365B1 - Computer-implemented methods and systems for embedding and authenticating supplemental information in digitally signed content - Google Patents

Abstract

Disclosed are a computer-implemented system and method for embedding and authenticating supplemental information in digitally signed content. The method and system checks for digital signature of the digitally signed executable file and the integrity of the content, while loading digital content including the digitally signed executable file into memory for execution, and non-authentication. Erasing any unauthorized regions of the digital content by reducing or filling in memory locations corresponding to the encrypted regions.

Description

COMPATER-IMPLEMENTED METHOD AND SYSTEM FOR EMBEDDING AND AUTHENTICATING ANCILLARY INFORMATION IN DIGITALLY SIGNED CONTENT}

The present invention relates to the distribution of digital content. More specifically, the present invention relates to embedding and authenticating supplemental information in digitally signed content.

The advent of digital distribution has created new business models for delivering software over the Internet. In the "try and buy" digital distribution model, consumers can sample "trial and buy" software versions before making a purchase decision. Such "trial-and-purchase" versions consist of locked versions of executable software that are unlocked after purchase. In a typical scenario, an end-user or potential consumer may use a freely available "Try and Buy" software application (hereinafter referred to as an installer) to a publisher's website or general purpose web portals (eg www.download.com). , www.yahoo.com, etc., below portals). Typically, a few percent of users downloading and installing "Try and Buy" installers purchase the software (or services or subscriptions associated with it) to obtain a complete version of the software product. As such, software authors have encouraged the availability of "Try and Buy" software for download by end-users. Software makers are doing so by placing such "Try and Buy" versions on their own websites for end users to download. In addition, software producers can distribute these installers through portals that are not necessarily controlled by the software producers. The motivation behind the "Try and Buy" business model for software publishers lies in the fact that they are rewarded when consumers purchase "Try and Buy" software. In addition, portals may conduct business transactions with software producers, publishers, or website aggregators to ensure that portals are rewarded when "trial-and-purchase" installers are downloaded from portal sites and generate revenue. Agree. Typically, portals share the revenue of the price paid by the consumer.

"Try and Buy" installers include a means for end users to purchase a complete version of a software application. As part of a purchase transaction, end-users are instructed to perform various steps in the online purchase transaction. Such instructions may include, for example, 1) text descriptions for completing an economic transaction, for example, sending a check to the post office mailbox xyz and receiving instructions to obtain a complete version of the software application, 2) online electronics. A URL containing instructions or means (eg, credit card payments) for performing commerce, 3) a purchase mechanism embedded in the application itself, 4) a purchase mechanism embedded in a wrapper of the software application, Or 5) any combination of these instructions. Since the same software product is normally distributed across multiple distribution networks (eg, multiple portals), a method of tracking which distribution network was responsible for a particular purchase is required. One way to determine which distribution network was responsible for a particular purchase is to create trackable versions of the software product. One method of generating trackable versions consists of creating different installers that contain information for identifying the distribution network in purchase instructions. For example, a software product may include a purchase URL that includes a value identifying a particular distribution network, for example,

It may be embedded at http://my.trymedia.com/buy?sku=0123&affiliate=abc .

Such a URL can be used for software distribution via the distribution network identified by the parameter, " affiliate = abc ". If the same software product is distributed through another distribution network (for example, " affiliate = xyz "), another version of the same software product may be a purchase URL that identifies another distribution network, for example,

http://my.trymedia.com/buy?sku-0123&affiliate=xyz should be created to be embedded.

Software publishers may generate different, traceable versions of a software product by various means known to those skilled in the art. For example: 1) recompiling software executables containing different supplemental information for identifying a distribution channel, 2) supplemental files, resources, or resources referenced by the instructions of the purchasing process, or Including such information in the data, or 3) any combination of the above. In most cases, it is desirable to create different traceable versions of the same software product without involving the software producer, so that the process can be scaled as efficiently as possible. One possible way to do so is to embed distribution related information at a predefined location in the installer or at a predefined location in the registry of the filesystem when the installer is first run. One advantage of embedding distribution related information in the installer is that this method does not require the software producer 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 very difficult.

The introduction of digital signatures in executable files provides security benefits for software producers and end-users. For end users, the digital signatures of the executable provide a tool to ensure that the executable does not change in any way because the executable is typically signed by the software manufacturer. For software authors, the benefit is translated into a form that reduces the likelihood that their software will be modified or changed without approval (eg, by a computer virus infecting the executable), resulting in fewer support calls and software. Leads to more user confidence. In Microsoft's Windows operating system executables, digital signatures are implemented in the form of a public certificate. In the header of the executable file, a public certificate table is provided, which contains information for accessing various attributes of the digital public certificate. When a software producer signs an executable file, the contents of the executable file cannot be easily changed without invalidating the public certificate or rendering the executable's digital signature mismatched with the digital public certificate of the executable file. In addition, when the executables are not digitally signed, the increasing risk of viruses, spyware and other malware will cause operating systems and Internet browser vendors to issue warnings. This will certainly lead to further introduction and widespread use of digital signatures with executable files.

However, as mentioned above, creating different versions of software products for different distribution networks is inefficient. In addition, it is very difficult to change the contents of executable files without breaking the integrity of the digital signature of the executable file. As such, since changing the secondary distribution-related information for the trackable copy would invalidate the digital signature, it is very difficult for anyone other than the software producer to create trackable copies of the software product.

Accordingly, what is needed is a computer-implemented system and method for embedding and authenticating supplemental information in digitally signed content.

Computer-implemented systems and methods are provided for embedding and authenticating supplemental information in digitally signed content.

1 illustrates an embodiment in which auxiliary information is stored in a header portion of an executable file.
2 illustrates examples of three different installers with different auxiliary data in executable code blocks of each of the three different installers.
3 illustrates an example of how distribution on various distribution networks is accomplished in various embodiments.
4 illustrates a typical structure of a digitally signed executable file.
5 illustrates a modified digitally signed executable file in accordance with various embodiments.
6 is a flow diagram illustrating basic processing operations performed in an embodiment.
7A and 7B are block diagrams of a computing system in which embodiments may operate and to which embodiments may belong.
8 and 9 are flow diagrams illustrating basic processing operations performed in an example embodiment.

Embodiments are illustrated by way of example and are not limited to the shapes of the accompanying drawings.

A computer-implemented system and method for embedding and authenticating supplemental information in digitally signed content is disclosed. In the following description, numerous specific details are set forth. However, it should be understood that embodiments may be practiced without these specific details. In other instances, well-known processes, structures, and techniques are not shown in the detailed description in order not to obscure the clarity of this description.

1 illustrates an embodiment in which auxiliary information (eg, distribution information) is stored in a header portion of an executable file portion of an installer. As shown, the installer 110 includes executable code blocks 120 and installer data 130. The executable code block 120 is composed of a header portion 122, an auxiliary data portion 124 that falls within the header portion, and an executable code section 126. Ancillary data 124 may include distribution related information, URLs, price information, timestamps, distribution channel information, business rules, digital rights management (DRM) information, distributor brand information, pointers or links to other information. And any other usage information for the software producer, distributor, wholesaler, retailer or end user. It will be apparent to those skilled in the art that various different types of information may be included in the supplemental data 124, including combinations or combinations of different types of supplemental information. Such supplemental information 124 may be generated, stored, and transmitted within an installer associated with it. Given an auxiliary data block 124 within installer 110, a particular installer can be created for a particular software product. For example, the same software product can be distributed in a number of different ways using a number of different specific installers, each of which has specific assistance data 124 that defines a distribution methodology for a particular distribution network. . Referring to FIG. 2, examples of three different installers with different auxiliary data in executable code blocks 121, 122, and 123 of each of the three different installers are illustrated. Note that each of the three example installers illustrated in FIG. 2 can be used to distribute a software product in a particular distribution network, and installer data 131 is the same for three different installers. Only executable code blocks 121, 122, and 123 are different to reflect different distribution networks for each installer.

Referring to FIG. 3, an example illustrates how distribution is accomplished in various embodiments on various distribution networks. In the example of FIG. 3, server 350 includes an installer template 340. Installer template 340 includes executable code block 321 and installer data 331. Upon receiving a request for download of a particular software product on a particular distribution network (eg, network 1), server 350 generates distribution network specific information (eg, network 1) and installs the information. Stored in a duplicate of the template 340. The distribution network specific installer 351 may then be sent to the originator of the request for distribution of the software product on the specific distribution network. Similarly, other distribution network-specific installers 352 and 353 can be generated from installer template 340 and sent to senders of their specific download requests. In this way, an efficient and scalable solution for the distribution of software products in multiple distribution networks is provided.

The use of digital signatures in downloaded executables is becoming more and more common. However, once a software producer signs an executable file, the contents of the executable file cannot be easily changed without rendering the public certificate invalid or causing the digital signature of the executable file to be inconsistent with the digital certificate of the executable file. As such, it is becoming difficult to insert supplemental information into the installer for downloading a particular software product. Nevertheless, as described in more detail below, the various embodiments described above solve this problem.

Referring to FIG. 4, a typical structure of a digitally signed executable file 401 is illustrated. File 401 is typically a cyclic redundancy check (CRC) block 410, digital signature pointer 412, digital signature size 414, variable data block 416, digital signature block 420, and unused portions ( 430). As is known in the art, digital signature 420 is generated from a hash of variable data 416 and executable headers by combining a software developer's private key and a trusted permission private key. do. Variable data 416 may be virtually any code or data payload in file 401 including executable headers. Typically, the downloadable software product and associated data may be stored in variable data block 416. If the software product is stored in the variable data block 416, and the digital signature 420 is generated from the content of the variable data block 416, any of the variable data block 416 without invalidating the digital signature 420. It is very difficult to modify the parts. The size of the generated digital signature 420 is stored in the digital signature size block 414. Because the variable data block 416 can be of variable size, the pointer 413 for the digital signature 420 is stored in the digital signature pointer block 412. In typical implementations of digitally signed executable 401, CRC block 410, digital signature pointer 412, and digital signature size 414 are not included in the calculation of digital signature 420. As such, these blocks of file 401 may be modified without invalidating digital signature 420.

Referring to FIG. 5, a modified digitally signed executable file 501 is illustrated in accordance with various embodiments. File 501 is modified by changing the value of the digital signature size belonging to block 514. The value of the digital signature size can be modified by taking the size of the digital signature 520 and adding the size of the unused block 530 to it. In some cases, it may be necessary to increase (or decrease) the modified digital signature size value by a predetermined pad value to terminate auxiliary data block 530 on a byte, word, page or other memory segment boundary. . In other cases, it may be necessary to preemptively zero out or store a default value in each memory location of auxiliary data block 530. This new digital signature size value is stored in digital signature size block 514 as shown by arrow 515 in FIG. Since the digital signature size value in block 514 is not included in the calculation of the digital signature 520, modification of the digital signature size in block 514 does not invalidate the digital signature 520. In addition, due to the conventional structure of digital signature 520, attaching additional memory space 530 to the end of digital signature 520 also does not invalidate digital signature 520. The addition of unused memory space 530 to file 501 allows a third party to store auxiliary data in block 530. The ancillary data stored at block 530 may be used for various purposes. For example, the ancillary data stored at block 530 may include distribution related information, URLs, price information, timestamps, distribution channel information, business rules, digital rights management (DRM) information, distributor brand information, other information. Pointers or links to and any other usage information for the software manufacturer, distributor, wholesaler, retailer or end use. It will be apparent to those skilled in the art that various different types of information may be included in block 530, including combinations or combinations of different types of auxiliary information. Such assistance information may be generated, stored, and transmitted within block 530 of file 501 without invalidating digital signature 520.

In alternative embodiments, the data in CRC block 510 may be overwritten with auxiliary data. Since the CRC value of block 510 is not included in the calculation of the digital signature 520, modification of the CRC data in block 510 does not invalidate the digital signature 520. However, the size of the CRC block 510 is very limited. In typical implementations of the file 501 structure, very little information can be stored at block 510. A pointer, link, or index to a larger block of supplemental data may be stored at block 510, and such supplemental data is stored at a local or remote location (eg, a server).

With reference to FIG. 6, a flowchart illustrates basic processing operations performed in an embodiment. At block 612, the digitally signed file 501 is read, and the digital signature block and digital signature size block are identified in the digitally signed file header. At block 614, the digital signature size is retrieved from the digital signature size block and the digital signature size value is modified. The value of the digital signature size is modified by taking the size of the digital signature (i.e. the old value in the digital signature size block) and adding to it the size of the unused data block where the supplemental data can be stored. In some cases, it may be necessary to increase (or decrease) the modified digital signature size value by a predetermined pad value to end the auxiliary data block on a byte, word, page or other memory segment boundary. In other cases, it may be necessary to preliminarily reduce or store a default value in each memory location of auxiliary data block 530. This new digital signature size value is stored in the digital signature size block at processing block 616. Ancillary data corresponding to this digitally signed file 501 is generated at processing block 618 and stored in ancillary data block 530. At processing block 620, the CRC value for modified file 501 may be recalculated and stored at CRC block 510. Given the auxiliary data stored in block 530 in the digitally signed file 510 in accordance with various embodiments, a particular installer may be generated for a particular software product by a third party. In addition, digitally signed files include digital rights management policies, access controls, purchase procedures, or various other content specific, party-specific or transaction specific information associated with a particular digitally signed file 501. It can be modified to.

7A and 7B show examples of computer system 200 illustrating an example client or server computer system in which features of the example embodiment may be implemented. Computer system 200 includes bus or other communication means 214 and 216 for communicating information, and processing means such as a processor 220 coupled with bus 214 for processing information. Computer system 200 is random access memory (RAM) or other dynamic storage device 222 (generally referred to as main memory) coupled to bus 214 for storing instructions and information to be executed by processor 220. More). Main memory 222 may also be used to store temporal variations or other intermediate information during execution of instructions by processor 220. Computer system 200 also includes read-only memory (ROM) and / or other static storage device 224 coupled to bus 214 for storing static information and instructions for processor 220.

Optional data storage devices 228, such as magnetic disks or optical disks and corresponding drives, may also be coupled to the computer system 200 to store information and instructions. Computer system 200 may also be coupled via bus 216 to a display device 204 such as a cathode ray tube (CRT) or liquid crystal display (LCD) to display information to a computer user. For example, graphical depictions of images, text, video or information may be presented to the user on the display device 204. Typically, an alphanumeric input device 208 comprising alphanumeric and other keys is coupled to the bus 216 to communicate information and / or command selections to the processor 220. Another type of user input device is cursor control, such as a conventional mouse, trackball, or other type of cursor direction keys for communicating indication information and command selection to the processor 220 and controlling cursor movement on the display 204. Device 206.

Communication device 226 may also be coupled to bus 216 to access remote computers or servers such as, for example, a web server or other servers via the Internet. The communication device 226 may include a modem, a network interface card or other known interface devices, such as those used to interface with Ethernet, Token-ring, Wireless, or other types of networks. In any case, in this manner, computer system 200 may be coupled to multiple servers through conventional network infrastructure.

The system of an exemplary embodiment includes software, information processing hardware, and various processing steps as described above. Features and process steps of example embodiments may be implemented as machine or computer executable instructions. The instructions may be used to cause a general purpose or special purpose processor programmed with the instructions to perform the steps of the example embodiment. Further, the features or steps may be performed by specific hardware components, including logic embedded in hardware to perform the steps, or any combination of programmed computer components and customary hardware components. Can be. Although embodiments have been described with reference to the Internet, the methods and apparatus described herein are equally applicable to other network infrastructure or other data communication systems.

It should be noted that the methods described herein need not be performed in the order described or in any particular order. In addition, various operations described in connection with the methods identified herein may be performed in an iterative, concurrent, recursive, serial, or parallel fashion. Information, including parameters, instructions, operands, and other data, may be transmitted and received in the form of one or more carriers via communication device 226.

Upon reading and understanding the present disclosure, those skilled in the art will understand how a software program can be launched from a computer readable medium in a computer-based system to carry out the functions defined in the software program to be described above. Those skilled in the art will also understand various programming languages that may be employed to generate one or more software programs designed to implement and perform the methods described above. The programs may be organized in an object oriented format using an object oriented language such as Java, Smalltalk, or C ++. In addition, the programs may be constructed in a procedural oriented format using an assembly or procedural language such as C. Software components may communicate using any of a number of mechanisms known in the art, such as application program interfaces or inter-process communication techniques, including remote procedure calls. The spirits of the various embodiments are not limited to any particular programming language or environment, including HTML and XML.

Thus, other embodiments can be realized. For example, FIGS. 7A and 7B illustrate computer 200, memory systems 222, 224, and 228, magnetic or optical disks 212, some other storage device 228, and / or any type of electronic device. Or block diagrams of an article of manufacture in accordance with various embodiments, such as a system. The article 200 is a fixed and / or removable storage medium that includes a computer-readable medium 212, and / or a storage device 228 (eg, a real memory having electrical, optical, or electromagnetic conductors). Or a computer 202 (with one or more processors) coupled to a carrier via the communication device 226, with associated information (e.g., computer program instructions and / or data), and Associated information causes the computer 202 to perform the methods described herein when executed by the computer 202.

Various embodiments are described. In particular, the use of embodiments having user interface presentations of various types and formats may be described. It will be apparent to those skilled in the art that alternative embodiments of the implementations described herein are employed and are within the scope of the claims set forth below. In the detailed description, various embodiments are described herein as being implemented in computer-implemented processing logic, sometimes referred to herein as "software." However, as noted above, the claimed invention is not limited to software implementation as a whole.

As mentioned above, the supplementary data can be embedded in a signed executable file, and the supplementary data can be modified without breaking the existing digital signature. The technique described above involves embedding such supplemental data into a digital signature directory, which is not counted as part of the verified message. As a result, the techniques described above provide an effective way to personalize installers for digital distribution upon download (or manufacture) as ancillary information (eg, source of distribution, etc.). One advantage of the techniques described above is that auxiliary information can be dynamically inserted into an executable file upon download. This allows tracking of distribution channels in a digital distribution business model consisting of multiple distributors. In such a business model, it is highly desirable to be able to identify the source of a particular file so that such source can be compensated for in the event of a monetary or advertising transaction or events related to the particular file. It is also highly desirable for the digital distribution provider to store only one version of the downloadable assets and to create a tag copy of those assets in an effective manner. Dynamic (partnership) tracking effectively creates a distribution network where 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. Allow it.

US Pat. Nos. 5,892,904 and 6,367,012 describe methods for ensuring 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 guarantee the authenticity and integrity of the transmitted executable file, and the transmitted executable file may contain a signed program or code, a digital signature, and possibly some other data and padding. Include.

For example, the Microsoft Windows operating system implements signed executables by adding an "Attribute Certificate Table" and "Certificate Data" sections, including an Authenticode signature. The image hash used to generate the verification code signature is in the following sections (according to Microsoft documentation):

i. A file checksum field of window-specific fields of an optional header;

ii. Information related to attribute certificates; And

iii. Generated from all sections in the executable, except for information located in a section past the end of the last section.

Since the image hash used to generate the authentication code signature is not generated from the sections in the file referenced above (denoted as unauthenticated sections herein), modifications to these unauthenticated sections will not affect or affect the hash. It will not affect the authentication code signing. Thus, if the file or transfer does not affect the signing of the authentication code of the executable file, then the authentication and integrity of the transmitted executable file may not be affected in the non-authenticated sections. Indeed, the invention disclosed in US Published Patent Application No. 20060265591 utilizes this fact to effectively modify the executable or transfer it in useful ways without breaking the digital signature.

In various embodiments described below, the authenticity and integrity of a file or transmission that includes a digitally signed executable file is defined as areas of the file or transmission that are not included in the generation of the digital signature of the file or transmission (ie, By verifying unauthorized domains). The process described below is used to verify that unauthorized areas do not contain unsolicited data and that the required data in the unauthorized areas have explicitly specified values.

This verification of the content of unauthenticated areas may include: 1) when the digital signature of the file or transmission is verified, 2) when the file or transmission is downloaded, or 3) upon execution by the executable file itself, or when the file is received. Can be performed by an operating system residing on a machine for manipulating. If the verification process is performed at the time of execution by the executable file itself, the execution of the executable file is terminated in the case where the verification fails. Performing the verification process at run time by the executable file itself may not be an ideal solution in all situations, but since the executable code is properly protected by existing digital signatures, the process may be safe enough for many applications. Can be.

In certain embodiments described below, the authenticity and integrity of a file or transmission that includes a digitally signed executable file is verified using an implementation for Microsoft Windows Portable Executable (PE) files. In this particular embodiment, the verification process includes the following operations:

i. Checking and verifying that the checksum field in the window specific fields of the optional header matches the image file checksum;

ii. Checking and verifying that no information exists beyond the end of the last section of the file or transfer;

iii. Checking and verifying to ensure that the attribute certificate table includes one single entry and does not include padding or padding with fixed data; And

iv. Checking and verifying to ensure that the certificate fills the entire space allocated to the certificate in the attribute certificate table, except for possible fixed-data padding for the next octaword boundary.

The verification process described above is based on the Portable Executable (PE) standard already used in millions of executables for consumption and binary generation or modification tools (e.g. forensic tools, linkers, compilers, etc.). May require changes. As a result of such potentially required changes to the PE standard, the verification process described above may not be optimal for some applications.

In another particular embodiment described below, the authentication and integrity of a file or transmission that includes a digitally signed executable file is verified using an implementation for Microsoft Windows Portable Executable (PE) files. In this particular embodiment, an operating system (OS) sales company or provider (eg, Microsoft) mitigates or eliminates the security risk of executing a digitally signed file or transfer that includes unauthorized areas. You can implement a verification process to accomplish this. In this embodiment, when the executable file is loaded into memory, the verification process prevents or monitors access to unauthorized areas. The verification process of a particular embodiment includes the following operations:

i. Checking the integrity of the digital signature and the contents of the executable file, while loading the memory or file containing the digitally signed executable file for execution;

ii. Erasing any unauthorized areas of the file or transfer by reducing or filling in memory locations of unauthorized areas;

iii. Optionally, virtualizing access to the contents of such an executable file on disk and erasing any unauthorized areas of the virtualized file or transfer as described above, wherein the executable file is a file input / output call such as Win32 CreateFile. When attempting to load itself (eg, or from another executable module associated with it, such as a DLL or COM object) using calls, virtualization of access to the contents of such an executable file may be performed. The erase operation may be included.

In another particular embodiment described below, the authentication and integrity of a file or transmission that includes a digitally signed executable file is verified using an implementation for Microsoft Windows Portable Executable (PE) files. In this particular embodiment, an operating system (OS) sales company or provider (eg, Microsoft) mitigates or eliminates the security risk of executing a digitally signed file or transfer that includes unauthorized areas. You can implement a verification process to accomplish this. In this embodiment, when the executable file is loaded into memory, the verification process prevents or monitors access to unauthorized areas. The verification process of a particular embodiment includes the following operations:

i. Virtualizing access to the contents of a digitally signed executable file on a disk;

ii. Deleting or filling in values of virtualized files corresponding to the contents of unauthorized regions, thereby erasing any unauthorized regions of the file or transfer for the virtualized files in memory;

Unauthorized realms are:

1. a checksum field of window specific fields of an optional header;

2. Information past the end of the last section of the file or transfer;

3. information related to attribute certificates; And

4. Include locations where the certificate does not fill the entire space allocated to the certificate in the attribute certificate table.

8 and 9, flowcharts illustrate basic processing operations performed in example embodiments.

Accordingly, computer-implemented systems and methods are disclosed for embedding and authenticating supplemental information in digitally signed content. While the present invention has been described in connection with some exemplary embodiments, those skilled in the art will recognize that the invention is not limited to the described embodiments but may be practiced with modifications and variations within the appended claims and spirit. Accordingly, the description herein is to be regarded as illustrative instead of limiting.

120: executable code block 122: header
124: Supplementary Data 126: Executable Code and Sections
130: installer data 131: installer data
321: executable code block 331: installer data
410: CRC 412: pointer to digital signature
414: Digital signature size 416: Variable data
420: digital signature 510: CRC
512: Pointer to digital signature 514: Size of digital signature
516: variable data 520: digital signature
530: auxiliary data 204: display device
206: cursor control unit 208: keyboard
218: bus bridge 220: processor
222: main memory 224: read-only memory
226: communication device 228: storage device

Claims (30)

Checking digital integrity of the executable file and the integrity of the content while loading the digital content including the digitally signed executable into memory; And
Erasing any unauthorized areas of the digital content by zeroing out memory locations corresponding to unauthorized areas or by filling in the memory locations. The method of claim 1, wherein the unauthorized areas of the digital content include regions past the end of the last section. 2. The method of claim 1 including verifying that a checksum field in the header of the digital content matches an image file checksum. The method of claim 1 including verifying that an attribute certificate table contains one single entry and does not include padding. 2. The method of claim 1 including verifying that the digital signature actually fills the entire space allocated to the digital signature in an attribute certificate table. A computer-readable recording medium containing data, the method comprising:
When the data is accessed by a computer, it causes the computer to:
Loading digital content including a digitally signed executable file for execution into memory, checking for integrity of the digital signature and content of the executable file,
And erase any unauthorized areas of the digital content by reducing memory locations corresponding to unauthorized areas or by filling in values in the memory locations. 7. The computer readable recording medium of claim 6, wherein the unauthorized areas of the digital content comprise areas past an end of a final section of the digital content. 7. The computer readable medium of claim 6, further operable to verify that a checksum field in the header of the digital content matches an image file checksum. 7. The computer readable medium of claim 6, further operable to verify that the attribute certificate table includes one single entry and does not include padding. 7. The computer readable medium of claim 6, further operable to verify that the digital signature actually fills the entire space allocated to the digital signature in an attribute certificate table. Checking digital integrity of the executable file and the integrity of the content while loading the digital content including the digitally signed executable file for execution into memory; And
Performing verify operations on the executable file to verify the integrity of the executable file. The method of claim 11, wherein the verifying operations include verifying that the attribute certificate table includes one single entry and does not include padding or padding with fixed data. 12. The method of claim 11, wherein the verifying operations comprise verifying that the certificate actually fills the entire allocated space in the attribute certificate table. A computer-readable recording medium containing data, the method comprising:
The data, when accessed by a computer, causes the computer to:
Loading digital content including a digitally signed executable file for execution into memory, checking for integrity of the digital signature and content of the executable file,
And perform verify operations on the executable file to verify the integrity of the executable file. 15. The computer readable medium of claim 14, wherein the verifying operations comprise verifying that the attribute certificate table includes one single entry and does not include padding or padding with fixed data. 15. The computer readable medium of claim 14, wherein the verifying operations comprise verifying that the certificate actually fills the entire allocated space in the attribute certificate table. delete delete delete delete delete delete delete delete delete delete delete delete delete delete

Images