Note: Descriptions are shown in the official language in which they were submitted.
CA 02690095 2009-12-04
WO 2009/016426 PCT/IB2007/003032
1
A COMPUTER-IlVIPLEMENTED METHOD AND SYSTEM FOR
EMBEDDING AND AIJTHENTICATING ANCILLARY INFORMATION
IN DIGITALLY SIGNED CONTENT
BACKGROUND
L. Technical Field
[0001] 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
[0002] 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 J~pr 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
CA 02690095 2009-12-04
WO 2009/016426 PCT/IB2007/003032
2
are downloaded from the portal sites and generate revenue. Typically, portals
get
a revenue share of the price paid by the consumer.
[0003] 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 &affili ate=abc
[0004] 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. trymedia. com/buy? sku=0123 &affiliate-~yz
[0005) 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)
CA 02690095 2009-12-04
WO 2009/016426 PCT/IB2007/003032
3
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.
[0006] 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 MicrosoftTM' 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.
[0007] 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
CA 02690095 2009-12-04
WO 2009/016426 PCT/IB2007/003032
4
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.
[0008] Thus, a computer-implemented system and method for
embedding and authenticating ancillary information in digitally signed content
are needed.
BRIEF DESCRIPTION OF THE DRAWINGS
[0009] Embodiments illustrated by way of example and not
limitation in the figures of the accompanying drawings, in which:
[0010] Figure 1 illustrates an embodiment in which ancillary
information is stored in the header portion of an executable file.
[0011] Figure 2 illustrates examples of three different installers
with different ancillary data within their respective executable code blocks.
[0012] Figure 3 illustrates an example of how distribution on a
variety of distribution networks is accomplished in various embodiments.
[0013] Figure 4 illustrates a typical structure of a digitally signed
executable file.
[0014] Figure 5 illustrates a modified digitally signed executable
file according to various embodiments.
[0015] Figure 6 illustrates a flow chart showing the basic
processing operations performed in an embodiment
[0016] Figures 7a and 7b are block diagrams of a computing
system on which an embodiment may operate and in which embodiments may
reside.
[0017] Figures 8 and 9 are flow diagrams illustrating the basic
processing operations performed in an example embodiment.
DETAILED DESCRIPTION
[0018] 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
CA 02690095 2009-12-04
WO 2009/016426 PCT/IB2007/003032
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.
5 [0019] Figure 1 illustrates an embodiment in which ancillary
information (e.g. distribution information) is stored in the header portion of
the
executable part of an installer. As shown, an installer 110 includes an
executable
code block 120 and installer data 130. Executable code block 120 is comprised
of a header portion 122, and ancillary data portion 124 that resides within
the
header portion, and an executable code section 126. Ancillary data 124, can
include distribution related information, URLs, pricing information,
timestamps,
distribution channel information, business rules, digital rights maiagement
(DRM) information, distributor branding information, pointers or links to
other
information, and any other information of use to a software manufacturer,
distributor, wholesaler, retailer, or end user. It will be apparent to one of
ordinary skill in the art that a variety of different types of information,
including
aggregations or combinations of different types of ancillary information may
be
included in ancillary data 124. Such ancillary information 124 can be created,
stored, and transferred within an installer to which it relates. Given
ancillary
data block 124 within installer 110, a specific installer can be created for a
particular software product. For example, the same software product can be
distributed in multiple different methods using multiple different specific
installers, each with specific ancillary data 124 that defines the
distribution
methodology for that particular distribution network. Referring to Figure 2,
examples of three such different installers with different ancillary data
within
their respective executable code blocks, 121, 122, and 123 are illustrated.
Each
of the three example installers illustrated in Figure 2 can be used to
distribute a
software product in a particular distribution network; note that the installer
data
131 is the same on the three different installers Only the executable code
blocks,
121, 122, and 123 are different to reflect the different distribution networks
for
each installer.
[0020] Referring to Figure 3, an example illustrates how
distribution on a variety of distribution networks is accomplished in various
CA 02690095 2009-12-04
WO 2009/016426 PCT/IB2007/003032
6
embodiments. In the example of Figure 3, a server 350 includes an installer
template 340. The installer template 340 includes an executable code block 321
and installer data 331. Upon receiving a request for the download of a
particular
software product on a particular distribution network (e.g. network 1), server
350
generates distribution network-specific information (e.g. network 1) and
stores
the information in a copy of installer template 340. The distribution network-
specific installer 351 can 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 the originators of those
particular download requests. In this manner, an efficient and scalable
solution
for the distribution of software products in a multiple of distribution
networks is
provided.
[0021] 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.
[0022] Referring to Figure 4, a typical structure of a digitally
signed executable file 401 is illustrated. File 401 typically includes a
cyclic
redundancy check (CRC) block 410, a digital signature pointer 412, a digital
signature size 414, a variable data block 416, a digital signature block 420,
and
an unused portion 430. As well known to those of ordinary skill in the art,
digital signature 420 is generated from a hash of the variable data 416 and
executable headers in combination with the private key of the software
developer
and the private key of a trusted authority. Variable data 416 can be virtually
any
code or data payload within the file 401, including executable headers.
Typically, a downloadable software product and related data can be stored in
variable data block 416. Once the software product is stored in variable data
block of 416 and the digital signature 420 is generated from the content of
CA 02690095 2009-12-04
WO 2009/016426 PCT/IB2007/003032
7
variable data block 416, it becomes very difficult to modify any portion of
variable data block 416 without invalidating digital signature 420. The size
of
the generated digital signature 420 is stored in digital signature size block
of
414. Because variable data block 416 can be of variable size, a pointer 413 to
digital signature 420 is stored in digital signature pointer block 412. In
typical
implementations of digitally signed executable file 401, CRC block 410,
digital
signature pointer 412, and digital signature size 414 are not included in the
computation of digital signature 420. As such, these blocks of file 401 can be
modified without invalidating digital signature 420.
[0023] Referring to Figure 5, a modified digitally signed
executable file 501 according to various embodiments is illustrated. File 501
has
been modified by changing the value of the digital signature size residing in
block 514. The value of the digital signature size has been modified by taking
the size of the digital signature 520 and adding to it the size of unused
block 530.
In some cases, it may be necessary to increase (or decrease) the modified
digital
signature size value by a pre-determined pad value to terminate ancillary data
block 530 on a byte, word, page, or other memory segment boundary. In other
cases, it may be necessary to preliminarily zero out or store a default value
in
each memory location of ancillary data block 530. This new digital signature
size value is stored in digital signature size block 514 as shownby arrow 515
in
Figure 5. Because the digital signature size value in block 514 is not
included in
the computation of digital signature 520, the modification of the digital
signature
size in block 514 does not invalidate digital signature 520. Additionally,
because
of the conventional construction of digital signature 520, appending
additional
memory space 530 at the end of digital signature 520 also does not invalidate
digital signature 520. The addition of unused memory space 530 to file 501
enables a third party to store ancillary data in block 530. Ancillary data
stored in
block 530 can be used for a variety of purposes. For example, ancillary data
stored in block 530 can include distribution related information, URLs,
pricing
information, timestamps, distribution channel information, business rules,
digital
rights management (DRM) information, distributor branding information,
pointers or links to other information, and any other information of use to a
software manufacturer, distributor, wholesaler, retailer, or end user. It will
be
CA 02690095 2009-12-04
WO 2009/016426 PCT/IB2007/003032
8
apparent to one of ordinary skill in the art that a variety of different types
of
information, including aggregations or combinations of different types of
ancillary information may be included in block 530. Such ancillary information
can be created, stored, and transferred within block 530 of file 501 without
invalidating digital signature 520.
[0024] 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)
[0025] Referring to Figure 6, a flow chart illustrates the basic
processing operations performed in an embodiment. At block of 612, a digitally
signed file 501 is read and a digital signature block and a digital signature
size
block the end, the digitally signed file header is identified. In 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 an unused data
block in
which ancillary data can be stored. In some cases, it may be necessary to
increase (or decrease) the modified digital signature size value by a pre-
determined pad value to terminate the ancillary data block on a byte, word,
page,
or other memory segment boundary. In other cases, it may be necessary to
preliminarily zero out or store a default value in each memory location of
ancillary data block 530. This new digital signature size value is stored in
the
digital signature size block in processing block 616. The ancillary data
corresponding to this digitally signed file 501 is generated in processing
block
618 and stored in ancillary data block 530. In processing block 620, the CRC
value for the modified file 501 can be recomputed and stored in CRC block 510.
Given the ancillary data stored in block 530 within digitally signed file 510
CA 02690095 2009-12-04
WO 2009/016426 PCT/IB2007/003032
9
according to various embodiments, a specific installer can be created for a
particular software product by a third party. Further, digitally signed files
can be
modified to include digital rights management policies, access controls,
purchasing procedures, or a variety of other content-specific, party-specific,
or
transaction-specific information associated with a particular digitally signed
file
501.
[0026] Figures 7a and 7b show an example of a computer system
200 illustrating an exemplary client or server computer system in which the
features of an example embodiment may be implemented. Computer system 200
is comprised of a bus or other communications means 214 and 216 for
communicating information, and a processing means such as processor 220
coupled with bus 214 for processing information. Computer system 200 further
comprises a random access memory (RAM) or other dynamic storage device 222
(commonly referred to as main memory), coupled to bus 214 for storing
information and instructions to be executed by processor 220. Main memory
222 also may be used for storing temporary variables or other intermediate
information during execution of instructions by processor 220. Computer
system 200 also comprises a read only memory (ROM) and /or other static
storage device 224 coupled to bus 214 for storing static information and
instructions for processor 220.
[0027] 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.
CA 02690095 2009-12-04
WO 2009/016426 PCT/IB2007/003032
[0028] 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 Intemet, for example. The communication device 226 may
include a modem, a network interface card, or other well-known interface
5 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.
[0029] The system of an example embodiment includes software,
10 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.
[0030] 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.
[0031] 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
CA 02690095 2009-12-04
WO 2009/016426 PCT/IB2007/003032
11
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.
[0032] Thus, other embodiments may be realized. For example,
Figures 7a and 7b illustrate block diagrams of an article of manufacture
according to various embodiments, such as a computer 200, a memory system
222, 224, and 228, a magnetic or optical disk 212, some other storage device
228, and/or any type of electronic device or system. The article 200 may
include
a computer 202 (having one or more processors) coupled to a computer-readable
medium 212, and/or a storage device 228 (e.g., fixed and/or removable storage
media, including tangible memory having electrical, optical, or
electromagnetic
conductors) or a carrier wave through communication device 226, having
associated information (e.g., computer program instructions and/or data),
which
when executed by the computer 202, causes the computer 202 to perform the
methods described herein.
[0033] 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.
[0034] As described above, ancillary data can be embedded within
a signed executable file, the ancillary data being modifiable without breaking
the
CA 02690095 2009-12-04
WO 2009/016426 PCT/IB2007/003032
12
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.
[0035]
[0036] U.S. Patent 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.
[0037] 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;
CA 02690095 2009-12-04
WO 2009/016426 PCT/IB2007/003032
13
ii. Information related to attribute certificates; and
iii. Information located in a section past the end of the last
section.
[0038] 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.
[0039] 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.
[0040] 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
itselt
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.
CA 02690095 2009-12-04
WO 2009/016426 PCT/IB2007/003032
14
[0041] 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 pas t
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.
[0042] 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.
[0043] 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
CA 02690095 2009-12-04
WO 2009/016426 PCT/IB2007/003032
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
5 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
10 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
15 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.
[0044] 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
CA 02690095 2009-12-04
WO 2009/016426 PCT/IB2007/003032
16
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.
[0045] Referring to Figures 8 and 9, flow diagrams illustrate the
basic processing operations performed in example embodiments.
[0046] 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.
