Bundesamt für Sicherheit in der
Informationstechnik
Federal Agency for Security in
Information Technology
Security Conside...
Federal Agency for Security in Information Technology
The President
Security Considerations with Electronic Commerce
Forew...
Security Considerations with Electronic Commerce Table of Contents
BSI Page i
Table of Contents
1 Introduction 1
2 Definit...
Table of Contents Security Considerations with Electronic Commerce
Page ii BSI
6.3 Information and Communication Services ...
Security Considerations with Electronic Commerce Introduction
BSI Page 1
1 Introduction
It is said that the Internet is th...
Definitions Security Considerations with Electronic Commerce
Page 2 BSI
reason, the security of "electronic payments", the...
Security Considerations with Electronic Commerce Definitions
BSI Page 3
- delivery
- use of the products
Like conventional...
Definitions Security Considerations with Electronic Commerce
Page 4 BSI
When one considers e-commerce, a number of additio...
Security Considerations with Electronic Commerce Definitions
BSI Page 5
Problem: Supplied data Supplied physical goods
Pro...
Definitions Security Considerations with Electronic Commerce
Page 6 BSI
17 May 1977, on the common system of Value Added T...
Security Considerations with Electronic Commerce Definitions
BSI Page 7
2.3 Variants of electronic money systems
Sending m...
Definitions Security Considerations with Electronic Commerce
Page 8 BSI
O Online or offline (offline means that there does...
Security Considerations with Electronic Commerce Definitions
BSI Page 9
- telephone banking,
- mobile banking,
- home bank...
Definitions Security Considerations with Electronic Commerce
Page 10 BSI
Under telephone banking, transactions are validat...
Security Considerations with Electronic Commerce Definitions
BSI Page 11
With home banking, customers
can access their acc...
Definitions Security Considerations with Electronic Commerce
Page 12 BSI
ineffective that it can be quickly broken, failin...
Security Considerations with Electronic Commerce Definitions
BSI Page 13
programming knowledge, as was demonstrated in the...
Definitions Security Considerations with Electronic Commerce
Page 14 BSI
Protection of home banking transactions via six-d...
Security Considerations with Electronic Commerce Definitions
BSI Page 15
The target public here is the large majority of p...
Threats Associated With Electronic Commerce Security Considerations with Electronic Commerce
Page 16 BSI
3 Threats Associa...
Security Considerations with Electronic Commerce Threats Associated With Electronic Commerce
BSI Page 17
But it is not jus...
Threats Associated With Electronic Commerce Security Considerations with Electronic Commerce
Page 18 BSI
Confidentiality I...
Security Considerations with Electronic Commerce Threats Associated With Electronic Commerce
BSI Page 19
- Theft of compon...
Threats Associated With Electronic Commerce Security Considerations with Electronic Commerce
Page 20 BSI
It should be born...
Security Considerations with Electronic Commerce Security Requirements
BSI Page 21
4 Security Requirements
The security re...
Security Requirements Security Considerations with Electronic Commerce
Page 22 BSI
4.2 Verification of the identity of the...
Security Considerations with Electronic Commerce Security Requirements
BSI Page 23
offensive protection to his computers, ...
Security Requirements Security Considerations with Electronic Commerce
Page 24 BSI
server unless these are already part of...
Security Considerations with Electronic Commerce Security Requirements
BSI Page 25
4.4 Protection of the user
The customer...
Security Requirements Security Considerations with Electronic Commerce
Page 26 BSI
payments over a secure communication ch...
Security Considerations with Electronic Commerce Security Requirements
BSI Page 27
Internet and that the use of ActiveX sh...
Security Requirements Security Considerations with Electronic Commerce
Page 28 BSI
issues must be taken to achieve the des...
Security Considerations with Electronic Commerce Security Requirements
BSI Page 29
taken. Experience shows that specificat...
Examples of Electronic Money Systems Security Considerations with Electronic Commerce
Page 30 BSI
5 Examples of Electronic...
Security Considerations with Electronic Commerce Examples of Electronic Money Systems
BSI Page 31
Transactions using SET
T...
Examples of Electronic Money Systems Security Considerations with Electronic Commerce
Page 32 BSI
The vendor's system decr...
Security Considerations with Electronic Commerce Examples of Electronic Money Systems
BSI Page 33
The uppermost certificat...
Examples of Electronic Money Systems Security Considerations with Electronic Commerce
Page 34 BSI
signature key and for ke...
Security Considerations with Electronic Commerce Examples of Electronic Money Systems
BSI Page 35
The "electronic commerce...
Examples of Electronic Money Systems Security Considerations with Electronic Commerce
Page 36 BSI
The bank signs this info...
Security Considerations with Electronic Commerce Examples of Electronic Money Systems
BSI Page 37
5.2.2 Blind signatures
O...
Examples of Electronic Money Systems Security Considerations with Electronic Commerce
Page 38 BSI
- The customer can now r...
Security Considerations with Electronic Commerce Examples of Electronic Money Systems
BSI Page 39
- A debit card-based pay...
Examples of Electronic Money Systems Security Considerations with Electronic Commerce
Page 40 BSI
5.3.1 CyberCoin
The cust...
Security Considerations with Electronic Commerce Examples of Electronic Money Systems
BSI Page 41
When the customer decide...
Examples of Electronic Money Systems Security Considerations with Electronic Commerce
Page 42 BSI
5.3.4 Features of CyberC...
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Security consideration with e commerce
Upcoming SlideShare
Loading in...5
×

Security consideration with e commerce

213

Published on

Published in: Economy & Finance, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
213
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
10
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Security consideration with e commerce

  1. 1. 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
  2. 2. 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
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. Definitions Security Considerations with Electronic Commerce 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.
  9. 9. Security Considerations with Electronic Commerce Definitions 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
  10. 10. Definitions Security Considerations with Electronic Commerce 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)
  11. 11. Security Considerations with Electronic Commerce Definitions 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)
  12. 12. Definitions Security Considerations with Electronic Commerce 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:
  13. 13. Security Considerations with Electronic Commerce Definitions 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
  14. 14. Definitions Security Considerations with Electronic Commerce 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).
  15. 15. Security Considerations with Electronic Commerce Definitions 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
  16. 16. Definitions Security Considerations with Electronic Commerce 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
  17. 17. Security Considerations with Electronic Commerce Definitions 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.
  18. 18. Definitions Security Considerations with Electronic Commerce 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
  19. 19. Security Considerations with Electronic Commerce Definitions 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.
  20. 20. 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.
  21. 21. 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.
  22. 22. Threats Associated With Electronic Commerce Security Considerations with Electronic Commerce 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
  23. 23. 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.
  24. 24. Threats Associated With Electronic Commerce Security Considerations with Electronic Commerce 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.
  25. 25. 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.
  26. 26. 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
  27. 27. Security Considerations with Electronic Commerce Security Requirements 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
  28. 28. Security Requirements Security Considerations with Electronic Commerce 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.
  29. 29. Security Considerations with Electronic Commerce Security Requirements 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
  30. 30. Security Requirements Security Considerations with Electronic Commerce 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
  31. 31. Security Considerations with Electronic Commerce Security Requirements 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
  32. 32. Security Requirements Security Considerations with Electronic Commerce 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
  33. 33. Security Considerations with Electronic Commerce Security Requirements 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.
  34. 34. 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).
  35. 35. 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.
  36. 36. Examples of Electronic Money Systems Security Considerations with Electronic Commerce 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)
  37. 37. Security Considerations with Electronic Commerce Examples of Electronic Money Systems 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
  38. 38. Examples of Electronic Money Systems Security Considerations with Electronic Commerce 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.
  39. 39. Security Considerations with Electronic Commerce Examples of Electronic Money Systems 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.
  40. 40. Examples of Electronic Money Systems Security Considerations with Electronic Commerce 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.
  41. 41. Security Considerations with Electronic Commerce Examples of Electronic Money Systems 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.
  42. 42. Examples of Electronic Money Systems Security Considerations with Electronic Commerce 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. 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 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.
  43. 43. Security Considerations with Electronic Commerce Examples of Electronic Money Systems 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.
  44. 44. Examples of Electronic Money Systems Security Considerations with Electronic Commerce 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.
  45. 45. Security Considerations with Electronic Commerce Examples of Electronic Money Systems 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.
  46. 46. Examples of Electronic Money Systems Security Considerations with Electronic Commerce 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. M Smart card can be used anywhere, pure software variant more difficult. 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.

×