ProofMark System Concepts, Architecture, & Planning Guide 2.08

8/14/2019 ProofMark System Concepts, Architecture, & Planning Guide 2.08

1/50

ProofMark System Concepts, Architecture, and Planning Guide

February 2008


2/50


3/50

contents

contents.............................................................................................3 introduction .......................................................................................1whats in this guide .................................................................. ...........2additional documentation ................................................ ....................3technology overview.......................................................................... 4the client component ............................................................... ...........4the server component...... ........................................................ ...........4

creating Intervals...................................................... ....................5issuing ProofMark certificates ..................................................... ..5verifying ProofMark certificates ................................................... ..6

Intervals and transient-key technology............................................... ..6

additional safeguards..........................................................................7sample of transaction flow....................................................... ...........8product architecture ..........................................................................9system components.................. ........................................................ ..9servlet overview.................................................... ............................ 10platform specifications...................................................................... 12client API .................................................... ..................................... 13issuance request options................................................................... 13performance considerations.............................................................. 14

multi-processor support .................................................... ......... 15load balancing .................... ........................................................ 15hardware acceleration ....................................................... ......... 15summary chart...................................... ..................................... 15

persistent storage options............................ ..................................... 16core concepts................................................................................... 17the client component ............................................................... ......... 17

ProofMark requests...................... .............................................. 17verification requests ..................... .............................................. 18

the server component ..................................................... .................. 18ProofMark certificates ....................................................... ......... 19

definition of a ProofMark certificate .......................................20Intervals.....................................................................................20

definition of an Interval............ .............................................. 21Interval chains.............. ........................................................ 21using Intervals to issue ProofMark certificates..... .................. 22

Interval cross-certification ................................................. .........24trusted time ....................... ........................................................ 25digest logs..................................................................................25ensuring server and Interval identity ............................................ 26


4/50

verification ..................................................... ............................ 27ProofMark internal verification .............................................. 28Interval verification ...................................................... .........28cross-certification verification ............................................... 29digest log verification ....................... ..................................... 29ProofMark verification reports.......... ..................................... 29

archives.....................................................................................30 the ProofMark archive directory ............................................. 30replication............................................................................30the Interval archive tree ........................................................ 31archive integrity ............................... ..................................... 32

publication ........................................................................ .........32syslog / message log.............................. ..................................... 33

planning your ProofMark implementation .........................................34considerations for selecting an Interval length.................................... 34

smaller target for hackers........................................................... 34Intervals are independently cross-certified................. .................. 35

creation of the next Interval ................................................ .........35storage of Intervals................................................... .................. 35

topology considerations......................................... ............................ 36intra-organizational topologies...... .............................................. 36

reciprocal peer topology............................ ............................ 37load balancing topology................................................ .........37

inter-organizational topologies .................................................... 38meshed peer topology .................................................. .........39hierarchical topology .............. .............................................. 40

appendix Acryptography primer ....................................................42basic concepts........ ........................................................ .................. 42uses of cryptography ....................................................... .................. 44appendix Bglossary ......................................................................45index ...............................................................................................48


5/50

introduction / whats in this guide

ProofSpace , Inc., 1999-2008

Proprietary and Confidential. All rights reserved.

1

introduction

The ProofMark software solution is a broadly applicable system that operates on

a computer, server, network, system, or infrastructure. This system utilizes

public-key cryptography to create an irrefutable record of the time-existence and

exact composition of any digital data.

Today's computer systems do not provide the means of proving exactly what

exists in a set of electronic data or file at a specific point in time. Current

operating systems mark data and files with a date and time as the date and files

are created or modified. These date and timestamps may be inaccurate and

must be considered unreliable, especially since users can easily manipulate the

data and/or the date and time stamp provided by the computer. Time stamps

may be inaccurate because of intentional or unintentional manipulation; different

time zones, clock inaccuracies or daylight savings time adjustments. More

importantly, operating system-generated date and time stamps offer no form ofproof of data integrity at a particular point in time.

Using the ProofMark system, a ProofMark server issues a certificate that

contains the proof for an online event of what someone did& when they did it.

A ProofMark certificate shrink-wraps any type of digital data using

public-key cryptography, proving its authenticity at a particular point in

time.

Possible uses of the ProofMark system include:

- Electronic Commercedigital receipts for Internet purchases and business-to-

business transactions

- Healthcare or medical applicationsauthenticity of patient records, x-rays, a

secure audit trail of who looked at what data, when

- Securities Tradingbrokerage order acknowledgements and confirmations

- Online bankingproof of bill payments, account transfers

- Drug Trialsa chain-of-proof of the test results over time

- Electronic Communicationscontent integrity of e-mail or attached files

The ProofMark certificate provides an independently verifiable, digital proof of

the state of the electronic data set at a moment in time. ProofMark certificates

are created using ProofSpaces transient-key technology, which protects the

private key used to encrypt the data. The ProofMark system distributes the proof

of the existence of the private key used to create the ProofMark certificates over

a network of servers. This provides independent verification from outside of the

organization that created the ProofMark certificate. In addition, the ProofMark


6/50

introduction / whats in this guide



2

system verifies the timestamp included in the ProofMark certificate by

crosschecking the time across servers.

Examples of the data that can be included in a ProofMark certificate include

transaction data, SQL queries, files on a user's hard drive, and graphic or

medical images. In addition to data, the ProofMark certificate can capture the

identity of the entities involved with the transaction (owners, authors, buyers,sellers, servers, users, companies). Identity data can include whatever you use

as your current methods for authenticating users, including login name, id

number, or a PKI signature.

whats in this guide

This document, the ProofMark System Concepts, Architecture, and Planning

Guide, provides you with a broad technical overview of the ProofMark system.

You should read this guide if you are involved in the implementation of a

ProofMark system from a technical perspective. Appropriate readers include:

- Application programmers who will be designing and writing code to integrate

the ProofMark server into applications

- Network and Security Administrators who need to certify the products security

protocols and understand the implications to the rest of their corporate security

infrastructure

- Database Administrators who will provide the data support for the product

Additional interested readers may include IT Managers, Quality Assurance

Analysts, and anyone who is interested in how the ProofMark system works.

The guide is organized as follows:

Product architecture. This section describes the system components, platform

specifications, and configuration and performance considerations.

Core concepts. This section describes the core concepts of the ProofMark

system, grouping them by client and server.

Planning your ProofMark implementation . This section describes the

considerations for selecting Interval length and topology considerations.

Appendix A cryptography primer. Appendix A provides a very brief introduction

to the terminology and concepts used in cryptography.

Appendix B glossary. Appendix B provides a glossary including many of the

terms used in this document.


7/50


8/50

technology overview / the server component



4

technology overview

The ProofMark system is based on ProofSpace's transient-key technology. The

ProofMark system has been designed specifically to support high volume

transaction situations, using public key cryptography in an innovative way to

provide irrefutable proof of the what, when, and who of an electronic

transaction or activity. (See appendix Acryptography primer if you are

unfamiliar with applied cryptography.)

The ProofMark system consists of both client and server components.

This brief technology overview includes the following:

- The client component

- The server component

- Intervals and transient-key technology

- Additional safeguards

- Sample of transaction flow

the client component

The client component of the ProofMark system consists of the ProofMark clientAPI, which you use from your corporate systems to request the issuance or

verification of ProofMark certificates from the ProofMark server.

The Programmer's Guide contains the information your development staff needs

to integrate your corporate systems with the ProofMark system.

the server component

When you use the ProofMark system, you set up one or more ProofMark servers,which have three primary responsibilities:

- Creating Intervals

- Issuing ProofMark certificates

- Verifying ProofMark certificates


9/50

technology overview / the server component



5

The Server Installation & Configuration Guide contains the information you need

to configure all aspects of the ProofMark system to meet the needs of your

organization.

creating Intervals

Intervals are created by the ProofMark system to provide transient key pairs for

encrypting data. Each Interval produces one key pair, with a private key that is

available only for the duration of the Interval, and a public key, which is passedon to an archive tree. The archive tree provides the redundancy and ease of

access.

In addition to creating the key pair, each Interval attests to the next Interval in the

Interval chain. This chain of Intervals, each signed by the previous Interval, is

used to provide verifiable proof for the ProofMark certificates produced by the

ProofMark system.

Intervals exist for a pre-determined length of time (defined when you configure

the system). At the end of each Interval, the private key is destroyed. The private

key has existed only for the duration of the Interval, and has never been written

to a storage device, increasing the security of the system.

A more complete definition of an Interval is included in the Core Concepts section

of this document.

issuing ProofMark certificates

A ProofMark certificate is a signed XML (eXtensible Markup Language)

document, created with the Intervals private key.

ProofMark certificates contain the data to be certified (the what), a time stampfrom a trusted time source (the when), and optionally the identity information

of the parties involved (the who). A ProofMark certificate also includes the

public key of the Interval used to create it and information about where to find an

archive that can be used to verify the ProofMark certificate.


10/50

technology overview / Intervals and transient-key technology



6

Dissection of a ProofMark Certificate

Request

Interval Information

Timestamp

Digital Signature

verifying ProofMark certificates

A ProofMark Verification Report is issued by a ProofMark server in response to

receiving a request for verification of a ProofMark certificate. There are multiple

levels of verification available. These levels range from confirming that the data

in the ProofMark certificate has not been tampered with (a consistency check)

through a recursive validation of the Interval chain used to sign the ProofMark

certificate, to checking a log for record of the creation of the ProofMark

certificate being verified.

Intervals and transient-key technology

The use of transient-key technology removes the necessity of long-term

protection of the private key in a public/private key pair. The private key is used

for some relatively short period of time (an Interval) to generate signatures, and

is then destroyed. The use of cross-certification across multiple servers

provides a widely witnessed and distributed proof model that attests to theintegrity of the ProofMark certificates created during the Intervals.

By using transient-key technology:

- The private key exists only for a short period of time (the duration of the

Interval)

- The private key is never stored on disk, transmitted over a network, or

distributed or backed up in any way

- If a supported Hardware Security Module (HSM) or crypto-processor board is

used, the key pair will be generated by the board and never given to the server

application at all (instead, the key pair is kept in protected storage inside the


11/50

technology overview / additional safeguards



7

crypto-processor for use in generating signatures, and then the private key is

destroyed when no longer needed)

Because the private key exists in only one place and for a very short period of

time, the risk of someone stealing the private key is minimal.

To strengthen the integrity of the transient key pairs, they are chained together

and then cross-chained across other servers. This creates a widely witnessed

web of key signatures and cross-key signatures, eliminating a single server as a

point of attack. To steal the private key of an Interval would require access to all

of the servers cross-certifying the Interval.

additional safeguards

The ProofMark servers transient-key technology provides the means to issue

cryptographically secure ProofMark certificates. Other security measuresincluded in the ProofMark system further strengthen its integrity. These are

described in detail in the Core Concepts section, and include:

- Interval cross-certification (see Interval cross-certification)

- Digest logs (see digest logs)

- Network Timing Protocol (NTP) (see trusted time)

- (Optional) HSM or Cryptographic accelerator card (see hardware acceleration)


12/50

technology overview / sample of transaction flow



8

sample of transaction flow

The following diagram displays one of many example scenarios involving the use

of the ProofMark system.

Online Banking TransactionPayment Acknowledgment

Scenario

ProofMarkServer

ProofMark StorageCustomer

XYZ Online Banking Co.

Firewall

(1) Pay Mortgage

Issue ProofMark (4)

ProofMark XML (5)

Acknowledgement Receipt (6)

ProofMark XML

this is anacknolwled

gement

of your orderfor 100

eolas shares

1) Customer requests to pay monthly mortgage2) Banking server issues electronic paymentrequest to banks payment execution system3) Banks payment execution system issuespayment acknowledgement4) Banking server requests a ProofMark filefrom ProofMark server5) ProofMark server generates an XML file(receipt) and returns it to the banking server6) Banking server returns the "receipt" to thecustomer7) Customer stores and optionally prints thereceipt

Typical Scenario

Payment ExecutionSystem

Banking Web Server

Print Receipt(7)

Issue payment (2)

Payment Complete (3)

In this scenario, the client API is running within the Banking Web Server and

providing communication to the ProofMark server for issuing and verifying

ProofMark certificates. The Bank has chosen to store the certificates

themselves. Optionally, the ProofMark server can be configured to store the

certificates.


13/50

product architecture / system components



9

product architecture

This section describes the following aspects of the ProofMark system:

- System components

- Servlet overview

- Platform specifications

- Client API

- Issuance request options

- Performance considerations

- Persistent storage options

- Additional product use-cases

system components

There are two components to the ProofMark system:

- ProofMark server

- ProofMark client API


14/50

product architecture / servlet overview



10

Customer Application

ProofMark Client API

ProofMark Software Architecture

HTTPS/HTTP 1. 1

HTTP Server

Application Server /Servlet Engine

OS

Database

ProofMark Servlets

ProofMark Server

Browser

ProofMark Client

Web/HTTP Server

HTML Servlets

XML ProofMark request

newly created ProofMark

ProofMark generatinguser event

The ProofMark server is implemented as a set of Java Servlets that run on an

Application Server.

The ProofMark client API is implemented as a Java class library and runs in a

Java Virtual Machine. The client API typically runs in your corporate

environment, not in an end-user's browser or on the end-user's desktop (though

it could for standalone applications). You use the client API to request or verify

ProofMark certificates from your corporate systems. The client API helps to

simplify the implementation of the ProofMark server. For details on the client

API, see the ProofMark Programmers Guide.

The ProofMark system supports application integration in languages other than

Java, provided the client-programming environment supports TCP/IP and HTTP.

Because the ProofMark certificates and API-to-server layer utilize XML, the

client-programming environment must be able to format and parse XML

documents.

The client API communicates with the server via standard HTTPS/HTTP 1.1.

servlet overview

As depicted in the diagram below, there are seven main servlets on the

ProofSpace server.


15/50

product architecture / servlet overview



11

Customer Application

HTML Servlets

ProofMark Client API

JSP

Servlet Engine

HTTP Server

ProofMark Software Architecture

Retriever

HTTPS/HTTP 1.1

HTTP ServerApache

othersNetscape

Application Server /Servlet Engine

JRunJSWDK

JServWebLogic

WebSphere

OS - 2000, NT, LINUX, Solaris

Database

JDBCDB2

OracleNative File

System

ProofMark Servlets

Message Logging

NTP

Client API

Cross Certifier

Publisher

Replicator

ProofMark Server

OS

Browser

Issuer

VerifierProofMark Client

Propagator

The following table identifies the primary purpose of each servlet.

Servlet Purpose

Issuer Responds to requests from the client API for the issuance of a

ProofMark certificate

Verifier Responds to requests from the client API for verification of a

ProofMark certificate

Retriever Responds to requests from the client API for the retrieval of a

ProofMark certificate, given a ProofMark reference

Cross Certifier Issues ProofMark certificates to certify another ProofMark

servers Intervals

Publisher Stores Intervals and ProofMark certificates


16/50


17/50

product architecture / issuance request options



13

Within the context of the ProofMark system, the term client API is not referring

to software that would ultimately reside on a consumer desktop (a two-tier

architecture, although there are situations where this could occur). This API

typically is used in your internal core systems, where your web-based online

ordering system utilizes the client API to request ProofMark certificates (a 3-tier

or n-tier architecture).

If you apply the ProofSpace technology for an end-user or consumer side

application where the end-user interact directly with the ProofMark server, then

the client API would reside on the end-users machine.

The API provides a mediating layer between your systems and the ProofMark

server to make it easy for you to integrate ProofMark functionality into your

processes.

The client API provides for a high-level Java object interface to the lower-level

HTTP / XML interface. This document primarily describes the Java object

programming and XML interfaces; a brief section on implementing a non-JavaHTTP client (which also uses XML) is also included.

issuance request options

Through the Client API you can choose among several options for generating

ProofMark certificates. Each option offers different benefits that may apply to

your particular requirements. When generating a ProofMark certificate you can:

- Request that the ProofMark server return either the ProofMark certificate itself

or a reference to the ProofMark certificate

- Include the original data (transaction data, file, etc.) in the ProofMark certificate

or just include a reference to the original data

A ProofMark reference is like a URL that can be used for later retrieval. The

ProofMark reference could be returned to the original requestor and/or stored

with the transaction detail for future verification purposes. If a ProofMark

reference is returned you need to configure the ProofMark server to store the

ProofMark certificates for you in some persistence mechanism.

If the data size is relatively small you can include it in the ProofMark certificate

itself. Alternatively, when ProofMarking very large data you can include a

reference (e.g. file name, ID, or other reference) to the data instead. This option

removes the requirement to transmit the data to the ProofMark server, but

assumes that you can get back to the data when the ProofMark certificate is later

verified.


18/50

product architecture / performance considerations



14

Dissection of a ProofMark Reference

Interval Server ID

Interval Chain Start Time

Interval Start Time

ProofMark Sequence Number

performance considerations

There are several configuration options that affect the throughput of the

ProofMark system. These include:

- Multi-processor support

- Load balancing

- Hardware acceleration

multi-processor support

We strongly recommend that you run on a multi-processor (MP) machine.

Cryptographic algorithms perform mathematical calculations on large numbers.

An MP machine greatly improves the servers performance, and requires no

configuration change to your ProofMark server.

load balancing

A Multiplexing proxy set in front of a group of ProofMark servers will increase

throughput. Generally, we found that each server added will provide an 85%

increase in throughput from a single server.


19/50

product architecture / persistent storage options



15

When you use a Multiplexing proxy, your client applications point at the proxy,

and the proxy redirects the request to actual ProofMark servers based on

current workload.

hardware acceleration

A third option that greatly increases performance is a Cryptographic Accelerator

card, which is a piece of dedicated hardware that can create key pairs, issue

signatures, and verify signatures. For example, nCiphers nFast300 can increase

the throughout of an MP machine by approximately 300%.

persistent storage options

The are two storage options for Intervals, ProofMark certificates, and Digest

Logs:

- Any JDBC compliant database

- The local file system can be used (information is stored hierarchically in

folders)

You can use both options in combination: file system for Intervals and Digest

Logs, a relational database for ProofMark certificates.

Storage options are discussed in more detail in the Administrators Guide.


20/50

core concepts / the client component



16

core concepts

This section describes the core concepts of the ProofMark system. This section

is broken into two primary areas:

- The client component

- The server component

the client component

On the client side, the ProofMark client API (which runs in your corporate

environment, not directly on the desktop of the users) receives requests via

HTTP. These requests can be for the issuance of ProofMark certificates or forthe verification of previously issued ProofMark certificates.

ProofMark requests

A ProofMark request contains the following information:

- A reference to the data being ProofMarked, such as a filename or a SQL string

or the actual data to be ProofMarked (used when the amount of data to be

ProofMarked is relatively small and can be included in the request)

- An SHA1/SHA2 digest of the contents of the data or the data referred to by the

reference (the digest is prepared by your client program when creating the

ProofMark Request)

- Zero or more X.509 certificates acting as witnesses to the request (to include

X.509 certificates, your application must provide the signed hash of the

transaction data to the ProofMark client API)There are additional options that can be used when requesting a ProofMark

certificate, indicating whether the ProofMark certificate should be stored on the

ProofMark server or whether only a reference to the certificate should be

returned. These options are described in the Programmer's Guide.

verification requests

The API also supports verification of previously issued ProofMark certificates.

There are several levels of verification:


21/50

core concepts / the server component



17

- An internal consistency check (validating the signature within the ProofMark

certificate using the public key)

- Sending the ProofMark certificate to a ProofMark archive server for

authentication

- Recursively verifying the integrity of the Interval chain using Cross-certifications

- Recursively verifying the integrity of the Interval chain using Cross-

certifications and checking the digest log for the digest of the ProofMark

certificate being verified

Each level except the internal consistency check produces an XML verification

report. If the ProofMark certificate has been tampered with, the report will

indicate what errors were uncovered. Using the more thorough levels of

verification impacts the amount of CPU time required to complete the

verification.

the server component

The servlets on the server are responsible for the creation of Intervals, the

issuance of ProofMark certificates, and the verification of ProofMark certificates.

To understand how these actions are accomplished, the following concepts are

explained:

- ProofMark certificates

- Intervals

- Interval cross-certification

- Trusted time

- Digest logs

- Ensuring server and Interval identity

- Verification

- Archives

- Publication

- Syslog / Message log


22/50




18

ProofMark certificates

A ProofMark certificate is an electronic document that verifies the existence of

some data at a point in time that is provable independent of the organization

issuing the ProofMark certificate. It provides non-repudiable proof of the what,

when, and (optionally) who of E-commerce transactions and network events.

ProofMark certificates are XML (eXtensible Markup Language) documents

containing digital signatures that authenticate some data. When a server

receives an issuance Request (also an XML document) as input to an HTTP

request, a ProofMark certificate is issued.

When an issuance Request is sent to the HTTP server component of a ProofMark

server, the HTTP server recognizes the header as a request for a servlet and

dispatches the servlet engine running the ProofMark server to handle the

request. The ProofMark server encapsulates the ProofMark certificate Request

inside an XML document and returns this to the client of the request.

Application

Server

ProofMarkServer

ProofMark

XMLDocument

2) create proofmarkand store in

XML document

3) Send ProofMark

via HTTP

1) Request ProofMarkvia HTTP

ProofMark certificates can, as an option, be stored in a database on the

ProofMark Server. When that is done, a reference URL used for retrieving the

ProofMark certificate can be returned instead of the full ProofMark certificate.

definition of a ProofMark certificate

In addition to the original data to be ProofMarked, the ProofMark certificate

contains:

- The timestamp, in UTC, that the ProofMark certificate was issued and the

current accuracy of the server's time source

- The Interval (see Interval, below)

- A sequence number within the Interval


23/50




19

- A copy of the message digest (hash) from the previously issued ProofMark

certificate

- A message digest of the contents of the ProofMark certificate

- A digital signature of the concatenation of the two message digests

Detailed explanations and examples can be found in the ProofMark Certificate

Anatomy Guide.

Intervals

Intervals are used by the ProofMark system to provide the transient key pairs

which signs the data in a ProofMark certificate. Using transient key pairs instead

of a long-term secure facility greatly reduces the exposure of the private key to

theft or compromise.

The length of time during which a key-pair can be used is set during start-up of

an issuing ProofMark server (this is part of the system configuration, which is

covered in the Administrator's Guide). Each server generates one key-pair per

Interval.

A single ProofMark server has only one active Interval at any given time. As the

server runs, subsequent Intervals are created which are guaranteed to becontiguous (the stop time of an Interval is identical to the start time of the next

Interval). These contiguous Intervals form a chain of keys, with each Interval's

public key being signed by the previous Interval's private key. If a new Interval

cannot be readied and prepared before its prescribed start time, the chain is

broken, and the server automatically restarts a new chain.

definition of an Interval

An Interval contains the following information:

- The server-id (the hostname[:port] of the server)

- The start time of the Interval chain in UTC (universal coordinated time, see

Trusted time)

- The start time of the Interval in UTC

- The stop time of the Interval in UTC

- The public key for the Interval


24/50


ProofSpace, Inc., 1999-2008


20

- The digital signature of the Interval's public key, signed by the previous

Interval's private key

- A digital signature for the Interval, signed by the server's X.509 (an international

standard for the format of digital certificates) identity key

- Cross-certification information (a ProofMark certificate issued for an Interval byanother ProofMark server, see Interval cross-certification)

- The digest log of the Interval completed just prior to the Interval used to create

the current Interval

Interval chains

The start time of the very first Interval in the chain is known as the chain start

time, and is stored in each Interval. While theoretically possible, it is unlikely

that two different servers would be configured with the same server-id. It ishighly improbable that these servers could also be started at exactly the same

time, resulting in identical chain start-times. Therefore, adding the chain start

time to the server-id uniquely identifies an Interval chain. Once the chain is

identified, an Interval within the chain is uniquely identified by the Interval's start

time.

The chains Intervals are stored persistently in an archive (see Archive, below).


25/50




21

using Intervals to issue ProofMark

certificates

During each Interval, the private key is used in the creation of ProofMark

certificates. Many ProofMark certificates can be issued during an Interval, eachsigned by the Intervals private key.

At the end of each Interval the private key is destroyed and a new key pair isgenerated for the subsequent Interval. During the process of activating a new

Interval, the current Intervals private key signs the new Intervals public key and

start and stop times. Once a signature for the Intervals key has been acquired,

the private key is permanently destroyed.


26/50




22

The start time within each Interval coupled with the chain start time form an

unbroken sequence of public keys that can be used to fix a ProofMark

certificates position in time, which also fixes the exact state of a set of data at

that point in time. To prove this state at some future point, the chain of public

keys is posted to an easily accessible place (i.e. several web servers) from where

they can be used to verify a ProofMark certificate.

Interval cross-certification

Cross-certification refers to the process by which one ProofMark server issues a

ProofMark certificate for another ProofMark servers Interval. This process

provides independent proof of the existence of the Interval (and its public key) ata point in time, and creates a widely witnessed chain of proof for the Interval.

Cross-certification also protects the archive from tampering, since the Cross-

certification web extends to several archives and replicas of those archives. To

steal the private key of an interval would require access to the entire web of

cross-certifying archives.

The actual Cross-certifications are ProofMark certificates whose signed data is

an Interval. Cross-certifications are used to authenticate another server's time.

An Interval can have any number of Cross-certifications, issued either by other

servers within the same organization, or by servers in other organizations. A

minimum number of Cross-certifications must be returned before the Interval

can become active (set when you configure the ProofMark system). A larger

number of Cross-certifications results in a more widely witnessed chain of proof.


27/50




23

X-Cert Issuing Server

Certifying Server

Certifying Sever

Certiying Server

Certifying Server

X-Cert

X-Cert

X-Cert

The Cross-certification process requires that the timestamp (from a trusted timesource, see Trusted time, below) of the Interval and the timestamp of the Cross-

certifying server agree. That means the difference is less than the sum of the

accuracies of the two timestamps plus the time required to obtain the Cross-

certification.

During Cross-certification, the cross-certifying server authenticates the PKIsignature in the Interval that is being cross-certified, and rejects any requests

whose PKI signatures cannot be verified.

trusted time

Each ProofMark certificate has a timestamp indicating the time that the

ProofMark certificate was issued. The timestamp is created using Universal

Coordinated Time (UTC), with precision to the nearest millisecond. Within the

server, timestamps are obtained from a trusted time source (commonly via the

Network Timing Protocol (NTP).

Times are calculated via a time biasing mechanism, which obtains the time from

the trusted time source periodically and uses a local hardware timer in the

interim. If the trusted time cannot be obtained, the ProofMark server will not

issue ProofMark certificates until the trusted time can be reestablished. The

system clock, which is vulnerable to tampering, is never used as a source of

time.


28/50




24

Every timestamp has an associated accuracy, in milliseconds, which is reported

along with the timestamp in every issued ProofMark certificate. In a typical

configuration, accuracy within 100 milliseconds of the Atomic clock is possible.

If the Time Source is not running within its specified tolerance, a Stale Time

Exception occurs, which prevents the creation of ProofMark certificates.

digest logs

The digest log is used to ensure that false ProofMark certificates cannot be

created after an Interval has been created, Cross-certified, and published (unless

the attacker has successfully compromised the entire distributed network of

cross-certifying servers and archives).

The digest log contains the individual digests for each ProofMark certificate

created by an Interval, as well as a superhash digest, computed from the

individual digests. The digest log is placed into the next Interval to be createdwithin the Interval chain (this is not the Interval immediately after the Interval the

digest log represents, but the one following it). When the Interval is published,

the digest log is also published.

Digest logs are periodically propagated to the same archive(s) as the Intervals

they represent.

The digest log is used to protect against the creation of false ProofMark

certificates. While it is theoretically possible for someone to obtain the transient

key for an Interval (which can be done only while the Interval is active), the digest

log would not contain a digest for any false ProofMark certificates created using

the private key.

The existence of the digest log also makes cracking attacks virtually impossible.

A cracking attack is one in which the transient private key is deduced after the

end of an Interval, by applying cryptanalysis techniques to existing ProofMark

certificates created during the Interval. A false ProofMark certificate created

using a private key obtained in this manner could not be verified if the digest log

verification option was required, since no record of that certificate would be

present in the digest log for the issuing Interval. Finally, since digest logs are

cross-certified in the same manner as Intervals, tampering with a published

digest log after the fact would require altering all records of the digest log, in all

cross-certifying servers.

The risk of false certificates is much lower with ProofMark transient-key

technology since keys are never stored or transported, and only exist during the

Interval. Using a supported hardware crypto-accelerator, they never exist or are

accessible outside of the transient memory in the crypto-processor board. While

no security system is perfect, this is a significant improvement over permanent

key, third party key systems.


29/50


30/50




26

- Digest log verification (the third level of archive verification)

Stronger

Weaker

ProofMark InternalVerification

Interval Verification

Cross-Certification

Verification

DigestLog

Verification

ProofMark internal verification

With the aid of publicly available software, any ProofMark certificate can be

tested for internal consistency. This check does not require communication with

a ProofMark server, yet will immediately detect if the certificate was modified

since it was issued.

To test a ProofMark certificate for internal consistency, you compare a digest ofthe original data (created with an SHA2 hash algorithm) with the digest from the

ProofMark certificate. If the two digests match, the ProofMark certificate is

internally consistent. If the two digests do not match, the data in the ProofMark

certificate has been tampered with, and it is not a valid ProofMark certificate.

Interval verification

The first level of archive verification authenticates any PKI signatures that were

included in the original request that generated the ProofMark (these are part of

the ProofMark). Authentication is accomplished by first verifying each certificatein the PKI signature's certificate chain, then checking for a trusted certificate in

the machine's local keystore whose subjectDN matches the issuerDN of the first

certificate in the PKI signature's certificate chain. If these keys fail to match, an

error is reported in the verification report.


31/50


32/50




28

If the archives real host ceases to exist, the ProofMark archive Directory (see

below) will list forwarding host addresses where copies of the archive are

located.

the ProofMark archive directoryProofSpace plans are to operate a Web server that contains a database of

forwarding addresses for archives whose contents are no longer serviced by the

original logical host. The normal verification of a ProofMark certificate would

send a request to one of the archive hosts listed in the ProofMark certificatesarchive Tree. If one or more of these hosts were no longer operating, the

directory could be queried for other servers that now serve the archive.

replication

Since several servers may have a copy of an archive, or contribute to it, the

copies of the archive are replicated among each server in the archive. This

replication is achieved by one of several methods:

- For file-system archives, use any file replication product, such as the Andrew

File System (AFS), or utilities such as RDIST (remote software distribution

system) or RSYNC (a file transfer program for Unix systems)

- For JDBC database archives, use either a shared database service or the

ProofMark replication service

Replication between mixed archive types is not supported in this release.

the Interval archive tree

Every Interval must be stored in at least one archive, known as the Interval's root

archive. Intervals may be stored in additional archives as well. During creation

of the Interval, an archive Tree is established for the Interval and the Interval is

stored or published in its root archive before it is available for use.

After its initial publication, the Interval is forwarded asynchronously to one or

more additional archives in the archive Tree, which may in turn each forward toadditional archives. The archive Tree is represented as part of the Intervals XML

representation and therefore appears in each ProofMark certificate issued by the

Interval. This enables the holder of the ProofMark certificate to know which

archives can be used for later verification of the ProofMark certificate. In a

typical situation, an organization will have its own archive, and will forward its

Intervals to a public archive, but more extensive archive Trees are possible.

Each additional archive may have been configured to forward to another level of

archive (propagating the archives).


33/50




29

The process of establishing the archive Tree for an Interval occurs immediately

after the Cross-certifications for the Interval have been obtained. The archive

Tree is constructed by combining the archive Trees from the servers that issued

Cross-certifications as follows:

- The Intervals local archive becomes the root of the archive Tree

- The set of archive trees of all of the Cross-certifications for the Interval are

added as immediate branches of the root archive

- If there are archives that have been configured for publication, without requiring

Cross-certifications, these archives are also added as branches

- Any cycles or redundant branches in the resulting archive tree are removed

In an exception to this process, the Interval does not have a local archive. In this

case, it must be configured with only a single Cross-certification group from

which Cross-certifications are required. The resulting archive Tree thenbecomes a copy of the archive Tree from that group. See the Load Balancing

Topology in the Planning section below for an example.

archive integrity

The integrity of the Intervals stored in an archive is important and must be

protected from tampering in order to guarantee the authenticity of ProofMark

certificates. Since one cannot guarantee that any particular server is immune

from tampering, the Intervals themselves have been designed to prevent

undetected tampering:

- Each Interval in the chain has been signed by the previous Interval

- Each Interval can have a PKI signature that certifies that it was created by a

particular server

- Each Interval has Cross-certification ProofMark certificates, issued by other

servers, which sign the Interval, and the Intervals that issued these Cross-

certifications are themselves cross-certified

- The Interval issuing a Cross-certification for another Interval is archived into an

archive Tree that is a branch of the archive Tree of the Interval that is beingcertified

Since Intervals and their Cross-certifications appear in more than one archive,

the integrity of any given archive replica can be validated by verifying the Cross-

certification ProofMark certificates using a different archive. An automatic

auditing process that cross-authenticates an archives integrity is planned for a

future version of the system.


34/50




30

publication

Publication refers to the process of making Intervals and their Cross-

certifications available in one or more databases that are:

- Permanently accessible, even if the issuing organization ceases to exist

- Stored in such a way that they cannot be altered without detection

Publication is achieved in the ProofMark system with the following processes:

- An Interval and its Cross-certifications are published to the root archive in the

Intervals archive Tree, before the Interval can become active

- An archive can be periodically replicated to several servers in order to provide

high availability and redundancy against loss

- Intervals and their Cross-certifications are propagated from one archive to

another, as defined by the subordinate branches of the Intervals archive Tree,

using the following automatic process:

?? As an Interval is stored in any archive, it is flagged for propagation if there

are any branches in the Intervals archive Tree that occur beneath the

archive in which the Interval is currently being stored

?? Periodically, a ProofMark propagation service forwards all Intervals marked

in this way to each of the archives that appear beneath the current archive

in the Intervals archive Tree (the propagation flag for the Interval is cleared

when the Interval has been propagated successfully to each of thesearchives)

?? This recursive process continues until the Interval has eventually been

stored in each archive in its archive Tree

Replication is important, even for verification-only servers, since Interval

publishing and propagation only distribute Interval information to a single server

in each archive group.

syslog / message log

Each ProofMark server logs activity messages related to its operation in a

standardized format. There are several configuration options available to specify

where these messages are logged and which message levels are included in the

log. These choices are described in the Configuration Guide.

The syslog message-logging configuration is strongly recommended. It enables

a ProofMark server to send messages to any server running a syslog daemon


35/50




31

process. With this option and a set of widely available third party tools,

ProofMark server messages can be filtered and routed to a variety of

destinations including pagers, e-mail accounts or Internet based messaging

services.


36/50

planning your ProofMark implementation / considerations fo



32

planning your ProofMark implementation

When you implement the ProofMark system, you need to make several important

decisions, including the length (in time) of each Interval, and the topology of

servers.

considerations for selecting an Interval length

One of the key parameters in configuring a ProofMark server is the selection of

an Interval length. This length, in seconds, is the amount of time that an Interval

and its unique key-pair will be used before destroying the private key and

creating a new Interval. There are several considerations in selecting this

length:

- Shorter Intervals provide a smaller target for hackers

- Intervals are independently cross-certified (shorter is better)

- Creation of the next Interval (each Interval is prepared during the previous

Interval, so longer is better)

- Storage of Intervals in the archive (longer Intervals result in fewer Intervals to

store)

In weighing these considerations, an Interval length of around 5 minutes is

appropriate for most installations.

smaller target for hackers

A shorter Interval is preferable since it is a smaller target for hackers. If the

other safeguards in protecting the transient private key were broken, obtaining

any given private key would only allow for false issuance of ProofMark

certificates for the one Interval. This risk is much lower with ProofMark

transient-key technology since keys are never stored or transported, and only

exist during the Interval. Using a supported hardware crypto-accelerator, they

never exist or are accessible outside of the transient memory in the crypto-processor board. While no security system is perfect, this is a significant

improvement over permanent key, third party key systems.

The digest log is placed into the next Interval to be created within the Interval

chain. When the Interval is published, the digest log is also published. In a

smaller interval, the digest is also smaller, since fewer ProofMark certificates

are issued during the Interval.


37/50

planning your ProofMark implementation / topology consider



33

Intervals are independently cross-certified

A shorter Interval is preferable since each Interval is independently cross-

certified. A smaller Interval may tend to strengthen the independently-verifiable

time of the ProofMark certificates issued by the Interval, to the extent that the

atomic-clock time sources used by any one server are suspect. This is a minor

consideration. The accuracy of time should not be a major consideration in

selecting Interval length.

creation of the next Interval

A longer Interval is preferable since the Interval is prepared for use during the

previous Interval. This preparation includes

- Key generation (a somewhat time-intensive process)

- Obtaining Cross-certifications for the Interval

- Storing the Interval in the local archive

- Publishing the Interval to at least one external archive (if any are specified)

All of these must be completed before the start time of the Interval, and extra

time may be required if there are temporary network bottlenecks in obtaining,

for example, Cross-certifications for the Interval. Selecting too short an Interval

may impact server availability if these things cannot be completed on time.

storage of Intervals

A longer Interval is preferable since there will be fewer of them to store in the

archive, retrieve, and cross-certify. This results in less network overhead and

less file storage in the archives where the Interval is stored.

topology considerations

There are two types of topologies to consider regarding Cross-certification:

- Intra-organization

- Inter-organization


38/50




34

Intra-organizational Cross-certification topologies address server workload and

system reliability issues. Inter-organizational topologies provide additional

quality of service levels to the ProofMark certificates that are issued.

The topologies discussed below represent only a few of the possible

configurations. Of the intra-organizational ones, the choice is primarily a matter

of volume requirements; the load balancing topology is more appropriate for

high volume installations. However, setting up and managing a load balancing

environment takes time and expertise that low volume installations most likely

will not have.

intra-organizational topologies

The two primary intra-organizational topologies are:

- Reciprocal peer

- Load balancing


39/50




35

reciprocal peer topology

The reciprocal peer topology consists of ProofMark clients connecting directly to

one or more ProofMark servers that cross-certify each other.

X-Cert

P

1

P

2

Load Balancer

Persistent

Archive

Cn

..C2

C1

In this diagram, all of the organizations ProofMark clients C 1.n connect directly to

one of the ProofMark servers P1 or P2 via a load-balancing server which provides

the appearance of a single virtual host. These servers store Intervals and Cross-

certification trees to a shared or replicated archive. The same virtual hostname

is used for both issuance and verification, and is therefore used as the archives

nominal hostname.

load balancing topology

In a load balancing topology, which is used in conjunction with a reciprocal peer

topology, ProofMark clients connect to one of several ProofMark servers NP 1.n

that do not have local access to the archive. These servers in turn Cross-certify

with at least one of the servers P1 or P2 that only serve as Cross-certification and

archive servers. Notice that a load balancer is not used on the connection

between the NPm and P1/P2 servers for purposes of Cross-certification, but is

present as the nominal archive host and serves to load-balance verification

requests to the archive. While not shown, servers distinct from P1 and Pn could


40/50




36

be deployed as independent verification/archive servers, so that P1 and P2 would

perform only Cross-certification requests. Given the light load of simply issuing

Cross-certifications, one server could easily satisfy this role, but having two

provides for redundancy of this critical function.

X-Cert

P

1

P

2

NP

1

NP

2

...NP

n

Load Balancer(Issuing host)

PersistentArchive

Load Balancer(Verification host)

C1

C2

... Cn

inter-organizational topologies

The two primary inter-organizational topologies are:

- Meshed peer

- Hierarchical

These topologies are extensions of the intra-organizational topologies described

above.


41/50




37

meshed peer topology

In a meshed peer topology, several organizations running ProofMark servers

agree to provide mutual Cross-certification and publication services. Each

participating organization can configure its Cross-certifications to be obtained

from any number of other organizations, and may specify how many are optionalor required for certifying the Interval. ProofMark certificates issued by one of

these Intervals will list the root archive as the one belonging to the issuing

organization, and will list a tree of other archives where the Interval is published.

In the diagram below, the organizations deploy reciprocal peer topologies, but

they may also deploy load-balancing topologies. If the load balancing topology is

used within an organization, the Cross-certification servers will issue Cross-

certifications both within and between organizations. This work is normally

insignificant when compared to the load placed on the issuing server farms.

An organization, for purposes of this discussion, may be any form of entity or

sub-entity within a larger organization.

X-Cert, Publish

X-Cert,

Publish

X-Ce

rt,Pu

blish

X-Cert

,PublishX-Cert,Publish

X-Cert, Publish

Org1

Org3

Org4

Org2

Variations on these topologies include organizations that lurk on a meshed peer

topology, receiving Cross-certification services from one or more of the trusted

peers, but providing no Cross-certification in return. Additionally, an

organization may participate in more than one trusted peer topology. These

variations do not uniquely influence the Cross-certification tree for a given


42/50




38

ProofMark client, but can be useful when discussing the implications of adopting

alternative Cross-certification topologies.

hierarchical topology

The hierarchical topology closely models the certificate authority (CA) model for

digital certificates. In this case, there are recognized and reputable Public

Record (PR) service organizations that only supply Cross-certification and

publication services to ProofMark organizations. Organizations can request

Cross-certification directly from a PR, or indirectly through another organization.In the diagram below, S1 is considered a broker between the public records and

organization S2.

X-Cert,Publish

X-Ce

rt,Pu

blish

X-Cert,

Publish

X-Cert,

Publish

PR1

PR2

PR3

S1

S2


43/50

appendix Acryptography primer / basic concepts



39

appendix Acryptography primer

For those unfamiliar with the basics of cryptography, this appendix provides a

brief primer on the subject, introducing you to the basic concepts, and describing

the two primary uses.

basic concepts

Cryptology is the science of secret writing, and has been used for millennia to

transmit information from one party to another without allowing intermediaries

to learn the information. Cryptology includes cryptography, which is the

encoding of information, and cryptanalysis, which is the decoding of the

information. Plaintext is the original message to be sent from one party to

another. The text is encrypted using an algorithm or cipher, and the result iscalled ciphertext. Often, people use the term cryptography to include both

cryptography and cryptanalysis.

Many algorithms use a key as part of the input, to vary the results of the

algorithm and make the ciphertext more difficult to decipher, or convert into

plaintext. Cracking means breaking the secret code or key used to encrypt data

(cracking allows the intermediary who cracks the algorithm to learn the

information by decrypting a piece of ciphertext). Hacking means breaking into a

system either to steal something or to be disruptive. Stealing a key or some

ciphertext would be hacking. Breaking the key and decrypting the ciphertext

would be cracking.

Symmetric encryption uses a single key to both encrypt the plaintext and

decrypt the ciphertext. Asymmetric encryption uses two separate keys, one to

encrypt, and one to decrypt. These two keys have a mathematical relationship

that allows what is encrypted with one key to be decrypted only with the other

key. Because of the nature of the mathematical relationship between the two

keys, it takes longer to encrypt and decrypt information using asymmetric

encryption.

Public key cryptography uses asymmetric encryption, where one key is made

public, and the other is kept private. This is referred to as a public/private key

pair. You publish your public key and anyone can use it to encrypt information.

You will be the only one who can decrypt the information, using your private key.

Some well-know asymmetric encryption algorithms include RSA, DSA, and

Elliptic Curve.

Another aspect of cryptology is the message-digest, which is a one-way function

that takes any amount of plaintext and produces a fixed-length ciphertext. This

ciphertext is referred to as the message digest, digest, or hash. It is called a

one-way function because you cannot recreate the original data from the digest.


44/50

appendix Acryptography primer / basic concepts



40

The digest acts as a signature for the data. In fact, a strong message-digest

algorithm produces a unique digest for each set of plaintext used as input, such

that if only one character of the plaintext changes the new digest is completely

different. Some well-known message-digest algorithms include SHA2 and MD2,

MD3, and MD4.

How are these digests used? An important use of public key cryptography isauthentication and integrity. You can encrypt a piece of data with your private

key. Anyone knowing your public key can then decrypt the data and know that

the data came from you. This use of public key cryptography is called signing.

The output created when signing a digest is called a digital signature. Since you

are not trying to hide the information itself, only the digest is signed (this

improves the performance of your cryptographic system). The public key can

decrypt the digest and match it to the accompanying data.

To ensure that the digital signature was created by the entity claiming it, a

trusted organization must vouch for the relationship between the private key and

its owner. This is accomplished through a digital cert ificate, a digitally signedpublic key. Registration authorities (RA) issue digital certificates and ensure

that they are issued only to legitimate parties. A trusted organization referred to

as a certificate authori ty (CA) issues and manages the certificates. Some well-

known CAs include Verisign, Entrust, and Baltimore.

The CA will vouch for the validity of the digital certificate and, as a result for a

digital signature generated with the private keys certificate. If another party

discovers the private key of a digital certificate, that digital certificate is added to

a cert ificate revocat ion list (CRL) to indicate that the digital certificate is no

longer secure. The Public Key Infrastructure (PKI) allows widespread use of

public key technology by providing an accepted standard of algorithms, CAs, RAs,

and access to public keys.

The PKI infrastructure has resulted from the advancements in cryptography over

the last few years, and provides a way for organizations to communicate

electronically with confidence using digital certificates.

The security of an algorithm used to encrypt information is based on whether or

not it is considered possible to crack the ciphertext and find the plaintext. The

larger the key used with the algorithm, the more secure the data is.

Cryptanalysts traditionally break ciphers by finding patterns within the data or by

learning the key. Having more examples of ciphertext created with the same key

increases the chance of finding patterns within the resulting data. Mostalgorithms are published in order to undergo public scrutiny to see if there are

any weaknesses that can break the cipher.


45/50

appendix Acryptography primer / uses of cryptography



41

uses of cryptography

There are two primary uses of cryptography: secrecy and integrity. When used

for secrecy, data is encrypted with a key into a non-readable form, transmitted to

someone where it is decrypted and restored to its original form. When used for

integrity, data is signed using a cryptographic key, but the data is transmitted in

its original form. This use of cryptography enables after-the-fact confirmation

that the transmitted data has not been altered in any way.

The ProofMark system uses applied cryptography for authentication and proof of

online transaction at a point in time, by issuing a certificate that contains the

proof for an online event of what someone did, when they did it, and who they

were.


46/50

appendix Bglossary / uses of cryptography



42

appendix Bglossary

This glossary contains common terms used throughout the ProofSpace

documentation set.

BLOB

Binary Large OBject.

Certificate authority (CA)

A trusted organization referred to as a certi ficate authority (CA) issues and

manages digital certificates within the Public Key Infrastructure (PKI).

Certificate revocation list (CRL)

If another party discovers the private key of a digital certificate, that digital

certificate is added to a certificate revocation list (CRL) to indicate that the digital

certificate is no longer secure.

ciphertext

In cryptography, ciphertext is encrypted text.

CRL

Certificate Revocation List.

Cryptology and cryptography

Cryptology is the science of secret writing, and is used to transmit information

from one party to another without allowing intermediaries to learn the

information. Cryptography is the encoding of information from plaintext to

ciphertext. Often, people use the term cryptography to include both cryptographyand cryptanalysis.

Digital certificate

A digital certificate is a digitally signed public key, which is used to authenticate

the identity of the individual or organization using it.

Digital signature

A digital signature is a piece of data encrypted with a private key. Anyone can

then use the public key to decrypt the data and confirm the source.

DTD

Document Type Definition.

Encryption and decryption

In cryptography, to encrypt is to use an algorithm or cipher to convert plaintext to

ciphertext. To decrypt is to convert the ciphertext back to plaintext.

Cracking refers to breaking the secret code or key used to encrypt data (cracking

allows the intermediary who cracks the algorithm to learn the information by


47/50




43

decrypting a piece of ciphertext). Hacking refers to breaking into a system either

to steal something or to be disruptive. Stealing a key or some ciphertext would

be hacking. Breaking the key and decrypting the ciphertext would be cracking.

HSM

Hardware Security Module

Indicia

Indicia refers to the graphical representation of the ProofMark certificate, which

contains the data in the graphical representation.

JDBC

Java Database Connectivity.

Key

In cryptography, many algorithms use a key as part of the input to an encryption

algorithm, which varies the results of the algorithm and makes the ciphertext

more difficult to decipher.

Message-digest

In cryptography, a message-digest is a one-way function that takes any amount

of plaintext and produces a fixed-length ciphertext. This ciphertext is referred to

as the message digest, digest, or hash.

NTP

Network Timing Protocol.

Plaintext

In cryptography, plaintext is ordinary text or data that has not been encrypted.

Public key infrastructure (PKI)

The Public Key Infrastructure (PKI) allows widespread use of public key

technology by providing an accepted standard of algorithms, CAs, RAs, and

access to public keys.

RDIST

Remote software distribution system. RDIST is used to maintain identical copies

of files over multiple hosts, preserving the owner, group, mode, and mtime of the

files if possible. Programs that are currently executing can be updated.

RSYNC

A file transfer program for Unix systems that provides a very fast method forsynchronizing remote files, by sending just the differences in the files across the

link without requiring that both sets of files be present at the same end of the

link.

Features include:

- Updating whole directory trees and file systems


48/50




44

- Preserving symbolic links, hard links, file ownership, permissions, devices, and

times

- Internal pipelining reduces latency for multiple files

- Supports anonymous rsync, which is ideal for mirroring

Servlet

A servlet is a Java program running inside a web server. The servlet uses HTTP

as the communication protocol between the web server and the servlet. The

client sends an HTTP message to the webserver, which in turn sends an HTTP

message to the servlet within the web server. The header of the URL indicates

which servlet the message is for.

Symmetric and asymmetric encryption

Symmetric encryption uses a single key to both encrypt the plaintext and decrypt

the ciphertext. Asymmetric encryption uses two separate keys, one to encrypt,

and one to decrypt. These two keys have a mathematical relationship that allowswhat is encrypted with one key to be decrypted only with the other key.

Public key cryptography uses asymmetric encryption, where one key is made

public, and the other is kept private.

TTP

Trusted Third Party. A trusted third party provides independent verification of

authenticity.

UML

Unified Modeling Language.

UTC

Universal coordinated time. This is a time standard for absolute time.

X.509

An international standard for the format of digital certificates.

XML

Refers to the eXtended Markup Language standard, published by the Worldwide

Web Consortium. XML is a markup language where the tags indicate the usage

of the data, rather than the layout or format of the data. The data within an XML

document can then be displayed in different ways, according to the needs of the

user.


49/50

index / uses of cryptography



45

index

additional safeguards, 7

application integration, 10

archives

directory, 28

integrity, 29

Interval archive tree, 28

introduction, 27

publication, 30

replication, 28

asymmetric encryption, 44

authenticating a ProofMark

certificate, 17

BLOB, 42

certificate. see ProofMarkcertificate

certificate authority, 42

certificate revocation list, 42

chain of Intervals, 5, 6, 7, 19, 20, 29,

32

ciphertext, 42

client API, 4, 8, 10, 12, 16

client component, 4

configuration

hardware acceleration, 15

issuance request options, 13

load balancing, 14multi-processor support, 14

persistent storage options, 15

creating Intervals, 5

CRL, 42

cross-certication verification, 27

cross-certification, 22, 27

archives, 27

cryptographic accelerator cards, 15

cryptography primer, 39

cryptography, definition, 42

cryptography, uses, 41

decryption, 42digest log

verification, 27

digest logs, 17, 24

digital certificate, 42

digital signature, 42

DTD, 42

encryption, 42

hardware acceleration, 15

hierarchical topology, 38

HSM, 43

HTTP, 10

indicia, 43

integrity of archives, 29

internal consistency check, 17

internal verification, 26

inter-organizational topologies, 36

Intervals

archive tree, 28

archives, 27

creating, 5

cross-certification, 22definition, 19

identity, 25

Interval chains, 5, 6, 7, 19, 20, 29,

32

introduction, 19

issuing ProofMark certificates, 21

selecting Interval length, 32

transient-key technology, 6

intra-organizational topologies, 34

issuance requests, 13, 18

issuing ProofMark certificates, 5, 21

Java servlets, 10JDBC, 43

key, 43

length of Intervals, 32

load balancing, 14

load balancing topology, 35

meshed peer topologies, 37

message digest, 43

message log, 30

MP machines, 14

multiplexing proxy, 14

multi-processor support, 14

NTP, 43performance considerations, 14

persistent storage options, 15

plaintext, 43

planning your implementation, 32

Interval length, 32

topology, 33

platform specifications, 12


50/50

index / uses of cryptography

product architecture, 9

ProofMark archive directory, 28

ProofMark certificates

authenticating, 17

data included, 5

definition, 1, 18

examples of data, 2introduction, 18

issuance request options, 13

issued by Intervals, 21

issuing, 5

referencing, 13

referencing data, 13

verification, 25, 26, 27

verification reports, 27

verification requests, 16

verifying, 6

ProofMark client API. See client APIProofMark references, 13

ProofMark requests, 16

ProofMark servers, 4

ProofMark Verification Report, 6

public key infrastructure, 43

publication, 30

RDIST, 43

reciprocal peer topology, 35

recursive verification, 17

recursive verification with digest

log, 17

referencing data in ProofMarkcertificates, 13

referencing ProofMark certificates,

13

replication, 28

RSYNC, 43

server component, 4

server components, 17

server identity, 25

servers, 4

servlets

cross certifier, 11

definition, 44

issuer, 11

overview, 10

propagator, 12publisher, 11

replicator, 12

retriever, 11

verifier, 11

SHA2 digest, 16

specifications, 12

storage

JDBC database, 15

local file system, 15

symmetric encryption, 44

syslog, 30system components, 9

technology overview, 4

time source, 23

topology considerations, 33, 34, 36

transaction flow (sample), 8

transient-key technology, 1, 4, 5, 6,

19, 24

trusted time, 23

TTP, 44

UML, 44

uses of the ProofMark system, 1

UTC, 44verification, 25, 26

verification reports, 27

verification requests, 16

verifying ProofMark certificates, 6

X.509, 44

X.509 certificates, 16

XML, 44

XML documents, 5, 17, 18

ProofMark System Concepts, Architecture, & Planning Guide 2.08

Documents

Transcript of ProofMark System Concepts, Architecture, & Planning Guide 2.08