Professional Documents
Culture Documents
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.
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
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
index ...............................................................................................48
introduction / what’s in this guide
introduction
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.
1
introduction / what’s in this guide
You should read this guide if you are involved in the implementation of a
ProofMark system from a technical perspective. Appropriate readers include:
- 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
Core concepts. This section describes the core concepts of the ProofMark
system, grouping them by client and server.
2
introduction / additional documentation
additional documentation
The following are additional documents provided with the ProofMark system:
3
technology overview / the server component
technology overview
- Additional safeguards
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.
When you use the ProofMark system, you set up one or more ProofMark servers,
which have three primary responsibilities:
- Creating Intervals
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.
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
Request
Interval Information
Timestamp
Digital Signature
- The private key exists only for a short period of time (the duration of the
Interval)
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
7
technology overview / sample of transaction flow
The following diagram displays one of many example scenarios involving the use
of the ProofMark system.
Payment Acknowledgment
Scenario
Payment Execution
System
Issue payment (2)
Banking Web Server
Print Receipt
(7) Acknowledgement Receipt (6)
ProofMark Storage
Customer Firewall
this is an
acknolwled
gement
of your order Typical Scenario
for 100
eolas shares
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
- System components
- Servlet overview
- Platform specifications
- Client API
- Performance considerations
system components
- ProofMark server
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
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 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 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
ProofMark Server
Servlet Purpose
Issuer Responds to requests from the client API for the issuance of a
ProofMark certificate
Retriever Responds to requests from the client API for the retrieval of a
ProofMark certificate, given a ProofMark reference
11
product architecture / client API
platform specifications
The following are the platform specifications for implementing the ProofMark
system, February 2008.
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
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).
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.
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
Interval Server ID
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%.
The are two storage options for Intervals, ProofMark certificates, and Digest
Logs:
You can use both options in combination: file system for Intervals and Digest
Logs, a relational database for ProofMark certificates.
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:
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:
- 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
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 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
- Verification
- Archives
- Publication
17
core concepts / the server component
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.
- The timestamp, in UTC, that the ProofMark certificate was issued and the
current accuracy of the server's time source
18
core concepts / the server component
- A copy of the message digest (hash) from the previously issued ProofMark
certificate
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 start time of the Interval chain in UTC (universal coordinated time, see
Trusted time)
19
core concepts / the server component
- 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
- 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
core concepts / the server component
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
core concepts / the server component
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.
22
core concepts / the server component
X-Cert
X-Cert Issuing Server
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.
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
core concepts / the server component
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.
24
core concepts / the server component
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.
25
core concepts / the server component
Stronger
Digest
Log
Verification
Cross-Certification
Verification
Interval Verification
ProofMark Internal
Verification
Weaker
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
core concepts / the server component
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.
The verification report either lists any errors discovered in the process or
indicates that the verification was successful.
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.
27
core concepts / the server component
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.
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
28
core concepts / the server component
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
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
core concepts / the server component
publication
Publication refers to the process of making Intervals and their Cross-
certifications available in one or more databases that are:
- An Interval and its Cross-certifications are published to the root archive in the
Interval’s archive Tree, before the Interval can become active
?? This recursive process continues until the Interval has eventually been
stored in each archive in its archive Tree
30
core concepts / the server component
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
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.
- Creation of the next Interval (each Interval is prepared during the previous
Interval, so longer is better)
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
- 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
- Intra-organization
- Inter-organization
33
planning your ProofMark implementation / topology considerations
intra-organizational topologies
The two primary intra-organizational topologies are:
- Reciprocal peer
- Load balancing
34
planning your ProofMark implementation / topology considerations
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.
35
planning your ProofMark implementation / topology considerations
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
36
planning your ProofMark implementation / topology considerations
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
37
planning your ProofMark implementation / topology considerations
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.
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
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.
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.
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
BLOB
Binary Large OBject.
ciphertext
In cryptography, ciphertext is encrypted text.
CRL
Certificate Revocation List.
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.
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
appendix B—glossary / uses of cryptography
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.
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:
43
appendix B—glossary / uses of cryptography
- Preserving symbolic links, hard links, file ownership, permissions, devices, and
times
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.
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
45
index / uses of cryptography