BASIC CONCEPTS Static Web Pages

Dynamic Web Poges

Active Web Pages
 Protocols and TCP/IP
• the lnternet is made up of computers and networks that have different
hardware as well as software characteristics. there must be some
universal l‘ron.rt'rrt0r', which can facilitate the communication between
all these computers.
• This is precisely what the protocol software docs in any data
communications. Including Internet communications.
• Protocol software defines an abstract model of communication hierarchy.
which is independent of all physical characteristics of the computers and
computer networks.
• As long as all participating computers and computer networks adhere to
the standards specified by the protocol software, they cart communicate
with each other without worrying about their inherent diFFet'ent:es.
Layered Organization
 SECURE SOCKET LAYER (SSL)
• The Secure Socket Layer [SSL] protocol is an Internet protocol
for the secure exchange of information between a Web browser
and a web server.
• lt provides two basic security" services: authentication and
confidentiality. Logically. it provides a secure pipe between the
Web browser anti the Web server.
• Netscape Corporation developed SSL in 1994. Since then. SSL
has become the world's most popular Web-security mechanism.
• All the major ‘Web browsers support SSL. Currently, SSL comes
in t0 three versions: 2, 3 and 3.1. most popular of them is
Version 3, which was released in 1995
 The Working ot SSL
• SSL has three sub-protocols, namely the Handshake Protocol,
the Record Protocol, and the Alert Protocol.
• These three sub-protocols constitute the overall working of
SSL
 The Handshake Protocol
• The Handshake Protocol of SSL is the first sub-protocol used
by the client and the server to communicate using an SSL-
enabled connection.
• This is similar to how Alice and Bob would first shake hands
with each other accompanied with a hello before they start
conversing.
• As the figure shows, the handshake protocol consists of a series of
messages between the client and the server. Each of these messages has
the format
• each handshake message has three fields. as follows:
• (A) Type (1 byte) This field indicates one of the ten possible
message types. These ten message types are listed in
• (B) length (3 byte) This field indicates the length of the
message in bytes.
• (C) Content [1 or more bytes] This field contains the
parameters associated with this message, depending on the
message type,
• The handshake protocol is actually made up of tour phases, as
shown in Fig. These phases are
• Phase l. Establish Security Capabilities This first phase of the
SSL handshake is used to initiate a logical connection and
establish the security capabilities associated with that
connection.
• This consists of two messages. the client hello and the server
hello. as shown in Fig.
• As shown in the figure, the process starts with a client Hello
message from the client to the server. It consists of the
following parameters:
• Version : This field identifies the highest version of SSL that
the client can support. its we have seen, at the time of this
writing, this can be 2, 3 or 3. I.
• I Random This field is useful for the later. Actual
communication between the client and the server.
• It contains two sub-fields:
• A 32-bit date-time field that identities the current system
date and time on the client computer.
• A 28-byte random number generated by the random-number
generator software built inside the client computer.
• Session id: This is a variable-length session identifier. If this field
contains a non-zero value.
• It means that there is already a connection between the client and
the server, and the client wishes to up- date the parameters of
that connection.
• A zero value in this field indicates that the client wants to create a
new connection with the server.
• Cipher suite: This list contains a list of the cryptographic
algorithms supported by the client {e.g. RSA. Diffie-Hellman, etc.].
in the decreasing order of preference.
• Compression method: This field contains a list of the compression
algorithms supported by the client.
• The client sends the client Hello mrssagr to the server and
waits for the server’s response. Accordingly. the server sends
back a server hello message to the client.
• This message also contains the same fields as in the client
Hello message. However. their purpose is now different. The
server- Hello message consists of the following fields:
• Version: This field identifies the lower of the versions
suggested by the client and the highest supported by the
server. For instance. if the client had suggested version 3. but
the server also supports version 3.1, the server will select 3.
• Random :This field has the same structure as the Random
field of the client. However, the Random value generated by
the server is completely independent of the client's Random
value.
• Session Id: If the Session Id value sent by the client was non-
zero, the server uses the same value. Otherwise, the server
creates a new session id and puts it in this field.
• Cipher suite: Contains a single cipher suite. which the server
selects from the list sent earlier by the client.
• Compression method: Contains a compression algorithm,
which the server selects from the list sent earlier by the client.
• Phase 2. Server Authentication and Key Exchange The server
initiates this second phase of the SSL handshake and is the
sole sender of all the messages in this phase.
• The client is the sole recipient of all these messages.
• This phase contains four steps, as shown in Fig. These steps
are: Certificate, Server key exchange, Certificate request and
Server hello done.
• In the first step (certificate), the server sends its digital
certificate and the entire chain leading up to root CA to the
client.

• This will help the client to authenticate the server using the
server's public key from the server's certificate. The server‘s
certificate is mandatory in all situations, except if the key is
being agreed upon by using Difiie-Hellman

• The second step (Server key exchange) is optional. it is used

only if the server does not send its digital certificate to the
client in Step l above. In this step, the server sends its public
key to the client [as the certificate is not available].
• The third step {certificate request‘}. the server can request
for the client's digital certificate. The client authentication
in SSL is optional and the server may not always expect the
client to be authenticated. Therefore. this step is optional.
• The last step (server hello done) message indicates to the
client that its portion of the hello message [i.e. the server
hello message) is complete.
• This indicates to the client that the client can now
(optionally) verify the certificates sent by the server and
ensure that all the parameters sent by the server are
acceptable. This message does not have any parameters.
After sending this message, the server waits for the
client's response.
 Phase 3. Client Authentication and Key
Exchange
• The client initiates this third phase of the SSL handshake. and
is the sole sender of all the messages in this phase. The server
is the sole recipient of all these messages. This phase contains
three steps. as shown in.
• These steps are: Certificate. Client key exchange and
Certificate verify.
• The first step (certificate) is optional. This step is performed
only if the server had requested for the client's digital
certificate. If the server has requested for the client’s
certificate and if the client does not recipient of all these
messages.
• This phase contains three steps, as shown in Fig. 6.16. These
steps are Certificate, Client key exchange, and Certificate
verify.
• The first step (certificate) is optional_ This step is performed
only if the sender had requested for the client‘s digital
certificate. If the server has requested for the client's certificate,
and if the client does not have one. the client sends a N0
certificate message,
• instead of a certificate message. It then is up to the server to
decide if it wants to still continue or not.
• Like the server key exchange message. this second step [client
key exchange) allows the client to send information to the
server. but in the opposite direction. This in information is
related to the symmetric key that both the parties will use in this
session.
• Here. the client creates a 43-byte pre-master secret.
andencrypts it with the server's public key and sends this
encrypted pre-master secret to the server.
• The third step {Certificate verify} is necessary only if the server had
demanded client authentication.
• As we know, if this is the ease. the client has already sent its
certificate to the server. However, additionally, the client also
needs to prove to the server that it is the correct and authorized
holder of the private key corresponding to the certificate.
• For this purpose, in this optional step, the client combines the pre-
master secret with the random numbers exchanged by the client
and the server earlier
• (in Phase l Establish security capabilities) alter hashing them
together using MD5 and SHA-1, and signs the result with its
private key.
• Phase -4. Finish The client initiates this fourth phase of the SSL
handshake. which the server ends.This phase contains four
steps, as shown in Fig. 6.11 The first two messages are from
the client: Change cipher specs. Finished. The server responds
back with two identical messages: Change cipher specs.
Finished.
• Based on the pre-master secret that was created and sent by
the client in the client key exchange message. both the client
and the server create a master secret .
• Before secure encryption or integrity verification can be
performed on records. the client and server need to generate
shared secret information known only to them.
• This value is a 43-byte quantity called the master secret . The
master secret is used to generate keys and secrets for
encryption and MAE? computations.
• Finally, the symmetric keys to he used by the
client and the server are generated. For this,
the conceptual process is used as shown in
Fig. 6.19.
• After this, the first step (Change cipher specs)
is a continuation from the client that all is well
from its end, which it strengthens with the
Finished message. The server sends identical
messages to the client.
 The Record Protocol
• The Record Protocol in SSL comes into picture after a successful
handshake is completed between the client and the server.
That is, after the client and the server have optimally
• authenticated each other and have decided what algorithms to
use for secure intfomtation exchange, we enter into the SSL
record Protocol. This protocol provides two services to an SSL
connection. As follows:
• I Confidentiality: This is achieved by using the secret key that is
defined by the handshake protocol.
• I Integrity: The handshake protocol also defines a shared secret
key (MAC) that is used for assuring the message integrity.
• As the figure shows, the SSL record protocol takes an
application message as input. First. It fragments it into smaller
blocks. optionally compresses each block, adds MAC. encrypts
it. adds a header and gives it to the transport layer, where the
TCP protocol processes it like any other TCP block.
• At the receiver's end. the header of each block is removed;
the block is then decrypted. verified. decompressed and
reassembled into application messages
• Fragmentation: The original application message is broken
into blocks, so that the size of each block is less than or equal
to 2“ bytes (l6.384 bytes).
• ' Compression: The fragmented blocks are optionally
compressed. The compression process must not result into
the loss of the original data. which means that this must be a
loss-less compression mechanism.
• ' Addition of MAC: Using the shared secret key established
previously in the handshake protocol. the Message
Authentication Code {MAC} for each block is calculated. This
operation is similar to the HMAC algorithm.
• ' Encryption: Using thc symmetric key established previously
in the handshake protocol. the output of the previous step is
now encrypted. This encryption may not increase the overall
size of the block by more than I024 bytes..
• ' Append header: Finally. a header is added to the encrypted block.
The header contains tlte following fields:
• o Content type (8 bits): Specifies the protocol used for processing the
record in the next higher level (e.g. handshake. alert, change cipher].
• o Major version (8 hits]: Specifies the major version of the SSL protocol
in use. For instance. it SSL version 3.1 is in use. this field contains 3.
• o Minor version {S bits]: Specifies the minor version of the SSL protocol
in use. For instance. if SSL version 3.0 is in use. this field contains D.
• o Compremed length (16 hits]: Specifies the length in bytes ofthe
original plain text block (or the compressed block. if compression is
used}.
• The Alert Protocol When either the client or the server
detects an error. tl1e detecting party sends an alert
message to the other party.
• if the error is fatal. both the parties immediately close the
SSL connection (which means that the transmission from b-
oth the ends is terminated immediately].
• Both the parties also destroy the session identifiers, secrets
and keys associated with this connection before it is
terminated. Other errors. which are not so severe. do not
result in the termination of the connection. Instead. The
parties handle the error and continue.
• Each alert message consists of two bytes. The
first byte signifies the type of error. If it is a
warning, this byte contains 1. If the error is
fatal. this byte contains 2. The second byte
specifies the actual error.
 Closing and Resuming SSL Connections
• Before ending their communication, the client and the server
must inform each other that their side of the connection is
ending.
• As we have noted. each party sends a Close notify alert to the
other party. This ensures a graceful closure of the connection.
When a party receives this alert.
• it must immediately stop whatever it is doing, send its own
Close notify alert and end the connection from its side as
well.
• If an SSL connection ends without a Close notify from either
party. it cannot be resumed.
 Transport Layer Security (TLS)
• Transport Layer Security (TLSJ is an IETF
standardization initiative, whose goal is to come
out with an lnternet standard version of SSL.
• Netscape wanted to standardize SSL. and hence
handed the protocol over to IETF. There are
subtle differences between SSL and TLS.
• However. the core idea and implementation are
quite similar. TLS is defined in RFC 2246.
 Secure Hyper Text Transfer
Protocol (SHTTP]
• Secure Hyper Text Transfer Protocol (SHTTP) is a set of security
mechanisms defined for protecting the Internet traffic.
• This includes the data entry forms and lnternet-based
transactions. Note that an HTTP request sent by using SSL is
identified as HTTPS (e.g HTTPs://www.yahoo.com),
• whereas this is SHTTP (e.g. sHTTP:// www.yahoo.com). The
services offered by SHTTP are quite similar to those of SSL.
However. SSL has become highly successful –
• SHTTP has not. SHTTP works at the application layer. and is
therefore. tightly coupled with HTTP. unlike SSL (which sits
between the application and the transport layers].
• SHTTP supports both authentication and encryption '
• of HTTP traffic between the client and the server. The encryption
and digital signature formats used in SHTTP in the PEM protocol.
• The key difference between SSL and SHTTP is that, SHTTP works
at the level of individual messages. It can encrypt and sign
individual messages.
• On the other hand, SSL does not differentiate between different
messages.
• Instead. it aims at making the connection between a client and
the server. regardless of the messages that they are exchanging.
Also. SSL cannot perform digital signatures
 Time Stamping Protocol rrsr)
• The Time Stamping Protocol [TSP] provides proof that a
certain piece of data existed at a particular time. This PKI
service is provided by an authority called as Time Stamping
Authority (TSA).
• TSP is currently under the development of the PKIX working
group.
• Digital signatures provided via the use of PKI can lead to
disputes, if the signer of an important document (cg. a funds
transfer order] later wants to repudiate her digital signature.
• She can dishonestly claim later that her private key was
compromised. and that it should be revoked.
• in such situations. It may be difficult to prove whether the
document was signed before: the signer reported the key
compromise or not.
• Using the time stamping technique. we can ascertain
whether an electronic document was created or signed at or
before a particular date and time.
• Step 1: Message Digest calculation
• Firstly, the entity (client) requiring a timestamp calculates a
message digest of the original message, which needs a
timestamp from the TSA.
• The client should use at standard message digest algorithm.
such as MD5 or SHA-I for this purpose. This is shown in Fig.
6.2].
• Step 2: Time Stamping Request
• Now. the client sends the message digest calculated in step l
to the : Time Stamp Authority(ISA) for getting time stamped,
as shown in Fig. 6.22. "this is called as a Time Stamping
Request.
• Step 3: Time Stamping Response In response to the client's
request, the TSA might decide to grant or reject the time
stamp.
• If it decides to accept the request and process it, it signs the
client's request together with the time stamp by the TSA
private key. Regardless, it returns a Time Stamping Response
• back to the client. This is shown in Fig. 6.23.
 SECURE ELECTRONIC TRANSACTION (SET)
• The Secure Electronic Transaction (SET) is an open encnptton and security
specification that is designed for protecting credit card transactions on the
Internet. The pioneering work in this area was done in 1996 by MasterCard
and Visa joinik They were joined by IBM. Microsoft. Netscape. RSA. Tensa
and VeriSign Starting from that time. there have been many tests of the
concept and by 1993 the first generation of SET-compliant products
appeared in the market.
• The need for SET came from the fact that MasterCard and Visa realized that
for e-commerce payment processing. software vendors were coming up
with new and conflicting standards. Microsoft mainly drove these on one
hand. and IBM on tl1e other.
• To avoid all sorts of future incompatibilities. MasterCard and Visa decided
to come up with a standard. ignoring all their competition issues and in
theprocess. involving all the major software manufacturers.
• SET is not a payment system. Instead. it is a set of security
protocols and formats that enable the users to employ the
existing credit card payment infrastructure on the Internet in :
1 secure manner. SET services can be summarized its follows:
• l. lt provides a secure communication channel among all the
parties involved in an e-commerce transaction.
• 2. lt provides authentication by the use of digital certificates.
• 3. lt ensures confidentiality. because the information is only
available to the parties involved in a transaction and that too
only when and where necessary.
 SET Participants
• Cardholder: Using the Internet, consumers and corporate purchasers
interact with merchants for buying goods and services. A cardholder
is an authorized holder of :1 payment card such as MasterCard or
Visa that has been issued by an Issuer (discussed subsequently].
• Merchant : A merchant is a person or art organization that wants to
sell goods or services to cardholders. A merchant must have a
relationship with an Acquirer {discussed subsequently) for accepting
payments on the lntemel.
• Issuer: The issuer is :1 financial institution (such as a bank) that
provides a payment card to a cardholder. The most critical point is
that issuer is the ultimately responsible for the payment of
thecardholder's debt.
• Acquirer: This is a financial institution that has El relationship with
merchants for processing payment card authorization and
payments.
• The reason for having acquirers is that merchants accept credit
cards of more than one brand. but are not interested in dealing with
so many bankcard organizations or issuers.
• instead. an acquirer provides the merchant an assurance (with the
help of the issuer) that :1 particular cardholder account is active and
that the purchase amount does not exceed the credit limits. etc.
• The acquirer also provides electronic funds transfer to the
merchant account. Later. the issuer reimburses the acquirer using
some payment network
• Payment Gateway: This can he taken up by the acquirer or an
organization as a dedicated function. The payment gateway
processes the payment messages on behalf of the merchant .
• Specifically in SET. the payment gateway acts as an interface
between SET and the existing card payment networks for
payment authorizations.
• The merchant exchanges SET messages with the payment
gateway over the Internet. The payment gateway. in tum.
connects to the acquirer's systems using a dedicated network
line in most cases.
• Certification Authority {CA}: As we know, this is an authority
that is trusted to provide public key certificates to
cardholders, merchants and payment gateways. in fact, CAs
are very crucial to the success of SET.
 The SET Process
• 1. The customer opens an account — The customer opens a
credit card account (such as MasterCard or Visa) with a bank
(issuer) that supports electronic payment mechanisms and
the SET protocol.
• 2. The customer receives a certificate— After the customer’s
identity is verified (with the help of details such as passport .
business documents etc. the customer receives a digital
certificate from a CA. The certificate also contains details such
as the customer's public key and its expiration date.
• 3. The merchant receives a certificate - A merchant that wants
to accept a certain brand of credit cards must possess a digital
certificate.
• 4 The customer places an order - This is a typical shopping
cart process wherein the customer browses the list of items
available, searches for specific items. selects one or more of
them and places the order.
• The merchant, in turn, sends back details such as the list of
items selected, their quantities, prices. total bill, etc. back to
the customer for his record, with the help of an order form.
• 5.The merchant is verified - The merchant also sends its digital certificate to
the customer. This assures the customer that he is dealing with a valid
merchant.
• 6.The order and payment details are sent — The customer sends both the
order and payment details to the merchant along with the customer's digital
certificate. The order confirms the purchase transaction with reference to
the items mentioned in the order form. The payment contains credit card
details. However, the payment information is so encrypted that the
merchant cannot read it. The customer's certificate assures the merchant of
the customer's identity.
7.The merchant requests payment authorization - The merchant forwards
the payment details sent by the customer to the payment gateway via the
acquirer [or to the acquirer if the acquirer also acts as the payment gateway]
and requests the payment gateway to authorize the payment i.e. ensure that
the credit card is valid and that the credit limits are not breached].
• 8.The payment gateway authorizes the payment — Using the credit card
information received from the merchant. the payment gateway verifies the
details of the customer's credit card with the help of the issuer, and either
authorizes or rejects the payment.
• 9.The merchant confirms the order — Assuming that the payment gateway
authorizes the payment, the merchant sends a confirmation of the order to
the customer.
• 10.The merchant provides goods or services — The merchant now ships the
goods or provides the services as per the customer‘:-. order.
• 11.The merchant requests payment - The payment gateway receives a
request from the merchant for making the payment. The payment gateway
interacts with the various financial institutions such as the issuer, acquirer
and the clearing house to effect the payment from the customer’s account
to the merchant’s account
 How SET Achieves its Objectives
• The main concern with online-payment mechanisms is
that they demand that the customer send his! her credit-
card details to the merchant . There are two aspects of
this.
• One is that the credit-card number travels in clear text,
which provides an intruder with an opportunity to know
that number and use it with malicious intentions (for
instance, to make his her own payments using that credit-
card number).
• The second issue is that the credit-card number is
available to the merchant, who can misuse it.
• Tlte first concem is generally dealt with by SSL. Since all
information exchange in SSL happens in an encrypted l'omt. such
that an intruder cannot make any sense out of it.
• Therefore, even if an intruder is able to listen to an active
conversation between a client and a server over the Internet. as
long as the session is SSL-enabled, the intruder’s intentions will
be defeated.
• However. SSL does not achieve the second objective. which is of
protecting the credit-card number from the ntercltant. In this
context.
• SET is very important. as it hides the credit-card details front the
merchant.
• The way SET hides the cardholder's credit-card details from
the merchzutt is pretty interesting. For this, SET relies on the
concept of a digital envelope. The following steps illustrate
the idea.
• l. The SET software prepares the Payment information (PI) on
the cardholder's computer (which primarily contains the
cardholder's credit-card details) exactly the same way as it
happens in any Web-based payment system.
• 2. However, what is specific to SET is that the cardholder's
computer new creates a one-time session key.
• 3. Using this one-time session key. the cardholder's
computer now encrypts the payment information.
• 4. The cardholder's computer now wraps the one-
time session key with the public key of the payment
gateway to form a digital envelope.
• 5. It then sends the encrypted payment information
(step 3} and the digital envelope (step 5} together
to the merchant [who has to pass it on to the
payment gateway).
• The merchant has access only to the encrypted
payment information. so it cannot read it. If it
were to read it.
• it would need to know the one-time session
key that was used to encrypt the payment
information. However, the one-time session
key itself is further encrypted by the payment
gateway's public key {to form at digital
envelope).
• The only way to open the digital envelope. that is to
obtain the original one-time session key. is to use the
payment gateway's private key. And as we know very
well, the whole idea behind a private key is that it
must be kept private.
• So, it is expected that only the payment gateway
knows its private key—the merchant does not know
it. Therefore, it cannot open the envelope and know
the one-time session key. and thus it cannot also
decrypt the original payment information.
• Purchase Request When we enter this phase of the SET
protocol. the real action begins.
• At this stage of Purchase Request step. the user is expected
to have completed the shopping pan, such as selection of
goods and services, etc
• The Purchase Request exchange is made up of four messages:
Initiate Request. Initiate Response. Purchase Request and
Purchase Response.
 Step I: Initiate request
• We have discussed digital certificates in detail. These digital
certificates are used in SET heavily. Here. three entities come
into picture. described as follows:
• ta) A Financial Institution {Fl} such as a bank credit cards for
people to make purchases without making cash payments.
• These banks are members of a common credit card payment
system group, such as Visa or MasterCard. Entities such as
Visa and MasterCard help govern the rules and protocols for
credit card payments.
• They also set up and monitor various merchant and bank
related services pertaining to credit cards
• We have discussed certification Authorities
(CA) earlier in detail.
• They authenticate individuals! organizations
and issue digital certificates to them for
conducting electronic commerce transactions.
(CA) help in ensuring non-fraudulent
transactions on the Web. They are involved in
the SET protocol indirectly.
• Payment gateways are third party payment processors. who
process payments on behalf of merchants by tying up with Fls
and banks.
• We have discussed them earlier: in some cases. The financial
institutions outsource the functions of the payment gateway to
third parties. Thus. There can be various models for this.
• The cardholder requests the merchant's certificates in the
Initiate Request message.
• The cardholder also sends the name of its credit card company
and an id created by the cardholder for this interaction
process. to the merchant in this message as shown in Fig. 6.2
 Step 2: Initiate response
• ln this phase. thc action is initiated by the merchant. For
this purpose. The merchant prepares a message (actually a
response to the user's request].
• For ensuring non-repudiation, it is also encrypted with the
merchants private key. in other words the digital signature
of the message.
• Also. it contains a unique transaction id that is created by
the merchant. For verification purposes, it also has the
merchant's digital ceritificate and the payment gateway's
digital certificate. This message is called as Initiate
response. as shown in Fig. 6.23.
• At the beginning of the step. The cardholder ensures the
identity of the merchant and that of the payment gateway.
• For this. The cardholder of course verifies the digital
certificates of the merchant and that of the payment gateway.
• At this stage, assuming that this verification was successful.
the cardholder creates two critical blocks of information:
• Order Information (OI) and Payment Information (Pl). To
ensure consistency and security. the transaction id that was
created earlier by the merchant is also appended to both OI
and PI.
• OI contains order information. such as which items
are being purchased etc {usually in the form of a
reference to the customer's order created earlier).
• On the other hand, PI contains details such as credit
card number, expiry, and purchase amount. Using
both of these, the cardholder now prepares the
Purchase Request package.
• However. this is not sent as it is. instead, a runtime:
key K is generated randomly.
 1. Purchase-related lnformation
• This information is mainly for the payment gateway.
• a. lt contains (al Pl. (b) digital signature calculated over Pl and OI
and (OI Message Digest OIMD). which is the message digest
calculated over OI by signing it with the cardholder's private key.
b. All these are encrypted with K.
• c. Finally. the digital envelope is created by encrypting K. with the
payment gateways public key.
• The name envelope signifies that it must be decrypted first before
any other Pl can be accessed. We should note that the key K is not
known to the merchant. This also prevents the merchant from
reading any payment-related information. instead, it must forward
this to the payment gateway.
• 2. Order-related Information — The order-related
information is not meant for payment gateway. Instead.
the merchant needs it. It is made up of the Order
Information {OI}.
• the signature computed over Pl and CI] and the Pl
Message Digest (PIMD) (which is calculated by encrypting
a small portion of the Pl with the cardholder's private key).
• As we shall discover soon. the PIMD is required so that the
merchant can verify the signature. Without it. it would not
be possible to do so
• Cardholder certificate — We know that a
digital certificate contains the public key of the
subject.
• Therefore, here, the certificate contains the
public key of the cardholder. It would be
needed by the merchant and the payment
gateway as described shortly
• The cardholder performs a message digest or
hash [H] on the Pl to generate PIMD. The
cardholder also hashes OI to generate CIIMD.
• The cardholder then combines PIMD and OIMD,
and hashes them together to form POMD.
• It then encrypts the PDMD with its own private
key to generate the Dual-Signature (DS). The
PDMD is available to both the merchant and the
payment gateway
• The cardholder sends the merchant the OI, DS
and PIMD. Note that the merchant must not
get PI (we shall see how the cardholder
achieves it. soon].
• Using these pieces of information. The
merchant verifies that the order came from
the cardholder, and not from someone posing
as the cardholder.
• The payment gateway gets Pl, DS and DIMD. Note
that the payment gateway need not get Ol. Using
these, the payment gateway can verify POMD.
• This verification satisfies the payment gateway
that the payment information came from the
cardholder, and not from someone posing as the
cardholder. For this purpose. the payment
gateway performs the actions as shown in Fig.
6.32
• An important question now is. how docs the cardholder protect thc
payment information from the merchant’? For this, the cardholder
performs the following process:
• - Cardholder creates Pl, DS and UIMD and encrypts the whole thing
with a one-time session key K.
• - Cardholder then encrypts session key K with the payment
gateways public key.
• - These two together form a digital envelope.
• - Cardholder sends the digital envelope to the merchant.
instructing it to forward it to the payment gateway. Since the
merchant does not have the private key of the payment gateway. it
cannot decrypt the envelope and obtain the payment details.
 Step 4: Purchase response
• When the merchant receives the Purchase Request, it does the
following:
• (a) Verifies the cardholder's certificates by means of its CA
signatures.
• {b) Verifies the signature created over Pl and D1 using the
cardholder's public key [which is part of the cardholder's digital
certificate]. This ensures that the order has not been tampered
with. While in transit and that it was signed using the cardholder's
private key.
• (c) Processes the order and forwards the Payment Information IIPI)
to the payment gateway for authorization (discussed later).
• (d) Sends a Purrhrtre Resporere back to the cardholder,
• The Purchase response message includes a message
acknowledging the order and references the
corresponding transaction number. The merchant
signs the message using its private key.
• The message and its signature are sent along with the
merchant's digital certificate to the cardholder.
• When the cardholder software receives the Purchase
Purchase response, it verifies the merchant’s
certificate and then takes some action, such as
displaying a message to the user.
 Payment Authorization
• This process ensures that the issuer of the credit card
approved the transaction. The Payment Authorization step
happens when the merchant sends the payment details to
the payment gateway.
• The payment gateway verifies these details and authorizes
the payment. Which ensures that the merchant will
receive payment.
• Therefore, the merchant can provide the services or goods
to the cardholder. as ordered. The Payment Authorization
exchange consists of two messages: Authorization Request
and Authorization Response.
 Step I: Authorization request
• In this step. an Authorization Request is prepared by
the merchant. ‘This is sent to the payment gateway,
which consists of the following details:
• 1. Information related to the purchase — This block
contains the Payment information (Pl).
• The dual signature calculated over Pl and OI by the
cardholder. the OI Message Digest (DIMD) and the
digital envelope. as discussed earlier.
• We would notice tl1at this was prepared by the
cardholder earlier.
• 2. Authorization-related information - In order that the
payment gateway trusts the message coming from the
merchant, the merchant takes the transaction id, signs it,
and encrypts it with a one-time symmetric key. This key is
generated by the merchant. Along with this. the merchant
also sends the digital envelope.
• 3. Digital certificates - The necessary certificates are
attached. For this, the merchant sends the cardholder's
digital certificate needed for verifying the cardholder's
digital signature and the merchant's digital certificate
needed for verifying the merchant's digital signature.
• As a result. the payment gateway ensures that all the certificates
are valid as usual. it then opens the digital envelope.
• For this purpose. it needs to decrypt it. After that. it obtains the
symmetric key. Using this key. it decrypts the authorization block.
• The payment gateway checks the merchant's digital signature on
the authorization information received from the merchant.
• It also tallies the two transaction ids: one received from the
merchant and the other received from inside the Pl sent by the
cardholder earlier.
• The payment gateway now obtains a payment authorization from
the credit card issuer (i.e. thecardholder's bank) for the payment
from the cardholder.
 Step 2: Authorization response
• I. Authorization-related block - The Authorization
block prepared by the payment gateway is signed with
the payment gateways private key.
• This ensures non-repudiation. in addition. this is
further encrypted by a one-time randomly created
symmetric key.
• This key is generated at run time generated by the
gateway. in order that the merchant be able to open
this block. the payment gateway encrypts the one-
time symmetric Key with the merchant's public key.
• 2. Capture token information - This block has
nothing to do with SET as such. instead. in
order that payment processing happens
correctly later. this information is used.
• The merchant does not get involved here.
Instead, it passes it back to the cardholder.
• 3. Digital certificate — The payment gateway's
digital certificate is also included in the
message
• with this authorization from the payment
gateway. the merchant can provide the goods
or services to the cardholder.
• Payment Capture For obtaining payment, the
merchant engages the payment gateway in a
Payment Capture transaction.
• lt also contains two messages: Capture
Request and Capture Response.
 Step I: Capture request
• Here. the merchant creates a Capture Request
block. lt contains the amount to be paid along
with the transaction id.
• For providing non-repudiation and
confidentiality. it is both signed as well as
encrypted. In addition, we should note that it
also contains the encrypted rupture token that
the merchant dad received earlier. and the
merchant's digital certificate
 Capture response
• In this message, the payment gateway notifies
the merchant of the payment. The message
includes a Capture response block, which is
signed and encrypted by the payment gateway.
• For ‘verification purposes. this message block.
also contains the payment gateway 's digital
certificate. The merchant processes this message
and stores the information therein for tallying
with the payment received from the bank later
 SET Conclusions
• From the discussion. it should become clear that although SSL and SET
are both used for facilitating secure exchange of information. their
purposes are quite different.
• Whereas SSL is primarily used for secure exchange of information of
any kind between only two parties la client and a server].
• SET is specifically designed for conducting e-commerce transactions.
• SET involves a third party called as a payment gateway. which is
responsible for issues such as credit card authorization, payment to the
merchant, etc.
• This is not the case with SSL. SSL primarily deals with encryption and
decryption of information between two parties. ll does not specify how
payment would be made. The architecture of SET ensures this as well.
SET Model
SSL Versus SET
 3-D Secure Protocol
• ln spite of its advantages, SET has one
limitation: it does not prevent a user from
providing someone else's credit card number.
• The credit card number it protected front the
merchant. However. how can one prevent H
costumer from using another person credit card
number’? That is not achieved in SET.
• Consequently. it new protocol developed by
Visa has emerged. called as 3-D Secure.
• The main difference between SET and 3-D
Secure is that any cardholder who wishes to
participate in a payment transaction involving
the usage of the 3-D Secure protocol has to
enroll on the issuer Bank’s Enrollment Server.
That is. before a cardholder makes a card
payment. she must enroll with the issuer
bank's Enrollment sewer.
• At the time of an actual 3-D Secure transaction. when the merchant
receives a payment instruction
• from the cardholder. the merchant forwards this request to the
issuer bank through the Visa network.
• The issuer bank requires the cardholder to provide the user id and
password that were created at the
• time of user enrollment process. The cardholder provides these
details. which the issuer bank verifies
• against its 3-D Secure enrolled users database (against the stored
curd number). Only after the user is
• authenticated successfully that the issuer bank informs the
merchant that it can accept the card payment instruction.
• At the time of an actual 3-D Secure transaction. when the
merchant receives a payment instruction from the cardholder. the
merchant forwards this request to the issuer bank through the Visa
network.
• The issuer bank requires the cardholder to provide the user id and
password that were created at the time of user enrollment process.
• The cardholder provides these details. which the issuer bank
verifies against its 3-D Secure enrolled users database (against the
stored curd number).
• Only after the user is authenticated successfully that the issuer
bank informs the merchant that it can accept the card payment
instruction.
Protocol Overview
• Step I The user shops using the shopping can on the merchant
site, and decides to pay the amount. The user cnlcrs the credit
card details for this purpose and clicks on the OK button
• Step 2 When the user elicits on the OK button, the user will be
redirected to the issuer bank's site. The bank site will popup u
screen. prompting the user to enter the password provided by
the issuer bank.
• This is shown in Fig. 6.4!. The bank (issuer) authenticates the
user by the mechanism selected by the user earlier. in this case.
we consider a simple static id and password based mechanism.
• Newer trends involve sending :1 number to the user‘s mobile
phone and asking the user to enter that number on the screen.
However. that falls outside of the purview of the 3-D Secure
protocol
At this stage. the hank verifies the user's password by comparing
it with its database entry. The bank sends an appropriate
success/failure message to the merchant. based on which the
merchant takes an appropriate decision. and shows the
corresponding screen to the user.
 Electronic money
• Electronic money is known as digital cash or
electronic cash is used for making a payment
over the internet.
• Electronic money is nothing but the
representation of money as computer files.
• The physical form of money is converted into
binary form of computer data
Security Mechanisms in Electronic Money
 Types of Electronic Money

• Electronic money can be classified in two ways. in the first

classification, the types of electronic money are decided
based on whether the electronic money is tracked or not.
• In this classification. Electronic money can be of these two
types: Identified electronic money and anonymous
electronic money.
• In the other method of classification, it is based on
whether or not the transaction is real-time.
• In this classification. electronic money can he either
online electronic money or oflllne electronic money.
 Classification Based on the Tracking of
Money
• This classification is based on whether the electronic money
is tracked throughout its lifetime.
• 1.Identified electronic money : identified electronic money
more or less works like a credit card.
• The progress of the identified electronic money from the very
first time it is issued by a bank to one of its customer. up to its
final return to the bank can he easily tracked by the bank.
• As a result. the bank can precisely know how and when the
money was spent by the customer.
• Consequently. the bank knows who is the original customer
that had requested for this money and how he spent it.
 Anonymous electronic money
• The anonymous electronic money (also called
as blinded money) works like real hard cash.
• There is no trace of how the money was
spent. There is no trail of the transactions
involved in this type of electronic money.
• Products like DigiCash provide this kind of
electronic money to lnternet users to spend.
by tying up with banks.
• The key difference between identified
electronic money and anonymous electronic
money (which creates the anonymity) is the
fact that whereas in case of the identified
electronic money the bank creates the serial
number.
• in case of the anonymous electronic money. it
is the customer who creates the serial number.
• l. The customer generates a random number by some mathematical
algorithm. The customer then multiplies it by another huge number
(called as the blinding factor].
• The customer sends the resulting number. called as blinded number
to the bank.
• The bank docs not know about the original number of Step (I).
• Bank signs (i.c. encrypts) the blinded number and sends it back to the
customer.
• The customer converts the blinded number back to the original
number using some algorithm.
• The customer then uses the original number land not the blinded
number] when making any transaction with a merchant.
• The merchant's encashment request to the bank is also with the
original number.
• The bank cannot trace this electronic money as it does not know the
relationship between the original number and the blinded number.
 Classification Based on the Involvement of
the Bank in the Transaction

• Online electronic money

• In this type, the bank must actively participate in the
transaction between the customer and the
merchant. That is. before the purchase transaction of
the customer can complete.
• the merchant would confirm front the bank in real
time as to whether the electronic money offered by
the customer is acceptable e.g. ensuring that it is not
already spent. or that the serial number for it is
valid}.
 Offline electronic money
• in this type, the bank docs not participate in the
transaction between the customer and the merchant.
• That is. the customer purchaser; something from the
merchant and offers to pay by electronic money .
• The merchant accepts the electronic money ; but
does not validate it online.
• The merchant might collect a group of such electronic
money transactions and process them together at
fixed time every day.
 EMAIL SECURITY
• Electronic mail (entail) is perhaps the most
widely used application on the Internet. Using
email. An internet user can send a message
(and these days. pictures. video. sound. etc.)
to other internet user(s).
• Consequently, the security of email messages
has become an extremely important issue.
• RFC 822 defines a format for text email messages.
email message is considered to be made up of
two portions: its content {or body) and headers
• an email message consists of a number of header
lines followed by the actual message contents.
• A header line usually consists of a keyword.
followed by a colon, followed by the keyword‘:
arguments. Examples of header keywords are
From,To, Subject and Date.
The Simple Mail Transfer Protocol (SMTP)

• The Simple Mail Transfer Protocol (SMTP) is

used for email communications. The email
software at the sender‘s end gives the email
message to the local SMTP server.
• This SMTP server actually transfers the email
message from the SMTP server of the
receiver: lts main job is to carry the entail
message between the sender and the receiver.
• The basic phases of an email communication consists
of the following steps:
• l. At the sender's end, an SMTP server takes the
message sent by a user's computer.
• 2. The SMTP server at the sender's end then transfers
the message to the SMTP server of the receiver.
• 3. The receiver's computer then pulls the email
message from the SMTP server at the receiver's end.
using other email protocols such as Post office Protocol
(POP) or Internet Message Access IMAP
• 1. Based on the Client's request for an email message transfer, the server sends
back a READY FOR
• MAIL reply, indicating that it can accept an email message from the client.
• 2. The client then sends a HELO (abbreviation of HELLO) command to the server.
and identifies itself.
• 3. The server then sends back an acknowledgement in the form of its own DNS
name.
• 4. The client cart now send one or more email messages to the server. The email
transfer begins with a MAIL command that identifies the sender.
• 5. The recipient allocates buffers to store the incoming entail message. and sends
back an OK response to the client. The server also sends back a return code of 250.
which essentially means OK. The reason both OK and a return code of 250 are sent
back is to help both humans and application programs understand the server's
intentions (humans prefer OK, application programs prefer a return code such as
250).
• The client now sends the list of the intended recipients of the
email message by one or more
• RCPT commands t one per recipient). The server must send back
a 250 OK or 550 N0 such user here reply back to the client for
each recipient.
• 8. After all RCPT commands. the client sends a DA T4 command.
indicating the server that the client is ready to start transmission
of the email message.
• 9. The server responds back with a 354 Start mail input message,
indicating that it is ready to accept the email message. It also tells
the client what identifiers it should send to signify that the
message is over.
• IO. The client sends the email message and when
it is over, sends the identifier provided by the
server to indicate that its transmission is over.
• The server sends back a 250 OK response.
• The client sends a QUIT command to the server.
• . The server sends back a 221 Service closing
transmission channel message. indicating that it is
also closing its portion of the connection
 Privacy Enhanced Mail (PEM)
• The Privacy Enhanced Mail {PEM} is an email security standard
adopted by the Internet Architecture Hoard (MB) to provide
secure electronic mail communication over the lnternet.
• PEM was initially developed by the internet Research Task
Force {IRTFJ and Privacy Security Research Group (PSRG). They
then handed over the PEM standard to the Internet
Engineering Task Force (IETF) FEM Working Group.
• PEM is described in four specification documents, which are
RFC numbers I421 to 1424.
• PEM supports the three main cryptographic functions of
encryption, non repudiation, and message integrity,
FEM allows for three security options when sending an email message. These
options are as follows:
I Signature only (Steps I and 2)
0 Signature and Base-64 encoding (Steps I, 2 and 4)
I Signature. encryption and Base-64 encoding (Steps I to 4)
 Step 1: Canonical conversion
• Tltcrc is at distinct possibility that the sender and the receiver of an email
message use computers that have different architectures and operating systems.
This is because the Internet works on any computer that has a TCP/IP stack.
regardless of its architecture or ‘operating system.
• Therefore, it is quite possible that the same thing is represented diffrrently in
these different computers
• For example. in the MS-DOS operating system, a new line
• (i.e.. the result of the keyboard‘s Enter key) is represented by two characters,
which is not the case in an operating system such as UNIX, wherein it is a single
character.
• This can create problems when creating message digests, and therefore, digital
signatures. For instance, the message digest for an entail message composed on a
computer that runs MS-DOS can differ from that on a computer that runs UNIX.
as the input for the message digest creation is not the same in the two cases.
• PEM transforms each email message into an
abstract. canonical representation.
• This means that regardless of the architecture
and the operating system of the sending and
the receiving computers. the email message
always travels in a uniform. independent
format.
• Step 2: Digital signature This is a typical
process of digital signature. It starts by
creating a message digest of the email
message using an algorithm such as MD5 or
SHA-l .
• The message digest thus created is then
encrypted with the sender's private key to
form the sender's digital signature.
• Step 3: Encryption In this step. the original
email and the digital signature arc encrypted
together with a symmetric Key. For this. thc
DES or DE.S~3 algorithm in CBC mode is used.
• Step 4: Bose-64 encoding This is the last step in FEM.
The Base-64 encoding (also called as Radix-64
encoding or ASCII armor) process transform arbitrary
binary input into printable character output.
• In this technique. the binary input is processed in
blocks of 3 octets or 24 bits. These 24 bits are
considered to be made up of 4 sets. each of 6 bits.
• Each such set of 6 bits is mapped into an B-bit output
character in this process.
 Pretty Good Privacy (PGP)
• Phil Zintmemtan is the father of die Pretty
Good Privacy IPGPI protocol. He is credited
with the creation of PGP
• The most significant aspects of PGP are that it
supports the basic requirements of
cryptography, is quite simple to use and is
completely free. including its source code and
documentation.
 How PGP Works?
• In PGP. the sender of the message needs to
include the identifiers of the algorithm used in
the message. along with the value of the keys.
The broad level steps in PEM are illustrated in
Fig. .
• As shown, PGP starts with a digital signature,
which is followed by compression, then by
encryption. then by digital enveloping and
finally. by Base-64 encoding.
PGP allows for four security options when sending an 3' H an
entail message. These options are as follows: I
0 Signature only (Steps I and 2)
I Signature and Base-64 encoding (Steps I. 2 and 5)
0 Signature. encryption, enveloping and Base-64 encoding (Steps l to 5)
• Step l: Digital signature This is a typical process of digital
signature. in PGP, it consists of the creation of a message
digest of the email message using the SHA-l algorithm.
The resulting message digest is then encrypted with the
sender's private key. The result is the sender's digital
signature.
• Step 2: Compression This is an additional step in PGP.
Here. the input message as well as the digital signature
are compressed together to reduce the size of the final
message that will be transmitted. For this, the Lempel-Ziv
algorithm is used.
• The Lempel—Ziv algorithm looks for repeated
strings or words. and stores them in variables.
• It then replaces the actual occurrence of the
repeated word or string with a pointer to the
corresponding variable.
• Since a pointer requires only a few bits of
memory as compared to the original string, this
method results in the data being compressed.
• Step 3: Encryption In this step, the compressed output of
Step 2 (i.c., the compressed form of the original email and
the digital signature together) are encrypted with a
symmetric key. For this. generally the IDEA algorithm is
used.
• Step 4: Digital enveloping In this ease, the symmetric key
used for encryption in Step 3 is now encrypted with the
receiver's public key. The output of Step 3 and Step 4
together form a digital envelope.
• Step 5: Base-64 encoding The output of Step 4 is Base-64
encoded now, as described earlier.
 Key Rings
• When a sender wants to send an email message to a single
recipient. there is not too much of a problem. Complcttities are
introduced when a message has to be sent to multiple recipients.
• if Alice needs to correspond with 10 people. Alice needs the
public keys of all these 10 people. Hence. Alice is said to need n
key ring of 10 public keys.
• Additionally. PGP specifies o ring of public-private keys. This is
because Alice may want to change her public-private key pair. or
may went to use a different key pair for different groups of users
(e.g. one key pair when corresponding with someone in her
family, another when corresponding with friends. a third in
business correspondence, etc}.
• In other words, every PGP user needs to have two sets of key
rings: (a) A ring of her own public-private key pairs and (b) A
ring of the public keys of other users.
 PGP Certificates
• In order to trust the public key of a user, we need to have
that user's digital certificate.
• PGP can use certificates issued by a CA, or can use its own
certificate system.
• As explained in our discussion of digital certificates. in
X509, there is a root CA, who issue: certificates to the
second level CAs. The second level CAs can issue
certificates to the third level CA: and so on.
• This can continue up to the required number of levels. At
the lowest level. the last CA issue certificates to the end
users.
• In PGP, things work differently. There is no CA.
Any one can sign a certificate belonging to
anyone else in the ring.
• Atul can sign the certificate for Ana. Jul, Harsh
and so on. There is no hierarchy of trust, or a
tree-like structure.
• The equivalent of CA (i.e. a user who issues
certificates} in PGP is called an introducer
• The whole concept can be understood better
with the help of three ideas:
• lntroduccr trust
• Certificate trust
• Key legitimacy
• We have mentioned that there is no concept of a hierarchical
CA structure in PGP. Hence.
• it is natural that the ring of trust in PGP cannot be very large.
if every user has to trust every other user in the system. Think
about this. In real life, we do not fully trust everyone we
know. Do we?
• To resolve this issue, PGP provides for multiple
levels of trust.
• let us say that we have decided to implement
three levels of trust to an Introducer.
• Let us call these levels as none. partial. And
complete.
• The Introducer trust then specifics what level of
trust the Introducer wants to allocate to other
users in the system.
 Certificate Trust
• When a user A receives a certificate of anothcr
user B issued by a third user C. depending on
the level of trust that A has in C. A assigns a
certificate trust level to that certificate while
storing it. lt is normally the same as the
Introducer trust level that issued the
cerificate.
 Wireless Application Protocol IWAPJ
Security
• In the late l990‘s, wireless computing stonned the
world of the lntemet. Until that time, the lntemet
• was accessible only if you had a PC. However. that
changed in 199'! with the arrival ol" a new set of
• standards for wireless [ntemet access through wireless
handheld devices and Personal Digital
• Assistants t[PDAs). The Wireless Application Protocol
IWAP} had arrived. in simple terms. WAP is a
• communication protocol that enables wireless mobile
devices to have an access to the Internet
• in the case of the WAP architecture. we have an additional level
between the client and the service". The ‘WAP gateway.
Simplistically. the job of' the WAP gateway is to translate client
requests to the server from WAP’ to HTTP and on the way back
from the server to the client. from HTTP to WAP as shown in Fig.
t5. 70.
• The WAP requests first originate from the mobile device (usually
a mobile phone). Which travel to the network carrier's base
station [shown as a tower) and from there. they are relayed on
in the WAP gateway where the conversion from WAP to HTTP
takes place.
•
• The WAP gateway then interacts with the Web
server [also called as origin server] as if it is a
Web browser: i.e. it uses HTTP protocol for
interacting with the Web server.
• On return. the Web server sends tm HTTP
response to the WAP gateway. where it is
convened into a WAP response. which first
goes to the base station and from then: on. to
the mobile device.
• The conversion between WTLS and SSL is a major point for debate. This is
because; the WAP gateway first converts WTLS test into plain text and then
applies SSL (or vice versa]. Therefore :. it has access to the non-encrypted
message in its original format !
• The WAP gateway performs this conversion in its memory and never stores
any portions of it on its disk. Clearly. if it stores it on its disk. it can be a major
cause for worry.
• However. even the fact that it performs this conversion in its memory has
made many people quite unhappy about the amount of security thus
provided.
• They feel that even a momentary lapse here could cause havoc. As a
consequence, many banks. merchants and financial institutions supporting
WAP transactions prefer to have their own WAP gateways to make sure that
the WTLS—to-SSL and SSL-to-WTL5 conversion is under their control.
 Security in GSM
• In the earlier days of mobile telephony. analog technologies such as
Advanced Mobile Phone System (AMPS) were used. There was little or
no security in such technologies.
• Each mobile phone in such a system has a 32.-bit serial number and a
10-digit telephone number in its PROM.
• The telephone number is made up of : 3-digit area code. represented
by ID bits and a 7-digit subscriber number in 24 bits.
• When a mobile telephone is switched on, it sends out its 32-bit serial
number and 34-bit number.
• All this information was scat out in clear text. So. anyone trying to
listen to the passing wireless communication could do so. and also
access the serial number and the telephone number to her advantage.
• An improvement over AMPS was to make it digital. This was in
the form of a technology called as Digital AMPS (D-AMPS).
• Another similar voice technology called as Global System for
Mobile Communications [GSM] is used widely in Europe. and
it has now spread its wings even in US
• alternatives to the WAP standard have emerged. and have
actually become quite popular. General Packet Radio Service
(GPRS) is an emerging wireless data service that offers a
mobile data experience similar to current analog modems
without wires and with access wherever GSM wireless service
is available.
• There are three key aspects to GSM security:
• - Subscriber identity authentication
• - Signaling data confidentiality
• User data confidentiality
• Each subscriber is identified with a unique
International mobile subscriber identity (IMSI).
• Each subscriber also has a unique subscriber
authentication key. GSM authentication and encryption
work in such a way that this sensitive information is
never transmitted across the mobile network.
• lnstead. a challenge-response mechanism is used to
perform authentication. The actual transmissions are
encrypted with the help of a temporary. randomly
generated ciphering key {Kc}
• The security is distributed in three different elements of the GSM
infrastructure: the Subscriber identity Module (SIM). which is a
plastic card inside a mobile phone. the GSM handset and the
GEM network.
• ' The SIM contains the LMSI. Ki. the ciphering key generation
algorithm (A3). the authentication algorithm (A31 as well as a
Personal Identification Number (P1N}.
• ' The GSM handset contains the ciphering algorithm {A5}.
• * The Authentication Center [AUC], which is a part of the GSM
network. contains the encryption algorithms (A3. A5 and A8] as
well as a database of identification and authentication
information about the subscribers.
• Signaling and Data Confidentiality As we have mentioned
earlier, the SIM contains the ciphering key generation
algorithm {AS}. This is used to produce the 64-bit
ciphering key (Kc).
• The value of Kc is obtained by applying the same random
number as used in authentication to the A8 algorithm
with the individual subscriber authentication key [Ki].
• This key {Kc} is later used for secure communications
between the subscriber and the mobile telephony base
station.
• Voice and Data Security The A5 algorithm is used
to encrypt the voice and data traffic between the
user's handset and the GSM network.
• For this. the subscriber's handset sends a
ciphering mode request to the GEM network.
The network.
• in response. starts encryption and decryption of
the traffic using the ciphering algorithm [A5] and
the ciphering key [Kc].