Security consideration with e commerce

Bundesamt für Sicherheit in der
Informationstechnik
Federal Agency for Security in
Information Technology
Security Considerations with
Electronic Commerce
Series on IT Security
Volume 10
July 1999
Isabel Münch, VI 3, BSI, Godesberger Allee 183,
53175 Bonn, Germany
Tel.: ++49-228-9582-367
Mail: muench@bsi.de

Federal Agency for Security in Information Technology
The President
Security Considerations with Electronic Commerce
Foreword
Information security is one of the most important acceptance factors in the further
development of new media and services such as electronic commerce or "e-
commerce". Given the expected expansion of electronic payment transactions and e-
commerce and the investment which this requires, it is imperative that adequate
security mechanisms are put in place if consumer confidence in the reliability and
correct functioning of online systems is to be won and reinforced.
Users of multimedia services or e-commerce systems do not expect that use of such
systems will expose them to any security risks. Evidence suggests that when new
goods and services are offered to the public, the associated security and the
assurance of data and consumer protection are critical to their gaining acceptance.
The present volume in the series on IT Security provides an overview of the potential
threats associated with e-commerce and the security requirements needed to
counter these threats. A secondary function of this volume is to introduce the various
methods of payment available under e-commerce.
Dr. Dirk Henze

Security Considerations with Electronic Commerce Table of Contents
BSI Page i
Table of Contents
1 Introduction 1
2 Definitions 1
2.1 Electronic commerce 2
2.2 Electronic money 6
2.3 Variants of electronic money systems 7
2.4 Home banking 8
3 Threats Associated With Electronic Commerce 16
3.1 Survey of possible threats and dangers 17
3.2 Summary 19
4 Security Requirements 21
4.1 Protection of communication 21
4.2 Verification of the identity of the communication partners 22
4.3 Component security 22
4.4 Protection of the user 25
4.5 General security requirements 27
5 Examples of Electronic Money Systems 30
5.1 SET 30
5.2 ecash 35
5.3 CyberCash 38
5.4 First Virtual (FV) 42
5.5 Millicent 44
5.6 iKP 46
5.7 OTP 47
5.8 HBCI 47
5.9 Protection of communication through "secure channels" 48
5.10 Electronic purses 50
5.11 Summary 51
6 Regulatory Framework 53
6.1 German Banking Act (KWG) 53
6.2 Tax 53

Table of Contents Security Considerations with Electronic Commerce
Page ii BSI
6.3 Information and Communication Services Act (IuKDG) 54
6.4 Digital Signature Act 54
6.5 Data privacy protection 54
6.6 Distance Selling Directive 54
6.7 Industrial property law 55
7 Literature 56
8 Links 58
Appendix 59
A.1 Codes of practice for users 60
A.2 ActiveX attacks 62
A.3 Central banks 66
A.4 Cryptography 69
A.5 E-commerce and consumer protection 71
A.6 Overview of the threats and dangers to which e-commerce transactions are exposed 74

Security Considerations with Electronic Commerce Introduction
BSI Page 1
1 Introduction
It is said that the Internet is the marketplace of the future. Although up to now the Internet has
been primarily used as a means of publishing information about a company's goods and
services, many vendors have now begun to offer their products in "electronic department
stores". Use of electronic commerce or e-commerce, electronic trading over the Internet or
other open networks, is expected to increase at a meteoric rate and holds out the prospect of
huge profits. The business world of the future, it is claimed, will be digital.
At the same time, demand is increasing steadily for fast and cheap variants of electronic
money transfer. But the Internet was not developed for the transfer of sensitive information
and should therefore not be used for payment transactions without additional security
measures.
Although e-commerce is the latest buzzword, potential customers continue to be frequently
faced with the problem of how they should pay for goods purchased through e-commerce.
There is a number of Internet payment systems under development and the first of these have
completed their pilot phases, but it will still be some time before the first "Internet-wide"
systems have become established. Whether these will then be the best, the most secure or the
cheapest systems remains to be seen. Until then, every vendor will continue to operate a
different payment method, which often will be available only to a closed circle of users.
Currently the same payment variants are usually offered under e-commerce as in traditional
mail order transactions, i.e. credit card, cash on delivery, direct debit and bank transfer,
although special electronic money systems which were developed for handling payments over
the Internet are already in use to some extent. However, many vendors only accept payment by
credit card. This requires that the customer, on placing his order, enters his credit card number
and expiry date, which are generally transmitted unencrypted. But the relaying of unencrypted
messages over the Internet is about as secure as sending a postcard, except that in the case of
the Internet more intermediaries handle the message en route than is the case with ordinary
mail. This means that there is a real danger of the data being "intercepted" and misused.
In an open network such as the Internet, attacks can take many different forms. A brief
overview will therefore be provided in order to clarify the threats which need to be addressed
and the security requirements which must be placed on electronic money and e-commerce.
Given the expected expansion of electronic payment transactions and e-commerce and the
investment which this requires, it is imperative that adequate security mechanisms are put in
place if consumer confidence in the reliability and correct functioning of online systems is to
be won and reinforced.
2 Definitions
The payment procedure is a part of e-commerce, along with selection, ordering and delivery.
Many of the security issues relating to the use of e-commerce systems revolve around the
question of how one can pay securely over networks which are inherently insecure. For this

Definitions Security Considerations with Electronic Commerce
Page 2 BSI
reason, the security of "electronic payments", the possible dangers associated with them and
the related security requirements are all primary considerations in this document.
A number of different players are involved in the virtual circulation of money under the
various e-commerce systems. Essentially, the participants comprise customers, vendors and
payment intermediaries. A payment intermediary is usually a bank or credit card company, but
many new innovative companies are also coming forward as intermediaries with self-
developed electronic money methods. For the sake of simplicity, these will be referred to
below as "banks". The role of the bank is generally broken down in turn into a number of
different types of entity, such as customer's bank, vendor's bank, operator of the electronic
money system, clearing house, Payment Gateway, etc.
2.1 Electronic commerce
"Electronic commerce" or "e-commerce" refers to all commercial transactions in which one or
more of the following stages are processed electronically:
- advertising and promotion of products
- selection
- ordering
- payment
Customer
Intermediary/Bank
Vendor
Internet

Security Considerations with Electronic Commerce Definitions
BSI Page 3
- delivery
- use of the products
Like conventional trading, e-commerce can be divided into four phases: information,
agreement, delivery and after sales (see diagram).
Of special interest are cases of e-commerce where every stage or phase can be carried out
electronically, although of course, depending on the product, it may not always be possible to
deliver and use the product electronically.
Variations of e-commerce have been around for some time, for example, EDI (electronic data
interchange) for business-to-business transactions or EFTPOS (Electronic Funds Transfer at
the Point-of-Sale), i.e. non-cash electronic payment at the point of purchase.
However, unlike these forms of electronic commerce, the increasingly widely used term "e-
commerce" covers cases where the individual stages involved in a transaction are conducted
over open, insecure networks such as the Internet. The application of the term "e-commerce"
to cases where only single stages in the transaction are offered over the Internet, e.g. the
product range is presented on the Internet but ordering and payment have to be done by fax,
telephone or other "classic" routes, is often viewed as an exaggeration.
Information Agreement
After Sales Delivery
Advertising
Entry in
search
engines
Negotiate
transaction
Payment
Hotline
Guarantee,
repair,
exchange
Updates
Presentation of goods
and/or services
Use
Selection
Order

Page 4 BSI
When one considers e-commerce, a number of additional points have to be borne in mind
which do not apply in the case of pure electronic money systems. These include:
- copyright,
- product liability and
- delivery guarantee, defective delivery, complaints procedure.
The transfer of trading activities from the real world to the virtual world introduces a number
of problem areas. Procedures must be implemented in these areas in order to clarify the issues
to the satisfaction of all those involved.
When considering these issues, a distinction must be made between the type of goods being
traded, i.e. whether the commodity is a matter of bits (e.g. information, software, images,
sounds, online games, bets) or physical goods (e.g. toasters, books, computer accessories or
CDs). This difference is irrelevant to offering the goods for sale and ordering them; the
difference lies in the delivery. It is characteristic of the second group of goods that a different
route is required to deliver the goods from that used to order them. Even if e-commerce results
in a large increase in cross-border trade in the business-to-consumer area, it should be borne in
mind that, realistically speaking, transport costs are a major hurdle to electronic trading in
physical goods over large distances.
Where the commodity being electronically traded is data, a number of problems arise which
still have to be clarified as they are problems which are foreign to conventional commercial
transactions. It is not clear, for example, what the situation is regarding liability, scope for
redress or exchange of goods when a customer has downloaded a software package from the
Internet or other networks for a fee (generally these are provided in compressed form) and
then discovers that the software cannot be unzipped, will not start, is infected with a virus or
any other problems occur.

BSI Page 5
Problem: Supplied data Supplied physical goods
Problem/damage Cannot be read, not executable
etc.
Scratches, defects etc.
Impaired
functionality
Viruses, Trojan horses Electrically unsafe
Wrong goods
supplied
How can the customer prove that
the goods delivered are incorrect
or faulty or that the service was
not performed as promised?
Who pays the cost of returning the
goods?
Non-delivery Hacker has intercepted data/goods, recipient denies having received
them, sender claims that they have been dispatched.
Supplier has advertised goods but never delivered.
Goods delivered do not match the product descriptions in the
promotional material.
Exchange Must the recipient undertake to
delete the data? Is an electronic
receipt sufficient for the purposes
of seeking redress?
Goods returned.
Customs duties /
tax
Competitive neutrality, where
does any tax liability occur? How
does the customer receive a
receipt which is adequate for tax
purposes?
When one considers the problem areas, it is clear that most of the problems are not actually
new, it is merely that in most cases new types of solutions are needed.
Under e-commerce, competitive neutrality must be guaranteed, i.e. "electronic" commerce
must be subject to the same rules regarding VAT as "conventional" commerce. If the goods
are only ordered but not delivered over networks, then for tax purposes also the transaction is
no different from a conventional mail order transaction. If, however, the goods are also
delivered online it becomes more complicated as the underlying legislation does not yet cover
"online deliveries" (on this point see also the sixth EC Council Directive 77/388/EEC, dated

Page 6 BSI
17 May 1977, on the common system of Value Added Tax, especially Article 9 para 2; this
directive was adopted under German law in Section 3 a UStG1
).
Again, it is still unclear at present how taxation can be effectively implemented and controlled
under e-commerce. Problems here are as follows:
- The assignment of geographic locations to activities in networks (where is the vendor's
principal place of business, his WWW server, his provider etc.).
- Anonymity of purchasers and sellers.
- Payments with electronic money.
2.2 Electronic money
Another catchword which is commonly found in all the media today is "electronic money".
Before we consider the security aspects, once again we need to clarify first what we
understand by this term. This is another case of a term which actually covers many traditional
methods of transacting electronic payments.
We shall start by distinguishing the three following variants:
1. Customer-bank transactions (e.g. home banking, telephone banking etc.) which serve
the purpose of running the account or entail other direct contacts between customer
and bank.
2. Customer-vendor transactions. A (legally enforceable) contract is concluded under
which the vendor provides a particular service for which the customer pays.
Whether it is a case of teleshopping or Internet shopping, there is essentially no
difference between such a transaction and the classic mail order transaction. While the
goods are ordered online, payment can be effected either by the traditional route (e.g.
cash on delivery or money transfer) or using an electronic money system.
To protect a pure customer-vendor transaction, methods such as digital signatures
should be used in order that both parties can be sure of the authenticity of the sales
contract.
3. Customer-intermediary-vendor transactions. In this case payment is controlled through
an intermediary. This is usually a bank or credit card company, but many new
innovative companies are also coming forward as intermediaries with self-developed
electronic money methods.
It is this type of transaction which is the main application area considered in the
electronic money systems discussed below.
1
= Umsatzsteuergesetz (turnover tax law)

BSI Page 7
2.3 Variants of electronic money systems
Sending money digitally over computer networks is nothing new. Banks have been
exchanging money payments with each other and with their customers electronically for many
years. The familiar methods used to effect non-cash money payments include cheques,
transfers, bank deposits and direct debits. These too can be viewed as electronic payments in
the widest sense if one considers how they are processed in the underlying systems.
A whole range of electronic payment systems is currently being developed by different
interest groups. These are intended on the one hand to make traditional non-cash payment
procedures such as credit card payments and transfers also available on the Internet and on the
other hand to make digital cash payments possible. The feasibility of these new electronic
payment methods depends to no mean degree on their security.
The different electronic payment systems may be distinguished by their features, amongst
other things. A brief summary is provided below of those features which are relevant to "cyber
money".
T Point in time at which the money leaves the customer's account
- pre-paid (as with stored value cards)
- pay now (as for cash)
- post-paid (as with credit cards or cheques)
D Divisibility of units of value
- similar to coins
- cheque-like / credit card based
- transfers
A Anonymity
- completely anonymous
- partially anonymous
- not anonymous / completely transparent
S Suitability
- for paying small amounts
- for large amounts
- for information, programmes or services from the Internet
- for mail order
M Mobility (use of different terminal devices possible, e.g. private / public terminals)

Page 8 BSI
O Online or offline (offline means that there does not need to be direct communication
during the transaction so that no other party such as an authorising server or Payment
Gateway is introduced)
Sp Suitability for spontaneous purchases
N Negotiability (passing from hand to hand or only possible through bank/intermediary)
G Geographical extent of use
- confined locally
- national
- international
Today there are a large number of publications in which electronic money systems are
compared, but almost every one of them employs different criteria to classify the various
electronic money systems into groups. The distinction encountered most frequently here is
between credit card-based and coin-like systems.
Sometimes a distinction is also made as to whether payment entails accessing an "electronic
purse", i.e. a smart card which has been designed to enable the payment of small amounts.
However, when one considers the other aspects, this does not amount to a significant
difference; all that happens here is that the customer is provided with a secure medium for
storing his electronic money, which he can also use when he goes shopping in the real world.
Even when, as is often the case, electronic money systems use the catchword anonymity, this
does not necessarily mean that payments are completely anonymous. Often anonymity merely
means that the vendor cannot read the customer's account details while the bank does not have
access to the ordering information. The vendor must not be able to identify the individual
customer unless he needs a delivery address; he must simply be able to check the customer's
ability to pay. However, there are also systems which can successfully ensure that the bank
can neither detect the denomination of the amounts spent nor trace what happens to the
amounts spent after they have been debited to the smart card.
2.4 Home banking
In the age of global networking, more and more customers want to transact their banking
business online so as to avoid having to visit the local branch of the bank to arrange a transfer.
For the banks this provides an opportunity for further reductions in their costs; hence it is
clearly in their interests to develop home banking further. This is all part of an increasing
trend away from staff-intensive processing of customers' business in the branch towards self-
service by the customers.
For this purpose banks are offering different methods and technical solutions, some of them
still going by different names. Thus, for example, the terms home banking, Internet banking
and online banking are all used. The most important terms which need to be distinguished are
as follows:

BSI Page 9
- telephone banking,
- mobile banking,
- home banking,
- Internet banking,
- telebanking.
All these banking transactions over networks have in common the fact that transactions no
longer take place in the bank branch but at the customer's. Typical business transactions here
include, for example, execution of bank transfers, setting up or modifying standing orders, and
ordering blank cheques.
2.4.1 Telephone banking
Under telephone banking, the customer calls his bank's service centre and can obtain
information about his bank balance, arrange transfers or process other payment transactions all
over the phone. Generally the transactions which can be performed are standard payment
transactions. The bank receives the incoming calls and processes customers' instructions.
There are a number of different variants of telephone banking (see also [MH]).
On the one hand there is pure human-
to-human communication in which the
customer gives his instructions
directly to the banking employee. This
is the variant preferred by customers,
but it is also the most labour-intensive.
For this reason some credit institutions
are attempting to introduce IT-
supported methods.
The result is various systems of man-machine communication, under which the customer no
longer talks to a human. For example, some systems use speech recognition, while others
accept customers' requests in the form of numeric entries on a telephone with dual-tone multi-
frequency dialling or using the relevant add-on device which will be familiar from telephone
answering machines. With speech recognition systems, there continue to be problems as to the
reliability of speech recognition. When using this kind of system, customers should ensure
that in addition to speech recognition systems the banks also record calls so that they can
ensure that mistakes in transactions can be detected and corrected, for example where the
incorrect amount has been transferred.
Other combined forms of communication are also available under telephone banking, so that
the manner in which the customer's transaction is processed depends on the type of transaction
involved. Thus, a simple bank account balance enquiry could be provided by a machine,
whereas a more complex requests would be passed to an employee of the bank.
Telephone banking

Page 10 BSI
Under telephone banking, transactions are validated by means of passwords (also known as
codes) which take the place of a signature in a telephone transaction.
When telephone banking was first introduced, it was possible for customers to overhear parts
of the requests and passwords of other customers on the telephone due to defective acoustic
shielding. These problems have evidently been resolved in the meantime. There remains the
problem, however, that under telephone banking it is possible for other persons to overhear
the transactions and passwords either by chance or deliberately, e.g., where telephone banking
is conducted from phone booths or public rooms.
In general it should be borne in mind that telephone conversations can be overheard.
However, this does require technical expertise, appropriate equipment and also a certain
degree of criminal energy. Especially problematic is the use of cordless telephones. If these do
not comply with the DECT standard, they can be overheard by an ordinary person within a
range of 500 m using scanners which are easy to obtain. In this way, the eavesdropper can not
only listen in to the family secrets of his neighbour but also the passwords used to access his
bank account.
Moreover, it is apparent that, as is the case with many other systems in which users are free to
choose their own passwords, most people choose trivial passwords which are easy to guess.
According to a study carried out by the Quelle Bank ([QB]), 39% of passwords chosen by
customers are the names of persons, 16% are the names of cities and states, 12% the names of
animals or plants and 8% are signs of the Zodiac. Only 4% of customers chose passwords
which were neither proper names nor were in the Duden dictionary.
2.4.2 Mobile banking
Another variation of telephone banking is the development of mobile phone applications. For
example, some banks offer applications such as the communication of current stock market
prices or account balances over mobile message receivers using the SMS (Short Messaging
System) service; such services are provided over GSM networks such as D1 or D2.
2.4.3 Home banking
Home banking refers to the possibility of checking one's bank balance, arranging transfers,
setting up and deleting standing orders and performing various other banking transactions
from the home PC. In the past this has generally involved connecting the PC to the bank's
computer over videotex (CEPT) using the "ZKA"2
standard, a uniform bank interface. The
Home Banking Computer Interface standard (HBCI) was developed to enable customers to
also perform home banking over the Internet (see below).
2
= ZKA = Zentraler Kreditausschuss der deutschen Geldinstitute (banking associations' central credit
committee).

BSI Page 11
With home banking, customers
can access their accounts all
round the clock. This means that
the distance between the home
and the bank is irrelevant.
Customers can select the most
favourable offer of banking
services, regardless of the
geographic location of the bank.
Interception of passwords or transaction numbers
In order to be able to access his account over T-online, the customer needs a numeric
password or PIN in addition to a user ID or videotex account number. Only after the user has
entered these numbers correctly can he access his account. The PIN can be altered by the user
independently at any time. Normally the PIN has to be five digits long. Even if the user ID and
password are intercepted or unintentionally disclosed, a perpetrator can do no more than
enquire about the account balance. To arrange a transfer, so called TANs, six-digit transaction
numbers, are required. For this purpose the customer receives a written list of TANs from his
bank. Every transaction must be authorised by entering a TAN from this list, and each TAN
can only be used once. If a sequence of incorrect TANs is entered, access to the account is
blocked.
The user must ensure that passwords, PINs and TANs are kept in a safe place where they
cannot be accessed by unauthorised persons. It is best to keep the TANs separate from other
videotex passwords and PINs, if possible so that it is obvious to the user if anyone else has
accessed them. The user should note down for each TAN which transaction it was used on. If
an "unused" TAN is rejected as invalid, this should alert the user to the need to review the
most recent account transactions. TANs, passwords and PINs should not be stored within the
home banking software.
Home banking should also be used by the users to periodically review the current account
balance and the most recent account movements in order to be able to react quickly to any
irregularities.
Inappropriate password storage
In order that a user can operate home banking, as well as a T-Online3
ID and password, he
also needs a user ID together with the related password (PIN) from his bank. Most
programmes which are used for T-Online or home banking ask for these items during
installation so that after that the customer no longer needs to bother with a longwinded dial-in
procedure. These entries are then stored in a file, which in some applications is encrypted but
in others is held as plaintext. Even where encryption is used, in many applications it is so
3
T-Online is the most widely used service provider in Germany.
Videotex
Home banking

Page 12 BSI
ineffective that it can be quickly broken, failing which decryption programmes can be
obtained over the Internet.
But generally it is not necessary to go to this trouble, as often it is sufficient to copy the
relevant file in order to be able to perform transactions at the expense of the original user.
Unfortunately many privately used PCs are not sufficiently protected against unauthorised
accesses. A frequently cited argument is that in the private home only trusted persons have
access to the PC. However, there have already been a number of incidents in which home
banking programmes were copied and security-related information was passed on along with
the programme, which thus ended up in the hands of a person or persons other than the
original user. It is clear therefore that access passwords should never be stored in programmes
for reasons of convenience, as anyone who gains access to such a password either by theft or
as a result of carelessness can manipulate data and transact monetary transactions using the
name of the original owner and at his expense.
Some home banking applications such as Quicken even require users to enter the complete list
of TANs. Some banks make this even easier by offering the facility to download lists of
TANs. However, when all the TANs are stored in the home banking programme, anyone who
has access to the PC can gain access to the account. (Anyone who stores all his PINs and
TANs in the home banking programme is effectively giving potential perpetrators a licence to
help themselves to his account!) If this results in any financial loss to the customer, it may be
assumed that the loss will not be borne by the bank since it arose through breach of the
customer's duty of care. Even if access to the home banking programme is password
protected, in case of doubt, this does not prove that the TANs were handled with care as it has
not prevented access by unauthorised persons.
Trojan horses
Another way of intercepting passwords and TANs is via the use of Trojan horses. These are
harmful functions in programmes which can be caught rather like viruses from exchanging
programmes or files and which will read out data such as PINs and TANs from the
communicatios or home banking programmes and forward these unnoticed to unauthorised
persons during the next data transmission. It is possible to protect oneself against this danger
by
- never storing passwords or TANs in communication or home banking programmes,
- regularly performing virus checks and
- even in the private domain, refusing to accept any programmes or data from
unauthorised sources.
The best possible protection against Trojan horses continues to be to maintain strict separation
between "games" and "work" domains, e.g. by having a different computer for each.
Separation into two or more partitions provides a certain amount of protection.
Trojan horses are not merely hypothetical but they are found more and more, and in quite
different operational environments. They do not even require particularly in-depth

BSI Page 13
programming knowledge, as was demonstrated in the spring of 1998 by two 16 year-old
schoolchildren from Cologne (see [CT]). These children used a Trojan horse to collect the
passwords of several hundred T-Online customers and published this fact in order to draw
attention to the underlying security weaknesses. They started their campaign by offering a
shareware programme called "T-Online Power Tools" which contained some interesting
functions such as an e-mail address management facility for T-Online. However, the
programme also contained a Trojan horse which surreptitiously collected users' T-Online
passwords and then forwarded them to the authors of the programme.
Threat to passwords or TANs from software errors
As early as 1984, a software error actually discredited the entire videotex system. This
software error meant that when the specified command length was exceeded, protected areas
of storage could be read out. As a result the Chaos Computer Club (CCC) was able to obtain
the videotex password of the Hamburger Sparkasse (Hamburg savings bank). To make this
transparent, one night, masquerading as the Hamburger Sparkasse, they stayed on the CCC
website, which operated on a "pay-as-you-view" basis, until the Hamburger Sparkasse had run
up a debt of DM 135,000. The next day they published the information. Although Deutsche
Post denied that this or any other passwords had been disclosed through errors in its software,
the error was quickly rectified.
Tapping of telephone lines
Videotex (T-Online on CEPT standard) is based on quite normal telecommunications
connections, e.g. by modem or ISDN, and can be tapped just like any other telephone
conversation. A perpetrator could record a videotex session, including the videotex access
number and password, and then log in using the particulars overheard to access pages which
are not free of charge.
The same applies to any type of computer logon which is performed over a telephone line, as
long as the user ID and password are transmitted unencrypted.
A perpetrator wishing to listen to home banking traffic would tap into the connection between
the customer PC and the bank and read all the data traffic until the customer sent a transfer
including a TAN. At this point, the perpetrator would intercept the valid TAN, send the
customer a "TAN invalid" message, and then himself send a transfer to any account using the
intercepted TAN, which would still be valid.
Attacks of this kind have been discussed for some time, but no successful attempts have yet
been disclosed. In practice such an attack would be difficult to implement as the tapping of
modem connections requires a lot of resources. Moreover, most banks do not allow
international transfers to be arranged with home banking so that perpetrators then face the
question of which account they should transfer the money to. Moreover, the customer can
quickly detect such a manipulation if he checks after each transfer to make sure it has been
correctly posted.

Page 14 BSI
Protection of home banking transactions via six-digit TANs is not the technically ideal
solution, but evidently it has been sufficient up to now. However, work is under way to
develop new methods of protecting home banking transactions (see HBCI chapter).
2.4.4 Internet banking
Many banks now offer their customers access to their accounts over the Internet. This can be
achieved today via the ubiquitous browser. The concept of Internet banking was developed in
order to differentiate this type of access from home banking over videotex whose character-
based interface is not technologically up to date. However, the processes which run in the
background under Internet banking are largely the same as in home banking over videotex. In
most cases the familiar PIN/TAN procedure continues to be used; only seldom is HBCI used.
As the Internet offers significantly more opportunities for attack than the closed T-Online
network, additional measures must be taken if the PIN/TAN procedure is to be used.
Otherwise it could be possible, for example, for a transfer which has already been authorised
with a TAN to be retrospectively altered.
For this reason, it is essential with Internet banking that communication between customer
and bank is protected by encryption. The SSL protocol, which is integrated in most browsers,
is frequently used for this purpose (see Section 5.9).
When SSL is used, a customer must know and be able to assess a large number of different
parameters, as only when they work together correctly can the desired security be guaranteed.
Unfortunately, many banks do not even indicate on their Internet sites all the security
measures they have implemented, but provide only a few general statements on security which
are often difficult to find.
SSL was therefore intended only to be used as an interim solution. For Internet banking, HBCI
is recommended with a smart card solution (see HBCI chapter).
2.4.5 Telebanking
The terms telebanking and teleshopping refer to the execution of banking transactions, the
ordering of goods or the making of travel bookings over the television set. They are closely
related to the term interactive television.
The television set must have a computer-
supported connector, which the user controls
using a remote control device and which
contains a return channel. A separate device
or set-top box can be used, or alternatively
this will be fully integrated in television sets
of the next generation. A connector such as
this should enable users in the future to interactively use a wide range of novel services such
as video on demand, telebanking or teleshopping.
Telebanking /
Teleshopping

BSI Page 15
The target public here is the large majority of people who are less interested in technical
matters. In particular, the idea is to reach for the first time a mass market which extends
beyond the group of PC specialists. Currently around 10% of German households have access
to online services. Although the trend is moving sharply upwards, it will be some time before
a networking level comparable to that which currently exists for televisions is attained.
Simple variants of teleshopping are already possible today, for example, via special
promotional broadcasts or teletext offers intended to encourage customers to place orders by
phone. The following points should be noted in connection with teleshopping:
- Customers should familiarise themselves with the contractual conditions prior to
ordering, especially as regards their rights to exchange or return goods, delivery
charges and similar. Articles should only be ordered when the customer is assured of
the right to return the goods. Customers should insist that goods are only paid for after
an invoice has been received and, if possible, not until the goods have been delivered.
- If several payment methods are possible, the customer should choose a method which
does not entail sending personal data such as credit card numbers in plaintext over the
network.
- In the event that the product delivered is defective, the same rights apply to goods
purchased within Germany as to any other purchase. The customer can demand within
the 6-month period specified in the German Civil Code that the goods are replaced by
fault-free goods, obtain a reduction on the purchase price which reflects the defects or
cancel the purchase and demand a refund.
- When ordering, customers should note down the address of the supplier, the exact
designation and price of the article and the specific details contained in the commercial
or online presentation.
International suppliers generally only accept payment by credit card. This requires that the
name of the cardholder, the number and expiry date of the credit card and the name of the
credit card organisation are notified to the supplier. When this data is relayed over the
telephone or over a data network there is always a certain risk that it will be intercepted and
misused. However, there are many other opportunities for an imposter to obtain this
information, for example when a customer hands over his card in a shop or restaurant in order
to make a payment or when the customer carelessly leaves the transaction voucher behind.

Threats Associated With Electronic Commerce Security Considerations with Electronic Commerce
Page 16 BSI
3 Threats Associated With Electronic Commerce
E-commerce entails the use of the Internet, a public network which was not developed for the
transmission of sensitive information. The question of how payments can be made securely
over the Internet is very much in the foreground, along with other security issues.
Payments over public networks like the Internet are characterised by the fact that the payment
is made purely electronically through the exchange of information. During such transactions,
this information can be exchanged between several parties: customer - customer's bank,
customer - vendor, customer - intermediary, vendor - vendor's bank, vendor - intermediary.
If one assumes that the Internet, as a network open to all, uses switching nodes which
essentially are unprotected, then the following threats must be considered for all
communications links:
- Loss of confidentiality of the transmitted data, for example through interception of
the communication. In particular, passwords used to obtain authentication or other
confidential data such as the originator, recipient, amount of the payment etc. can be
intercepted.
- Loss of integrity of the transmitted data, for example, due to bit errors which are
attributable to technical defects, or are the result of intentional manipulations. In this
case, payment amounts or recipients of payments can be manipulated so that a third
party benefits financially.
- Loss of availability of transaction data. This could be due to force majeure such as a
network failure, network interruption or transmission error, or it could be the result of
deliberate manipulation by third parties.
- Replay of old transaction data, for example, an attempt could be made to repeat a
payment by copying the data and reusing it.
- Denial of payment or order, for example, the recipient of the money can maintain
that he has not received it.
- Masquerade, for example, a perpetrator could pretend to be a particular vendor and
divert the payment to his own benefit. But the customer himself could assume a false
identity and make an invalid payment which the dealer would not actually receive.
- Fraud. Instead of attempting to manipulate an existing WWW server, a perpetrator
can create his own website on the Internet and design it in such a way that visitors have
the impression of being connected with an established, reputable institution. A
perpetrator can also attempt to pass himself off to vendors as a respectable customer
even though he is not solvent.

Security Considerations with Electronic Commerce Threats Associated With Electronic Commerce
BSI Page 17
But it is not just on the data transport route, the open Internet, that threats are to be expected.
The connected computers are also threatened, and here the perpetrators may not only be
outsiders on the Internet, but insiders. Some of the major threats are described briefly below:
- Attacks from outsiders, for example, a perpetrator could attempt to penetrate the
supplier's server over the Internet by exploiting security weaknesses. He could then
manipulate payment transaction data or delete such data.
- Attacks from insiders. For example, an aggrieved employee of the supplier could
obtain access to the server and then misuse the stored data. Similarly, a person in the
customer's family environment could misuse the customer's computer for the purpose
of ordering goods at his expense.
- Sabotage. For example, either an outsider or an insider could attempt to sabotage the
supplier's server by systematically overloading the server (denial of service attacks) so
that he is forced to discontinue the service.
- System failure. For example, the server could fail due to a technical defect. This
would mean that neither customer nor vendor could utilise its services. Similarly the
storage media on which the cryptographic keys or cash value bit strings are stored
could fail so that the information is lost.
- Computer viruses. These can, for example, delete stored data or manipulate actual
payment data.
- Loading of uncontrolled software from the Internet. For example, while surfing on
the Internet, executable software can be loaded onto the user's computer (ActiveX
controls or Java applets). This software can be systematically created for the purpose
of collecting user passwords and then manipulating existing payment programmes or
hardware for the purpose of generating counterfeit payments. (However, due to
internal security measures, the danger from Java applets should be considerably lower
than with ActiveX applications.)
With e-commerce, a number of additional points have to be borne in mind which do not apply
in the case of pure electronic money systems. These include: copyright, product liability,
delivery guarantee and issues relating to obtaining redress.
3.1 Survey of possible threats and dangers
Many dangers are capable of affecting all the parties involved in an e-commerce system,
whereas others affect only one party. When one considers the potential threats, these can be
classified in different ways. Starting from the basic values which IT security measures are
aimed at safeguarding, i.e. confidentiality, integrity and availability, one can consider how a
loss in any of these basic features could be caused in relation to the different phases of an e-
commerce transaction (providing/obtaining information, reaching agreement, delivering
goods/services, after sales). This produces a quick overview of the potential dangers, such as
is presented in the following table by means of a few examples.

Page 18 BSI
Confidentiality Integrity Availability
Information Competitors obtain
access to internal
information.
Perpetrator manipulates
(spoils the look of)
website.
Perpetrator diverts
customers to his own
website by
masquerading as
someone else.
Agreement Passwords, amount of
payment, types of goods
are disclosed.
Prices or orders are
manipulated.
Denial of service attack,
system failure, ordering
or payment not possible.
Delivery Third party learns
customers' shopping
habits.
Goods are damaged. Goods are not delivered
or only after a long
delay.
After sales Competitors learn
reasons for complaints
and frequency.
Customers exchange
goods which they have
not received from the
dealer.
There is no after sales
service, customers are
unsatisfied.
Many threats and dangers do not fit easily into the above analysis. For example, are disputes
about receipt of payment a problem of confidentiality, integrity or availability?
Moreover, the nature of the danger depends on whether it concerns a single workstation at the
customer's or the bank's computer centre. We shall therefore start by considering the dangers
which affect the technical components used by the individual parties before then considering
dangers in data communications, payment procedures, cryptography and other areas.
The set of dangers and threats presented below does not claim to be complete, but rather to
provide an overview of the diversity of potential dangers in the various areas and to draw
attention to the resulting need for action. For the sake of clarity, the different types of danger
are simply listed at this point. A more detailed description of the dangers will be found in the
appendix.
Dangers relating to the technical components
- Loss of confidentiality of the IT system access code
- Manipulation of software in components
- Weaknesses in the hardware or software
- Defective components
- Loss of stored data
- Manipulation of stored data
- Inconsistency of stored data

Security Considerations with Electronic Commerce Threats Associated With Electronic Commerce
BSI Page 19
- Theft of components
- Loss of information where storage medium is exhausted
- Duplication of monetary units
- Denial of service
- Inadequate separation of users
Dangers in the area of data communication
- Replaying old messages
- Tapping of communications
- Masquerading as an authentic communication partner
- Masquerading as a trustworthy communication partner
- Unauthorised changes to messages
- Transmission errors
- Repudiation of a message
- Redirection of messages
- Misuse of remote maintenance accesses
- Inconsistencies due to faulty execution of transaction
Dangers in the area of payment transactions
- Faking of transactions
- Creation of customer profiles
- Money laundering
- Insolvency
Dangers in the cryptography area
- Discovery of cryptographic keys
- Insecure encryption methods
- Insecure hash functions
- Defective random number generators
- Reuse of test keys after system is productive
- Insecure key generation and relay
- Weak cryptographic keys
- Loss of stored keys
Other dangers
- Inadequate control of IT security measures
- Access of unauthorised persons to premises requiring protection
- Unauthorised exercise of rights
- Inadequate or missing catastrophe/contingency planning
3.2 Summary
An e-commerce system faces a large number of threats. Some of these are obvious, others are
concealed within a specific implementation, while still others can only be understood by
experts. This means that attacks can be directed on a system from many different directions.

Page 20 BSI
It should be borne in mind that many of the threats and hence the security measures required
also depend on the size, type and reputation of the company running the e-commerce
operation. A small or medium-sized company typically uses standard software for its Internet
presentation, whereas a large organisation will develop its own software or modify existing
software to suit its particular purpose. When security weaknesses occur on standard software,
these rapidly become public knowledge. Servers using standard software can therefore be
attacked by many people because this does not require much in the way of intellectual effort.
Proprietary software statistically contains just as many errors; the difference is that in this case
the perpetrator has to find out about them himself. The motivation behind attacking a server
which uses proprietary software is therefore different, e.g. the "reward" is the value of the
information believed to be held on the server or the fame and glory which is expected to result
from a successful attack.
Which type of action is required to counter the various threats faced by a given electronic
money system or e-commerce system depends on
- the expected likelihood of security breaches,
- the damage which could be caused by the breach,
- the amount of effort required to execute such an attack,
- the likelihood that the perpetrator will be detected.
Of course the degree of security perceived as being required will depend to no small extent on
the financial context. How much security is appropriate and what security measures need to be
implemented to achieve that degree of security depends amongst other things on how big the
payments are, the types of goods offered (tea / computers and accessories / digitised images
etc.) and what is known about one's customers (regular customers or chance customers /
known delivery address etc.). In the final analysis, the level of security which a company aims
for is always a question of cost-benefit ratios, i.e. the extent to which the resulting measures
will pay for themselves.
On the other hand one should remember that 100% security is not feasible. Even with the best
possible security measures, there will always be residual risks with e-commerce, just as there
will always be shoplifters as long as customers are allowed inside a shop. Therefore one
should aim to be able to deal both with all currently known threats and also with new threats
as they become known. If the public is deterred by hearing about threats or even successful
attacks, those responsible must have answers and alternative courses of action ready.

Security Considerations with Electronic Commerce Security Requirements
BSI Page 21
4 Security Requirements
The security requirements of e-commerce systems can initially be divided roughly into three
areas:
1. Protection of communication
2. Verification of the identity of the communication partners
3. Security of the components
4.1 Protection of communication
To protect communication in e-commerce systems, the following security objectives must be
achieved:
- Manipulation of the data transferred, especially in the areas of ordering, payment and
delivery, must be detected, and transactions must be rejected where manipulation has
occurred.
- The confidentiality of the data transferred, especially person related data and data
relating to the payment transactions, must be guaranteed.
- It must not be possible for old transaction data to be reused.
- It must not be possible to deny that order, payment or delivery has taken place.
The following measures can be used to achieve these objectives:
- Assurance of integrity. To ensure that the data transmitted has not been distorted
either by chance or intentionally, a cryptographic checksum can be assigned to it. This
can be effected, for example, using MACs (Message Authentication Codes), hashing
or digital signatures.
- Encryption. Both symmetric (e.g. DES, IDEA) and asymmetric (e.g. RSA, elliptic
curves) cryptographic techniques can be used to guarantee the confidentiality of the
data transmitted.
- Receipt. If the sender wishes to be able to prove that he has transferred money to the
recipient over the Internet, then the sender needs a receipt from the recipient which
will serve as conclusive evidence to the effect that the payment has been received. One
way of achieving this is, for example, for the recipient to generate a hash value from
the received data, sign this digitally and send it back by way of receipt. Under this
procedure, the sender can prove that the receipt comes from the recipient and that he
could only have generated the receipt through knowledge of the data transferred, i.e.
the recipient must have received the data correctly.
- Prevention of replay. Dynamic keys, transaction numbers and time stamps can all be
used to ensure that replayed messages can be detected as such and rejected.

Security Requirements Security Considerations with Electronic Commerce
Page 22 BSI
4.2 Verification of the identity of the communication partners
Another important point for the security of e-commerce systems is the verification of the
identity of the communication partners. In open networks such as the Internet one cannot rely
on a name being entered correctly; one cannot assume that the company located at the URL
www.xy-bank.com will necessarily be the XY-Bank. Hence, mutual authentication of all
system components must be guaranteed.
The normal procedure used here is a Challenge-Response procedure. The principle by which
person A authenticates himself to person B (i.e. computer A to computer B), runs as follows.
B has knowledge of a characteristic of A which only A possesses. For example, this can be a
symmetric key which is known only to A and B or the fact that person A knows the secret key
of an asymmetric encryption system, and person B has knowledge of a certificate containing
the corresponding public key.
As an initial step, B sends A a newly selected random number. A then processes this random
number with his secret parameter and sends the result back to B. B refers to his own
information in order to check whether the random number he had previously chosen is
contained in the answer. If it is, then B knows he is really communicating with A as only A is
in possession of the necessary secret information.
4.3 Component security
Suppliers of e-commerce services on the Internet must bear in mind that the risks to which
they are exposed are quite different from those of a user. A supplier has to operate a server
which is known on the Internet and is always available. This server can be subject for an
attack aimed at inflicting damage on the supplier. The supplier must therefore provided
?
"On the Internet, no one can tell that you are not
what you purport to be."
Nicholas Negroponte

BSI Page 23
offensive protection to his computers, whereas the customer can generally adopt a defensive
posture.
As supplier, the following protection objectives must be achieved:
- The service and the server which makes that service possible must always be available;
only short downtime can be tolerated.
- All activities executed on the server must have a complete audit trail permitting
traceability.
- Misuse of the server either by internal or external perpetrators must be ruled out.
- The integrity and confidentiality of the data processed must be guaranteed.
Achieving these protection objectives requires a number of measures which cannot be fully
described here. The most important measures are outlined below:
- Use of a firewall. An e-commerce supplier's server can be configured so that it is
inside the supplier's internal network, in a screened subnet or on the external side of
the firewall. A screened subnet is a subnetwork which is interposed between a network
requiring protection and an external network in which the connections and data
packets are monitored and filtered by firewall components. In order to be able to
guarantee the security of both the supplier's server and the internal network, the server
must lie beyond the firewall and be viewed like other server in the external network. It
should be administered either locally or else via special accesses at predefined times
from the protected network.
In this connection the reader is referred to the IT Baseline Protection Manual issued by
the BSI (Federal Agency for Security in Information Technology). This book contains
initial suggestions and recommended measures as to how to secure a Unix or Windows
NT server and what limiting conditions should be considered when selecting and
operating a firewall (see [GSHB]).
- Access control. It is essential to the secure operation of every server that access rights
for rooms, computers, and data are used in a restrictive way. Only the administrators of
an e-commerce server should have access to it. Care should be taken here to ensure
that complex passwords which are difficult to guess are used, and that predefined
passwords are changed.
- Restricted server operation. The server should have a secure operating system.
Amongst other things, this means that it only offers the services which are necessary to
handle the Internet payment transactions. The fewer programmes a perpetrator finds on
a target computer, the more difficult it is for him to find and exploit other weaknesses
on the target computer. This also significantly simplifies the task of maintaining a
server. In particular, all other network services which are not actually necessary should
be disabled. At the same time, extra security programmes should be installed on the

Page 24 BSI
server unless these are already part of the operating system. An integrity check
programme and a software packet filter are recommended, also additional software for
detecting viruses and analysing the log entries.
- Fail-safe systems. The supplier's server should if possible be available 24 hours a day.
This means that the server can be used on the Internet and also that completed
financial transactions are processed immediately in the supplier's domain, generally on
internal computers "behind" the server. The possible dangers which must be
considered here include both technical defects and sabotage, and also attacks from the
Internet aimed at blocking the server (e.g. SYN flooding). It is possible to protect
against technical faults by installing redundant systems. In the case of deliberate
attacks which cannot be excluded, the system must behave intelligently so that attacks
are detected either automatically or manually and countermeasures are initiated.
- Hardware security. Because the server has to manage and store securely a number of
cryptographic keys and, as a server, to execute many cryptographic operations, it is
recommended equipping the server with either partially or fully autonomous
cryptographic hardware. This is especially effective as a form of protection against
misuse by internal perpetrators and also against hackers.
- Contingency planning. A payment transaction server on the Internet can be subject to
different kinds of emergency. For example, the server could fail due to technical
defects, user error could cause loss of data or sensitive changes to system parameters,
or the server could be manipulated by perpetrators. But it is also conceivable that the
application software will prove to have critical security weaknesses so that corrective
action must be taken to prevent misuse.
Preventive measures can be taken to avoid technical failures. These include, for
example, designing redundancy into the server or installation of an uninterruptible
power supply. Furthermore, the supplier must have drawn up advance solutions for
expected types of emergency which can be implemented in the short term. Here it is
important to have drawn up an alarm plan and an contingency concept.
- Security audit and audit trail. The activities of the administrative personnel,
successful and failed logon attempts by users and transaction data must all be logged.
This logged data should be checked at regular intervals to determine whether any
irregularities have occurred in the administration or whether any attempts have been
made to attack the system over the Internet. Where a customer's transaction was
interrupted, it is also possible to clarify from the logged data the status of the
transaction at the point where it was interrupted.
- Suitable personnel. The personnel entrusted with supporting the server and the series-
connected systems must satisfy stringent requirements. In particular, if the danger of
internal perpetrators is to be reduced, they must be extremely trustworthy. Staff must
also be adequately trained and be kept up-to-date with the latest developments in IT
security through continuous further training.

BSI Page 25
4.4 Protection of the user
The customer of e-commerce systems does not expect that use of such systems will expose
him to any security risks. He cannot be assumed to have a deep understanding of security risks
and measures. He wants to be able to surf on the Internet without any restrictions, but
normally he will be unaware of all the dangers and security measures. The customer is of
course responsible for his computer and its IT security, but here he should receive support
from the supplier of an e-commerce systems.
- The parts of the system which are installed on the customer's computer must have an
adequate degree of security.
- The system must be simple to operate so that no user is forced to call in a third party to
assist with security related sub-steps.
- All transactions (orders, payments etc.) must be evidential and counterfeit-proof.
- The system should provide protection against loss and be tolerant of errors. Neither
system failures nor interruption of a connection should result in pecuniary loss to the
customer.
- The system should already be designed so that the customer is assured data protection.
It should enable transactions to be largely anonymous and only pass on a minimum of
information about the customer.
Even when, as is often the case, electronic money systems use the catchword anonymity, this
does not necessarily mean that payments are completely anonymous. Often anonymity merely
means that the retailer cannot read the customer's account details while the bank does not have
access to the ordering information. The vendor must not be able to identify the individual
customer unless he needs a delivery address; he must simply be able to check the customer's
ability to pay. However, there are also systems which can successfully ensure that the bank
can neither detect the denomination of the amounts spent nor trace what happens to the
amounts spent after they have been debited to the smart card.
4.4.1 Customer hardware and software
The security level necessary for electronic money systems usually cannot be achieved by
software alone. If an electronic money system requires that sensitive data such as
cryptographic keys, PINs or virtual money is stored at the customer's, additional hardware
which is resistant to attack should be made available to the customer. This could take the form
of a smart card, for example. Smart cards offer the additional advantage that customers can
make purchases online not only from their homes but also from alternative locations.
As a first step, procedures which provide customers with more security than they have
enjoyed in the past should be developed, i.e. as a minimum, the transaction data should be
transmitted securely. The example of credit card payments over the Internet shows the
direction in which electronic money methods need to develop: starting with an end to insecure

Page 26 BSI
payments over a secure communication channel (SSL) there must be a progression from
methods which secure all components simultaneously (SET) to the use of hardware
components for all security-relevant tasks (C-SET).
The customer hardware and software should guarantee the following security requirements:
- It must not be possible for payments to be effected without the consent of the
customer. This consent can be implicit through the input of a password, use of a
biometric "fingerprint" or a smart card. This will prevent unauthorised access from the
customer's environment, among other things.
- It must not be possible for harmful programmes such as computer viruses or Trojan
horses to make changes to payment transactions. In particular, it must not be possible
for software downloaded from the Internet to manipulate or execute payment
transactions unnoticed by the customer.
- A system crash must not result in any pecuniary loss. The product should provide a
simple means of backing up payment-relevant data.
- Confidential information relating to payments, for example, passwords, PINs,
transaction numbers and cryptographic keys, must be stored securely so that only the
authorised customer can access them.
- During processing of payments, the customer must not be misled about the monetary
value of a transaction. Integrity of the data must be preserved.
- All transactions should be recorded in a way which enables them to be traced.
To achieve these objectives, the supplier of an electronic money system or e-commerce
system must implement a number of measures at the outset:
- Provision of a suitable product. In the case of software products, the customer must
observe a large number of security-related configurations and procedures. If he
receives a hardware add-on as well, then the cryptographic keys and cash value
information can be securely stored on this in a portable manner.
- Quality assurance of the product. Just as precautions must be taken on the supplier
side, the products customers use must also be investigated independently as to the IT
security they provide. ITSEC certification is recommended here. This means that the
customer can be sure he is using a product which is sufficiently secure and has been
properly tested.
- Product-specific education of the customer. The customer should be provided with
documentation which contains full information regarding any security aspects which
need to be observed when payment transactions are processed using particular
products. This must also include advice as to how to operate a browser securely and
the recommendations that executable programmes should not be downloaded from the

BSI Page 27
Internet and that the use of ActiveX should be avoided. The user should be informed
of the risks associated with the handling of passwords and cryptographic keys.
- IT system-specific education of the customer. As many customers do not know what
IT security measures are necessary for their computers, the supplier should supply
information on this topic to the customer. This could, for example, comprise IT
system-specific extracts from the BSI's IT Baseline Protection Manual [GSHB].
4.4.2 Codes of practice for customers
The risk must be transparent to customers. They must know how they should conduct
themselves in order to avoid incurring any loss through the use of electronic money or e-
commerce systems.
To this end they must implement some measures in order to be able to make purchases or
operate home banking securely over the Internet.
- Compliance with the security recommendations. The customer should heed the
information and security recommendations provided by the supplier. If these are not
clear enough, the customer should ask for information which is easier to understand or
more detailed, or read up about it in another place.
- Data backup. The customer should make regular backups of his data, especially of
finance-related data. This will ensure that he is able to continue working despite
technical problems or wilful damage induced through harmful programmes.
- Avoidance of computer viruses. Customers should always ensure that their
computers are protected against computer viruses, Trojan horses and dubious software.
This includes not using executable programmes of unknown provenance.
- Secure storage of means of access. Means of access such as passwords, PINs, TANs
or smart cards should be stored in a secure place. If possible they should not be stored
on the IT system. If they are documented or copied, this information should be stored
under lock and key.
4.5 General security requirements
When designing an e-commerce procedure, steps must be taken to address a large number of
dangers. This requires that a number of quite different security measures are implemented. To
ensure that these do not conflict with each other, the system operator must see to it that all the
security measures are included in a comprehensive security concept.
This security concept must consider a number of individual components as well as the
interaction of these components, extending from the issue of security against counterfeiting of
electronic money through to key management. Depending on the nature of these individual
components, measures addressing organisational, personnel, infrastructure and technical

Page 28 BSI
issues must be taken to achieve the desired security objectives. The following points are
relevant here:
- Good cryptography
Only cryptographic algorithms which are strong enough both for today and to cope
with likely developments over the next few years should be used. Hence, for example,
instead of using single DES, triple-DES should be used. If RSA is used, key length
should be at least 768 bits, or, better still, 1024 bits.
- Control mechanisms
The system must contain control mechanisms enabling attacks (e.g. duplication of
units of value) to be detected early in order that appropriate countermeasures can be
taken. Once again, data protection aspects must be considered. The control
mechanisms deployed must not allow customer profiles to be generated.
- Customer hardware and software
To use electronic money systems, customers must be provided with both hardware and
software. Both components must provide an appropriate level of security. If the
electronic money system concerned requires that sensitive data is stored by the
customer, this should be stored on attack-resistant hardware such as smart cards or PC
cards. The software should have a built-in test function barring modification by Trojan
horses or viruses.
If cash value information is stored on the customer's PC, it must not be possible for a
system crash to result in pecuniary loss.
- Confidentiality of security-relevant information
All security-relevant information must be reliably protected against manipulation and
unauthorised access. Security-relevant information includes PINs, cryptographic keys,
credit card numbers and messages ordering or paying for goods. This data must be
adequately protected in all the system components, i.e. not only during transmission
but also on all the IT systems involved.
When developing electronic money systems, it should be borne in mind as early as at
the design stage that security-relevant information is simpler to protect on a central
bank system than on a multitude of customer and vendor systems.
- Independent security investigations
Achievement of the security objectives requires not only that suitable measures are
selected but that they are implemented carefully and that the implementation is then
reviewed thoroughly and at regular intervals. It is especially important that these
checks are exercised using independent parties, simply to allow an objective view to be

BSI Page 29
taken. Experience shows that specifications for highly complex e-commerce
applications often contain flaws, even when they are produced by recognised experts.
The earlier such errors are detected, the easier they are to rectify.
Security studies do not necessarily have to be based on formal criteria such as the
ITSEC (see [ITSEC]) or the Common Criteria (see [CC]), but they should be carried
out by independent, experienced IT security experts. Nevertheless, investigations
which are based on the ITSEC or Common Criteria do relieve users of the potential
problem of comparability of the results obtained for different products.
The report produced by the Committee on Payment and Settlement Systems and the IT experts
of the central banks of the G10 countries, "Security of Electronic Money", provides a good
overview of security requirements for electronic money systems (see [BIS1]). Security
requirements are discussed in Chapter 4 of that document.
Security is always of a temporary nature. What passes today as secure may well no longer be
secure next year. It is always necessary to be equipped with the latest technology.
Not all systems are geared towards maximum security from the start. Often the introduction of
new procedures is intended merely to replace outmoded, insecure procedures and, for
financial reasons, only the first step is taken towards achieving the best possible security. In
the continued development of security mechanisms it is important that procedures are
designed from the outset so that improved security features can be added on without causing
any problems. Sometimes the act of retaining compatibility to old systems can open up
potential security weaknesses. Care must be taken to avoid doing this.

Examples of Electronic Money Systems Security Considerations with Electronic Commerce
Page 30 BSI
5 Examples of Electronic Money Systems
When considering electronic payment transactions, a distinction must be made between
electronic banking and electronic money. Electronic banking refers to the processing of
banking transactions, e.g. home banking, while electronic money refers to payment for goods
or services over networks.
Electronic payment systems fall into a number of categories:
- payments via customer accounts or direct settlement with the provider in closed online
services,
- electronic direct debit systems,
- credit card-based systems and
- systems which utilise virtual money.
5.1 SET
The Secure Electronic Transaction (SET) system was developed jointly by Visa and
MasterCard. With SET, the predecessor protocols SEPP and STT, which were put forward by
consortia consisting of MasterCard, Cybercash, GTE, IBM and Netscape (SEPP) and Visa and
Microsoft (STT), were discontinued.
SET provides a means of protecting credit card transactions effected over insecure networks
such as the Internet. In SET, both symmetric and asymmetric cryptographic procedures are
used in addition to hashing to protect the information transferred. SET is intended to
simultaneously protect financial transactions from the eyes of unauthorised persons and from
manipulation and also to enable participants to be identified as business partners.
In order for SET transactions to be executed, both the customer and the vendor must be
registered with a SET certification authority. Following registration, both customer and
vendor receive a private signature key and a certified public signature key.
With the development of SET, an attempt was made to transfer credit card payments from the
real world to the virtual world. A customer of bank A can make purchases using a SET
certificate from a vendor of bank B which has a SET certificate. A cardholder’s certificate is
comparable in function to a credit card, while the vendor’s certificate is similar to the credit
card logo which appears by the door of a shop.
The end customer normally receives the certificate from his bank (the "issuer"), while the
vendor receives his certificate from the financial institution with which he has a relationship
(the "acquirer"). By analogy to "real world" transactions, a certificate is needed for each credit
card company accepted by a vendor in payment for goods or services purchased by an end
customer (plus in addition the bank must hold a certificate for the Payment Gateway which
acts as the interface between the Internet and the banking world).

Security Considerations with Electronic Commerce Examples of Electronic Money Systems
BSI Page 31
Transactions using SET
The SET specification can be retrieved on the Internet. It is divided into three sections:
Business Description, Programmers' Guide and Protocol Description. The "Business
Description" section provides a good overview of all the functionality of SET.
In order for a customer to use the SET procedure, as well as a credit card and the
cryptographic keys he also needs the electronic wallet or "SET wallet" software which guides
him through the individual steps involved in a SET transaction.
If a customer then wishes to order goods from an Internet vendor who accepts payments using
the SET procedure, first of all he needs the vendor's certified public key. This he uses to verify
the reply of the vendor's system to his order request. Once this key has been passed to him, the
customer generates a session key so that he can then symmetrically encrypt the customer
information (order and payment data). The message sent to the vendor contains the session
key encrypted with the vendor's public key as well as the customer information. This message
is hashed and digitally signed using the customer's private key.
SET
Credit card
company
Customer Vendor
1. Initiate payment
2. Payment confirmation
3. Vendor forwards order
and payment information
4. Checking by gateway
5. Checking by credit card
company
6. Results of authorisation
check
7. Confirmation of
purchase
8. Invoicing
2.1.
3.
4. 8.
7.
6.
5.
Payment
Gateway
6.

Page 32 BSI
The vendor's system decrypts and checks the received message, and, assuming that everything
is in order, the payment request is forwarded to the credit card company and an encrypted
message is sent to the customer confirming the order.
Because the order and payment information is kept separate, the customer retains partial
anonymity. The order information can only be evaluated by the vendor and the payment
information only by the credit card company. In this way only the vendor receives the detailed
information about the goods ordered and only the credit card company receives all the
information about the purchaser and his credit card account. Both sets of information are
signed separately by the customer but they are linked together with a dual signature. This
entails the hash values for both sets of information flowing into the digital signature of each
partial set of information.
In order for SET transactions to be executed, both the customer and the vendor must be
registered with a certification authority. Within the framework of SET a hierarchy of different
certification authorities exists. As SET is designed for international use, this hierarchy is quite
complex.
SET certificate hierarchy
Root
(SETCo)
VISA Brand XMastercard
Issuer Acquirer Groups Payment
GW CA
Card-
holder
Vendor Payment
Gateway
Tasks of SETCo:
1. Generate the SET root keys
and store them securely
2. Generate and sign SET
root CA certificate
3. Process brand certificate
queries and generate
(credit card) brand
CA certificates
4. Generate and distribute
certificate revocation
lists (CRLs)

BSI Page 33
The uppermost certification authority, i.e. the "root", is SETCo. At the next level down in the
hierarchy are the certification authorities used by the credit card companies, for example, Visa
or MasterCard. Further down still are the certification authority for customers (the issuer) and
the certification authority for vendors (the acquirer). An additional hierarchical level can be
implemented to accommodate country-specific requirements, e.g. Visa Germany (as group
members).
SETCo is also the certification authority for all products which claim to be SET-compatible.
Only after a product has passed a conformance test may the SET logo be used. The SETCo
home page displays a list of products already approved.
5.1.1 Sequence of steps involved in a SET payment
Selection
The customer selects the goods or services from which he wishes to make a purchase on the
vendor's website. He chooses to pay for the order with SET. The customer's SET wallet
software is started. This must be authorised by entry of his password. The invoice amount is
then displayed to him in the SET wallet.
Payment initialisation (payment initialisation request/response)
The customer chooses one of the credit cards available in the wallet. The keys and certificates
required for transactions using this credit card are then exchanged in the background with the
vendor's server.
Payment confirmation (purchase order request/response)
The customer checks the invoice and confirms the payment. The certificates of the vendor and
the SET Payment Gateway are now checked. If everything is in order, the customer knows
that he is dealing with an authentic partner of the financial institution. A message containing
the order and payment information (Order Information - OI / Payment Instructions - PI) is then
created. Both parts of the message are now signed separately by the customer wallet. The
payment information is then encrypted with a randomly selected symmetric key which is
added to the account information encrypted with the public key of the Payment Gateway. The
message with both message parts is now sent to the vendor.
Vendor's authorisation request (authorisation request/response)
The vendor's software starts by checking the certificate of the cardholder (customer) to ensure
that the cardholder is genuine. The signature of the ordering information is then checked and
an authorisation request containing the customer's payment information and his certificate and
the vendor's payment information is sent to the SET Payment Gateway.
The vendor's payment information is signed with his private SET key and encrypted using a
randomly generated symmetric key, which in turn is appended to the message encrypted with
the public key of the Payment Gateway. The message containing the vendor's (certificate for

Page 34 BSI
signature key and for key exchange key) and customer's certificates is then sent to the SET
Payment Gateway in the form of an authorisation request.
Verification by the SET Payment Gateway
The SET Payment Gateway verifies all parts of the message and checks that the payment
information agrees.
Assuming that these checks are completed successfully, the SET Payment Gateway now
forwards the currency, the amount and the credit card number of the purchaser (from the
certificate) to the authorisation host for further processing.
Checking by the authorisation computer
The credit card organisation's authorisation computer checks that a valid contract exists with
the vendor, the card is not blocked and the card limits are not exceeded.
Authorisation results
The result of the authorisation process is sent back to the SET Payment Gateway, which in
turn notifies the vendor's server of the result.
Confirmation of purchase
Once the purchase has been authorised by the SET Payment Gateway, the purchaser is
informed that the purchase is going ahead. Otherwise, the cardholder is informed of the reason
why the transaction has been rejected. The customer's SET-wallet checks the correctness of
the vendor's reply and logs the transaction. As far as both the customer and the vendor are
concerned, settlement then proceeds via the credit card company as is normal for other credit
card payments, with a time delay.
5.1.2 C-SET
C-SET stands for "chip-secure electronic transaction" and is an extension of the SET payment
protocol to include the use of smart cards as a customer security module. A pilot study of C-
SET is being carried out by the Cartes Bancaires group in France.
With C-SET, the SET protocol is extended to include extra physical security mechanisms.
These include smart cards, secure smart card readers and so-called "electronic commerce
black boxes".
The smart card readers contain a numeric key pad, a display and some dedicated software
including an RSA module, enabling signatures to be generated and verified. The software can
be downloaded in encrypted form. Self-testing of the software is carried out at regular
intervals. In this way, the security of card processing is independent of the security of the
customer's computer.

BSI Page 35
The "electronic commerce black boxes" are hardware crypto modules which are based on
security boxes used by French banks.
The use of smart cards under C-SET provides users with a secure, yet simple-to-use medium
for storing all security-relevant information which is both portable and easy to store securely.
This means that customers can access the World Wide Web not only from their homes but
also from Internet cafés. With the increasing requirement for secure transactions over the
Internet, smart card readers will soon be a standard feature on PCs.
5.1.3 Features of SET
T Post-paid (credit card-based).
D Divisibility not relevant.
A Partially anonymous.
S Less suited to small payments due to the complex protocol (and also to the
charges per transaction).
M Smart card can be used anywhere, pure software variant more difficult.
O Designed for online operation, but can also be used offline to some extent.
Sp Suitable for spontaneous purchases, provided the credit cards are widely used.
N Relaying only through intermediary.
G International, based on conventional means of payment
5.2 ecash
ecash is the payment transaction protocol of the DigiCash company, under which digital coins
are exchanged over the Internet. ecash is closely related to the CAFE smart card payment
system also developed by David Chaum. In Germany the ecash system is offered by the
Deutsche Bank.
As with electronic purses and stored value cards, the customer receives "electronic coins" in
return for an upfront payment. These coins can then be used on Internet to purchase goods. An
account is created for the coins with a digital bank, and the customer can withdraw and pay in
his "electronic coins" at this bank. The customer is provided with the software needed to
operate ecash, and this he uses to store and spend his money.
When the customer withdraws "electronic coins", i.e. downloads them onto his PC, his
software first of all calculates how many coins are required in what denominations. ecash
coins are not divisible but have a fixed unit value. They can be denominated in all powers of
2. Thus, for example, with a basic value of one penny, it is possible to have coins for 1, 2, 4,
8, 16 and 32 (=20
, 21
, 22
, 23
, 24
, 25
) pennies. Serial numbers are then calculated for these coins
and a so called "blinding factor". The calculated information is then passed to the bank.

Page 36 BSI
The bank signs this information (encrypts it with the secret key), debits the equivalent amount
to the customer's account and sends the signed coins to the customer. The customer now
removes the blinding factor and has the signed serial numbers as "electronic coins". He can
now use these coins as a means of payment with any vendor who accepts ecash. When a
payment is made, the customer's ecash application transfers the appropriate number of ecash
coins in encrypted form to the vendor's computer.
The bank maintains a database of all coins already issued, identified by their serial numbers.
When an ecash payment is effected, the vendor forwards the ecash coins to the bank which
checks on its database that the ecash coins tendered are genuine, i.e. cryptographically correct,
and have not already been spent. Once the coins have been validated, the amount is credited to
the vendor. The vendor then forwards the results of the bank's validation procedure to the
customer and, assuming that the coins have been validated, he can hand over the ordered
online goods at the same time.
The anonymity of the customer is retained during the payment, i.e. as is the case with cash
transactions, the bank cannot trace the path of the money from the vendor to the customer.
5.2.1 Procedure
ecash is based on the asymmetric RSA encryption algorithm. When the customer opens his
ecash account, he receives from the bank two kinds of public keys. One kind is used to
encrypt messages to the bank, and the other to generate "electronic coins". The electronic
coins are digitally signed by the bank using RSA, thus guaranteeing the authenticity of the
coins.

BSI Page 37
5.2.2 Blind signatures
One of the basic features of ecash is the use of "blind signatures". Blind signatures make it
possible to largely preserve the anonymity of the parties involved while at the same time
ensuring that if the same data is submitted twice the person responsible can be identified.
When the customer withdraws "electronic coins", his ecash application first of all calculates
how many coins are required in what denominations. Then for each new coin, two random
numbers are generated: the first is a serial number and the second is a "blinding factor".
Using the public key of the bank and starting from the serial number x of the coin to be signed
and the blinding factor r, the customer's software generates the message x*re (mod pq),
addressed to the bank, where e is the public key of the bank, d is the private key and pq is the
public modulus. The calculated information is then passed to the bank.
- The bank signs this message "blind" - (x*re)d = r*xd (mod pq) - and sends the result
back to the customer.
ecash
Bank
Customer Vendor
1. Customer generates coins via random
number function in his wallet
2. Bank signs coins and debits customer's
account with the amount
3. Customer removes blinding factor
4. Customer pays with
ecash coins
5. Vendor forwards coins
for verification
6. ecash server checks for
correctness and double
spending
7. Results of checking
2.
1.
3.
4.
7.
6.
5.
7.

Page 38 BSI
- The customer can now remove the blinding factor r:
(r*xd)/r = xd (mod pq)
- The customer's software now saves the value xd as the "electronic coin" which he will
later be able to use to make a payment. As the blinding factor r was randomly
generated, the bank cannot work out the serial number of the coin, so that once the
money has been tendered by a vendor, it cannot trace the money tendered back to a
particular person.
If, however, a digital coin has been copied and is tendered twice, the bank has the means to
establish retrospectively which customer generated this coin. When an ecash coin is tendered,
the bank checks the serial numbers of all the coins which have already been spent, along with
their cryptographic correctness. If the coin has already been tendered or is invalid, the
transaction is rejected.
5.2.3 Features of ecash
T Pre-paid.
D Similar to coins.
A Partially anonymous.
S Specially designed for small cash payments.
O Designed for online operation, but can also be used offline to some extent.
Sp Only suitable for spontaneous purchases if the system is widely used. Purchaser
must have loaded sufficient ecash, seller must be able to process ecash
payments.
N The system is designed to accommodate relay from customer to customer;
however in current implementations the coins must be forwarded via
intermediaries.
G International use is possible, but currently the system is only implemented at
national level.
5.3 CyberCash
The generic term CyberCash covers essentially three different electronic payment systems:
- A credit card-based system, under which the relaying of credit card information is
secured through encryption. The SET protocol is used here.

BSI Page 39
- A debit card-based payment system, under which the customer issues a written
collection authorisation to CyberCash GmbH and can then make purchases from
vendors who have a contractual relationship with CyberCash.
- CyberCoin pre-paid payment system for small cash payments.
CyberCash is offered by various American banks and in Germany by a banking consortium
whose members include Dresdner Bank, Sachsen LB, WestLB and Commerzbank.
The discussion below describes the procedures of the CyberCash system as used in Germany.
For each of the three systems supported by CyberCash a potential customer must first apply in
person at the local branch of a bank to use the system. This entails the customer giving his
name, address and bank account details, which are passed to Cybercash GmbH in the event
that authorisation is subsequently granted. In the case of the CyberCoin system and the debit
card-based variant, the customer must also sign a collection authorisation.
In addition, every customer needs an electronic purse software application, the CyberCash
wallet, which can be obtained free of charge from the Internet. Every wallet has a unique ID.
The registration process ensures that only a uniquely identified wallet can access a given
customer account. During the installation process, the user has to assign a password for access
to the wallet. An RSA key pair is then generated for the user. The private key is only stored in
the wallet, whereas the public key is passed to the CyberCash gateway. During the installation
process, a "verification ID" is also generated and sent to the CyberCash gateway in encrypted
form.

Page 40 BSI
5.3.1 CyberCoin
The customer must first load the wallet, i.e. he must pass the information that a particular sum
of money is available to the wallet.
For this purpose the wallet generates a load request which is transmitted to the CyberCash
gateway encrypted. CyberCash debits the customer’s account by the appropriate amount.
When the wallet is loaded for the first time, the customer cannot use his CyberCoins until the
cash has been received at Cybercash. This is intended to prevent dishonest persons from
registering under false names.
In return a "cash container" is opened on the CyberCash gateway as a virtual account. One
cash container is maintained for each customer and each vendor. The wallet balance serves a
purely information purpose, allowing the customer to see how much money he has in his
account; only the amount noted in the cash container is contractually committed.
CyberCoin
Bank
Customer Vendor
1. Customer loads wallet
2. After receipt of payment,
a cash container is opened
on the gateway
3. Customer orders and pays,
payment data is transmitted
encrypted
4. Vendor presents payment
data + vendor data
5. Gateway performs check
6. Confirmation
7. Settlement
2.
1.
3.
4.
7.
7.
6.
5.
CyberCash-
Gateway
1.
6.

BSI Page 41
When the customer decides on a product of a vendor which interests him, he selects the
payment option with his browser.
This causes the wallet to open and the customer is required to enter the password needed for
access to the wallet. The received demand for payment from the vendor is then displayed. As
soon as the customer confirms this, the wallet relays the payment transaction data encrypted
and digitally signed to the vendor.
The vendor can neither decrypt nor alter the data which is sent to him by the customer, as he
does not know the customer’s private key or the session key used for the encryption. The
vendor's system adds the purchase information such as the price and encrypts the entire
packet, including the encrypted and signed customer data, with the vendor's private key. This
data packet is in turn digitally signed by the vendor and sent to the CyberCash gateway.
The CyberCash gateway decrypts and checks the received data. If the data disagrees (e.g. the
purchase prices are different), the transaction is rejected and an error messages is returned.
If the data is correct, the virtual accounts of the customer and vendor are balanced, i.e. the
appropriate number of CyberCoins are withdrawn from the customer’s cash container and
added to that of the vendor. The vendor receives a message confirming that the payment has
been effected. The vendor’s system passes this on to the customer’s wallet, where the amount
available is reduced and the payment transaction is logged.
In the event of loss of data or if the user has forgotten his password, the user can have his
wallet blocked by CyberCash. To do this, he has to authenticate himself by entering his wallet
ID and the verification ID. He then receives the remaining amount in the account which he
specified during registration.
5.3.2 Direct debit variant
Under the "electronic direct debit" (edd) card-based payment system, the customer issues a
written collection authorisation to CyberCash GmbH and can then make purchases from
vendors who have a contractual relationship with CyberCash.
When the customer wishes to buy something, the vendor's software sends the customer a
demand for payment which also contains a collection authorisation. After that, the exchange
of data is essentially the same as with the CyberCoin system, except that in this case a
collection authorisation is relayed. Similarly, the payment data is only transmitted in
encrypted form.
5.3.3 Credit card payments
Under CyberCash, credit card payments are secured using the SET protocol, under which
encryption and a digital signature are used to protect credit card transactions.

Page 42 BSI
5.3.4 Features of CyberCoin
T Pre-paid.
D Divisible, account-based.
A Not anonymous.
S Suitable for small cash payments.
O Designed for usage online.
Sp Suitable for spontaneous purchases if payment method sufficiently widely used.
N Relaying only through intermediary.
G International, but at present national implementations are not compatible with
each other.
5.4 First Virtual (FV)
First Virtual offered an interesting variant of an electronic payment system which operated
entirely without the use of cryptography. Moreover, customers required no special software or
hardware in order to be able to use the system. An additional significant feature of First
Virtual was the right to return the goods after purchase which was granted to customers.
After considerable initial success, First Virtual was discontinued in July 1998. Customers
were recommended to switch to the CyberCash system.
The system functioned as described below.

Security consideration with e commerce

Security consideration with e commerce

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (10)

Similar to Security consideration with e commerce

Similar to Security consideration with e commerce (20)

More from StudsPlanet.com

More from StudsPlanet.com (20)

Recently uploaded

Recently uploaded (20)

Security consideration with e commerce