Technical Report
Secure Socket Layer Protocol in
e-Commerce
(Secure Socket Layer Protocol in
e-commerce)
by
Koh Cheng Wah
EE 01778
Universiti Tenaga Nasional,
Data Communication EECB 423
Dr. Ong Hang See, Lecturer
EECB 423
A brief Study of Secure Socket Layer
Case Study : Using SSL for typical e-Commerce
W
|
ith the advent of the Internet, electronic
commerce is catching up with
conventional business. Merchants still use a lot of publicity,
advertisements and other market driven techniques to sell their products to a
crowd of people. Only this time, the crowd is bigger and ‘virtual’. Merchants
now use the widespread connectivity of the Internet to every corner of the
world to get their product to their customers. Customers on the other hand,
surf the Internet to find what they need to purchase.
For a simplest form of electronic commerce to take
place, customers generally only need to have a credit card. They would just hit
‘Submit’ after typing that 16-digit number in the Credit Card Number field and whoala!
the stuffs they would like to purchase arrive right at the customers’ doorstep
within a few working days. What is of concern here is not the amount of money a
customer would spend. (obviously). What matters, though, is the Internet
security involved in e-commerce.
What actually is this issue of Internet security?
Internet security ensures that irrelevant people, generally called hackers,
cannot read, modify nor steal messages intended for the customer or the bank.
When we speak of Internet security in e-commerce, we mainly speak of secure
electronic transactions. Secure electronic transactions should take care of all
four major concerns of Internet security areas - secrecy, authentication,
nonrepudiation and integrity.
To keep data secure,
technology that is equally as complex as the concepts of hypertext in Internet
is needed. Browsers like Netscape Communications’ Netscape Communicator and
Microsoft’s Internet Explorer stand between unscrupulous hackers and users of
the Internet like us to protect data that is being transacted. One may suggest
that data could just easily be jumbled up in a such a way that only the
intended person is able to read it. True enough, this is known as encrypting
the data.
Encryption
is scrambling data to make it into a secret incomprehensible code (cipher)
and in the same time permitting the code to return to the original data form
using complicated algorithms that employ esoteric mathematical equations. (PC
Magazine Online: Pc Network Security in e-Commerce) (http://www.zdnet.com/pcmag/pctech/content/17/02/it1702.002.html)
All
security protocols on the Internet use some form of encryption to make data
secure to transact from its source to its destination. Encryption, being the
basis of these security protocols, if combined with other forms of protection
of the data, will guarantee an ideal protocol that is suitable for
implementation in Web browsers for the needs of e-commerce.
A brief
Study of Secure Sockets Layer (SSL)
The power of the padlock.
What
is the padlock at the left bottom of the Netscape Navigator screen? How
powerful is this padlock? How does it protect us as Internet users?
The padlock such as the above signifies an SSL
protocol enabled application. The SSL protocol is a program layer in the
application layer of the Open System Interconnect (OSI) model developed by
Netscape, the maker of the popular web browser Netscape Navigator. Netscape's idea is that the programming for keeping
messages confidential ought to be contained in a program layer between an
application (such as your Web browser) and the Internet's TCP/IP layers. The ‘sockets’ part of the term refers to the sockets’ method of
passing data back and forth between a client and a server program in a network
or between program layers in the same computer. (Client here is the customer
and server is the web merchant). The SSL has been offered as a proposed
standard protocol to the World Wide Web Consortium (W3C) and the Internet Engineering Task
Force (IETF) as a standard
security approach for Web browsers and servers. Since then, SSL is becoming ‘a de facto
standard’ for secure transactions and other exchanges over the Web.
Secure transactions across the Internet, as with any
other medium, have three goals. First, two parties engaging in a business
transaction don't want a third party to be able to read their transmission.
Some form of data encryption is needed. Second, the receiver of a
message should be able to detect whether someone has tampered with the message
in transit. This calls for a message integrity scheme. Finally, both
parties must know that they are communicating with the real party, not an
impostor. This needs some form of identification. .
The primary
goal of the SSL Protocol is to provide privacy and reliability between two
communicating transacting applications. (SSLv3 Secure Socket Layer version 3.0
Specification, (http://home.netscape.com/eng/ssl3/3-SPEC.HTM). In our case, to
establish a secure connection between a user’s web browser and the web server
of the merchant. This means SSL
link-authenticate both the parties.
Next, SSL lets browsers and servers share data or information and blocks any
other party from viewing the shared information. This is done using
cryptography and encryption. Having taken care of secrecy, SSL then ensures
that the shared data is not corrupted. If data corruption should occur, the SSL
will play its role in detecting data integrity. Eventually, SSL allows
controlled access to servers, directories, files and services.
Netscape uses RSA public and private key cryptography
for Internet security. RSA key cryptography is widely used for authentication
and encryption in the computer industry. Netscape has licensed RSA public key
cryptography from RSA Data Security
Inc. for use in its products, specifically for authentication. (http://developer.netscape.com/tech/security/ssl/howitworks.html).
RSA public key encryption is a technique that uses a
pair of asymmetric keys for encryption and decryption. Each pair of keys
consists of a public key and a private key. The public key is made public by
distributing it widely, thus the word ‘public’. The private key, on the other
hand, is never distributed; it is always kept secret, thus the word ‘private’.
Data that is encrypted with the public key can be decrypted only with the
private key of the other party. Conversely, data encrypted with the private key
can be decrypted only with the public key of the same party. This asymmetry is
the property that makes public key cryptography so useful.
So, two parties engaging in a secure transaction must
know each other's public keys but need not know the other’s private keys. When
A wants to send B an encrypted message, A use B’s public key to turn A’s
message into gibberish. A know that only B can turn the gibberish back into the
original message, because only B knows her private key. In some cases, when B
loses her private key, RSA’s asymmetry property in this public key cryptography
enables A to recover her own encrypted message (encrypted using her own private
key) with A’s own public key.
The
public key itself has been standardized by RSA with several credible
institutions. The form of the public key shall take the same format and
structure. The Public-Key Cryptography Standards (PKCS) are a set of standards
for public-key cryptography, developed by RSA Laboratories in cooperation with
an informal consortium, originally including Apple, Microsoft, DEC, Lotus, Sun
and MIT. PKCS includes both algorithm-specific and algorithm-independent implementation
standards. (RSA Laboratories FAQ ver 4: What is PKCS?; http://www.rsa.com/rsalabs/faq/html/5-3-3.html)
Having
merely a key to unlock the wealth of information contain within the transaction
is not enough to ensure total message secrecy from other party. The message
itself would have to be jumbled up even more. This is some sort of 2nd
level encryption in the SSL protocol. The sender runs each message through a message-digest
function such as MD5 or SHA. (RSA Labs FAQ v.4 : What are MD2, MD4, MD5? ; http://www.rsa.com/rsalabs/faq/html/3-6-6.html).
This function within an application produces a number called a message
authentication code (MAC). The system works because it's almost impossible
for an altered message to have the same MAC as another message. Also, you can't
take a MAC and turn it back into the original message.
message
digest
Message => Message
Authentication Code (pre hash code)
Up to this stage, SSL produces a MAC for a message
first before it is encrypted (2nd level encryption). Next, it
encrypts the MAC with the sender's private key (top level encryption).
Pre Hash Code
+ Sender’s Private Key => Top Level Encryption
It then encrypts both the message and the encrypted
MAC with the recipient's public key and sends the message.
The encrypted pre hash code and the
message are encrypted using the secret key.
Sender obtains public key (digital
certificate) from receiver
Sender encrypts the product of top
level encryption with recipients public key and sends the message
The message now is gibberish but it contains the
identity of the sender and the information itself. So, authentication is
possible at the receivers end. The encryption methods used above are either
from the RC2_CBC_40. (RSA Laboratories FAQ version 4; http://www.rsa.com/rsalabs/faq/html/3-6-2.html)
or RC4_40 category of proprietary encryption method. (RSA Laboratories FAQ version 4; http://www.rsa.com/rsalabs/faq/html/3-6-3.html)
The process at the
receiving is actually the reverse of the process of encryption. When B gets A’s
message and decrypt it, B also get the encrypted MAC. B’s software takes the
message and runs it through the same message-digest function that A used to get
B’s MAC. Then it decrypts A’s encrypted MAC. If B’s MAC and A’s decrypted MAC
are the same, then A know the message has not been tampered with. (Turn to the
following page for a diagram of RSA Key Cryptography Summary). The process of
decryption
The recipient uses his/her private key to decrypt the secret key.
The recipient uses his private key to decrypt the encrypted message and
pre hash code.
The recipient gets the sender's
public key and verifies its certificate with a certificate authority.
The recipient uses the sender's public key to decrypt the pre hash code.
This verifies the identity of the sender.
The recipient generates a post hash
code from the message.
The post hash code equals the pre hash code. This verifies that the
message has not been changed enroute.
To recap, SSL is capable of identifying
(authenticating), prevent unwanted changes to the original information by third
parties (enhance integrity of data), prevent information from leaking (taking
care of secrecy) and assures that no unauthorized entity has intercepted data,
like account numbers or credit card numbers, en rout to the intended
destination. SSL will guarantee that the customer cannot deny that she had not
been billed for purchases that she did not make. (non-repudiation).
A problem arises when a customer wants to send
encrypted credit card information to the merchant for the first time commerce
takes place between both parties. A customer’s computer will not know the public
key that belongs to the web merchant. SSL provides an automated solution that
performs user authentication and verification of public key by using digital
certificates.
Using SSL, a client program and a server program
agree on encryption and MAC methods. The server authenticates itself to the
client (customer) by sending an unencrypted ASCII-based digital certificate
(authentication of the client is optional). (refer to the diagram above). A
digital certificate contains information about the company operating the server
- including the server's public key. By
using digital certificate, the SSL protocol enables SSL enabled customer web
browsers to confirm that they are actually submitting their valuable credit card
information to the intended web merchant and not with a fraudulent site
stealing credit card information
To further enhance the credibility of this so called
certificates, the digital certificate is "signed" by a trusted
digital-certificate issuer, which means that the issuer has investigated the
company operating the server and believes it to be legitimate. If the client
trusts the issuer, then it can trust the server. The digital-certificate issuer
"signs" the certificate by generating a MAC for it, then encrypting
the MAC with the issuer's private key. If the client trusts the issuer, then
the client already knows the issuer's public key. Popular certificate issuers
include RSA and VeriSign, whose services are not free.
Currently, there are only a handful of issuers.
Besides agreeing on an encryption and MAC scheme,
client and server have to agree on a key-exchange method: To close security
holes, SSL requires that the client and server agree on a set of randomly generated
keys. After the session is terminated, the keys are thrown away.
The SSL protocol gives two levels of encryption:
40-bit and 128-bit. With 40-bit encryption, there are billions of possible keys
to decipher the coded information, and only one of them works. Someone
intercepting the information would have to find the right key - a nearly
impossible task. With 128-bit encryption, there are 300 billion trillion times
as many keys as with 40-bit encryption. It is virtually impossible for an
unauthorized party to find the right key, even if they are equipped with the
best computers at speeds of a few million gigahertz. (http://home.netscape.com/security/basics/encryption.html)
The encryption method used in the SSL protocol is
judged so difficult to break by the US government that it was restricted for
export to other countries. This method has become a Data Encryption Standard
(DES) for Internet Security purposes.
Here’s an example of a
digital signature that is explained above.
It belongs to Jim Heath, the author of the article “How Electronic
Business Works and how it will change your business”, http://www.viacorp.com/crypto.html
- details).
Version:
2.6.3ia
iQEVAwUBM1HX3frQmI8kGPQBAQGWWAgAmd36+ds4YdVXNfzlK+zvYwcnYoXJ211H
Kc8Vdav5YQ5Gm7qEMdTOyTNns5d8z02oQk4PnnxE8AFBT+UfGAIYLT9g6yjdvLcS
GRcJtneTr73OqJeY0w0SvHOBmBxNnd2bfv9D3jo4WaCIxG4TJGCNP82brVfh+UcD
HWa+PXw8Lxl5w2ChbQMfv4YoVpJvKtSaJnSD/5/ZBtH07Hppz2bfUxY/wcnPSznZ
28/wdD66s97HbUmDN+2c+z/QHpcg2OnZGAF/acdhisFbjEGCpl7jjv1i55rZO0MY
qSnPq+cZsYf2M/R48S4QjBIi5UgdLx9GPmIjlD5AFv29Zap3JO4X5A==
=7gLs
Save that as a file, and run
it through a digital certificate capable software such as Eudora Email or
Netscape’s Mail.
You'll get a message that
says:
File has signature. Public key is required to check signature. Please enter filename of material that signature applies to:
Type in the right filename
which contain the public key, and you get a message like this:
Good signature from user "jim heath <[email protected]>"
If you didn't pick the right
file, or the text in it didn't match exactly, you would get a message
like this:
Bad signature from user "jim heath <[email protected]>"
This exercise will show you how digital certificate would
help in the authentication process in secure transactions. Because a digital
certificate is produced by a credible body in phase with a public key of a web
merchant, the customer should have more thrust on the company which she is
making her purchase from.
RSA Key Cryptography Summary in Secure Socket Layer Protocol
Taken from: http://www.zdnet.com/pcmag/pctech/content/17/10/nt1710.006.html
1. A sender takes a document and
produces a message authentication code (MAC) using a message-digest function.
2. The sender encrypts the MAC with
the sender's private key.
3. The sender attaches the encrypted
MAC to the document and encrypts both with the recipient's public key.
4. The sender sends the message to the
recipient, which receives and decrypts the message with its private key.
5. The recipient produces a local copy
of the document's MAC using the same message-digest function that the sender
used.
6. The recipient decrypts the sender's
MAC using the sender's public key.
7. The recipient compares its local
copy of the MAC to the sender's unencrypted MAC. If the two match, then the
recipient knows that the document has not been tampered with--and that only the
sender could have created the original message.
Case Study : Using SSL for typical e-commerce
The following example involves Alice and Bob. Suppose
that Bob is a Web Merchant that Alice wants to buy something from through
electronic commerce.
First, Alice will want to authenticate Bob. Alice
needs to make sure that Bob is really a web merchant that is the real, true
person who Alice would want to make her purchase from. Bob has a pair of keys,
one public and one private. Bob discloses to Alice his public key (the way he
does this is discussed later). Alice then generates a random message and sends
it to Bob:
|
|
|
|
|
Bob uses his private key to encrypt the message and
returns the encrypted version to Alice:
|
|
|
|
Alice receives this message and decrypts it by using
Bob's previously published public key. She compares the decrypted message with
the one she originally sent to Bob; if they match, she knows she's talking to
Bob. An imposter presumably wouldn't know Bob's private key and would therefore
be unable to properly encrypt the random message for Alice to check. (using the
private key).
Unless you know exactly what you are encrypting, it
is never a good idea to encrypt something with your private key and then send
it to somebody else. This is because the encrypted value can be used against
you (remember, only you could have done the encryption because only you have
the private key).
So, to further enhance security, instead of encrypting the
original message sent by Alice, Bob constructs a message digest and encrypts
that. A message digest is derived from the random message in a way that has the
following useful properties:
- The digest is difficult to reverse. Someone
trying to impersonate Bob couldn't get the original message back from the
digest.
- An impersonator would have a hard time finding a
different message that computed to the same digest value.
By using a digest, Bob can protect himself. He computes the digest of the random message sent by Alice and then encrypts the result. He sends the encrypted digest back to Alice. Alice can compute the same digest and authenticate Bob by decrypting Bob's message and comparing values.
The technique just described above is known as a
digital signature. Bob has signed a message generated by Alice, and in doing so
he has taken a step that is just about as dangerous as encrypting a random
value originated by Alice. Consequently, our authentication protocol needs one
more twist: some (or all) of the data needs to be originated by Bob.
|
|
|
|
When he uses this protocol, Bob knows what message he is
sending to Alice, and he doesn't mind signing it. He sends the unencrypted version
of the message first, "Alice, This Is Bob." Then he sends the
digested-encrypted version second. Alice can easily verify that Bob is Bob, and
Bob hasn't signed anything he doesn't want to.
Handing Out
Public Keys
How does Bob hand out his public key in a safe way? Let's
say the authentication protocol looks like this:
|
|
|
|
With this protocol, anybody can be Bob. All you need
is a public and private key. You lie to Alice and say you are Bob, and then you
provide your public key instead of Bob's. Then you prove it by encrypting
something with the private key you have, and Alice can't tell you're not Bob.
To solve this problem, the standards community has invented
an object called a certificate. A certificate has the following content:
- The certificate issuer's name
- The entity for whom the certificate is being
issued (aka the subject)
- The public key of the subject
- Some time stamps
The certificate is signed using the certificate issuer's private key.
Everybody knows the certificate issuer's public key (that is, the certificate
issuer has a certificate, and so on...). Certificates are a standard way of
binding a public key to a name.
By using this certificate technology, everybody can
examine Bob's certificate to see whether it's been forged. Assuming that Bob
keeps tight control of his private key and that it really is Bob who gets the
certificate, then all is well. Here is the amended protocol:
|
|
|
|
Now when Alice receives Bob's first message, she can
examine the certificate, check the signature (as above, using a digest and
public key decryption), and then check the subject (that is, Bob's name) and
see that it is indeed Bob. She can then trust that the public key is Bob's
public key and request Bob to prove his identity. Bob goes through the same
process as before, making a message digest of his design and then responding to
Alice with a signed version of it. Alice can verify Bob's message digest by using
the public key taken from the certificate and checking the result.
A hacker - Chris -
can do the following:
|
|
|
|
But Chris can't satisfy Alice in the final message. Chris
doesn't have Bob's private key, so he can't construct a message that Alice will
believe came from Bob.
On to the
buying process: Exchanging credit card information
Once Alice has
authenticated Bob, she can then send Bob her credit card details ,a message
that only Bob can decode, for billing purposes.
|
|
|
|
The only way to find the credit card number is by decrypting
the above message with Bob's private key. Exchanging sensitve information like
credit card number is another powerful way of why using public key cryptography
willl guarantee safe online transaction. Even if the communication between
Alice and Bob is being observed (by Dante this time who somehow managed to get
pass the authentication process but not Chris since he has failed in the
authentication stage), nobody but Bob can get the secret.
Next, SSL protocol intelligently use the credit card
number as another key, but this time it's a key to a symmetric cryptographic
algorithm (such as RC4). Alice (of course) knows the credit card number because
she generated it before sending it to Bob. Bob knows the credit card number now
because Bob has the private key and can decrypt Alice's message. Because they
both know the credit card details now, they can both initialize a symmetric
encryption (cipher) algorithm and then start sending messages encrypted with
it. Here is a revised protocol:
|
A->B |
|
|
The secret-key is made up of randomly generated codes
derived from the credit card information.
Here comes
Dante
Dante is still in the picture now. Although Dante cannot
discover the secret that Alice and Bob have exchanged, he is angry and has
decided to interfere in their transaction by damaging it. For example, if Dante
is sitting between Alice and Bob, he can choose to pass most information back
and forth unchanged but mangle certain messages (easy for him to do because he
knows the protocol that Alice and Bob are speaking):
|
B->D A->D B->D D->A
B->D |
|
Hi, I'm Bob,
bobs-certificate prove it Alice, This Is bob ok bob, here is my
{C.C.no.} bobs-public-key {some message}secret-key |
Dante passes the data through without modification until
Alice and Bob share a secret. Then Mallet gets in the way by garbling Bob's
message to Alice. By this point Alice trusts Bob, so she may believe the
garbled message and try to act on it. Note that Mallet doesn't know the secret
- all he can do is damage the data encrypted with the secret key. Mallet may
not produce a valid message. Then again, he may get lucky if he could somehow
(in a miracle) manage to produce the secret key (the same one that is derived
from the credit card information).
Message Authentication Code to the Rescue
To prevent this kind of damage, Alice and Bob can
introduce a message authentication code (MAC) into their protocol. A MAC is a
piece of data that is computed by using a secret and some transmitted data. The
digest algorithm described above has just the right properties for building a
MAC function that can defend against Dante:
|
|
|
|
Because Dante doesn't know the secret, he can't compute the right
value for the digest. Even if Dante randomly garbles messages, his chance of
success is small if the digest data is large. By using MD5 of SSL (a good
cryptographic digest algorithm invented by RSA), Alice and Bob can send 128-bit
MAC values with their messages. The odds of Mallet's guessing the right MAC are
approximately 1 in 18,446,744,073,709,551,616 - for all practical purposes,
never. Here is the sample protocol, revised yet again:
|
|
|
|
Dante is in trouble now. He can garble messages all he
wants, but the MAC computations will reveal him for the fraud he is. Alice or
Bob can discover the bogus MAC value and stop talking. Dante can no longer put
words in Bob's mouth. There Dante goes. Dante may decide to record, observe,
sit all his life replaying the ‘conversation’ that Alice and Bob has but he
will eventually find out that the SSL protocol is a Internet security protocol
that will be a standard of protection against people like him for all online
transactions now and in the future.
Most of the
SSL protocol that can be seen in today’s web browsers are only SSL version 2.0.
Netscape Navigator 3.0 and Internet Explorer 3.0 employs SSL protocol version
2.0. SSL protocol version 3.0 has already been released by Netscape Navigator.
The latest version of Netscape and Microsoft’s web browser supports the newer
version of the SSL.
There are several
significant differences between the newer version 3.0 protocol to the older
version 2.0.
Security
improvements:
- SSL 2.0 is vulnerable to a
"man-in-the-middle" (known in this paper as Dante) attack. An
active attacker might invisibly force both client and server to use 40-bit
encryption. This will enable him to have fewer key combinations to deduce
the information in the secret code. SSL 3.0 defends against this attack by
having the last handshake message include a hash of all the previous
handshake messages.
- SSL 2.0 uses a weak MAC construction, although post-encryption
seems to stop attacks. This is fixed in 3.0.
- SSL 2.0 feeds padding bytes into the MAC in block cipher modes, but
leaves the padding-length field unauthenticated, which could allow active
attackers to delete bytes from the end of messages. This, too, is fixed in
3.0.
- In SSL 3.0, the Message Authentication Hash uses a full 128 bits of
keying material, even when using an Export cipher. In SSL 2.0, Message
authentication used only 40 bits when using an Export cipher.
- In SSL 2.0, the client can only initiate a handshake at the
beginning of the connection. In 3.0, the client can initiate a handshake routine,
even in the middle of an open session. A server can request that the
client start a new handshake. Thus, the parties can change the algorithms
and keys used whenever they want.
- SSL 3.0 allows the server and client to send chains of
certificates. This allows organizations to use a certificate hierarchy
that is more than two certifications deep.
Backward
compatibility:
- SSL 3.0 can recognize an SSL 2.0 client hello and fall back to SSL
2.0. An SSL 3.0 client can also generate an SSL 2.0 client hello with the
version set to SSL 3.0, so SSL 3.0 servers will continue the handshake in
SSL 3.0, and SSL 2.0 server will cause the client to fall back to SSL 2.0.
Other:
- SSL 3.0 separates the transport of data from the message layer. In
2.0, each packet contained only one handshake message. In 3.0, a record
may contain part of a message, a whole message, or several messages. This
requires different logic to process packets into handshake messages.
Therefore, the formatting of the packets had to be completely changed.
- Cipher specifications, handshake messages, and other constants are
different.
We have discussed the
Secure Socket Layer protocols here in this student level technical paper. SSL
being a security protocol provides data encryption, server authentication,
message integrity and optional client authentication for TCP/IP connection.
When a customer’s program connect to a secure merchant server, the usual TCP/IP
protocol initiates a handshake and the SSL protocol makes the session secure.
With SSL protocol explained, online transactions for e-commerce is guaranteed
the following:
a) The connection is
private.
Encryption is used after an initial handshake to define a secret key. Symmetric cryptography is used for data encryption
b) The peer's identity can be authenticated using asymmetric, or public key cryptography
c)
The connection is reliable.
Message transport includes a message integrity check using a keyed
MAC. Secure hash functions are used for
MAC computations.
The future of
e-commerce really depends on how secure Internet transactions could be. The SSL
protocol, although is applicable to today’s e-commerce will still have its
limitation. R. M. Davies said in the National
Bureau of Standards Special Publication 500-27, Feb 1978,
“The intricacies of relating key
variations and working principles to the real strength of the
encryption/decryption equipment were, and are, virtually unknown to almost all
buyers, and informed decisions as to the right type of on-line, off-line,
key-generation, etc., which will meet buyers' security needs, have been most
difficult to make.”
The SSL is continuously being
revised to add improvements to the protocol as time passes. It is indeed
difficult to make up some protocol, and expect it to stay forever usable.
Newbie
Section
Whether or not you are a web server merchant or a purchaser, you have
got to know about SSL essentials. Further reading can be made here (http://www.ne-dev.com/ned-01-1998/ned-01-security.html)
or on the References Section at the end of this report. The following is
presented because they are the basics to using SSL.
First, who actually produces SSL software for e-commerce? As stated in
the report, SSL is actually developed by Netscape Communications. SSL does not
have a specific software. It is a protocol, and thus it is built into various
forms of softwares – whether Web
browsers or Web database software. An example of a Web browser that has SSL is
Netscape Communicator while an example of Web database software that has
built-in SSL capabilities is IBM Net.Commerce.
For Web Server Merchants
Suppose you are a web merchant who wants to have your server SSL
compliant. You encounter problems because a Web database software is usually
very expensive, thus making the whole process of implementing a Web Server that
is SSL capable very costly. Usually, you would opt for a company which can
provide the server with SSL capabilities. These companies are said to provide
SSL solutions. There are many companies that provide SSL solutions. An example
is Mimos Malaysia Sdn. Bhd.
Upon obtaining a SSL solution provider, you should now solve the
authentication process of Internet e-commerce. You should have your company
accredited by some credible company. What this means is that she should be
issued a digital certificate.
What you can see from the previous page is actually a snap out from VeriSign. VeriSign,
as stated before, is a digital certificate issuer. The process of obtaining
digital certificate can be done at the web site. (Currently, Malaysia too has
its own digital certificate issuer. http://www.digicert.com.my/)
Click.
Now, the process of having a SSL compliant server is now completed.
Purchases made from you is now secured.
For Web Purchasers
Suppose you want to buy something from
A Sdn. Bhd. You have never make any purchase before, but you know quite a bit
of SSL after reading this report.
You first, will want to see that A
is really a company you want to buy from. You want to check the authenticity of
A. You configure your Web browser to search for A’s public key that contains
the credibility of A. For example, in Internet Explorer, you can use the
following window.
By default, all Web browsers
nowadays will automatically search for the required public key that is needed
for authentication purposes.
Next, to check the validity of the
digital certificate issued to A, you can see a window like the following, after
downloading the digital certificate of A into your computer.
(A
in this case is DIGISIGN Sdn. Bhd.)
The next checklist on buying through
SSL enabled browser is to check for the following icon at the bottom of the
screen of the browser.
Once you are done with the steps
above, you are now protected by the security provided by SSL.
Glossary
- Secrecy – ability to keep secret information of
the data
- Authentication
- the act of proving data is valid
or genuine (true)
- Nonrepudiation –
acknowledgement, acceptance of data
- Integrity –
validity of the data
- Authentication -
the process of verifying identity so that one entity can be sure that
another entity is who it claims to be
- Digital certificate - contains information about the company
operating the server including the server's public key
- Message Digest – Process the message
- MAC – Message
Authenticate Code, contains information about the identity of the other
party
- Secret Key – A
secret code that is formed arbitrarily through the combination of randomly
picked binary data
- Public Key – A code
that contains the general information of a party that can be accessed by
anyone
- Private Key - A secret code that is only viewable by
the owner.
Bibliography
PC
Magazine Online: Pc Network Security in e-Commerce; http://www.zdnet.com/pcmag/pctech/content/17/02/it1702.002.html
Definition
of W3C; http://www.whatis.com/whc.htm
Definition
of IETF; http://www.whatis.com/ietf.htm
SSLv3 Secure Socket Layer
version 3.0 Specification; http://home.netscape.com/eng/ssl3/3-SPEC.HTM
RSA
Data Security; http://www.rsa.com/
RSA Laboratories FAQ ver 4:
What is PKCS?; http://www.rsa.com/rsalabs/faq/html/5-3-3.html
RSA
Laboratories FAQ ver 4: What is RC2_CBC_40; http://www.rsa.com/rsalabs/faq/html/3-6-2.html
RSA
Laboratories FAQ ver 4: RC4_40 category of proprietary encryption method; http://www.rsa.com/rsalabs/faq/html/3-6-3.html
SSL
Technical Brief; http://home.netscape.com/security/techbriefs/serv
PC
Magazine Network Edition – Internet Security, How Ecryption Works? http://www8.zdnet.com/pcmag/features/inetsecurity/howencrypt.htm
PC
Magazine Online – Digital Signatures, How they work?;
http://www.zdnet.com/pcmag/issues/1507/pcmg0090.htm
PC
Magazine Online – PC Tech (Secure Socket Layer 3.0);
http://www.zdnet.com/pcmag/pctech/content/17/10/nt1710.003.html
PC Webopedia Definition and Links: SSL;
http://webopedia.internet.com/TERM/S/SSL.html
Survey: How electronic encryption
works and how it will change your business;
http://www.viacorp.com/crypto.html
Study:
Cisco Study: Net Economy Bigger Than
Estimated;
http://ecommerce.internet.com/opinions/article/0,1281,3551_135521,00.html
The
SSL Protocol 2.0
http://home.netscape.com/eng/security/SSL_2.html
IBM Net.Commerce Set-up Guide, IBM Publications 1998
The above paper can be reproduced with permission from the author.
Referencing to this
document is permitted only for educational purposes. The author
welcomes feedback to
this document through his email: [email protected]