ProofMark System Concepts, Architecture, & Planning Guide 2.08

ProofMark System Concepts, Architecture, and Planning Guide
February 2008
The ProofMark System Concepts, Architecture, and
Planning Guide may not, in whole or in part, be
copied, photocopied, translated, or reduced to any
electronic medium or machine readable form or
otherwise reproduced or form the basis for any
derivative work, without the prior consent, in
writing, from ProofSpace, Inc.
Portions of the information described in this

document are covered by current or pending
patents.
Copyright 1999-2008, ProofSpace, Inc.

323 Washington St SE
Grand Rapids, MI 49503
Use of this copyright notice does not imply

publication, and all rights, including trade secret
rights, are reserved.
Printed in the United States of America

contents
contents.............................................................................................3
introduction .......................................................................................1
what’s in this guide .............................................................................2
additional documentation ....................................................................3
technology overview.......................................................................... 4
the client component ..........................................................................4
the server component .........................................................................4
creating Intervals..........................................................................5
issuing ProofMark certificates .......................................................5
verifying ProofMark certificates .....................................................6
Intervals and transient-key technology .................................................6
additional safeguards..........................................................................7
sample of transaction flow ..................................................................8
product architecture ..........................................................................9

system components............................................................................9
servlet overview................................................................................ 10
platform specifications...................................................................... 12
client API ......................................................................................... 13
issuance request options................................................................... 13
performance considerations.............................................................. 14
multi-processor support ............................................................. 15
load balancing ............................................................................ 15
hardware acceleration ................................................................ 15
summary chart........................................................................... 15
persistent storage options................................................................. 16
core concepts................................................................................... 17
the client component ........................................................................ 17
ProofMark requests.................................................................... 17
verification requests ................................................................... 18
the server component ....................................................................... 18
ProofMark certificates ................................................................ 19
definition of a ProofMark certificate ....................................... 20
Intervals..................................................................................... 20
definition of an Interval.......................................................... 21
Interval chains ...................................................................... 21
using Intervals to issue ProofMark certificates ....................... 22
Interval cross-certification .......................................................... 24
trusted time ............................................................................... 25
digest logs.................................................................................. 25
ensuring server and Interval identity ............................................ 26
verification ................................................................................. 27
ProofMark internal verification .............................................. 28
Interval verification ............................................................... 28
cross- certification verification ............................................... 29
digest log verification ............................................................ 29
ProofMark verification reports............................................... 29
archives ..................................................................................... 30
the ProofMark archive directory ............................................. 30
replication ............................................................................ 30
the Interval archive tree ........................................................ 31
archive integrity .................................................................... 32
publication ................................................................................. 32
syslog / message log................................................................... 33
planning your ProofMark implementation .........................................34

considerations for selecting an Interval length.................................... 34
smaller target for hackers........................................................... 34
Intervals are independently cross- certified................................... 35
creation of the next Interval ......................................................... 35
storage of Intervals..................................................................... 35
topology considerations..................................................................... 36
intra-organizational topologies .................................................... 36
reciprocal peer topology........................................................ 37
load balancing topology ......................................................... 37
inter-organizational topologies .................................................... 38
meshed peer topology ........................................................... 39
hierarchical topology ............................................................ 40
appendix A—cryptography primer ....................................................42

basic concepts .................................................................................. 42
uses of cryptography ......................................................................... 44
appendix B—glossary ......................................................................45
index ...............................................................................................48
introduction / what’s in this guide
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 of
proof 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 Commerce—digital receipts for Internet purchases and business-to-

business transactions
- Healthcare or medical applications—authenticity of patient records, x-rays, a

secure audit trail of who looked at what data, when
- Securities Trading—brokerage order acknowledgements and confirmations
- Online banking—proof of bill payments, account transfers
- Drug Trials—a chain-of-proof of the test results over time
- Electronic Communications—content 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 ProofSpace’s 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
ProofSpace , Inc., ©1999-2008

Proprietary and Confidential. All rights reserved.
1
introduction / what’s in this guide
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.
what’s 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 product’s 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.
2
introduction / additional documentation
additional documentation
The following are additional documents provided with the ProofMark system:
- SDK Programmer's Guide
- ProofMark Technical Overview
- ProofMark XML Reference Guide
- Server Installation Guide

3
technology overview / the server component
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 A—cryptography 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 client
API, 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

4
technology overview / the server component
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 passed
on 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 Interval’s private key.
ProofMark certificates contain the data to be certified (the “what”), a time stamp
from 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.

5
technology overview / Intervals and transient-key technology
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 the
integrity 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
6
technology overview / additional safeguards
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 server’s transient-key technology provides the means to issue

cryptographically secure ProofMark certificates. Other security measures
included 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)

7
technology overview / sample of transaction flow
sample of transaction flow
The following diagram displays one of many example scenarios involving the use
of the ProofMark system.
XYZ Online Banking Co.
Online Banking Transaction Payment Complete (3)
Payment Acknowledgment
Scenario
Payment Execution
System
Issue payment (2)
Banking Web Server
(1) Pay Mortgage
Print Receipt
(7) Acknowledgement Receipt (6)
ProofMark Storage
Customer Firewall
this is an
acknolwled
gement
of your order Typical Scenario
for 100
eolas shares
1) Customer requests to pay monthly mortgage

ProofMark XML 2) Banking server issues electronic payment
request to banks payment execution system Issue ProofMark (4)
3) Banks payment execution system issues
payment acknowledgement
4) Banking server requests a ProofMark file
from ProofMark server ProofMark XML (5)
5) ProofMark server generates an XML file
ProofMark
(receipt) and returns it to the banking server Server
6) Banking server returns the "receipt" to the
customer
7) Customer stores and optionally prints the
receipt
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.

8
product architecture / system components
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

9
product architecture / servlet overview
ProofMark Client
ProofMark Servlets
Customer Application
XML ProofMark request Application Server /
Database
ProofMark Client API newly created ProofMark
Servlet Engine
HTML Servlets
HTTP Server
Web/HTTP Server
HTTPS/HTTP 1.1
OS
ProofMark generating
user event ProofMark Server
Browser ProofMark Software Architecture
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.

10
product architecture / servlet overview
ProofMark Software Architecture
ProofMark Servlets
Issuer Cross Certifier
Verifier Publisher
ProofMark Client
Retriever Replicator
Customer Application
HTML Servlets Propagator
ProofMark Client API
HTTPS/HTTP 1.1
JSP NTP
Servlet Engine
Client API
HTTP Server
OS Message Logging
Application Server /
Database
Servlet Engine
JRun JDBC
JSWDK DB2
JServ Oracle
WebLogic Native File
WebSphere System
HTTP Server
Browser Apache
others
Netscape
OS - 2000, NT, LINUX, Solaris
ProofMark Server
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

server’s Intervals
Publisher Stores Intervals and ProofMark certificates

11
product architecture / client API
Replicator Duplicates archives
Propagator Sends copies of the archive tree to the appropriate servers
platform specifications
The following are the platform specifications for implementing the ProofMark
system, February 2008.
Supported server platforms

Windows XP, Vista (planned). Linux Kernel 2.6.
Database support
Oracle Server, DB2, SQL Server and above.
Protocol requirements
HTTP 1.1 and XML
Security/crypto components
JSSE, SHA1, SHA2, SHA256, SHA384, SHA512, RSA, ECC (planned)
Recommended hardware
Multi-processor Intel X86-compatible systems.
Client API
Java, native COM/.NET, XML-over-HTTP
client API
The ProofMark client API provides a client-side application-programming

interface to the ProofMark server for issuing and verifying ProofMark
certificates. In the current release, the client API is implemented in Java, but
implementations in any other language or system that supports HTTP socket
programming are possible.

12
product architecture / issuance request options
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-user’s 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-Java
HTTP 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.

13
product architecture / performance considerations
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 server’s 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.

14
product architecture / persistent storage options
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, nCipher’s 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 Administrator’s Guide.

15
core concepts / the client component
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 for
the 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:

16
core concepts / the server component
- 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

17
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 3) Send ProofMark

Server via HTTP ProofMark
2) create proofmark XML
and store in Document
XML document
1) Request ProofMark ProofMark

via HTTP Server
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

18
- 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 be
contiguous (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

19
- 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 by

another 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 is
highly 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 chain’s Intervals are stored persistently in an archive (see Archive, below).

20
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, each
signed by the Interval’s private key.
At the end of each Interval the private key is destroyed and a new key pair is
generated for the subsequent Interval. During the process of activating a new
Interval, the current Interval’s private key signs the new Interval’s public key and
start and stop times. Once a signature for the Interval’s key has been acquired,
the private key is permanently destroyed.

21
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
certificate’s 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 server’s Interval. This process
provides independent proof of the existence of the Interval (and its public key) at
a 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.

22
Certiying Server X-Cert Certifying Server
X-Cert
X-Cert Issuing Server
X-Cert Certifying Server

Certifying Sever
The Cross-certification process requires that the timestamp (from a trusted time
source, 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 PKI

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

23
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 created
within 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.

24
ensuring server and Interval identity

A ProofMark server is uniquely identified by an Internet hostname and optional
port number, which defaults to 80. The server ID is included in the Interval.
The ProofMark server can interoperate with the Public Key Infrastructure (PKI)
digital certificates issued by a Certificate Authority (CA), such as Verisign,
Entrust, or a customer-operated CA.
Each ProofMark server can have an optional digital certificate with a Subject
distinguished name (SubjectDN) that matches the server’s hostname (the
serverID, excluding the optional port). Each server that has such a certificate
can be configured with information on how to locate and use the certificate
during startup. A server that has been so configured will use the certificate’s key
to create a digital signature of each Interval that it creates. The digital
certificate’s key and signatures are distinct and independent from the Interval’s
transient key-pair. The PKI information will appear as a PKISignature element in
the Interval within each ProofMark certificate issued by the server.
Although the feature for incorporating PKI signatures is not required by the
ProofMark server, it is an important security feature. Always implement this
feature in production servers since it provides for the authentication of the server
that issued any given ProofMark certificate and prevents spoofing attacks in
which a fraudulent server masquerades as a ProofMark server.
verification
Once a ProofMark certificate is issued, it is useful to be able to determine that it
has not been tampered with and that it is authentic. To determine that a
ProofMark certificate has not been tampered with since it was issued, an internal
consistency check can be performed. To determine that a ProofMark certificate
is authentic, it must be sent to an archive (see Archive, below) for verification.
To confirm a ProofMark certificate’s authenticity, it must be verified against an

Archive. There are several levels of Archive verification. All levels of Archive
verification perform the internal verification described above prior to checking
the archive. Each adds an additional level of authentication, preventing against
increasingly sophisticated attacks. Each level also takes additional computing
resources to complete.
The ProofMark system provides the following levels of verification:
- ProofMark internal verification
- Interval verification (the first level of archive verification)
- Cross-certification verification (the second level of archive verification)

25
- Digest log verification (the third level of archive verification)
Stronger
Digest
Log
Verification
Cross-Certification
Verification
Interval Verification
ProofMark Internal
Verification
Weaker
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 of

the 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 certificate
in 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.

26
cross-certification verification
The second level of archive verification authenticates the PKI signatures, and
checks the archive for the public key of the Interval. Then, the Interval’s Cross-
certifications (which are themselves ProofMark certificates) existing in the
Archive are recursively authenticated.
digest log verification

The highest level of archive verification authenticates the PKI signatures, checks
the archive for the public key of the Interval, and checks the Interval's Cross-
certifications. When these have been verified, the server confirms that the
ProofMark digest exists in the Interval’s archived digest log.
ProofMark verification reports

The ProofMark server issues a ProofMark verification report in response to a
verification request. Input to this request is the ProofMark certification (the XML)
to be verified. Output from this request is a Verification Report XML document
containing the results.
The verification report either lists any errors discovered in the process or
indicates that the verification was successful.
See Verification Report Anatomy for detailed information on the report’s

contents.
archives
An archive is a logical or named database in which Intervals and their Cross-
certifications are stored. The ability to retrieve an Interval and its Cross-
certifications from an archive provides all the information necessary to complete
the verification of a ProofMark certificate.
Because an archive is a logical database, it can be shared or replicated (copied)

to many servers, and can be hosted on any server. Its physical persistence may
be mapped into either a normal file system or a JDBC-compliant (Java Database
Connectivity) relational database.
A unique hostname URL:hostname or hostname:port identifies each archive,

where the port defaults to 80. This host name is the logical host of the archive,
which may be either a single real server or a load-balance proxy to a group of
servers. Other hosts may have replicas of the archive as well.

27
If the archive’s 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 directory

ProofSpace 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 certificate’s
archive 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 to
additional archives. The archive Tree is represented as part of the Interval’s 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).
28
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 Interval’s 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 then
becomes 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 being
certified
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 archive’s integrity is planned for a
future version of the system.

29
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
Interval’s 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 Interval’s 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 Interval’s archive Tree (the propagation flag for the Interval is cleared
when the Interval has been propagated successfully to each of these
archives)
?? 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
30
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.

31
planning your ProofMark implementation / considerations for selecting
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.

32
planning your ProofMark implementation / topology considerations
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

33
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

34
reciprocal peer topology

The reciprocal peer topology consists of ProofMark clients connecting directly to
one or more ProofMark servers that cross-certify each other.
Persistent
Archive
X-Cert
P P
1 2
Load Balancer
C1 Cn
C2 ..
In this diagram, all of the organization’s 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 archive’s
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
35
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.
Persistent
Archive
Load Balancer
(Verification host)
X-Cert
P P
1 2
NP NP NP
...
1 2 n
Load Balancer
(Issuing 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.
36
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 optional
or 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.
Org1
X-C
h ert,
blis Pu
Pu blis
ert, h
Org2 X-
C
Org3
X-Cert, Publish
X-Cert, Publish
X-C h
ert blis
,P Pu
ub ert,
lish C
X-
Org4
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
37
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, S 1 is considered a broker between the public records and
organization S 2.
PR1 PR2 PR3
X-Cert, Publish
X-
Ce
h
rt,
blis
Pu
Pu
blis
rt,
h
Ce
X-
S1
S2 ,P
ub
lish
Cert
X-

38
appendix A—cryptography primer / basic concepts
appendix A—cryptography 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 is
called 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.
39
appendix A—cryptography primer / basic concepts
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 is
authentication 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 certificate, a digitally signed
public 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 authority (CA) issues and manages the certificates. Some well-
known CA’s 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 key’s certificate. 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. 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. Most
algorithms are published in order to undergo public scrutiny to see if there are
any weaknesses that can break the cipher.

40
appendix A—cryptography primer / uses of cryptography
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.

41
appendix B—glossary / uses of cryptography
appendix B—glossary
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 certificate 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 cryptography
and 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

42
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 for
synchronizing 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

43
- 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 allows
what 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.

44
index / uses of cryptography
index
additional safeguards, 7 hardware acceleration, 15

application integration, 10 hierarchical topology, 38
archives HSM, 43
directory, 28 HTTP, 10
integrity, 29 indicia, 43
Interval archive tree, 28 integrity of archives, 29
introduction, 27 internal consistency check, 17
publication, 30 internal verification, 26
replication, 28 inter-organizational topologies, 36
asymmetric encryption, 44 Intervals
authenticating a ProofMark archive tree, 28
certificate, 17 archives, 27
BLOB, 42 creating, 5
certificate. see ProofMark cross-certification, 22
certificate definition, 19
certificate authority, 42 identity, 25
certificate revocation list, 42 Interval chains, 5, 6, 7, 19, 20, 29,
chain of Intervals, 5, 6, 7, 19, 20, 29, 32
32 introduction, 19
ciphertext, 42 issuing ProofMark certificates, 21
client API, 4, 8, 10, 12, 16 selecting Interval length, 32
client component, 4 transient-key technology, 6
configuration intra-organizational topologies, 34
hardware acceleration, 15 issuance requests, 13, 18
issuance request options, 13 issuing ProofMark certificates, 5, 21
load balancing, 14 Java servlets, 10
multi-processor support, 14 JDBC, 43
persistent storage options, 15 key, 43
creating Intervals, 5 length of Intervals, 32
CRL, 42 load balancing, 14
cross-certication verification, 27 load balancing topology, 35
cross-certification, 22, 27 meshed peer topologies, 37
archives, 27 message digest, 43
cryptographic accelerator cards, 15 message log, 30
cryptography primer, 39 MP machines, 14
cryptography, definition, 42 multiplexing proxy, 14
cryptography, uses, 41 multi-processor support, 14
decryption, 42 NTP, 43
digest log performance considerations, 14
verification, 27 persistent storage options, 15
digest logs, 17, 24 plaintext, 43
digital certificate, 42 planning your implementation, 32
digital signature, 42 Interval length, 32
DTD, 42 topology, 33
encryption, 42 platform specifications, 12

45
index / uses of cryptography
product architecture, 9 servers, 4

ProofMark archive directory, 28 servlets
ProofMark certificates cross certifier, 11
authenticating, 17 definition, 44
data included, 5 issuer, 11
definition, 1, 18 overview, 10
examples of data, 2 propagator, 12
introduction, 18 publisher, 11
issuance request options, 13 replicator, 12
issued by Intervals, 21 retriever, 11
issuing, 5 verifier, 11
referencing, 13 SHA2 digest, 16
referencing data, 13 specifications, 12
verification, 25, 26, 27 storage
verification reports, 27 JDBC database, 15
verification requests, 16 local file system, 15
verifying, 6 symmetric encryption, 44
ProofMark client API. See client API syslog, 30
ProofMark references, 13 system components, 9
ProofMark requests, 16 technology overview, 4
ProofMark servers, 4 time source, 23
ProofMark Verification Report, 6 topology considerations, 33, 34, 36
public key infrastructure, 43 transaction flow (sample), 8
publication, 30 transient-key technology, 1, 4, 5, 6,
RDIST, 43 19, 24
reciprocal peer topology, 35 trusted time, 23
recursive verification, 17 TTP, 44
recursive verification with digest UML, 44
log, 17 uses of the ProofMark system, 1
referencing data in ProofMark UTC, 44
certificates, 13 verification, 25, 26
referencing ProofMark certificates, verification reports, 27
13 verification requests, 16
replication, 28 verifying ProofMark certificates, 6
RSYNC, 43 X.509, 44
server component, 4 X.509 certificates, 16
server components, 17 XML, 44
server identity, 25 XML documents, 5, 17, 18


ProofMark System Concepts, Architecture, &amp; Planning Guide 2.08

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ProofMark System Concepts, Architecture, &amp; Planning Guide 2.08

Uploaded by

Copyright:

Available Formats

ProofMark System Concepts, Architecture, and Planning Guide

Portions of the information described in this

Copyright 1999-2008, ProofSpace, Inc.

Use of this copyright notice does not imply

Printed in the United States of America

product architecture ..........................................................................9

planning your ProofMark implementation .........................................34

appendix A—cryptography primer ....................................................42

appendix B—glossary ......................................................................45

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

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

Possible uses of the ProofMark system include:

- Electronic Commerce—digital receipts for Internet purchases and business-to-

- Healthcare or medical applications—authenticity of patient records, x-rays, a

- Securities Trading—brokerage order acknowledgements and confirmations

- Online banking—proof of bill payments, account transfers

- Drug Trials—a chain-of-proof of the test results over time

- Electronic Communications—content integrity of e-mail or attached files

The ProofMark certificate provides an independently verifiable, digital proof of

ProofSpace , Inc., ©1999-2008

system verifies the timestamp included in the ProofMark certificate by

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

what’s in this guide

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

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

Additional interested readers may include IT Managers, Quality Assurance

The guide is organized as follows:

Product architecture. This section describes the system components, platform

Planning your ProofMark implementation . This section describes the

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

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

- SDK Programmer's Guide

- ProofMark Technical Overview

- ProofMark XML Reference Guide

- Server Installation Guide

ProofSpace , Inc., ©1999-2008

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

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

- Sample of transaction flow

the client component

the server component

- Issuing ProofMark certificates

- Verifying ProofMark certificates

ProofSpace , Inc., ©1999-2008

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

issuing ProofMark certificates

ProofSpace , Inc., ©1999-2008

Dissection of a ProofMark Certificate

verifying ProofMark certificates

Intervals and transient-key technology

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

By using transient-key technology:

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

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

The ProofMark server’s transient-key technology provides the means to issue

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

ProofSpace , Inc., ©1999-2008

ProofMark System Concepts, Architecture, & Planning Guide 2.08

ProofMark System Concepts, Architecture, & Planning Guide 2.08