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 1.1 What is a ProofMark? 1.2 What is the ProofMark System? 1.3 Integrating the ProofMark System into the Information Life Cycle 2. The ProofMark System — Core Constructs and Architecture 2.1 ProofMark System Core Constructs 2.1.1 The Time Interval 2.1.2 The Public/Private Key Pair 2.2 ProofMark System Architecture 2.2.1 ProofMark Servers and Clients 2.2.2 Forensic Repository 3. The ProofMark System — Processes and Operations 3.1 ProofMark Issuance 3.1.1 The ProofMark Request 3.1.2 ProofMark Construction 3.1.3 ProofMark Response 3.2 ProofMark Validation 3.2.1 ProofMark Level Verifications 3.2.2 Forensic Repository Level Verifications 3.3 ProofMark Preservation 3.3.1 ProofMark Registration 3.3.2 Forensic Repository Management 3.4 ProofMark System Operation 3.4.1 Time Sourcing 3.4.2 Interval Record Management 3.4.3 Current Interval Operation 3.4.4 Next Interval Activation Conclusion Bibliography About the Authors ProofSpace Technical Advisory Board
ProofSpace 900 Clancy Ave NE Grand Rapids, MI 49503 (312) 933.8823 www.proofspace.com

3 4 5 6 8 8 8 9 9 9 10 10 10 11 12 15 16 17 18 19 19 19 22 23 23 24 24 26 27 28 29 31

ProofSpace Business Advisory Board

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 validation.

ProofSpace 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 System for validation and reviewing the results of the validation report. (Requesting a ProofMark validation is illustrated by the lower right side of the diagram.)

ProofSpace 900 Clancy Ave NE 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 systemconfigurable. 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 shortlived 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 Grand Rapids, MI 49503 (312) 933.8823 www.proofspace.com

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. A secure hash function, such as SHA-256, is used to compute the hash.

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.

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

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.

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 900 Clancy Ave NE Grand Rapids, MI 49503 (312) 933.8823 www.proofspace.com

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 is then compared to the one contained in the ProofMark Request and if identical, the ProofMark is of the Original Data and that Original Data has not changed since it was sealed.

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.

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

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”. 5 The ProofMark digest contained in the ProofMark is compared to the ProofMark digest located in the Forensic Repository. The Interval’s meta digest log is first located using the Interval Identifier Elements: ProofMark Server ID, Interval chain start time, Interval start and stop time. The ProofMark digest itself is then located using the ProofMark Sequence Number.

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

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

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 Interval. The Interval certification process provides independent proof of the existence of an Interval.

8 Redundant: Critical data within the Repository is maintained redundant. Each time Interval activated by a ProofMark Issuing Server is replicated throughout the ProofMark System distributed archives.

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.

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

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 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 successfully then it can be assured that no Interval Record in the Interval chain has changed (all have integrity with respect to their Interval public keys and Interval times) since the initiation of the Interval chain by the ProofMark Issuing Server.

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 enterpriseoriented 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

Master your semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master your semester with Scribd & The New York Times

Cancel anytime.