ProofSpace White Paper

ProofMark System
Technical Overview
Cryptographic Data Integrity Seal & Trusted Timestamp
Issuance, Preservation and Validation

By Jacques R. Francoeur and Bruce Moulton

Edited by Dr. Yiqun Lisa Yin and Kurt Stammberger

ProofSpace
900 Clancy Ave NE
Grand Rapids, MI 49503
(312) 933.8823
www.proofspace.com
 ProofSpace White Paper

Table of Contents

1. Introduction 3
1.1 What is a ProofMark? 4
1.2 What is the ProofMark System? 5
1.3 Integrating the ProofMark System into the Information Life Cycle 6

2. The ProofMark System — Core Constructs and Architecture 8

2.1 ProofMark System Core Constructs 8
2.1.1 The Time Interval 8
2.1.2 The Public/Private Key Pair 9
2.2 ProofMark System Architecture 9
2.2.1 ProofMark Servers and Clients 9
2.2.2 Forensic Repository 10

3. The ProofMark System — Processes and Operations 10

3.1 ProofMark Issuance 10
3.1.1 The ProofMark Request 11
3.1.2 ProofMark Construction 12
3.1.3 ProofMark Response 15
3.2 ProofMark Validation 16
3.2.1 ProofMark Level Verifications 17
3.2.2 Forensic Repository Level Verifications 18
3.3 ProofMark Preservation 19
3.3.1 ProofMark Registration 19
3.3.2 Forensic Repository Management 19
3.4 ProofMark System Operation 22
3.4.1 Time Sourcing 23
3.4.2 Interval Record Management 23
3.4.3 Current Interval Operation 24
3.4.4 Next Interval Activation 24
Conclusion 26
Bibliography 27
About the Authors 28
ProofSpace Technical Advisory Board 29
ProofSpace ProofSpace Business Advisory Board 31
900 Clancy Ave NE
Grand Rapids, MI 49503
(312) 933.8823
www.proofspace.com ProofMark System Technical Overview — Revised December 2007 2
 ProofSpace White Paper

1. Introduction
With the rapid advances in information and communication technologies, more and
more business records are stored and transmitted electronically. Such advancement
has greatly reduced the need for storing documents in paper form, cutting costs and
making business transactions much more efficient. However, it has also become more
of a challenge to preserve and demonstrate the authenticity and integrity of records for
which there is now no paper “orginal”.
ProofSpace provides businesses with innovative solutions to prove the integrity of their
electronic records. To meet the demands of different organizations and computing
environments, ProofSpace delivers a variety of customized data integrity applications,
the basic building block of which is company’s cornerstone technology, the ProofMark™
System. The purpose of this whitepaper is to provide a technical overview of the
ProofMark System, including core constructs, system architecture, and functional
processes.
In a nutshell, the ProofMark System enables the creation of a “ProofMark”, a digital
tamper-detection seal and trusted timestamp that can be applied to any electronic
record. The ProofMark cryptographically binds the data with an ANSI ASC X9.95
standard trusted timestamp and can irrefutably prove that the data content has not
been tampered with since the ProofMark was issued. The ProofMark System as a whole
is composed of functional processes for issuing, preserving and validating ProofMarks.
These processes are built upon a system architecture consisting of ProofMark servers,
ProofMark clients and ProofMark forensic repositories, where all issued ProofMarks
are securely indexed and preserved. In addition, trusted times are provided by an
authentic time authority, and the overall system operations are further enhanced by
well-established cryptographic techniques (such as RSA public-key cryptography and
secure hashing algorithms) and distributed networking techniques that provide for
“widely-witnessed” transactions.
At the heart of the ProofMark System is ProofSpace’s patented transient key technology.
Building upon widely deployed and trusted digital signature mechanisms, the primary
advantage of the transient key technology is the elimination of the administrative
overhead and security risks associated with a private signing key in the conventional
X.509 digital signature applications. In particular, the private signing key in the
ProofMark system is bound to a brief time interval and destroyed at the end of the time
interval. This short-lived nature of the private key dramatically reduces the overall risk
profile of the ProofMark System when compared to competing approaches.
The ProofMark system has been designed for businesses to solidify their electronic
records management processes, withstand regulatory audits, minimize legal exposure
and mitigate risks. The ProofMark system can be seamlessly integrated into the
information life cycle within any business application and benefit a wide spectrum
of industries. In summary, the ProofMark System provides a complete, effective and
compelling solution for addressing modern data integrity issues in the enterprise.

ProofSpace
900 Clancy Ave NE
Grand Rapids, MI 49503
(312) 933.8823
www.proofspace.com ProofMark System Technical Overview — Revised December 2007 3
 ProofSpace White Paper

1.1 What is a ProofMark?

A ProofMark is a persistent, self-validating digital seal on any electronic data. It
cryptographically binds the data with a trusted timestamp and irrefutably proves that
the data content has not been tampered with since the ProofMark was issued, no
matter where the data resides or who controls it.
There are two basic ways a ProofMark can be “associated” with a data record:
• The ProofMark can be appended to the original data and stored together with it in a
file system.
• The ProofMark and the original data can be stored separately, their association then
maintained by an appropriate reference pointer.

ProofSpace
900 Clancy Ave NE
Grand Rapids, MI 49503
(312) 933.8823
www.proofspace.com ProofMark System Technical Overview — Revised December 2007 4
 ProofSpace White Paper

1.2 What is the ProofMark System?

The ProofMark System is a system that issues, preserves, and validates ProofMarks
associated with electronic data. It can be integrated seamlessly with content
management systems, records management systems, storage/archiving systems and
other business applications.

At a very high level, the ProofMark System architecture consists of ProofMark servers,
ProofMark clients and ProofMark forensic repositories where all issued ProofMarks
are securely indexed and preserved.
The ProofMark System is composed of four core Processes:

• ProofMark Issuance Process:

The ProofMark client or application generates a ProofMark issuance request and sends
it to the ProofMark server. The server processes the request, constructs the ProofMark,
and sends a response to the requesting client.

• ProofMark Preservation Process:

The ProofMark server registers the issued ProofMark into the forensic repository
(database), preserves it and makes it available for ProofMark validation requests.

• ProofMark Validation Process:

The ProofMark client or application generates a ProofMark validation request
and sends it to the ProofMark server. The server validates the ProofMark through
cryptographic mechanisms by possibly interacting with the forensic repository.

• ProofMark System Operation Process:

The overall system orchestration in terms of ProofMark issuance, preservation, and
ProofSpace validation.
900 Clancy Ave NE
Grand Rapids, MI 49503
(312) 933.8823
www.proofspace.com ProofMark System Technical Overview — Revised December 2007 5
 ProofSpace White Paper

1.3 Integrating the ProofMark System into the Information Life Cycle
The ProofMark System is a “call on demand” application that can be integrated into
the information life cycle within any business application. It enables the application to
request, receive, and validate ProofMarks.
Generally speaking, Information Life Cycles have two distinctive requirements:
• There are points in the process or transaction where the state and time of the
information (e.g., a “version”) must be captured and preserved (“frozen”) for future
reference; and
• At points of future reference, the information must be validated to show that it has
remained unchanged with respect to both its content and reference to time before
further usage can be sanctioned (for example, before the data can be admitted as
evidence in a court of law).

ProofSpace
900 Clancy Ave NE
Grand Rapids, MI 49503
(312) 933.8823
www.proofspace.com ProofMark System Technical Overview — Revised December 2007 6
 ProofSpace White Paper

The illustration below represents a simplified Information Life Cycle composed of three
main components defined as follows:
• “Create” is an active phase where data (e.g., records, files, etc) is either created or
amended through authorized methods.
• “Store” is a passive phase when the data generated is stored or archived without
change.
• “Use” is a passive phase where information is used (but not changed) for an intended/
authorized purpose.

ProofMarking and the Information Life Cycle

The illustration shows how the ProofMark System can be integrated into systems
and processes to support both of the ILC requirements outlined above. Consider, for
example, a contract. When the contract gets signed by the parties (executed) it must
be stored and retained for a prescribed retention period. The Contract Management
System (CMS) would request a ProofMark at the time the contract is executed, which
the ProofMark System would generate and return to the CMS. (Requesting a ProofMark
is illustrated by the lower left side of the diagram.) The CMS then associates the
ProofMark with the contract in a persistent way.
Years later, in a legal dispute the contract must be brought forward and submitted to
court as evidence. The contract would be accompanied by its ProofMark. A precondition
of being admitted into evidence might be that the authenticity of the contract (i.e.,
request a validation of the ProofMark) be reasonably demonstrated. The authenticity
of the contract is then irrefutably shown by submitting the ProofMark to the ProofMark
ProofSpace System for validation and reviewing the results of the validation report. (Requesting a
900 Clancy Ave NE ProofMark validation is illustrated by the lower right side of the diagram.)
Grand Rapids, MI 49503
(312) 933.8823
www.proofspace.com ProofMark System Technical Overview — Revised December 2007 7
 ProofSpace White Paper

If the validation report is positive then the contract is more likely to be admitted into
evidence, and the organization can proceed with the confidence that its corporate
records will be available to defend its interests. If the validation report is negative, then
the situation requires further investigation. The same basic scenario might play out
with respect to corporate purchasing agreements, real estate documents, employment
contracts or many other types of business documents where authenticity is crucial.

2. The ProofMark System — Core Constructs and Architecture

The following is a technical overview of the core constructs and general architecture of
the ProofMark System.

2.1 ProofMark System Core Constructs

At the core of the ProofMark system is a particular time interval and the cryptographic
keys that are bound to that specific time interval.

2.1.1 The Time Interval

In the ProofMark System, time is partitioned into precisely bounded periods called
“Intervals” (for example from 9:00 to 9:05 AM), the actual length of which is system-
configurable. As illustrated below, there are three types of time Intervals: “Expired”,
“Current” and “Next”.
• Current Interval: this interval is the active (“on duty”) interval because the actual
time (e.g., 9:03) falls within the start and end time of the Interval. In this example,
9:00 to 9:05 is the current interval.
• Expired Intervals: these are intervals whose time period has passed. For example,
8:55 to 9:00 am is an expired interval given that the current time is 9:03.
• Next Interval: this is the interval that will go “on duty” when the current interval
expires. For example, 9:05 to 9:10 is the next interval.
A well-defined set of data elements are generated for each time interval and
permanently stored in the ProofMark System’s Forensic Repository (database). These
data elements uniquely define the time Interval. To avoid a time gap between the end
of the current Interval and the next interval, data elements for the next interval are
prepared during the current Interval.

ProofSpace
900 Clancy Ave NE
Grand Rapids, MI 49503
(312) 933.8823
www.proofspace.com ProofMark System Technical Overview — Revised December 2007 8
 ProofSpace White Paper

2.1.2 The Public/Private Key Pair

The ProofMark System is based on public key cryptography, also known as “asymmetric
cryptography”, the most popular and widespread example of which is the RSA
Cryptosystem. In asymmetric cryptography key pairs are issued that are mathematically
related — whatever one key does, only the paired key can undo. One of the main uses of
public key cryptography is digital signatures. In a typical software application, a public/
private key pair for a given signer is first generated. The private key is kept secret by
the signer and can used to produce signatures on any message. The public key is made
public and can be used by anyone to verify the validity of a message/signature pair.
In the Proofmark System, digital signatures are deployed in a way that is somewhat
different from the traditional practice described above. First, the public/private keys
are issued and bound to a brief time interval, rather than a human signer. Second, the
private key only lives for a very short period of time. More specifically, the private key
for an Interval is “on duty” only for that Interval. At the end the current Interval that
private key is destroyed. This short-lived nature of the current Interval’s private key
dramatically reduces the vulnerability of the system, when compared to traditional
digital signature implementations, since there is only a very brief window of time during
which the private key can be stolen or hacked — after which it self-destructs. Hence,
in the ProofMark System the private key is often called the transient private key and,
more generally, the ProofMark System is categorized as “transient key cryptography”.
As each transient private key is unique to an Interval, its corresponding public key,
referred to as the Interval public key, is also unique to each Interval. Unlike the short-
lived nature of the transient private key, the Interval public key is persistent and made
available, long-term, in the ProofMark itself, the Forensic Repository and (optionally) in
other published database archives. The Interval public key is a critical component for the
validation of a ProofMark. As time passes and the end of the current Interval approaches,
a new key pair is prepared to come on duty as part of the activation of the next Interval.
Before self-destructing, the very last act the current Interval’s transient private key
performs is to sign the new Interval public key of the next Interval. This provides a strong
cryptographic chaining between consecutive time Intervals, and it allows the ProofMark
System to vouch for the integrity and sequence of Intervals over time.

2.2 ProofMark System Architecture

2.2.1 ProofMark Servers and Clients

A ProofMark System is a network of servers comprised of at least one ProofMark
Issuing Server that issues ProofMarks, zero or more Cross Certification Servers that
independently certify all new Intervals activated by the ProofMark Issuing Server(s) and
zero or more Publication Servers that make available duplicate archives for ProofMark
validation.
The ProofMark Client is an XML-based client API that can be easily integrated within
existing applications or services. The client can communicate with the ProofMark
server, requesting the issuance or validation of ProofMarks.

ProofSpace
900 Clancy Ave NE
Grand Rapids, MI 49503
(312) 933.8823
www.proofspace.com ProofMark System Technical Overview — Revised December 2007 9
 ProofSpace White Paper

2.2.2 Forensic Repository

The distributed network of archives (all data instances) is collectively referred to as the
ProofMark System Forensic Repository (“Repository”). Each ProofMark Issuing Server
maintains a “root” archive of its own Interval chains containing expired interval records
which in turn contain Interval data elements, the ProofMark digest logs and its cross
certification ProofMarks. The ProofMark System’s distributed archive architecture
enables the Interval records to be replicated to the other servers (ProofMark Issuing
Servers, Cross Certification servers, Publication Servers) within the ProofMark System.

3. The ProofMark System — Processes and Operations

The following is a technical overview of the ProofMark System and its core processes
and operations.

3.1 ProofMark Issuance

The ProofMark Issuance process involves three basic stages including:
1) a requesting application or client formats a request and sends it to the ProofMark
System
2) the ProofMark System receives the request information and constructs the
ProofMark, and
3) the ProofMark System replies to the requesting application or client with a response.
This is illustrated in the figure below.

ProofMark Issuance Process

ProofSpace
900 Clancy Ave NE
Grand Rapids, MI 49503
(312) 933.8823
www.proofspace.com ProofMark System Technical Overview — Revised December 2007 10
 ProofSpace White Paper

3.1.1 The ProofMark Request

A ProofMark request is an XML construct formatted and received from any application
or client through an application interface. As illustrated below, the ProofMark request
contains five data elements:
• Original Data Reference: a pointer (url, filespec/path, database key, etc.) to where
the original data is stored and maintained external to the ProofMark System.
• Original Data Digest: a cryptographic hash1 of the original data.
• Original Data (optional): The ProofMark System can be configured to also receive
the original data as part of the request whose hash is the original data digest data
element.
• ProofMark Request Signature: In cases where the requesting application must be
authenticated before a ProofMark request can be processed, an X.509-based server
signature should be included in the request.
• Nested ProofMark Request: A request can contain several ProofMark requests that
are “nested” for the creation of a sequence of ProofMarks each based on a different
original data element.

ProofSpace
900 Clancy Ave NE 1 A cryptographic hash (also known as “message digest”) of data is a short digital string that serves as a “finger print” of the data.
Grand Rapids, MI 49503 A secure hash function, such as SHA-256, is used to compute the hash.

(312) 933.8823
www.proofspace.com ProofMark System Technical Overview — Revised December 2007 11
 ProofSpace White Paper

3.1.2 ProofMark Construction

After the ProofMark Request is received by the ProofMark System, the ProofMark is
constructed, and data elements are created and assembled into an XML construct.
There are two classes of data elements. The first class is called Interval Data Elements
and the second class is called ProofMark Data Elements. Roughly speaking, the set of
Interval data elements define the specific time Interval that the ProofMark was issued
in, and they are identical for all ProofMarks issued within the same time Interval. The
set of ProofMark data elements define the attributes of the specific ProofMark that was
issued, and they are unique to each ProofMark. This is illustrated in the figure below.
The rest of the section describes in detail the individual data elements contained in
each of the two classes.

1) Interval Data Elements

There are two types of Interval data elements — Interval Identifier Elements and Interval
Verification Elements, as illustrated in the figure below. Interval Identifier Elements are
data elements that provide location or identification information necessary to find the
Interval Record in the Forensic Repository and perform the ProofMark validation process:

ProofSpace
900 Clancy Ave NE
Grand Rapids, MI 49503
(312) 933.8823
www.proofspace.com ProofMark System Technical Overview — Revised December 2007 12
 ProofSpace White Paper

• ProofMark Server ID: the identifier for the server that hosted the interval that issued
the ProofMark, referred to as the ProofMark Issuing Server.
• Interval Chain Start Time: the start time of the Interval chain (a set of contiguous
expired Intervals) that contains the Interval that the ProofMark was issued in.
• Interval Start and Stop Time: the start and end time of the Interval within the Interval
chain that the ProofMark was issued in.
• Cross Certifying Servers: the location information of the Cross Certification Servers
that performed certifications of the Interval (at the time of its activation) that the
ProofMark was issued in.
• Archive Tree: the location information of all servers within the ProofMark System
where copies of the Interval that the ProofMark was issued in have been replicated.
The second type of Interval data elements is Interval Verification Elements that are
necessary to perform ProofMark validation. These data elements include cryptographic
signatures, corresponding public keys and hashes as follows:
• Interval Transient Key Signature: a digital signature by the “on-duty” Interval’s
transient private key of the hash of the next Interval’s concatenated Interval public key
and Interval start and stop time. In this way, the “on-duty” current Interval vouches
for the essential elements of its successor — the next Interval. This signature is used
in the validation process to verify that a given interval is the one vouched for by its
immediate predecessor and that its Interval public key and Interval start and stop
time have not changed since the Interval was activated. This verification is important
step in the determining the integrity of the Forensic Repository.
• ProofMark Server Signature: a digital signature by the ProofMark Server’s PKI
private key of the hash of the next Interval’s concatenated data elements at the time
of activation. In this way, the ProofMark Issuing Server vouches for interval records
that it activates. This signature is used in the ProofMark validation process to verify
that a given interval was activated by a legitimate issuing server and that the Interval
data elements stored in the Forensic Repository have not changed since the Interval
was activated. This is an important step in the verification of the integrity of the
Forensic Repository.
• Interval public key: required to decrypt the ProofMark transient key signature, a
ProofMark data element used in ProofMark validation.
• Previous Interval public key: required to decrypt the Interval transient key signature,
an Interval data element used in ProofMark validation.
• Previous Meta Digest: the hash of the most recently expired Interval’s digest log.
As each ProofMark is issued during the current Interval, a hash of each ProofMark
is concatenated to a rolling “digest log”, and digest logs are stored permanently in
the interval record of the Forensic Repository. This Previous meta digest allows the
integrity of a prior interval’s digest log to be verified. This is an important step in the
verification of the integrity of the Forensic Repository.

ProofSpace
900 Clancy Ave NE
Grand Rapids, MI 49503
(312) 933.8823
www.proofspace.com ProofMark System Technical Overview — Revised December 2007 13
 ProofSpace White Paper

2) ProofMark Data Elements

ProofMark Data Elements define the attributes of a specific ProofMark, and hence
they are unique to each issued ProofMark. Individual data elements in this class are
illustrated by the figure below. There are two types of ProofMark data elements —
ProofMark Verification Elements (which are required to validate the ProofMark) and
ProofMark Request Elements (which are an exact copy of the ProofMark request).

The ProofMark Verification Elements are as follows:

• ProofMark Transient Key Signature: a digital signature by the current Interval’s
transient private key of the hash of the concatenated hashes of the data elements of
the ProofMark being validated and the previous ProofMark. In this way, the current
Interval (and its time) is bound to the ProofMark and each ProofMark is bound to its
immediate predecessor. This signature is used in the ProofMark validation process to
verify the integrity of the ProofMark and all its data elements.
• Previous ProofMark Digest: the hash of the ProofMark issued immediately previous
to the one being validated. During the ProofMark validation process, the ProofMark
sequence number and other Interval identifier elements are used to find the digest
of the ProofMark being validated in the digest log of the Forensic Repository. This
previous ProofMark digest contained in the ProofMark should be identical to the
previous ProofMark digest contained in the digest log of the Forensic Repository,
confirming that the digest log has integrity.
• ProofMark Digest: the hash of the ProofMark being validated. The ProofMark digest
is used during ProofMark validation process to verify that the ProofMark digest found
in the digest log in the Forensic Repository (via the ProofMark sequence number and
other identifiers) is a digest of the ProofMark being validated.
• ProofMark Time: the actual time the ProofMark was issued. This time is
informational and falls between the start and stop times of the current Interval that
issued the ProofMark.
ProofSpace
900 Clancy Ave NE
Grand Rapids, MI 49503
(312) 933.8823
www.proofspace.com ProofMark System Technical Overview — Revised December 2007 14
 ProofSpace White Paper

• ProofMark Sequence Number: the sequence number of the ProofMark within the
digest log of the Current Interval it was issued in. This permits (along with other
identifiers) the corresponding ProofMark digest to be found at a later time in the
digest log of the issuing Interval in the Forensic Repository.
The full set of 20 data elements that create the complete ProofMark are illustrated
in the figure below. The data elements in red indicated cryptographic data elements
that are used in ProofMark validation. This will be covered in the ProofMark validation
section of this document.

3.1.3 ProofMark Response

The response of the ProofMark System to a request depends on the configuration of
the system and the request itself. The response is an XML construct that will be the
ProofMark itself or a reference to the ProofMark. In the later case, the ProofMark is
stored in the Forensic Repository and a ProofMark Reference is returned, as illustrated
on the next page. The ProofMark Reference contains the information necessary to
locate the ProofMark (and its Interval/digest) in the Forensic Repository. That is, the
ProofMark Server ID points to the server that issued the ProofMark. The Interval chain
start time and Interval start and stop time locate the Interval that issued the ProofMark.
Finally, the ProofMark Sequential Number identifies the specific ProofMark digest in
the meta digest log.

ProofSpace
900 Clancy Ave NE
Grand Rapids, MI 49503
(312) 933.8823
www.proofspace.com ProofMark System Technical Overview — Revised December 2007 15
 ProofSpace White Paper

3.2 ProofMark Validation

The purpose of ProofMark validation is to determine whether a ProofMarked document
is authentic — that it is what it purports to be.
The ProofMark validation process illustrated below is initiated by the application or
ProofMark client and consists of a multi-stage validation process that performs a
number of verifications each designed to test for a specific assertion. The results of the
validation request are described in an XML Validation Report which is returned to the
requesting application or client.

The validation process involves two levels of verifications. The first level is performed
locally on the ProofMark itself, and the second level is performed remotely at the
Forensic Repository. The ProofMark local verifications may be performed by the client
application, and they determine the integrity of the ProofMark and the integrity of the
original data. Increased assurance of the ProofMark can be achieved by performing
verifications at the Forensic Repository. This includes the verification of the Interval
Record, the cross certification record, and the digest log records that are relevant to the
requested ProofMark.
ProofSpace
900 Clancy Ave NE
Grand Rapids, MI 49503
(312) 933.8823
www.proofspace.com ProofMark System Technical Overview — Revised December 2007 16
 ProofSpace White Paper

These two levels of verification are illustrated in the figure below and will be discussed
in the next section.

3.2.1 ProofMark Level Verifications

ProofMark level verifications are cryptographic checks that are local to the ProofMark
and, depending on system configuration, may or may not require resources from the
ProofMark System. There are two ProofMark level verifications:
• ProofMark Integrity Verification: This is a signature-based ProofMark internal
consistency check involving all ProofMark data elements to determine whether the
ProofMark has changed since it was issued.2
• ProofMark Original Data Verification: This verification determines whether the
original data referenced by the ProofMark was the data signed by the ProofMark and
whether it has changed since it was sealed.3
Upon a successful local ProofMark verification it can be assured that the ProofMark and
the corresponding original data are associated and have integrity. However, additional
Forensic Repository level verifications may be needed in order to have higher assurance
regarding the authenticity of the ProofMark.

2 The ProofMark Transient Key Signature is decrypted using the Interval public key yielding the hash of the concatenation of the
previous and issued ProofMark digests. The Previous ProofMark digest contained in the submitted ProofMark is concatenated
with the recalculated ProofMark digest from data elements contained in the ProofMark and hashed. The two digests are
compared and, if identical, the ProofMark data elements have not been changed.
ProofSpace 3 The Original Data digest and Original Data Reference are retrieved from the ProofMark Request contained in the ProofMark. The
Original Data Reference is used to retrieve the Original Data and recalculate a fresh Original Data digest. The recalculated digest
900 Clancy Ave NE is then compared to the one contained in the ProofMark Request and if identical, the ProofMark is of the Original Data and that
Grand Rapids, MI 49503 Original Data has not changed since it was sealed.

(312) 933.8823
www.proofspace.com ProofMark System Technical Overview — Revised December 2007 17
 ProofSpace White Paper

3.2.2 Forensic Repository Level Verifications

Forensic Repository level verifications are performed after the two ProofMark level
verifications are completed. There are three Forensic Repository level verifications.
The validation request that the calling application sends to the ProofMark System has
user-defined parameters that tell the server which verification steps to perform.
• Forensic Repository Interval Verification: This verification process determines
whether the Interval pointed to by the ProofMark was issued by a legitimate
ProofMark Issuing Server, whether the Interval data elements stored in the Forensic
Repository have integrity and whether the ProofMark was issued by this interval.4
• Forensic Repository Cross Certification Verification: At the time a new Interval
is activated, the ProofMark System can be configured to obtain independent
certifications of the Interval data elements from a server other than the ProofMark
Issuing Server. These “independent” servers are referred to as Cross Certification
Servers and they ProofMark the hash of the Interval data elements submitted by
the issuing server. Verification of the Cross certification ProofMark(s) (following the
steps described throughout this document) provides an independent and verifiable
attestation of the Interval data elements.
• Forensic Repository Digest Log Verification: The last stage of ProofMark validation
is verifying the existence and integrity of the ProofMark digest in the Interval’s meta
digest log.5 If the two digests are identical, in combination with successful previous
local and repository level verifications, it can be asserted with confidence that the
ProofMark is authentic; the original data is what it purports to be.

4 First, the Interval Record located in the Forensic Repository is identified using identifiers contained in the ProofMark: ProofMark
Server ID, Interval chain start time and Interval start time. Second, the X.509 certificate for the ProofMark Server is validated.
Third, the ProofMark Server Signature contained in the ProofMark is decrypted using the public key stored in the verified X.509
certificate yielding the hash of the Interval data elements that existed at the time the Interval was activated. The Forensic
Repository Interval Record data elements are hashed and compared with the hash from the server signature. Finally, the public
keys from the ProofMark and from the Forensic Repository Interval Record are compared. If all the above checks produce
positive results, then it can be concluded that the Interval was activated by a legitimate issuing server, that the Interval Record
has not changed since it was activated and that the ProofMark was issued by the validated Interval when it was “on-duty”.
ProofSpace
5 The ProofMark digest contained in the ProofMark is compared to the ProofMark digest located in the Forensic Repository. The
900 Clancy Ave NE Interval’s meta digest log is first located using the Interval Identifier Elements: ProofMark Server ID, Interval chain start time,
Grand Rapids, MI 49503 Interval start and stop time. The ProofMark digest itself is then located using the ProofMark Sequence Number.

(312) 933.8823
www.proofspace.com ProofMark System Technical Overview — Revised December 2007 18
 ProofSpace White Paper

3.3 ProofMark Preservation

The ProofMark Preservation process consists of two major operations. The first one is
registration of an issued ProofMark with the forensic repository, and the second one is
management of the forensic repository. This section describes each operation in detail.

3.3.1 ProofMark Registration

Before the first ProofMark can be issued its corresponding Interval must be
successfully activated by the ProofMark Issuing Server. Once this occurs, every issued
ProofMark within the Interval is registered in the Forensic Repository by recording the
hash of the ProofMark in the Interval’s meta digest log. The Interval meta digest log is a
concatenation of all the hashes of ProofMarks issued during the Interval, as illustrated
in the figure below.
As part of the activation of the next Interval, the hash of the most-recently-expired
Interval’s meta digest log becomes an Interval Data Element for the next Interval called
Previous meta digest. This binds all the ProofMarks issued in one Interval with the
next interval, thus making it infeasible to modify a digest log in the Forensic Repository
without being detected.

3.3.2 Forensic Repository Management

The primary functions of the Forensic Repository are to:
1) preserve data related to time Intervals, referred to as Interval Records;
2) capture and preserve data related to issued ProofMarks; and
3) provide necessary records for validating the authenticity of ProofMarked information.

ProofSpace
900 Clancy Ave NE
Grand Rapids, MI 49503
(312) 933.8823
www.proofspace.com ProofMark System Technical Overview — Revised December 2007 19
 ProofSpace White Paper

A key challenge of any information system is not only to mitigate outside threats by
hackers but risks posed by trusted insiders with administrative access to critical
configuration and operational system parameters and the source data itself. In order
to mitigate these vulnerabilities and ensure a high assurance validation process the
Forensic Repository is designed to detect unauthorized alterations using cryptographic
mechanisms6 and mitigate these risks using a widely witnessed7 and redundant8 system
design. These Forensic Repository attributes create a ProofMark System that has no
single point of failure, vulnerability and attack and has multiple points of validation. This
is illustrated by the figure and discussed in more detail below.

Forensic Nature of Repository

The ProofMark System employs four cryptographic mechanisms designed to verify the
integrity of the Forensic Repository, specifically the Expired Intervals and ProofMark
digests preserved in the repository. Three of the four cryptographic mechanisms were
covered in their corresponding Forensic Repository level verification processes referred
to as ProofMark Validation — Forensic Repository Level Verifications in Section 3.2.2.

6 Cryptographic: As discussed previously, the core data construct of the Repository is the time Interval. The Repository has
“forensic” characteristics as there are several cryptographic mechanisms designed to ensure the integrity of time Intervals and
the ProofMark data preserved in the Repository.
7 Witnessed: The Repository’s time Intervals are “widely witnessed” through a certification process at the time they are activated.
Certification is performed by one or more Cross Certification Servers, an independent server other than the server activating the
ProofSpace Interval. The Interval certification process provides independent proof of the existence of an Interval.
900 Clancy Ave NE 8 Redundant: Critical data within the Repository is maintained redundant. Each time Interval activated by a ProofMark Issuing
Grand Rapids, MI 49503 Server is replicated throughout the ProofMark System distributed archives.

(312) 933.8823
www.proofspace.com ProofMark System Technical Overview — Revised December 2007 20
 ProofSpace White Paper

ProofMark Server Signature: This cryptographic mechanism, involved in the Forensic

Repository Interval Verification stage of validation, verifies whether a given Interval was
issued by a legitimate ProofMark Issuing Server and whether the Interval data elements
stored in the Forensic Repository have integrity over time.
Cross Certification ProofMarks: This cryptographic mechanism, involved in the Forensic
Repository Cross Certification Verification stage of validation, verifies the independent
certification(s) of Intervals performed by Cross Certification Servers at the time they were
activated providing independent proof of their Integrity and of their relationship to time.
Interval Transient Key Signature: This cryptographic mechanism, involved in the Forensic
Repository Cross Interval Verification stage of validation, verifies the integrity of all the
Intervals within an Interval chain. The process starts with the last Interval in the Interval
chain and moves “upstream” to the first interval in the chain.9
Digest Log Verification: This cryptographic mechanism, involved in the Forensic
Repository digest log Verification, verifies the integrity of ProofMark digests contained
within Interval digest logs.
The above cryptographic mechanisms collectively verify the legitimacy of Intervals, the
integrity of the Interval chain, the integrity of Intervals within an Interval chain, and the
digest logs within Intervals.

9 For a given interval within the Interval chain, the Cross Interval Verification is accomplished by using the Previous Interval public key to
decrypt the Interval Transient Key Signature yielding a hash of the Interval public key, Interval start time and Interval stop time. A fresh
hash of these data elements from the Interval Record is generated and compared. If equal, then it is known that the Interval public key and
ProofSpace times are unchanged since they were signed by the previous interval’s Transient private key during activation. The cross interval verification
process continues with the previous Interval until all Intervals in the Interval chain are verified. If all Intervals in the Interval chain verify
900 Clancy Ave NE successfully then it can be assured that no Interval Record in the Interval chain has changed (all have integrity with respect to their Interval
Grand Rapids, MI 49503 public keys and Interval times) since the initiation of the Interval chain by the ProofMark Issuing Server.

(312) 933.8823
www.proofspace.com ProofMark System Technical Overview — Revised December 2007 21
 ProofSpace White Paper

Widely Witnessed
As a new Interval is prepared for activation by a ProofMark Issuing Server it first must
be “certified” by Cross Certification servers within the ProofMark System (if configured
to do so). The ProofMark Issuing Server of the Interval to be activated requests a
certification (i.e., ProofMark) from Cross Certification Server(s). However, before a
certification is issued the time between the two servers is compared to ensure they
are within a prescribed tolerance. If so, the digest of the Interval data elements is
ProofMarked.
Cross certifications create a “widely witnessed” independent network of proof of the
existence of an Interval and its public key at a verified point-in-time. Cross certifications
effectively make it impossible for a trusted insider to manipulate an Interval after it is
activated.

Redundancy
As in any information system, data redundancy is critical to data availability. Data
redundancy is achieved by the replication of the issuing server’s Interval Records to
other servers within the ProofMark System (e.g., Cross Certification Servers) at the
time of activation.
Replication occurs according to an Archive Tree, a “map” listing the host locations of
the archives where copies of the Expired Interval are to be replicated. The Archive Tree
is constructed by using the Issuing Server’s “local archive” as the Root Archive and
then combining “as branches” the Archive Trees of Cross Certification Servers. Each
ProofMark contains the Archive Tree as a data element allowing it to indicate to the
ProofMark System where validation can be performed.
To the degree that an enterprise has implemented data storage architectures involving
such resilient mechanisms as mirroring or alternate data center sites, the ProofMark
System can be implemented to take advantage of many of these facilities and services.

3.4 ProofMark System Operation

The ProofMark System must orchestrate three core functions concurrently:
1) management of Interval records;
2) operation of the current Interval, including the issuance of new ProofMarks; and
3) preparation of the next Interval for activation at the right time.
All these operations are orchestrated according to a common basis of time, as
illustrated in the figure on the next page. Each of these core operations will be
discussed in the following sections.

ProofSpace
900 Clancy Ave NE
Grand Rapids, MI 49503
(312) 933.8823
www.proofspace.com ProofMark System Technical Overview — Revised December 2007 22
 ProofSpace White Paper

3.4.1 Time Sourcing

As was mentioned above, time is critical to the proper operation of the ProofMark
System. Consequently, time is obtained from a trusted time source, such as a National
Timing Authority (NTA), commonly via the Network Timing Protocol (NTP). The system
clock, which is vulnerable to tampering, is never used as a source of time. Time
sourcing from a NTA is done on a periodic basis and in the interim time is calculated via
a time biasing mechanism and provided via a local hardware timer.
Each ProofMark has a time value indicating the time that the ProofMark was actually
issued in UTC, with millisecond precision (Format: “YYYY-MM-DD HH.MM.SS.XXX UTC
[+/-]HH:MM (ZONE)“ ). The time value is a ProofMark Data Element referred to as
ProofMark Time.

3.4.2 Interval Record Management

The ProofMark System manages Interval chains which are composed of contiguous
expired Intervals. Interval chains are designed to deal with breaks in continuous server
operation, as illustrated in the figure below.

ProofSpace
900 Clancy Ave NE
Grand Rapids, MI 49503
(312) 933.8823
www.proofspace.com ProofMark System Technical Overview — Revised December 2007 23
 ProofSpace White Paper

The ProofMark System performs the Repository level verifications of the ProofMark
validation process discussed previously against Expired Intervals first by locating the
relevant Interval chain, followed by issuing Interval and finally the ProofMark digest.
The ProofMark System also performs periodic system integrity checks such as Cross
Interval Verifications testing the integrity of all Expired Intervals within an Interval chain
The ProofMark System performs asynchronous Interval Record (Interval data elements,
ProofMark digest logs, Cross Certification ProofMarks) replications in order to provide
high availability and redundancy against loss. The Interval Records are replicated
throughout the ProofMark System distributed network of servers through an archive
tree as previously discussed.

3.4.3 Current Interval Operation

The ProofMark System operates the active “current” Interval for the prescribed time
period, for example 9:00 to 9:05, which can be configured as to length. ProofMark
requests are received by the ProofMark System and issued within the current Interval
by constructing the ProofMark, registering the ProofMark in the Repository and
responding to the requesting application or client, as previously discussed.

3.4.4 Next Interval Activation

While the Current Interval is in operation, the next Interval is prepared to be activated
— i.e. come “on duty.” There are several steps in the Interval activation process as
follows:
Generate a New Transient Key Pair: The current on duty transient private key will
expire at the end of the Current Interval. The ProofMark System requires a new key pair
to be available at the start of the next Interval. The first step is to generate a new RSA
key pair.
Generate Interval Transient Key Signature: Before the current Interval transient
private key is destroyed it signs the Interval public key of the next Interval providing a
cryptographic binding between the current and next Intervals.
ProofSpace
900 Clancy Ave NE
Grand Rapids, MI 49503
(312) 933.8823
www.proofspace.com ProofMark System Technical Overview — Revised December 2007 24
 ProofSpace White Paper

Generate the Previous Meta Digest: As a Current Interval is about to expire (and
therefore the next Interval is about to be activated) the hash of the digest log
(concatenation of all ProofMark digests) of the most recently expired Interval is
generated, referred to as the previous meta digest, and placed as an Interval data
element of the next Interval. This effectively binds evidence of all ProofMarks issued
during one Interval into its (n+2) successor.
Create Archive Tree: A “map” listing the host locations where copies of the Interval
record are to be replicated. The archive tree is constructed by using the ProofMark
Issuing Server’s “local archive” as the root archive and then combining “as branches”
the archive trees of Cross Certification Servers and Publication Servers.
Obtain Interval Certifications: If the ProofMark System is configured to require
independent certifications of new Intervals as they come “on duty” before they can be
activated, the ProofMark Issuing Server will requests and must successfully receive
Interval certifications from Cross Certification Server(s). However, a precondition of
receiving an Interval certification from a Cross Certification Server is its time must
match that of the ProofMark Issuing Server within a specified tolerance.
Generate ProofMark Server Signature: the ProofMark Issuing Server activating the
next Interval signs using its PKI server certificate (i.e., private key) the Interval data
elements of the new Interval.
Publish Interval Record: The Interval Record is published to the ProofMark Issuing
Server “root” archive and at other archives as specified by the Archive Tree.
Destroy Transient Private Key: Core to the high assurance characteristic of the
ProofMark System is the short-lived nature of the transient private key. The last step
of activation process is the irreversible destruction of the Current Interval’s transient
private key.

ProofSpace
900 Clancy Ave NE
Grand Rapids, MI 49503
(312) 933.8823
www.proofspace.com ProofMark System Technical Overview — Revised December 2007 25
 ProofSpace White Paper

Conclusion
The ProofMark system is an innovative solution for ensuring and proving the
authenticity of electronic data and implementing trusted timestamps. The primary
advancement of the ProofMark technology is to eliminate the administrative overhead
and security risks associated with a private signing key in conventional X.509 digital
signature applications. This is accomplished by combining patented transient key
technology with other well-established cryptographic mechanisms.
Some highlights of the system are summarized below:
1. The ProofMark system does not issue signing keys to humans, which eliminates
a primary failure-point common to traditional digital signature systems. Instead,
a transient private key is generated and bound to a short time interval, just a few
minutes long.
2. Any ProofMark request is processed within the time interval using cryptographic
mechanisms: first the data is hashed to produce a digest, and then the digest is
signed by the interval transient private key to produce the ProofMark.
3. All ProofMark requests to the system are accumulated by chaining the digest
logs together in a secure way, preventing any fraudulent insertion, deletion, or
manipulation of the issued ProofMarks by either outsiders or insiders in the future.
4. At the end of each time interval, the transient private key is destroyed, preventing it
from ever being disclosed. This eliminates another risk factor common to competing
digital signature systems, where high-level private keys persist (and are therefore
vulnerable to be hacked or stolen) for years at a time. Furthermore, the transient
private keys associated with different time intervals are generated independently,
providing both forward and backward security even in the event that a particular
private key is compromised.
For more information about ProofSpace and its patented ProofMark Transient Key
technology, please visit the company website at www.proofspace.com.

ProofSpace
900 Clancy Ave NE
Grand Rapids, MI 49503
(312) 933.8823
www.proofspace.com ProofMark System Technical Overview — Revised December 2007 26
 ProofSpace White Paper

Bibliography

[1] ANSI X9.31. Digital Signatures Using Reversible Public Key Cryptography for the
Financial Industry. 1998.
[2] ANSI X9.95. Trusted Time Stamp Management and Security. 2005.
[3] IEFT RFC 3161. C. Adams etc. Internet X.509 Public Key Infrastructure Time Stamp
Protocol. August 2001. http://www.ietf.org/rfc/rfc3161.txt
[4] NIST FIPS 180-2. Secure Hash Standard. August 2002.
http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf
[5] NIST FIPS 186-2. Digital Signature Standard. January 2000.
http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf
[6] RSA Laboratories. Crypto FAQ. http://www.rsa.com/rsalabs/node.asp?id=2152
[7] Bruce Schneier. Applied Cryptography. Second Edition. John Wiley & Sons. 1996.
http://www.schneier.com/book-applied.html
[8] US Patent #6,381,696. M. Doyle. Method and System for Transient Key Digital Time
Stamps. Issued on April 30, 2002.

ProofSpace
900 Clancy Ave NE
Grand Rapids, MI 49503
(312) 933.8823
www.proofspace.com ProofMark System Technical Overview — Revised December 2007 27
 ProofSpace White Paper

About the Authors

Jacques Francoeur, VP Professional Services, ProofSpace

As Vice President of Professional Services and Chief Evangelist at ProofSpace
Francoeur is responsible for professional services and thought leadership. A domain
expert in trusted electronic business and legal admissibility of electronically stored
information, he regularly authors white papers and makes presentations internationally.
As Executive Director of the Bay Area CSO Council, a nonprofit member-based
organization, Francoeur manages a trusted virtual community of leading Bay Area Chief
Security Officers (CSO), and hosts private and public CSO round tables. He founded
TrustEra and Forensic Signature Corp., specializing in the fields of enterprise electronic
risk management and high assurance digital signatures, respectively. Francoeur
also served as an instructor of Trusted e-Business and Trusted e-Systems at the
University of California, Berkeley Extension. He is an experienced public speaker and
established author and is often invited to speak on the legal, regulatory and technical
aspects of electronic business assurance, including digital accountability, digital trust
management and digital signatures.

Bruce Moulton, Independent Security Consultant

Bruce Moulton was most recently VP Information Security Business Strategy for
Symantec Corporation. He was a co-founder and the first elected chairman of the
Financial Services Information Sharing and Analysis Center (FS/ISAC), and has served
in senior leadership roles for the International Information Integrity Institute (I-4);
BITS; the technology task force of the Investment Company Institute (ICI); and for the
Securities Industry Root Certificate Authority (SIRCA). Mr. Moulton currently sits on
the board of directors of The Center for Internet Security (CIS). Previously, Moulton
was VP and CISO for Fidelity Investments where he had additional responsibilities for
the enterprise business contingency planning program and for worldwide technology
supporting physical security functions. Moulton also served VP of IT Audit where he
built and managed Fidelity Investments’ world-class IT audit group.

Kurt Stammberger, VP Marketing, ProofSpace

Kurt has 17+ years of experience in marketing infosec and cryptography technologies.
He joined cryptography startup RSA Security as employee #7, where he led their
marketing organization for eight years, helped launch spin-off company VeriSign,
and created the brand for the technology that now protects virtually every electronic
commerce transaction on the planet. He founded and still serves on the Board of
the annual RSA Conference, the world’s largest gatherings of computer security
professionals, which draw over 25,000 people to events in the United States, Europe and
Japan. He founded Coda Creative, a technology marketing firm for startups, and was
recently VP Content & Services for consumer healthcare startup Vimo.com.

ProofSpace
900 Clancy Ave NE
Grand Rapids, MI 49503
(312) 933.8823
www.proofspace.com ProofMark System Technical Overview — Revised December 2007 28
 ProofSpace White Paper

Dr. Yiqun Lisa Yin, Independent Security Consultant

Dr. Yin is currently an independent security consultant based in Connecticut. She has
over fifteen years of research and industry experience in cryptography and security.
She held positions as director of security technologies at NTT Labs in California, senior
scientist at RSA Labs, and visiting researcher at Princeton University. She received her
B.S. from Beijing University in 1989 and Ph.D. from MIT in 1994.
Dr. Yin is a well-known expert in the field of cryptography and security. From 1996 to
2000, she served as the chief editor of IEEE P1363, the first comprehensive standard
for public key cryptography. She was a co-inventor of RC6, a finalist for the Advanced
Encryption Standard. She was one of the three Chinese researchers who broke the NIST
hash standard SHA-1 in 2005.

ProofSpace Technical Advisory Board

Dr. Guy Bunker

Dr. Bunker is a Distinguished Engineer at Symantec, responsible for technical strategy
within the data management division and various research projects around intelligent
archiving. He has worked for Symantec (formerly VERITAS) for nearly a decade in a
number of divisions and roles. He has driven industry standards in computer storage
and management. He is a regular presenter at conferences and recently published
his second book: Delivering Utility Computing: Business-driven IT Optimization. While at
Oracle, he architected their BPR tools. He holds a PhD in Artificial Neural Networks
from King’s College London and is a Chartered Engineer with the IEE.

Dr. Taher Elgamal

Dr. Elgamal is one of the world’s leading cryptographers and an expert in computer,
network and information security. His theories are so pervasive that the space is often
referred to as “Elgamal Cryptography”. He participated in a number of Internet payment
schemes (eg, SET) and invented and patented the SSL protocol while at Netscape.
He was chief scientist at Netscape Communications, director of engineering at RSA
Security, and founder of Securify. He is a Venture Advisor with Diamondhead Ventures,
and sits on the boards of several technology companies. He holds a B.S. from Cairo
University, and Masters and Doctorate degrees in Computer Science from Stanford
University.

ProofSpace
900 Clancy Ave NE
Grand Rapids, MI 49503
(312) 933.8823
www.proofspace.com ProofMark System Technical Overview — Revised December 2007 29
 ProofSpace White Paper

Dr. Dan Geer

Dr. Geer is a pioneer in the information security world who has raised critical issues
before others could see the risk. He is currently Chief Scientist at Verdasys. He ran the
development arm of MIT’s Project Athena, where he helped pioneer Kerberos, the X
Window System, and much of what we take for granted in distributed computing. He
was the CTO for @stake, a computer security consulting company, and has held senior
technical roles at Harvard’s School of Public Health, Digital Equipment Corp., Geer
Zolot & Associates, OpenVision Technologies, Open Market, and Certco. He has a B.S.
in Electrical Engineering and Computer Science from MIT and a Ph.D. in biostatistics
from Harvard.

Ed Reed
Mr. Reed is Sr. Director of Development Services at Aesec, a developer of verifiably
secure computing platforms. Previously, he was the Security Tzar at Novell, responsible
for leading security product strategy, and worked to develop Novell’s enterprise-
oriented identity-based computing efforts. He is a frequent speaker at industry,
technology and analyst briefings and conferences. His standards activities have
included work with the IETF (LDAP, LDUP), DMTF, and OASIS. He is a graduate of
Purdue University (BS), and Rochester Institute of Technology (MSCS).

Dean Tribble
Mr. Tribble is a leader in creating secure, distributed systems who has founded
several technology companies. He is a Principal Architect at Microsoft, where he led
development of security and compliance features for Microsoft Exchange, and now is
incubating new operating systems technologies. He was founder and CTO for Agorics,
which developed security and ecommerce solutions for Fortune 500 companies;
his work was granted nine U.S. patents in electronic commerce, secure distributed
systems, and computer resource allocation. Previously, he pioneered secure,
distributed programming languages, hypermedia publishing systems (pre-Web), and
on-line information marketplaces at companies such as Xerox PARC and Autodesk.

ProofSpace
900 Clancy Ave NE
Grand Rapids, MI 49503
(312) 933.8823
www.proofspace.com ProofMark System Technical Overview — Revised December 2007 30
 ProofSpace White Paper

ProofSpace Business Advisory Board

Mike Miracle
Mike is a senior technology operating executive with expertise in strategy, business
development, strategic alliances (OEM and partnerships), product management
and marketing, and software development. He has been an advisor to several IT
infrastructure companies including Blackball, BladeLogic, Double Take (NSI Software),
InterSAN (sold to Finisar), OuterBay (sold to HP), and Princeton Softech. He has served
on the board of Connected Corporation (sold to Iron Mountain), Precise Software (sold
to Veritas), Evident Software, Neartek (sold to EMC), Mediconnect.net (sold to private
equity), and NuView (sold to Brocade). Mike was EVP of Product Management and
Marketing for Evident Software. As a VP at Veritas, he managed M&A, strategic venture
investing, technology licensing, and divestitures, completing numerous transactions.
He has held a variety of senior technical management positions at Hewlett Packard,
Novell, and Unix Systems Labs where he focused on operating systems development,
product management and OEM partnerships. He started his career developing
telecommunications software with AT&T Bell Labs. Mike holds a BS in Electrical and
Computer Engineering from the University of Wisconsin, and a Master’s degree from
Stanford University.

Howard Schmidt
Howard is a leading expert on defense, law enforcement and corporate security. Most
recently he was the Chief Security Strategist for the US CERT Partners Program for
the National Cyber Security Division, Department of Homeland Security. He was the
CISO and Chief Security Strategist for eBay, and was appointed by President Bush in
2001 as Vice Chair of the President’s Critical Infrastructure Protection Board and as
the Special Adviser for Cyberspace Security for the White House. He was the chief
security officer for Microsoft, where his duties included CISO, CSO and forming the
Trustworthy Computing Security Strategies Group. He was a supervisory special
agent and director of the Air Force Office of Special Investigations (AFOSI) Computer
Forensic Lab and Computer Crime and Information Warfare Division; while there, he
established the first dedicated computer forensic lab in the government. He has worked
on computer security with the FBI and the Army, and serves on numerous international
organizations. He is a co-author of the Black Book on Corporate Security, and is regularly
featured on CNN, CNBC, and Fox TV talking about cyber-security. He holds a bachelor’s
degree in business and a master’s degree in organizational management from the
University of Phoenix.

ProofSpace
900 Clancy Ave NE
Grand Rapids, MI 49503
(312) 933.8823
www.proofspace.com ProofMark System Technical Overview — Revised December 2007 31
 ProofSpace White Paper

Ed Gaudet
Ed is currently Vice President of Product Management and Marketing for Liquid
Machines. Most recently, Ed was Vice President of Worldwide Marketing for IONA
Technologies, the leading e-business platform provider for Web services integration.
During his three-year tenure at IONA, Ed was responsible for overall corporate
branding; product, partner and field marketing; and corporate communications. As
a member of the senior management team, Ed contributed to the company’s overall
business and operating strategies, which generated more than $181 million in
revenue in 2001. Prior to this experience, Ed held several senior marketing, product
management and business development positions in various start-up and public
software companies, including Rational Software, a provider of an integrated enterprise
development environment, and SQA Inc., a leader in automated testing solutions. Ed
received his bachelor’s degree from Bentley College in Waltham, Mass.

Michael A. Aisenberg
Mr. Aisenberg is Counselor to the President of Information & Infrastructure
Technologies, Inc., the largest operating subsidiary of Electronic Warfare Associates
(EWA). EWA is a privately held technology consulting and management firm, with global
government and commercial clients in the defense, intelligence, security and critical
infrastructure communities. He supports work with the Department of Homeland
SSecurity on cyber security response and the implementation of sector security plans
in IT and communications, with the Department of Justice on network-based abuses
against financial, transportation, defense and other critical infrastructures, and with
DNI on reform of the national classification system. A member of the D.C. Bar, he is a
graduate of the University of Pennsylvania and the University of Maine School of Law,
and attended Georgetown University Law Center. He has taught Communications Law
at the University of Maryland, and has been published on topics including Y2 K Liability
and Authentication in the Domain Name System.

ProofSpace
900 Clancy Ave NE
Grand Rapids, MI 49503
(312) 933.8823
©2007 ProofSpace. All Rights Reserved. ProofSpace, Transient Key, the ProofSpace logo, ProofMark and the ProofMark
System are trademarks of ProofSpace Inc. All other trademarks are owned by their respective companies. 32