In a public/private key system, the problem of having to distribute a secret key
and still maintaining the ability of keeping it secret has been resolved.
The public and private key pair makes up the entire secret key, but instead of
distributing the entire key, only half is distributed while the other half is
not. In this case, the public key is distributed and the private key is
not -- making the private key easier to secure. The public key can be
published and freely distributed without any concern of making it secret.
Together, the public/private key pair makes up one key because both are
required to secure and un-secure the document. For example, a document
encrypted using the public key requires the private key to decrypt the same
document. A document signed using the private key requires the public key
to verify the same document. A secure transmission can be established
between multiple trading partners just by distributing the public key between
them.
Public Private Key Pair
A digital certificate comprise of:
Public Key. The public key is a stream of binary data
always present in the digital certificate that is distributed to
trading partners of an organization. If trading partner A owns
a digital certificate, it would distribute a file or object that
contains this public key to trading partner B who will then use it
for the following:
Verifying. The owner of the certificate, trading
partner A, signs the document and sends it to trading partner B
who then uses the public key to verify that the signed document
has not been modified or tampered with.
Encrypting. To hide confidential information from
a third party, trading partner B uses the public key to encrypt
the document before sending it to trading partner A.
Private Key. The private key of the digital certificate is
never present in the file or object containing the public key that
is distributed to trading partners. It must always remain
separate from the public key. The only time a private key and
a public key pair exists together in a file is for storage purposes,
and the file is kept in a secure location. Otherwise, the
private key is maintained separately in a secure database and
accessed securely by applications when it is required.
Although kept separate, the private key and the public key are
linked by a complex algorithm, such that the associated private key
pair can be found in a certificate store just by running the
algorithm against the public key binary
The private key is used for the following:
Signing. The owner of the certificate, trading partner
A, uses the private key of the certificate to sign the document
before sending it to trading partner B who will then use the
corresponding public key pair to verify the signed document.
Decrypting. Trading partner B who possesses the
public key pair uses the key to encrypt the document before
sending it to trading partner A who will then use the associated
private key it owns to decrypt the document.
Figure 1. Diagram shows how public and private keys come into
play when exchanging documents. This scenario only shows trading partner
A possessing a certificate and is able to completely secure transactions
with partner B. To mandate secure transactions, partner B would
have to own a digital certificate as well.
Impersonation
Digital certificates makes it easier to manage keys and this feature
of simple key management allows secure transactions with multiple
trading partners possible. However, simple key management does not
address one of the key security issue of digital certificates:
impersonation. Impersonation allows a malicious third party to
pretend that it is an established trading partner of the organization
when in reality it is not, and in so doing intercepts any
secure documents that may have been intended for the actual trading
partner without the knowledge of both legal parties.
Consider the following scenario where trading partner A wants secure
communication with trading partner B.
Partner A wants to send a document to partner B unmodified, so it
signs a document, and then sends it to B who then verifies the
document using the public key it received from partner A.
Partner A wants to receive a confidential document from partner B,
so partner B encrypts a document using the public key it received
from A, and then sends it to partner A who then decrypts the
document using its private key.
Figure 2. Diagram showing flow of how a malicious entity can
impersonate trading partner A.
Impersonation begins when a malicious entity C can intercept
documents between trading partners A and B unbeknownst to both parties.
AA. Malicious entity C intercepts the certificate
containing the public key (Public Key A) from A. The public key is
kept by C and not discarded, and it then publishes a different
certificate containing a different public key (Public Key C)
specifying it is from A. Partner B believes that Public Key
C is from partner A.
S1. Impersonating a signature.
Partner A signs a document, Doc A, using its Private
Key A and sends it to partner B. Note: The digital
signature of a document is unique to that document. It is a
string that represents the byte-for-byte makeup of the document,
and a single character change made to that document will
generate a different signature. Thus the signature alone
guarantees the integrity of the contents of the document, and a
valid signature received by the receiving partner ensures that
the document has not been tampered with.
S2. Entity C intercepts the signed Doc A, and
using Public Key A, that it illegally acquired from A,
can verify the signature of Doc A.
S3. Having verified Doc A, entity C begins to
tamper with the contents of Doc A, modifying the text the
way C would like B to view it.
S4. After having modified Doc A, entity C signs
the document with its own Private Key C, and then sends
the document to B. Because of the modification made to the
document, the signature is now completely different from the
signature created by A..
S5. Partner B receives Doc A and believes it to
have originated from A. To be sure that it has not been
tampered with, it uses the public key that it believes it
received from A - Public Key C. Because Doc A
was signed using Private Key C, the document will verify
correctly using Public Key C. Thus partner B is
satisfied that the tampered document has been received from
partner A unmodified.
E1. Impersonating encryption.
Partner B wants to send a confidential document, Doc B,
to partner A. Partner B uses the public key it believes to
have received from partner A - Public Key C - and uses
this public key to encrypt the document. The encrypted
document is then sent to A.
E2. Entity C intercepts the encrypted Doc B, and
it then proceeds to decrypt Doc B using its Private
Key C. Because Doc B was encrypted using Public
Key C, the cipher text in Doc B will correctly
convert to plain text. Entity C can now view the
confidential information of A and B in plain text.
E3. After having viewed the document, entity C encrypts
Doc B using the Public Key A that it had illegally
acquired from A.
E4. The cipher text of the resulting encrypted document
has changed completely from the one that was originally
encrypted by partner B using Public Key C. The
document is then sent to partner A.
E5. Partner A receives the encrypted Doc B and
believes it to have originated from B. It proceeds to
decrypt the document using its Private Key A, and because
it was previously encrypted by malicious entity C using Public
Key A, the cipher text in the document will convert
correctly to plain text. Because partner A believes that
partner B was in possession of Public Key A, and
therefore the document was encrypted at the point of origin, it
is satisfied that only partner B has seen the contents of the
document.
Certificate Authority (CA)
To overcome the problem of impersonation, a Certificate Authority
(CA) has to be used. The CA provides the digital certificate for
the trading partners and is "stamped with certification" by
signing the issued certificates with the private key of the CA. It
also sets
itself as the issuer of the certificate. Any
trading partner requiring verification of the certificate can easily obtain and
use the public key of the CA to verify the certificate. For
example in the previous scenario, as soon as trading partner B received
the certificate from C it would verify if it actually came from partner
A. The certificate of trading partner A has been signed by a CA so
it contains a signature that only the CA can verify. The
certificate from entity C may have a signature but it will not be the
signature produced by the CA for A, so when B verifies the signature,
the verification will fail - protecting B from incorrectly using a
different public key.
Self-Signed Certificates
Self-signed certificates are digital certificates that have been created without
a CA. The entity that created the certificate is the same entity that has
signed and certified it. The most important aspect about digital
certificates is the presence of a CA, and, without it, the certificate is not
secure. Thus self-signed certificates should only be used for
testing. In some instances, self-signed certificates may be used between
bi-lateral trading partners, where there are other outside form of
communication and verification that can mitigate the risk of impersonation.
X.509 Digital Certificates and Cryptographic Service Providers
The Cryptographic Service Provider (CSP) system in Windows (R) operating systems
(except Windows 95 (R)) supports the X.509 Digital Certificate format.
Framework EDI (FREDI) provides the capability to import and export valid
digital certificates to certificate stores in the operating system. The
certificates can then be used for cryptographically encrypting, decrypting,
signing and verifying documents.
Digital certificates can also be created using FREDI, but, absent of a CA, they
can only be used for testing. There are two ways to create a digital
certificate:
The principle method of creating the digital certificate is to take the public
key from a key container in a CSP and storing it in a certificate. The
key container can contain at most two public/private key pairs. The test
certificate can use any of the public key in the public/private key pairs.
