Building an E-Commerce Trust
Infrastructure SSL
Server Certificates and Online Payment Services
Executive
Summary Businesses that can manage and process e-commerce
transactions can gain a competitive edge by reaching a worldwide
audience, at very low cost. But the Web poses a unique set of trust
issues, which businesses must address at the outset to minimize
risk. Customers submit information and purchase goods or services
via the Web only when they are confident that their personal
information, such as credit card numbers and financial data, is
secure.
The solution for businesses that are serious about
e-commerce is to implement a complete e-commerce trust
infrastructure. PKI cryptography and digital signature technology,
applied via Secure Sockets Layer (SSL) digital certificates, provide
the authentication, data integrity, and privacy necessary for
e-commerce. Internet payment gateway systems provide online
merchants with the ability to efficiently and securely accept and
process a variety of online payments from
customers.
VeriSign, Inc., offers the essential components of
an Internet trust infrastructure to e-commerce businesses. By
installing a VeriSign SSL Server ID on their Web servers, businesses
can securely collect sensitive information online and increase
business by giving their customers the confidence of knowing that
payment transactions are safe. VeriSign Payment Services VeriSign
Payflow Payment Services simplify e-commerce by providing payment
connectivity over the Internet between buyers, sellers, and
financial networks for transactions involving all major consumer
credit card, debit card, electronic check, purchase card, and
Automated ClearingHouse (ACH) transactions. VeriSign's Commerce Site
solutions combine both SSL Server IDs and Payflow Pro payment
services, along with additional value-added features, to form a
complete e-commerce trust infrastructure solution.
|
I.
The E-Commerce Opportunity A secure e-commerce Web site
can provide businesses with powerful competitive advantages,
including increased online retail sales as well as streamlined
application processes for products such as insurance, mortgages, or
credit cards. E-commerce credit card sales can be especially
lucrative: according to independent analysts, cash transactions on
the Internet will reach $9 billion in 2000, and $30 billion in
2005.
By offering products and services on the Web,
businesses can gain unique benefits:
- New customers: Anyone with an Internet connection is a
potential customer: millions around the world are already using
the Internet for business transactions. Web storefronts are open
24 hours a day, and require no investments in brick and mortar.
- Cost-effective delivery channel: Many products and
services, such as software or information, can be distributed
directly to customers via the Web, enhancing the customer
experience and increasing profitability by eliminating the
shipping and overhead costs associated with order fulfillment.
- Streamlined enrollment: Paper-based enrollment
workflows are fraught with delays. Applications for insurance, a
mortgage, or a credit card, for example, can be held up in the
mail. And once received, application information must be entered
into computer systems manually, a labor-intensive process that can
introduce errors. By accepting applications via a secure Web site,
businesses can speed application processing, reduce processing
costs, and improve customer service.
- Better marketing through better customer knowledge:
Establishing a storefront on the Web positions enterprises for
one-to-one marketing — the ability to customize products and
services to individual customers rather than large market
segments. The Web facilitates one-to-one marketing by enabling
businesses to capture information about demographics, personal
buying habits, and preferences. By analyzing this information,
enterprises can target merchandise and promotions for maximum
impact, tailor Web pages to specific consumers, and conduct
effective, tightly focused marketing campaigns.
No
business can afford to ignore this opportunity. But businesses also
can't ignore the potential pitfalls. Before entering the fiercely
competitive e-commerce arena, businesses must carefully assess and
address the accompanying risks.
A.
The Risks and Challenges of E-Commerce Trust To succeed in
the fiercely competitive e-commerce marketplace, businesses must
become fully aware of Internet security threats, take advantage of
the technology that overcomes them, and win customers' trust.
Eighty-five percent of Web users surveyed reported that a lack of
security made them uncomfortable sending credit card numbers over
the Internet. The merchants who can win the confidence of these
customers will gain their loyalty — and an enormous opportunity for
expanding market share.
In person-to-person transactions,
security is based on physical cues. Consumers accept the risks of
using credit cards in places like department stores because they can
see and touch the merchandise and make judgments about the store. On
the Internet, without those physical cues, it is much more difficult
to assess the safety of a business. Also, serious security threats
have emerged. By becoming aware of the risks of Internet-based
transactions, businesses can acquire technology solutions that
overcome those risks:
- Spoofing — The low cost of Web site creation and the
ease of copying existing pages makes it all too easy to create
illegitimate sites that appear to be published by established
organizations. In fact, con artists have illegally obtained credit
card numbers by setting up professional-looking storefronts that
mimic legitimate businesses.
- Unauthorized disclosure — When transaction information
is transmitted "in the clear," hackers can intercept the
transmissions to obtain customers' sensitive information.
- Unauthorized action — A competitor or disgruntled
customer can alter a Web site so that it refuses service to
potential clients or malfunctions.
- Eavesdropping — The private content of a transaction,
if unprotected, can be intercepted en route over the Internet.
- Data alteration — The content of a transaction can be
not only intercepted, but also altered en route, either
maliciously or accidentally. User names, credit card numbers, and
dollar amounts sent "in the clear" are all vulnerable to such
alteration.
B.
The Goals of Implementing an E-Commerce Trust
Infrastructure To take advantage of the opportunities of
e-commerce and avoid the risks of communicating and transacting
business online, every business must address practical problems and
questions involving privacy, security, and overall confidence in the
underlying features of the system. Such concerns include:
"How can I be certain that my customers' credit
card information is not accessible to online eavesdroppers when they
enter into a secure transaction on the Web?"
"How can I
reassure customers who come to my site that they are doing business
with me, not with a fake set up to steal their credit card
numbers?"
"Once I've found a way to authoritatively identify
my business to customers and protect private customer information on
the Web, what's the best way to let customers know about it, so that
they can confidently transact business
with me?"
"When customers feel confident
enough to buy something from me online, how can I enable them to pay
me easily using their credit cards or other
payment methods?"
"How can I verify that
customer's credit card information is valid?"
"What do I do
with payment information once customers send it to me?"
The process of addressing these general security questions
determine the fundamental goals of establishing an e-commerce trust
infrastructure:
Authentication: Customers must be able
to assure themselves that they are in fact doing business and
sending private information with a real entity — not a "spoof" site
masquerading as a legitimate bank or
e-store.
Confidentiality: Sensitive Internet
communications and transactions, such as the transmission of credit
card information, must be kept private.
Data
integrity: Communications must be protected from undetectable
alteration by third parties in transmission on the
Internet.
Nonrepudiation: It should not be possible
for a sender to reasonably claim that he or she did not send a
secured communication or did not make an online purchase.
|
II.
The Solution: How to Build an Infrastructure for Trusted
E-Commerce The solution for meeting each of the goals
above includes two essential components:
- Digital certificates for Web servers, to provide
authentication, privacy and data integrity through encryption
- A secure online payment management system, to allow e-commerce
Web sites to securely and automatically accept, process, and
manage payments online
Together, these technologies form
the essential trust infrastructure for any business that wants to
take full advantage of the Internet.
A.
Overview: Public Key Cryptography & Digital
Certificates This section presents background technical
information on cryptographic systems, including Public Key
Cryptography, the system underlying Secure Sockets Layer (SSL) — the
basis for every e-commerce trust infrastructure.
Encryption
is the process of transforming information before communicating it
to make it unintelligible to all but the intended recipient.
Encryption employs mathematical formulas called cryptographic
algorithms, or ciphers, and numbers called keys, to encrypt or
decrypt information.
1.
Symmetric Cryptography Until recently, symmetric
encryption techniques were used to secure information transmitted on
public networks. Traditional symmetric cryptographic systems are
based on the idea of a shared secret. In such a system, two parties
that want to communicate securely first agree in advance on a single
"secret key" that allows each party to both encrypt and decrypt
messages.
Symmetric cryptography has several drawbacks.
Exchanging secret keys is unwieldy in large networks. Furthermore,
the sharing of secret keys requires both senders and recipients to
trust, and therefore be familiar with, every person they communicate
with securely. Also, symmetric systems require a secure channel to
distribute the "secret" keys in the first place. If there is indeed
such a secure channel, why not use it to send the entire secret
message?
In today's Web-based systems involving many
participants and transitory interactions with strong cryptography
requirements, such symmetric key-based systems are highly
impractical as a means for agreeing upon the necessary secrets to
begin communicating securely.
This problem, the key
agreement, or key distribution problem, is part of a larger problem
that is central to the modern understanding of cryptographic systems
— the key management problem. The key management problem described
more fully below. Together, they represent the fundamental challenge
in designing effective cryptography systems for modern computing
systems. Symmetric key encryption plays an important role in the SSL
protocol, along with asymmetric public key encryption.
2.
Public-Key Cryptography Today's public key, or asymmetric
cryptography systems are a considerable improvement over traditional
symmetric cryptography systems in that they allow two parties to
exchange data privately in the presence of possible eavesdroppers,
without previously agreeing on a "shared secret." Such a system is a
called "asymmetric" because it based on the idea of a matched
cryptographic key pair in which a cryptographic key is no longer a
simple "shared secret" but rather is split into two subkeys, the
private key and public key.
Abstractly, a participant wishing
to receive encrypted communications using an asymmetric cryptography
system will first generate such a key pair, keeping the private-key
portion as a secret and the "publishing" the public-key portion to
all parties that would like to encrypt data for that participant.
Because encrypting data requires only access to the public key, and
decrypting data requires the private key, such a system in principle
can sidestep the first layer of complexity in the key management
problem since no shared secret need be exchanged.
3.
Modern Cryptography Systems: A Hybrid Approach In fact, a
combination of both public-key and traditional symmetric
cryptography is used in modern cryptographic systems. The reason for
this is that public-key encryption schemes are computationally
intensive versus their symmetric key counterparts. Because symmetric
key cryptography is much faster for encrypting bulk data, modern
cryptography systems typically use public-key cryptography to solve
the key distribution problem first, then symmetric key cryptography
is used to encrypt the bulk data.
Such a scheme is used by
today's SSL protocol for securing Web transactions, as well as by
secure e-mail schemes such as S/MIME that are built into such
products as Netscape Communicator and the Microsoft Internet
Explorer. See "IV. SSL Server Certificates" below for more on
SSL.
4.
The Key Management Problem Underlying every cryptographic
system is a set of practical problems and questions involving
privacy, security, and overall confidence in the underlying
confidentiality features of the system. In principle, the techniques
of asymmetric and symmetric cryptography are sufficient to resolve
the security questions and properties described above. For example,
today's Web browsers use the public key of a Web site in order to
send credit card numbers over the Web; similarly, one can protect
access to files and data using a private symmetric key to scramble
the information before saving it.
However, in practice, each
of these problems requires a "certified" public key in order to
operate correctly without third parties being able to interfere.
This leads to a second set of questions; for example:
"How can I be sure that the public key that my
browser uses to send credit card information is in fact the right
one for that Web site, and not a bogus one?"
"How can I
reliably communicate my public keys to my correspondents so that
they can rely on it to send me encrypted communications?"
What's needed in order to address such concerns is the
notion of a "secure binding" between a given entity that
participates in a transaction and the public key that is used to
bootstrap secure communication with that entity using asymmetric
public key cryptography. The next section describes how a
combination of digital signatures and X.509 digital certificates
(which employ digital signatures), including SSL certificates,
fulfills this role in e-commerce trust systems.
5.
Digital Signatures Digital signatures are based on a
combination of the traditional idea of data hashing with public-key
based encryption. Most hash functions are similar to encryption
functions; in fact, some hash functions are just slightly modified
encryption functions. Most operate by grabbing a block of data at a
time and repeatedly using a simple scrambling algorithm to modify
the bits. If this scrambling is done repeatedly, then there is no
known practical way to predict the outcome — it is not in general
practical for someone to modify the original data in any way while
ensuring that the same output will emerge from the hash function.
These hash-based signature algorithms use a cryptographically secure
hash function such as Message Digest 5 (MD-5) or Secure Hash
Algorithm (SHA) to produce a hash value from a given piece of
data.
Because the digital signature process is central to the
idea of a digital certificate — and in turn, the digital certificate
is the primary tool to ensure e-commerce security — it's useful to
look at a diagram of the process:
Figure 1: Steps in forming and
verifying a digitally signed message The figure
illustrates the steps taken by a sender in forming a digitally
signed message as well as the steps a recipient takes in verifying
that the signed message is valid.
The first step is to take
the original message and compute a "digest" of the outgoing message
using a hashing algorithm. The result is a "message digest," which
is typically is depicted as a long string of hexadecimal digits (and
manipulated by software as binary data). In the next step, the
sender uses his private key to encrypt the message
digest.
The original message content, together with the
encrypted digest, forms a digitally signed message, as depicted in
the center of the figure. This digitally signed message is suitable
for delivery to the recipient. On receipt, the receiver verifies the
digital signature using an inverse set of steps: first the encrypted
digest is decrypted using the sender's public key. Next, this result
is compared to an independent computation of the message digest
value using the hashing algorithm. If the two values are the same,
the message has been successfully verified.
Note that no
actual encryption of the message content itself need take place.
Only the digital signature itself is encrypted while the message is
in transit (unless, of course there are privacy concerns, in which
case the message content should be encrypted as well).
Why is
a digital signature compelling evidence that only the intended
signer could have created the message? For example, what if
interlopers were to change the original message? It was not
encrypted, after all, and could have been changed by a third party
in transit. The answer is that if such a change had been made, then
the decrypted, original message digest wouldn't have matched the
recomputed one for the changed data in the message. Verification of
the digital signature would fail. Similarly, the creation of a bogus
signature is impractical because an interloper doesn't have the
appropriate private key.
6.
Digital Certificates A digital certificate is an
electronic file that uniquely identifies individuals and Web sites
on the Internet and enables secure, confidential communications. It
associates the name of an entity that participates in a secured
transaction (for example, an e-mail address or a Web site address)
with the public key that is used to sign communication with that
entity in a cryptographic system.
Typically, the "signer" of
a digital certificate is a "trusted third party" or "Certificate
Authority" (CA), such as VeriSign, that all participants to the use
of the such certificates agree is a point of secure storage and
management of the associated private signing key. The CA issues,
creates, and signs certificates as well as possibly playing a role
in their distribution.
Using digital certificates simplifies
the problem of trusting that a particular public key is in fact
associated with a participating party, effectively reducing it to
the problem of "trusting" the associated CA service. Digital
certificates therefore can serve as a kind of digital passport or
credential. This approach represents an advance in the key
management problem because it reduces the problem of bootstrapping
trust to the problem of setting up (or in today's marketplace,
selecting as a vendor) the appropriate CA functionality. All parties
that trust the CA can be confident that the public keys that appear
in certificates are valid.
a.
Example: Use of Signer Certificates in Netscape Communicator (v4.05
& later) Digital certificates already play a
fundamental role in Internet-based cryptography systems. For
example, consider the case of a secure Web transaction that takes
place when a user visits a Web storefront to make a credit card
purchase. When the user's browser accesses a secure page, a public
key from the Web store has already been delivered to the client
browser in the form of an X.509 digital certificate. All this
happens transparently to the browser user at the time the secure
connection is set up.
The browser trusts the certificate
because it is signed, and the browser trusts the signature because
the signature can be verified. And why can it be verified? Because
the signer's public key is already embedded in the browser software
itself. To see this in the particular case of Netscape Communicator,
begin by clicking on the "Security" icon on the main
toolbar.
Figure 2: The "Security" Toolbar
button in Netscape Communicator v4.0 Under
"Certificates" choose "Signers," and scroll down the list. A window
similar to the following should appear:
Figure 3: The list of certificate
signers hard-coded to be trusted in Netscape
Communicator Next, select a particular
certificate and click on the "Edit" button. A display similar to the
following should appear:
Figure 4: A VeriSign CA
certificate embedded in Netscape Communicator
This is a representation of an X.509 digital certificate.
Although X.509 certificates come in three different versions,
version 3 certificates, such as the one displayed here, are the ones
that are most commonly encountered in today's cryptography systems.
Such a certificate consists of the following fields to identify the
owner of the certificate as well as the trusted CA that issued the
certificate:
- version
- serial number
- signature algorithm ID
- issuer name
- validity period
- subject (user) name
- subject public-key information
- issuer unique identifier (version 2 and 3 only)
- subject unique identifier (version 2 and 3 only)
- extensions (version 3 only)
- digital signature for the above fields
Figure 5: The fields of a X.509 digital
certificate
Although only a few of these fields
are shown in Figure 4 (version, serial number, issuer name, and
subject name) correspond to the display elements in Figure 4, these
basic elements give an idea of what such a typical certificate
contains.
A more detailed dump of raw certificate content
looks like this:
Certificate: Data: Version:
v3 (0x2) Serial Number: 8
(0x8) Signature Algorithm: PKCS #1 MD5 With RSA
Encryption Issuer: CN=Root CA, OU=CIS,
O=Structured Arts Computing Corporation,
C=US Validity: Not
Before: Fri Dec 5 18:39:01 1997 Not
After: Sat Dec 5 18:39:01 1998 Subject: CN=Test
User, OU=Test Org Unit, O=Test Organization,
C=US Subject Public Key
Info: Algorithm: PKCS #1 RSA
Encryption Public
Key: Modulus: 00:c2:29:01:63:a1:fe:32:ae:0c:51:8d:e9:07:6b:02:fe:ec: 6d:0e:cc:95:4b:dc:0a:4b:0b:31:a3:1a:e1:68:1f:d8:0b:b7: 91:fb:f7:fd:bd:32:ba:76:01:45:e1:7f:8b:66:cd:7e:79:67: 8d:48:30:2a:09:48:4c:9b:c7:98:d2:b3:1c:e9:54:2c:3c:0a: 10:b0:76:ae:06:69:58:ac:e8:d8:4f:37:83:c3:f1:34:02:6d: 9f:38:60:6f:5e:54:4f:71:c7:92:28:fb:0a:b3:44:f3:1a:a3: fe:99:f4:3f:d3:12:e2:f8:3b:03:65:33:88:9b:67:c7:de:88: 23:90:2b Public
Exponent: 65537
(0x10001) Extensions: Identifier:
Certificate Type Critical:
no Certified
Usage: SSL
Client Identifier: Authority Key
Identifier Critical:
no Key
Identifier: a7:84:21:f4:50:0e:40:0f:53:f2:c5:d0:53:d5:47:56:b7:c5: 5e:96 Signature: Algorithm:
PKCS #1 MD5 With RSA
Encryption Signature: 2d:76:3f:49:5b:53:3a:c5:02:06:a3:67:6d:d9:03:50:57:7f:de:a7:a9: cd:69:02:97:6f:66:6a:7f:95:ea:89:75:7a:fc:b0:26:81:fc:33:bb:60: e8:f7:73:77:37:f8:8a:04:3b:fc:c1:3e:42:40:3d:58:16:17:7e:47:35: 1c:73:5a:ab:72:33:c3:f5:2b:c6:eb:b5:39:52:82:c6:3e:e1:38:c6:39: 8b:ee:e3:9f:b3:b9:29:42:0d:11:a5:79:af:6d:3a:f8:a6:ba:d0:9c:55: 48:0d:75:91:05:0b:47:67:98:32:f3:2d:2e:49:ed:22:ab:28:e8:d6:96: a1:9b
Figure 6: The fields of a X.509 digital
certificate
In the next section, we describe how
SSL digital certificates for Web servers apply cryptographic
techniques to secure e-commerce Web sites.
|
IV.
SSL Server Certificates The practical means of
implementing PKI and digital signatures are via Web server
certificates that enable authentication and SSL encryption. SSL
certificates form the basis of an Internet trust infrastructure by
allowing Web sites to offer safe, secure information exchange to
their customers. SSL server certificates satisfy the need for
confidentiality, integrity, authentication, and
nonrepudiation.
A.
SSL Defined Secure Sockets Layer (SSL), originally
developed by Netscape Communications, is an information technology
for securely transmitting information over the Internet. The SSL
protocol has become the universal standard on the Web for
authenticating Web sites to Web browser users, and for encrypting
communications between browser users and Web servers.
Server
certificates are available from Certificate Authorities (CAs) such
as VeriSign — trustworthy, independent third parties that issue
certificates to individuals, organizations, and Web sites. CAs use
thorough verification methods to ensure that certificate users are
who they claim to be before issuing them. CA's own self-signed SSL
digital certificates are built into all major browsers and Web
servers, including Netscape Communicator and Microsoft Internet
Explorer, so that simply installing a digital certificate on a Web
server enables SSL capabilities when communicating with Web
browsers.
SSL server certificates fulfill two necessary
functions to establish e-commerce trust:
- SSL server authentication: Server certificates allows
users to confirm a Web server's identity. Web browsers
automatically check that a server's certificate and public ID are
valid and have been issued by a certificate authority (CA) — such
as VeriSign — included in the list of trusted CAs built into
browser software. SSL server authentication is vital for secure
e-commerce transactions in which users, for example, are sending
credit card numbers over the Web and first want to verify the
receiving server's identity.
- SSL encryption: SSL server certificates establish a
secure channel that enables all information sent between a user's
Web browser and a Web server to be encrypted by the sending
software and decrypted by the receiving software, protecting
private information from interception over the Internet. In
addition, all data sent over an encrypted SSL connection is
protected with a mechanism for detecting tampering: that is, for
automatically determining whether the data has been altered in
transit. This means that users can confidently send private data,
such as credit card numbers, to a Web site, trusting that SSL
keeps it private and confidential.
B.
How SSL Server Certificates Work Server IDs take advantage
of SSL to work seamlessly between Web sites and visitors' Web
browsers. The SSL protocol uses a combination of asymmetric public
key encryption and faster symmetric encryption.
The process
begins by establishing an SSL "handshake" — allowing the server to
authenticate itself to the browser user, and then permitting the
server and browser to cooperate in the creation of the symmetric
keys used for encryption, decryption, and tamper detection:
- A customer contacts a site and accesses a secured URL: a page
secured by a Server ID (indicated by a URL that begins with
"https:" instead of just "http:" or by a message from the
browser). This might typically be an online order form collecting
private information from the customer, such as address, phone
number, and credit card number or other payment
information.
- The customer's browser automatically sends the server the
browser's SSL version number, cipher settings, randomly generated
data, and other information the server needs to communicate with
the client using SSL.
- The server responds, automatically sending the customer's
browser the site's digital certificate, along with the server's
SSL version number, cipher settings, etc.
- The customer's browser examines the information contained in
the server's certificate, and verifies that:
- The server certificate is valid and has a valid date
- The CA that issued the server been signed by a trusted CA
whose certificate is built into the browser
- The issuing CA's public key, built into the browser,
validates the issuer's digital signature
- The domain name specified by the server certificate matches
the server's actual domain name
If the server cannot
be authenticated, the user is warned that an encrypted,
authenticated connection cannot be established.
- If the server can be successfully authenticated, the
customer's Web browser generates a unique "session key" to encrypt
all communications with the site using asymmetric
encryption.
- The user's browser encrypts the session key itself with the
site's public key so that only the site can read the session key,
and sends it to the server.
- The server decrypts the session key using its own private
key.
- The browser sends a message to the server informing it that
future messages from the client will be encrypted with the session
key.
- The server then sends a message to the client informing it
that future messages from the server will be encrypted with the
session key.
- An SSL-secured session is now established. SSL then uses
symmetric encryption, (which is much faster than asymmetric PKI
encryption) to encrypt and decrypt messages within the SSL-secured
"pipeline."
- Once the session is complete, the session key is eliminated.
It all takes only seconds and requires no action by the
user.
The Netscape Navigator and the Microsoft Internet
Explorer browsers have built-in security mechanisms to prevent users
from unwittingly submitting their personal information over insecure
channels. If a user tries to submit information to an unsecured site
(a site without an SSL server certificate), the browsers will, by
default, show a warning:
In contrast, if a user submits credit card or
other information to a site with a valid server certificate and an
SSL connection, the warning does not appear. The secure connection
is seamless, but visitors can be sure that transactions with a site
are secured by looking for the following cues:
- The URL in the browser window displays "https" at the
beginning, instead of http.
- In Netscape Communicator, the padlock in the lower left corner
of the Navigator window will be closed instead of open.
- In Internet Explorer, a padlock icon appears in the bar at the
bottom of the IE window.
1.
SSL Strengths: 40-bit and 128-bit SSL SSL comes in two
strengths, 40-bit and 128-bit, which refer to the length of the
session key generated by every encrypted transaction. The longer the
key, the more difficult it is to break the encryption code. 128-bit
SSL encryption is the world's strongest: according to RSA Labs, it
would take a trillion trillion years to crack using today's
technology. 128-bit encryption is approximately 3 X 1026 stronger than 40-bit
encryption.
Microsoft and Netscape offer two versions of
their Web browsers, export and domestic, that enable different
levels of encryption depending on the type of SSL server certificate
with which the browser is communicating.
- 40-bit SSL server certificates (such as VeriSign's
Secure Server IDs) enable 40-bit SSL when communicating with
export-version Netscape and Microsoft Internet Explorer browsers
(used by most people in the U.S. and worldwide), and 128-bit SSL
encryption when communicating with domestic-version Microsoft and
Netscape browsers.
- 128-bit SSL server certificates (such as VeriSign's
Global Server IDs) enable 128-bit SSL encryption — the world's
strongest — with both domestic and export versions of
Microsoft® and Netscape® browsers.
In order to fully enable
128-bit encryption with a Global Server ID, it's important to
generate the right kind of private key during the process of
obtaining a Server ID. An important step in the process is
generating a Certificate Signing Request within the Web server
software. In generating a CSR, Web server administrators should be
careful to select a 1024-bit private key, which enables the Global
Server ID to establish 128-bit SSL encryption, rather than a 512-bit
private key, which enables only 40-bit encryption.
Netscape
users can follow these steps to see what level of encryption is
protecting their transactions:
- Go to the secure Web page you want to check.
- Click the Security button in the Navigator's toolbar. The
Security Info dialog box indicates whether the Web site uses
encryption.
- If it does, click the Open Page Info button to display more
information about the site's security features, including the type
of encryption used.
- You can also check to see which level of SSL is activated on
your Web server by following these steps:
- Using a 128-bit client, such as the domestic version of the
Netscape Navigator, click on Options/Security Preferences.
- Under the enable SSL options, click on Configure for both SSL
2 and SSL 3. Make sure acceptance for the 40 and 56 bit encryption
ciphers are turned off.
- Try to access the site. If it using less than 128 bit
security, then you will receive an error in your browser window:
"Netscape and this server cannot communicate securely because they
have no common encryption methods."
IE users can find out
a Web site's encryption level by following these steps:
- Go to the Web site you want to check.
- Right-click on the Web site's page and select Properties.
- Click the Certificates button.
- In the Fields box, select "Encryption type." The Details box
shows you the level of encryption (40-bit or 128-bit. See the
following section for more information about SSL encryption
levels).
E-businesses may choose to simplify the process
of certificate checking for site visitors by describing the security
measures they have implemented in a Security and Privacy statement
on their sites. Sites that use VeriSign Server IDs can also post the
Secure Site Seal on their home page, security statement page, and
purchase pages. The Seal is a widely recognized symbol of trust that
enables site visitors to check certificates in real time from
VeriSign with one click (see "VII. The VeriSign Advantage" below for
more information about the Seal).
2.
SGC and 128-bit Step-up To ensure that strong 128-bit
encryption protects e-commerce transactions for all users,
businesses should install 128-bit IDs, such as VeriSign's Global
Server IDs, on their servers. However, the export browsers that
permit only 40-bit encryption with 40-bit SSL server certificates
will allow strong 128-bit encryption when interacting with 128-bit
server certificates because these certificates are equipped with a
special extension that enable "Server Gated Cryptography (SGC)" for
Microsoft browsers and "International Step-Up" for Netscape
browsers.
The extension enables 128-bit encryption with
export-version browsers by prompting two "handshakes" when a user's
browser accesses a page protected by a Global Server ID. When an
export-version Netscape or Microsoft browser connects to the Web
server, the browser initiates a connection with only a 40-bit
cipher. When the server certificate is transferred, the browser
verifies the certificate against its built-in list of approved CAs.
Here, it recognized that the server certificate includes the SGC or
International Step-Up extension, and then immediately renegotiates
the SSL parameters for the connection to initiate an SSL session
with a 128-bit cipher. In subsequent connections, the browser
immediately uses the 128-bit cipher for full-strength
encryption.
C.
Securing Multiple Servers and Domains with SSL As
organizations and service providers enhance their Web sites and
extranets with newer technology to reach larger audiences, server
configurations have become increasingly complex. They must now
accommodate:
- Redundant server backups that allow Web sites and extranets to
maximize site performance by balancing traffic loads among
multiple servers
- Organizations running multiple servers to support multiple
site names
- Organizations running multiple servers to support a single
site name
- Service providers using virtual and shared hosting
configurations
But in complex, multiserver environments,
SSL server certificates must be used carefully if they are to serve
their purpose of reliably identifying sites and the businesses
operating them to visitors and encrypt e-commerce transactions —
establishing the trust that customers require before engaging in
e-commerce.
When used properly in an e-commerce trust
infrastructure equipped with multiple servers, SSL server
certificates must still satisfy the three requirements of online
trust:
- Client applications, such as Web browsers, can verify that a
site is protected by an SSL server certificate by matching the
"common name" in a certificate to the domain name (such as
www.verisign.com) that appears in the browser. (Certificates are
easily accessible via Netscape and Microsoft browsers).
- Users can also verify that the organization listed in the
certificate has the right to use the domain name, and is the same
as the entity with which the customer is communicating.
- The private keys corresponding to the certificate, which
enable the encryption of data sent via Web browsers, are protected
from disclosure by the enterprise or ISP operating the server.
1.
The Certificate Sharing Problem VeriSign recommends that,
to satisfy the requirements of Internet trust, one SSL server
certificate be used to secure each domain name on every server in a
multi-server environment, and that the corresponding private keys be
generated from the hosting server.
Some enterprises or ISPs
practice certificate sharing, or using a single SSL server
certificate to secure multiple servers. Organizations use
certificate sharing in order to secure back-up servers, ensure
high-quality service on high-traffic sites by balancing traffic
among several servers, or, in the case of ISPs and Web hosts, to
provide inexpensive SSL protection to price-sensitive customers.
However, as described in the following section, certificate-sharing
configurations do not satisfy the fundamental requirements of
Internet trust.
2.
VeriSign Recommendations for Implementing SSL on Multiple
Servers Here are some common shared certificate
configurations and VeriSign's recommendations for addressing them to
most effectively reinforce an e-commerce trust
infrastructure:
Fail-Safe Backup: Redundant servers, not
used simultaneously Certificate sharing is permissible.
However, when the back-up server is not under the same control as
the primary server, the private key cannot be adequately protected,
and a separate certificate should be used for each
server.
Load Balancing: Multiple sites with different
common names on multiple servers To prevent browsers from
detecting that the URL of the site visited differs from the common
name in the certificate, and to protect the security of private
keys, a different certificate should be used for each server/domain
name combination.
Load Balancing: Multiple sites with the
same common name on multiple servers Instead of jeopardizing
private key functionality by copying the key for multiple servers, a
different certificate should be used for each server. Each
certificate may have the same common name and organizational name,
but slightly different organizational unit values.
ISP
Shared SSL: One certificate issued to an ISP's domain, used on
multiple servers by multiple Web sites This prevents site
visitors from verifying that the site they are visiting is the same
as the site protected by the certificate and listed in the
certificate itself. Each site's server should have its own
certificate. Or merchants must inform their customers that site
encryption is provided by the ISP, not the merchant, and the ISP
must guarantee the services of all the hosted companies whose sites
use shared SSL.
Name-Based Virtual Hosting: An ISP or Web
Host provides each hosted customer with a unique domain name, such
as customername.isp.com. If the same certificate is used for
each domain name, browsers will indicate that the site domain name
does not match the common name in the certificate. To solve this
problem, a "wildcard" certificate of the form *.isp.com is required
to properly serve the multi-hostname configuration without creating
browser mismatch error messages. (VeriSign offers wildcard
certificates on a case-by-case basis, and they are subject to
certain additional licensing terms and conditions. For more
information, please contact shared-ssl@verisign.com.)
For
a complete explanation of VeriSign's solutions for securing multiple
Web server and domain configurations, please see our white paper at
http://www.verisign.com/rsc/wp/certshare/index.html.
Next,
we examine the second key component of an Internet trust
infrastructure: secure online payment management.
|
V.
Online Payment Services Once businesses have built a Web
site and implemented SSL certificates to authenticate themselves to
customers and encrypt communications and transactions, they must
address another crucial component of an e-commerce infrastructure:
enabling customers to easily pay for products and services online,
and processing and managing those payments in conjunction with a
complex network of financial institutions.
Today's fragmented
Internet payment systems often connect online merchants to banks via
privately operated, point-to-point payment networks. In 1998, for
example, over 5 billion electronic payment transactions —
originating from approximately 2 million merchant locations and
representing over $250 billion in merchant dollar volume — were
passed over leased lines and non-Internet interfaces to a single
transaction processor (First Data Corporation).
This
situation is rapidly changing. Internet commerce is entering an
accelerated growth phase. IDC estimates worldwide e-commerce
revenues will increase to $218 billion in 2000. Behind each of these
Internet purchases is a payment transaction. However, traditional
payment systems have proven to be ill equipped to manage the costs
and complexity of transitioning and enabling transactions over the
Internet. As a result, only a fraction of today's potentially
automated e-commerce transactions are currently enabled for Internet
payment. The situation is particularly acute in the B2B payments
arena — today, most B2B systems stop short of enabling actual
payment execution on the Web.
Demand is therefore high for a
simpler, "Internet payment gateway" approach that provides easier
Internet connectivity between buyers, sellers, and the financial
networks that move money between them. A truly flexible Internet
payment gateway must support multiple payment instruments, connect
to all relevant back-office payment processors, and be packaged for
easy integration into front-office Web applications. Ideally, the
gateway should also offer uniform interfaces to payment
functionality, permitting e-businesses to deploy payment
applications that can be easily switched between alternative
financial instruments, institutions, and payment processors. And to
form part of a complete e-commerce trust infrastructure, the gateway
must assure fail-safe security for payment data as it passes from
customer to Web site and through the back-end processing
system.
Some merchants may build an Internet payment gateway
themselves, or purchase a software-based solution. However,
according to the Gartner Group, most e-merchants have transaction
volumes that do not justify the expense of bringing the process
in-house, and are opting to outsourced, ASP solutions.
A.
The Internet Payment Processing System Understanding how
best to address the need for Internet payment gateway services
requires first briefly examining the participants in an Internet
payment processing system.
Participants in a typical online
payment transaction include:
- The customer: typically, a holder of a payment card —
such as a credit card or debit card — from an issuer.
- The issuer: a financial institution, such as a bank,
that provides the customer with a payment card. The issuer is
responsible for the cardholder's debt payment.
- The merchant: the person or organization that sells
goods or services to the cardholder via a Web site. The merchant
that accepts payment cards must have an Internet Merchant Account
with an acquirer.
- The acquirer: a financial institution that establishes
an account with a merchant and processes payment card
authorizations and payments. The acquirer provides authorization
to the merchant that a given card account is active and that the
proposed purchase does not exceed the customer's credit limit. The
acquirer also provides electronic transfer of payments to the
merchant's account, and is then reimbursed by the issuer via the
transfer of electronic funds over a payment network.
- The payment gateway: This function, operated by a
third-party provider, processes merchant payments by providing an
interface between the merchant and the acquirer's financial
processing system.
- The processor: a large data center that processes
credit card transactions and settles funds to merchants, connected
to the merchant on behalf of an acquirer via a payment gateway.
The basic steps of an online payment transaction include
the following:
- The customer places an order online by selecting items from
the merchant's Web site and sending the merchant a list. The
merchant often replies with an order summary of the items, their
price, a total, and an order number.
- The customer sends the order to the merchant, including
payment data. The payment information is usually encrypted by an
SSL pipeline set up between the customer's Web browser and the
merchant's Web server SSL certificate.
- The merchant requests payment authorization from the payment
gateway, which routes the request to banks and payment processors.
Authorization is a request to charge a cardholder, and must be
settled for the cardholder's account to be charged. This ensures
that the payment is approved by the issuer, and guarantees that
the merchant will be paid.
- The merchant confirms the order and supplies the goods or
services to the customer.
- The merchant requests payment, sending the request to the
payment gateway, which handles the payment processing with the
processor.
- Transactions are settled, or routed by the acquiring bank to
the merchant's acquiring bank for deposit.
B.
VeriSign Payflow Payment Services VeriSign Payflow Payment
Services offers the most effective way to streamline the flow of all
kinds of payments through this complex system — quickly,
efficiently, and above all, securely. Payflow simplifies e-commerce
by providing payment connectivity over the Internet between buyers,
sellers, and financial networks. VeriSign uses a client server
architecture to process transactions: the client is installed on the
merchant's site and integrated with the merchant's e-commerce
application. The client software establishes a secure link with the
VeriSign processing server using an SSL connection to transmit
encrypted transaction requests. The VeriSign server transmits the
request over a private network to the appropriate financial
processing network. When the authorization response is received via
the financial processing network, the server returns the response to
the merchant's client, which then completes the transaction by
sending an acknowledgment to the server. Typical transactions occur
within 3 seconds.
By partnering with VeriSign, merchants gain
the ability to free themselves from point-to-point and
difficult-to-integrate payment solutions, reaping the benefits of an
integrated payment platform designed specifically for the Internet.
Payflow supports all major consumer credit card, debit card,
electronic check, purchase card, and Automated ClearingHouse (ACH)
transactions. (ACH is a nationwide, wholesale electronic payment and
collection system that serves as a method of transferring funds
between banks via the Federal Reserve System.)
Its robust and
open architecture has been designed to support both
business-to-consumer (B2C) and business-to-business (B2B) payment
applications. It provides the industry's highest performance and
reliability and is a highly scalable outsourced solution that can
easily grow to hundreds of millions of transactions per month.
VeriSign Payflow has proven to be considerably faster, more reliable
and scalable than any other competing solution. Using VeriSign
Payflow, a merchant can connect to most banks, transaction services,
or forms of payment without worrying about the underlying
technology. Customers can pay with a variety of financial
instruments, including checking accounts, savings accounts, and
credit cards, quickly and simply.
VeriSign Payflow hides the
complexity of payment Competitive design
advantages of the VeriSign Payflow service include:
- Open connectivity with almost all bank processors and payment
types through unified interfaces
- Pre-integration with the most popular e-commerce applications
and forthcoming payment-enabled Internet appliances such as
Personal Digital Assistants (PDAs)
- Continuous maintenance of a TCP/IP network connection
throughout each transaction until it either successfully completes
or times out. Unlike most competing solutions, VeriSign Payflow's
payment connection both enables a faster response times (averaging
2.2 seconds) and — through confirmation of transaction completion
— elimination of uncertainty of transaction status.
- High availability that exceeds 99.99 percent with dynamic load
balancing and failover between all servers
- An XML integration layer both on the server side for ease of
integration with additional services (such as fraud screening),
and on the merchant side for ease of integration into back office
applications
- A Software Development Kit (SDK) allowing for more advanced
custom integration into e-commerce applications
On the
merchant side, VeriSign's payment connectivity technology works with
all major shopping carts and e-commerce systems. Merchants can
select the shopping cart system and storefront system that best
suits their needs and be confident that VeriSign can make the
connections.
To the Internet merchant, VeriSign offers:
- Lower connectivity cost: Connecting to the payment
networks over the Internet through VeriSign costs less to set up
and maintain than leased lines or modem connections.
- Better connection quality: VeriSign manages
high-bandwidth, fault-tolerant network connections to the
processing networks.
- More payment options: Merchants can add new payment
types without having to install new software.
- Increased flexibility: Merchants can switch banking
relationships and continue to use the same installed software to
process payments with the new bank.
On the processor side,
VeriSign works with all of the major processing and bank networks.
Again, the merchant just selects an appropriate shopping cart,
e-commerce package, or VeriSign-provided software development kit
and knows that VeriSign will make the necessary connections to the
transaction processing services.
1.
How Payment Processing Services Work At the application
level, VeriSign's payment processing services can be accessed in
three ways:
- Payflow-enabled e-commerce applications: Many
off-the-shelf e-commerce applications are pre-enabled to use
VeriSign's Payflow payment processing, giving merchants a complete
solution that can be used out-of-the-box. VeriSign's broad
third-party support and superior payment connectivity enables
merchants to independently choose the best e-commerce application
and the best payment processor for their business needs.
- Payflow Link: A hosted order form service that makes
payment processing as simple as adding Web links to a merchant's
Web site. See "VI. VeriSign E-Commerce Trust Infrastructure
Solutions" below for more on Payflow Link.
- Payflow Pro SDK: A software development kit that gives
merchants direct access to VeriSign's Payflow payment processing
API via a "thin client" network service. See "VI. VeriSign
E-Commerce Trust Infrastructure Solutions" below for more on
Payflow Pro and the Payflow Pro SDK.
Through VeriSign's
acquiring bank partners, merchants are also able to apply for
merchant bank accounts during the registration process. In all
cases, online registration and account management enables merchants
to be up and running in minutes.
A look inside the VeriSign Payflow
payment processing operations center C.
Payment Processing Backbone The VeriSign payment client is
a Secure Sockets Layer (SSL)-enabled communications agent that uses
routing parameter inputs to locate and establish communications with
a VeriSign transaction server. After a secure communication channel
has been established, transaction data is passed to the VeriSign
payment infrastructure for processing. VeriSign transaction
communications have been designed to minimize message-handling
errors by ensuring an uninterrupted, TCP-level communication stream
between the client and the server. The VeriSign architecture has the
highest performance in the industry. The average transaction
response time is 2.2 seconds.
The following sequence of
messages illustrates the communication stream during a typical
transaction from a VeriSign-enabled client to the VeriSign Payment
Services operations center.
- The client opens an SSL connection to a server and sends all
transaction data.
- The server processes the transaction, sends a response back to
the client.
- The client sends an acknowledgment to the server indicating
that the response was successfully received.
- The connection is closed.
VeriSign Payment Services
incorporate the following features to reinforce an e-commerce trust
infrastructure:
1.
Connectivity VeriSign provides connectivity to more
payment processors and supports more payment types than any other
online payment solution provider.
PROCESSOR |
PAYMENT TYPES |
AVAILABLE |
First Data Corporation 'Nashville' |
Credit Cards Level II Purchase Cards |
Now |
Paymentech |
Credit Cards Level II Purchase Cards |
Now |
TeleCheck |
Electronic Check Verification and Guarantee |
Now |
Wells Fargo Norwest |
ACH |
Now |
NOVA |
Credit Cards Level II Purchase Cards |
Now |
VITAL |
Credit Cards Level II Purchase Cards |
Now |
EDS Aurora |
Credit Cards Level II Purchase Cards |
Now |
First Data Corporation 'South' |
Credit Cards Level II & III Purchase Cards |
Now | 2.
Scalability VeriSign's transaction processing power can
grow quickly, providing throughput and reliability as the
transaction load grows from millions to hundreds of millions of
transactions per month and beyond. VeriSign combines
custom-developed, high-throughput server software with a
load-balancing network architecture to deliver a solid payment
Internet service explicitly intended for today's quickly growing
e-commerce community.
3.
Maximum Throughput While many payment solutions have been
implemented as "add-ons" to existing Web server platforms, VeriSign
has built server software specifically designed for payment
transactions. This provides significant advantages in three areas:
- Internal Resources: VeriSign server software
incorporates a sophisticated threading model designed specifically
to deliver maximum throughput for payment transactions. Signal and
timer logic for handling payment transaction exceptions and errors
is built into the server's kernel. File system access and logging
are optimized for payment transactions.
- Database Resources: VeriSign uses state-of-the-art DBMS
technology to store and log the transaction activity. It has
kernel-level control of database logins and resources, which
provides a level of performance tuning and error recovery that is
not available to payment systems that are based on Web servers.
- Network Resources: Because the VeriSign server is
"payment-aware" at its core, it can manage the complex dynamics of
communicating with card processing networks. Effective load
balancing is achieved both in the local processes and in
coordination with peer servers to implement an array-wide
throughput optimization strategy — in other words, VeriSign
servers perform load balancing both internally and in relation to
other transaction servers in their cluster. As transaction loads
grow for a cluster, this advantage becomes increasingly important.
4.
Load Balancing and Linear Growth Highly available payment
processing requires that individual transaction servers be both
extremely reliable and efficient. To provide true scalability, it
must be practical to add new server capacity on demand. VeriSign
services are delivered through clusters:
- Payment Server Cluster: These machines run the VeriSign
Payment Server and manage the processing of inbound transaction
requests to the processing networks.
- Web Server Cluster: These servers provide Web
application functionality associated with the payment services.
VeriSign's merchant reporting and virtual terminal systems are
provided here.
- Replicated Database Cluster: These machines host the
database servers. This cluster is broken up into write-biased,
read-biased, and replicator machines. Write-biased servers are
configured for maximum throughput for new transactions and are
used by default by the transaction servers. Read-biased servers
are configured for maximum speed on queries and reports and are
used by default by the Web servers. Replication machines manage
the synchronization of the data between all of the local database
machines in the cluster as well as other cluster and
backup/archive services.
VeriSign provides quality service
for immense numbers of transactions by ensuring that it has provided
adequate service clusters and has sufficient bandwidth on the front
side (Internet) and back side (banking networks) to accommodate the
load.
VeriSign's current production cluster supports a
nominal load of two million transactions per day. In practice,
capacity is added well before it is needed. As a general rule, when
a cluster reaches a nominal load of 30% of capacity or when there
are frequent spikes above 50% of capacity, either new capacity is
added to the cluster or a new cluster is added to the
service.
5.
Reliability In addition to load balancing, VeriSign's
server clusters also provide failure protection. When a cluster
suffers a server failure, the transaction load is seamlessly
redistributed to the remaining servers in the cluster. Hardware
redundancy is also provided within each server for every important
subsystem.
6.
Security One of VeriSign's fundamental design
considerations is, of course, security. The hardware, software, and
physical plant developed and used by VeriSign services are carefully
coordinated with an aggressive set of best practices to provide
maximum protection and integrity at the transport, system, and
physical levels.
Transport Security Transport
security provides protects transaction messages between the VeriSign
client and server. Most transactions sent from the VeriSign client
to VeriSign's payment servers are sent over the Internet — a public
network. To ensure that the contents of transactions are private and
that they cannot be altered or embellished in any way, VeriSign uses
the Secure Sockets Layer (SSL) protocol for all communications
between clients and servers. Similarly, Web access to every VeriSign
Web site that provides sensitive data is available only under the
HTTPS protocol, which is the same SSL protocol used by the client,
running on top of HTTP.
VeriSign has licensed RSA Security,
Inc.'s cryptographic tools. These tools are the de facto standard
for highly secure communications over the Internet and are widely
regarded as the best available platform on which to build a secure
client/server system. This means that transaction data sent by the
merchant to the VeriSign server can be read and used only by the
VeriSign server.
Additionally, VeriSign offers merchants the
opportunity to identify a set of IP addresses or subnets that
constitute valid transaction sources for a given merchant. This
means that in addition to the protection afforded by SSL message
encryption, the merchant can specify a range of IP addresses using a
string (for example, 192.32.4.18-20 or 192.4.22.*) This specifies
the valid IP addresses for the VeriSign payment server. Transactions
that originate from unregistered IP addresses are logged as
suspicious behavior for VeriSign's network monitoring tools to
investigate. This allows the merchant to further validate and
protect the transaction stream to the VeriSign
service.
System Security VeriSign payment services
are protected by firewall systems based on an extremely conservative
access strategy: VeriSign's payment services are isolated from all
other services. VeriSign permits communication with the VeriSign
payment server or secured Web servers only through SSL (port 443.)
This means there is no backdoor access for email, FTP, DNS, ICMP,
and so on, which are all security risks. The only data that can
enter is SSL traffic. All access requires user name and password, IP
address validation, or X.509 client authentication.
The
VeriSign service is also protected on the "back side" — its array of
network connections to the processing networks — by firewall systems
that ensure that only authorized traffic from authorized sources
gets through to VeriSign's payment servers.
Inside the server
array, a layering strategy further isolates repositories that
contain sensitive information. Best-of-breed intruder detection
systems and network monitoring tools are manned on a 24x7 basis,
providing instant notification of suspicious or unauthorized access,
as well as automatic countermeasures and
remedies.
Physical Security VeriSign's measures for
physically protecting its Payment Services include 24x7 card key
customer access to data centers, 24x7 video surveillance and
recording of the premises by security personnel, and 24x7 on-site
security personnel
7.
XML In cooperation with selected e-commerce partners and
industry standards bodies, VeriSign has built an XML integration and
automation layer into its payment infrastructure. This layer
provides uniform XML access to all payment-related services
including payment execution, registration, and
reporting.
XMLPay XMLPay is a VeriSign Payment
Services specification that defines a set of XML document types for
payment transactions and XML digital receipts. Although XMLPay
loosely follows level 3 purchase card data formats, it supports a
variety of payment instruments beyond just purchase cards. XMLPay is
compliant with the joint IETF/W3C working group specification for
digitally signed XML.
XMLRegister Turning on a
business for VeriSign PayFlow is a moderately complex process that
involves the manual intervention of several parties, including not
only the merchant and VeriSign Payment Services itself but also the
merchant's acquiring bank and a payment processor to move money
between buyer and seller banks. Both resellers and emerging B2B
marketplaces are increasingly demanding more automated access to the
process of enabling online merchant payment accounts. In response,
VeriSign is developing XMLRegister, a specification defining data
formats and processing infrastructure supporting the automation of
VeriSign Payment Services merchant registrations.
Without
XMLRegister, merchants typically must register one at a time for
VeriSign Payment Services. With XMLRegister, formatted XML documents
may be submitted programmatically over a secure transport to a
registration server. The registration server supports methods for a
single or group merchant registration. Each registration element may
be for a new registration or update of an existing account. Because
business rules and the information needed to complete a registration
vary among processors and acquirers, an XMLRegister document does
not attempt to enforce business rules related to a registration. It
merely transports data across the wire for processing by the
registration server whose job is to enforce such rules and report
non-compliance.
XMLReport XMLReport specifies data
used in payment transaction reports. Resellers or merchants submit
XMLReport document when they need reports on their transactions. In
summary, today's widespread adoption of XML is leading to three
significant developments in the payments industry:
- Extensibility: XML enables easy update and extension of
existing services to quickly add altogether new services to
existing applications.
- Automation: Currently, merchants can download a set of
preset reports from the VeriSign Payflow Manager Web site, but
have limited flexibility in what can be queried, or how the
results are returned. XMLReport provides an automation language
for merchant reporting. Complex queries and result formatting
instructions can be communicated to the VeriSign service in a
straightforward manner.
- Interoperability: XML is quickly gaining momentum as
the lingua franca of system interchange. Via its three XML
specifications, VeriSign Payment Services will publish an
XML-based vocabulary for its services. By collaborating with
partners, this vocabulary will be consistent with emerging
industry-standard vocabularies, as well as those of the partners.
The VeriSign Payflow client continues to provide a
high-level API for developers who don't want to switch to XML. The
XML layer is therefore strictly optional, and is independently
accessible when it is used to communicate requests and responses
from VeriSign Payflow servers. |
VI.
VeriSign E-Commerce Trust Infrastructure Solutions
VeriSign offers a complete range of products and services to
help businesses implement an end-to-end trust infrastructure for
e-commerce. VeriSign's server certificates, or Server IDs, are
available in both 40-bit and 128-bit SSL as part of Secure Site
services. VeriSign Payflow Link and Payflow Pro online payment
services enable businesses to easily accept, manage, and process
payments electronically. VeriSign's Commerce Site services combine
SSL Server IDs, Payflow services, and other value-added features to
form a complete e-commerce infrastructure. And for large enterprises
operating multiple servers, OnSite for Server IDs simplifies the
process of issuing managing large numbers of Server
IDs.
A.
VeriSign Commerce Site and Secure Site Solutions VeriSign
provides SSL Server IDs in two encryption strengths:
- VeriSign's 128-bit SSL (Global Server) IDs enable the
world's strongest SSL encryption with both domestic and export
versions of Microsoft® and Netscape® browsers. 128-bit SSL Global Server IDs are
the standard for large-scale online merchants, banks, brokerages,
health care organizations, and insurance companies worldwide. U.S.
Government regulations determine who can implement the powerful
encryption of 128-bit SSL, though 128-bit IDs are now available to
nearly every company worldwide (see
www.verisign.com/server/rsc/faq.html#qualify2 for details).
- 40-bit SSL (Secure Server) IDs are ideal for
security-sensitive intranets, extranets, and Web sites.
VeriSign 128-bit SSL and 40-bit SSL Server IDs are
available as part of VeriSign's site trust solutions.
- Commerce Site Services, exclusively from VeriSign, are
complete, integrated solutions that are ideal for e-merchants and
online stores.
- Commerce Site includes a 40-bit SSL (Secure Server)
ID and VeriSign Payflow Pro online payment management service
(see below for more information), plus an array of additional
value-added services.
- Commerce Site Pro includes a 128-bit SSL (Global
Server) ID, VeriSign Payflow Pro, and value-added services.
- Secure Site Services are best for intranets, extranets,
and Web sites that require the leading SSL certificates and Web
site services.
- Secure Site includes a 40-bit SSL (Secure Server) ID,
plus additional value added services.
- Secure Site Pro includes a 128-bit SSL (Global
Server) ID and value-added services.
The
value-added services included with Secure Site and Commerce Site
Services include the VeriSign Secure Site Seal.
The Seal is designed for display on Web sites
as a symbol of security and trust, encouraging customers to
confidently provide credit card numbers and other sensitive
information. The Secure Site Seal is sent automatically to the
technical contact businesses provide as part of the Secure Site or
Commerce Site enrollment and purchasing process, 24 hours after the
Server ID is issued.
When the Seal is posted on a Web site's
home page, security/privacy policy page, or transaction pages,
businesses can connect it to their Server ID. When visitors click on
the Seal, they instantly link to a dynamic pop-up screen of
information about the Server ID, assuring them that transactions
with the site are encrypted by SSL, and allowing them to verify the
site's identity and check the ID status in real time.
Secure
Site and Commerce Site solutions also include up to $250,000 of
NetSure protection, an extended warranty program that protects
e-businesses against economic loss resulting from the theft,
corruption, impersonation, or loss of use of a server
certificate.
For a complete description of the additional
features included with Secure Site and Commerce Site solutions, see
http://www.verisign.com/site/index.html.
1.
How to Enroll for Commerce Site and Secure Site
Solutions Businesses can try VeriSign's 40-bit SSL Secure
Server ID for free. The trial Server ID can be applied for at
http://www.verisign.com/server/trial/index.html
now.
Businesses can purchase a one-year full-service Secure
Server ID as part of VeriSign's Secure Site or Commerce Site
Services by visiting http://www.verisign.com/server. The application
process takes about 15 minutes. In one to three days, after VeriSign
has verified credentials, it delivers your Secure Server ID via
e-mail.
The U.S. Department of Commerce requires that
companies qualify before buying the 128-bit SSL encryption power of
Global Server IDs, included with Secure Site Pro and Commerce Site
Pro Services. All companies within the United States are eligible
for Global Server IDs. The U.S. Government determines the categories
of companies that can implement 128-bit SSL encryption technology
outside the U.S. and across U.S. borders. New regulations make
Global Server IDs available to a wider group of customers than ever
before: any company or organization around the world may purchase a
Global Server ID, with the following exceptions: persons listed on
the U.S. Government's Denied Person's List, and customers located in
the following countries: Afghanistan (Taliban-controlled areas),
Cuba, Iran, Iraq, Libya, North Korea, Serbia, Sudan, and
Syria.
Before beginning VeriSign's online enrollment,
businesses should check to make sure they are ready to proceed by
following these steps:
- Install server software — Nearly all brands support
VeriSign Secure Server IDs. The server on which the 128-bit Global
Server ID can run server software from any non-U.S. software
vendor, or software from a U.S. software vendor properly
classified by the U.S. Department of Commerce, including:
- Apache-SSL
- BEA WebLogic
- C2Net Apache Stronghold
- Compaq/Tandem iTP Webserver
- Covalent Raven
- Hewlett Packard Virtual Vault (with Netscape Enterprise)
- IBM http Server/Webphone 1.3.3.1 and 1.3.6
- Lotus Domino 4.6.2 and later
- Microsoft IIS 3.0 and later
- Mod-SSL
- Nanoteq Netseq server
- Netscape Suite Spot servers, 3.0 or later, including
Netscape
- Enterprise 3.0+ and Netscape Proxy Server 3.0 or later, 2.0
- O'Reilly WebSite Pro v.2.5 and up
- Red Hat Professional 6.1
- Register domain name — If you haven't already, register
your URL at http://www.networksolutions.com.
- Confirm firewall configuration — Secure Server ID
enrollment requires that you can make both HTTP and HTTPS
connections to VeriSign's Web site.
- Prepare payment — You can pay with a purchase order,
check, wire transfer, or an American Express, Visa, Mastercard, or
Discover card.
- Review legal agreement — In the process of enrolling,
you will need to sign the VeriSign Secure Server Subscriber
Agreement. To review it in advance, see
http://www.verisign.com/repository/SUBAGR.html
- Gather proof of right documents — Before issuing your
Secure Server ID, VeriSign must confirm that your company is
legitimate and is registered with the proper government
authorities. If you have a Dun & Bradstreet DUNS number,
simply supply your number. International DUNS numbers must be in
the Dun & Bradstreet database for at least two months before
VeriSign can verify the information. If you do not have a DUNS
number, either go to http://www.dnb.com and apply for one, or
submit a hard copy of at least one of the following filed
documents for your company: articles of incorporation, partnership
papers, business license, or fictitious business license. All
documents must be in English.
To complete your Server ID
enrollment, please visit http://www.verisign.com/server. There you
will be instructed to complete the following steps.
1.
Generate Certificate Signing Request Follow the instructions
in your server software manual, or online at
http://digitalid.verisign.com/server/enrollStep3.htm, to create a
Certificate Signing Request (CSR) and a key pair. After the server
software creates the two files, make backup copies of them on a
floppy disk, and store the disk in a secure location. This is
important: If your private key is lost, VeriSign will not be able to
recover it for you.
2. Submit the Certificate Signing
Request (CSR) to VeriSign Open the CSR file in a text editor,
such as WordPad, NotePad, or Textpad. Do not use a word processing
application such as Microsoft Word or Adobe
FrameMaker.
Select the text in the CSR, beginning with and
including:
--BEGIN NEW CERTIFICATE REQUEST-- and ending
with --END NEW CERTIFICATE REQUEST--
Copy and paste the
CSR into the VeriSign online enrollment form for the trial or the
one-year subscription. Click the Submit button.
3.
Complete application Fill out the online application form
with information about your company and contacts. The technical
contact must be authorized to run and maintain your secure Web
server and must be employed by your organization. If you access the
Web through an Internet Service Provider (ISP), the ISP may complete
the CSR for you and serve as the technical contact, and you can then
enroll. If your ISP does not offer VeriSign IDs, refer it to
www.verisign.com/isp/index.html for information about VeriSign's
Secure Site ISP Program. The organizational contact must be
authorized to make binding agreements, such as the Secure Server
Service Agreement, and must be employed by your organization. It is
best to select a different person from the technical contact. The
billing contact will receive invoices. This can be the same person
as the technical or organizational contact.
4.
Authentication takes 1-3 days Within a few hours of receiving
your application, VeriSign will send a confirming e-mail to your
technical and organizational contacts. The e-mail will include a URL
where you can check the status of your application, as well as a
Personal Identification Number (PIN) you will need to view the
status. If the information you submitted is complete, your technical
contact and organizational contact will receive your Server ID by
e-mail in 1-3 working days.
5. Install your Server
ID When you receive your Server ID, make a backup copy of it
and store it on a labeled floppy disk, noting the date you received
it. Store the floppy disk in a secure place. To install your Server
ID, follow the instructions in your server software documentation
for digital certificates.
6. Enable SSL on your
server Consult your server software manual to enable SSL. The
process should take approximately five minutes.
7. Post
the Secure Site Seal on all your secure pages You should
receive a file of the Seal, complete with instructions on how to
install it, via e-mail shortly after completing the enrollment
process. You can also find downloadable Seal files and instructions
at http://www.verisign.com/server/prg/seal/install.html
NOTE:
SSL imposes some performance overhead. Therefore, most server
software applications allow you to apply SSL selectively to Web
pages that require encryption, such as payment pages. There is no
benefit from applying SSL to product information pages, for
example.
B.
Payflow Link and Payflow Pro VeriSign offers two Payment
Services that let e-commerce businesses securely accept and process
credit card, debit card, purchase card, and electronic check
payments on the Internet:
1.
VeriSign Payflow Link Payflow Link provides a fast,
easy-to-use solution that enables merchants to connect their
customers via SSL-secured HTTP to a secure VeriSign-hosted order
form to automate order acceptance, authorization, processing, and
transaction management.
Payflow Link allows merchants to
connect to VeriSign using simple Web links To
use Payflow Link, merchants simply add a Web link to the appropriate
Web pages at their site. When the customer clicks this link, he or
she is brought to a secure order form that is hosted by VeriSign.
Transaction details that are encoded in the link are used to
initialize the form. This includes SKU data, order amount, tax
amount, and other order-specific parameters. At the Payflow Link
order form, the consumer enters the required payment information and
submits the form to execute the order. When orders are submitted,
the merchant is notified via email. Merchants fetch the specifics of
new orders from the VeriSign Payflow Manager merchant Web site (see
more information on Payflow Manager below).
Targeting the
business-to-consumer marketplace, Payflow Link provides an
inexpensive payment solution for any merchant needing the ability to
quickly and efficiently process a variety of payment types. Payflow
Link is intended for use by merchants who process up to 1,000
transactions per month. It is especially easy to implement and
affordable, with a low setup cost and flat-fee billing. There is no
long-term obligation.
2.
Payflow Pro VeriSign Payflow Pro is the most robust,
versatile solution for online payment processing — ideal for
large-scale e-commerce merchants that require peak performance and
complete customizability. Payflow Pro is included with Commerce Site
and Commerce Site Pro e-commerce solutions and is available
separately as a downloadable Software Development Kit (SDK). It also
comes pre-integrated with most shopping carts and e-commerce
platforms.
Targeting the business-to-business market and
enterprise environments requiring discrete control over payment
functionality, Payflow Pro gives merchants direct access to the
Payflow payment processing API via a "thin client" network service.
The Payflow Pro SDK client software, which is installed on the
merchant's system, is a small (400k footprint) messaging agent that
uses SSL and X.509 digital certificate technology to securely
communicate with VeriSign's payment servers.
Payflow Pro SDK gives merchants
more control via a direct TCP/IP connection to the payment gateway
and a flexible Software Development Kit (SDK)
To use Payflow Pro SDK, merchants pass payment transaction
data to the client through a set name/value pairs. Here is an
example of encoded payment transaction
data:
TRXTYPE=S&TENDER=C&USER=userid&PWD=password& ACCT=5499740000000016&EXPDATE=1299&AMT=1.00
The
Payflow client's only job is to securely pass the payment
transaction data to VeriSign's payment servers for processing. The
Payflow client does not contain any payment-specific logic. This
means that VeriSign is able to introduce new services or transaction
types at any time, without upgrading the Payflow client software.
Merchants can take advantage of a new service by simply adding the
new parameter values it requires to their transaction
requests.
Payflow Pro SDK provides support through a single
client interface for the following payment types:
- Credit cards
- AmEx purchase card
- Purchase cards, Level II & III
- ACH transfer
- Electronic Check Verification and Guarantee
As with
the Payflow Link service, Payflow Pro enables merchants to
cost-effectively process high volumes of transactions under a
flat-fee pricing schedule. Payflow Pro SDK is intended for merchants
who process more than 1,000 transactions per month. It is robust and
scalable up to hundreds of millions of transactions.
3.
How to Purchase Payflow Link and Payflow Pro At
http://www.verisign.com/payment/seetrybuy.html, companies can
register and obtain a username and password that will enable them to
use and test VeriSign's Payflow and/or download Payflow
Pro.
Business can purchase and download Payflow Link or
Payflow Pro from http://www.verisign.com/payment/buyit.html; and can
then begin using the service after opening an activating an Internet
Merchant Account from an acquiring bank or financial
institution.
C.
OnSite for Server IDs Because managing the lifecycles of
Server IDs can be challenging for companies with multiple servers
spread across multiple divisions and locations, many businesses need
an easy way to control the issuing, renewing, and revoking of IDs,
and managing the access privileges associated with each
ID.
VeriSign OnSite for Server IDs is ideal for companies
that need to deploy Server IDs for 10 or more servers — for
intranets, extranets, or up to four of a company's domain names
("www.verisign.com," for example). OnSite makes organizations their
own "Certificate Authority (CA)," allowing enterprises to issue
Server IDs in minutes to dozens or even hundreds of servers with
fast, easy-to-use, Web-based tools for issuing server certificates —
without the need for extra hardware, software, or dedicated
personnel. Businesses can appoint one or more individuals to serve
as OnSite administrators, with full authority to approve, renew,
reject, and administer certificates, while VeriSign handles all the
back-end services necessary to maintain and scale the CA to meet
Internet trust needs.
OnSite for Server IDs offer
e-businesses the following benefits:
- Convenient, one-step purchasing: OnSite for Server IDs
lets enterprises take advantage of a single, unified enrollment
process, plus volume discounts based on the number of Server IDs
needed. Businesses need to complete only one purchase order a year
for all its Server IDs.
- Easy to set up and configure: Enterprises can issue
Server IDs quickly and manage them easily via the intuitive,
Web-based OnSite interface. VeriSign supplies the cryptographic
hardware, configuration wizards, enrollment Web templates, and
installation guides.
- Cost-effective: OnSite eliminates the need to invest in
the expensive hardware, software, or overhead necessary to build
and maintain a server certificate system from the ground up.
- Fast and simple to use: OnSite administrators can issue
certificates within minutes of receiving a request. VeriSign
maintains the back-end infrastructure, including high-speed
servers, telecommunications lines, data storage and back-up,
disaster recovery, and 24X7 customer service.
- Efficient, centralized ID management: Enterprises can
secure and manage multiple servers throughout their organization's
domain, and easily renew IDs or buy additional IDs.
- Flexible ID bundles: Server IDs are available via
OnSite in bundles of 10, 25, 50, 100, or more, based on
businesses' needs.
1.
How to Purchase OnSite for Server IDs To talk to a
VeriSign Sales Representative about purchasing VeriSign OnSite for
Server IDs, businesses should call 1-650-426-5115. Businesses can
also obtain more information by completing the form at
http://www.verisign.com/onsite/server/form.html.
|
VII.
The VeriSign Advantage VeriSign's Server IDs and
e-commerce trust services have earned the trust of businesses
worldwide, including virtually all of the Fortune 500 companies on
the Web and all of the top 40 e-commerce sites. To date, VeriSign,
the world's leading CA, has issued more than 400,000 Server
IDs.
A Server ID from VeriSign provides the ultimate in
credibility for online businesses. VeriSign's rigorous
authentication practices set the industry standard: VeriSign
documents its carefully crafted and time-proven practices and
procedures in a Certificate Practices Statement. And VeriSign
annually undergoes an extensive SAS 70 Type II audit by KPMG. (The
Statement of Auditing Standard 70, SAS 70, was established by the
American Institute of Certified Public Accountants to certify
trusted practices.) Employees responsible for dealing with
certificates undergo complete background checks and thorough
training.
VeriSign has achieved its unsurpassed reputation as
a trusted third party by paying as careful attention to physical
security as electronic security. For example, the company's
22,000-square-foot plant where keys are issued has five tiers of
security, the last three requiring fingerprint
identification.
VeriSign's rigorous authentication practices,
leading-edge cryptographic techniques, and ultra-secure facilities
are designed to maximize confidence in our services. These
practices, technology, and infrastructure are the foundation for its
e-commerce infrastructure services. |
| VIII.
For More Information
|
© 2002 VeriSign, Inc. All rights reserved. Legal
Notices Main Phone: 650-961-7500 · Fax:
650-961-7300 Sales:
650-426-5115
| |