bao mat co ban trong thuong mai dien tu

7/30/2019 bao mat co ban trong thuong mai dien tu

http://slidepdf.com/reader/full/bao-mat-co-ban-trong-thuong-mai-dien-tu 1/13

WAP has a layered architecture (see Figure 21.3). The layering is notstrict, however, because external applications may access all layers directly

except WDP. The Wireless Application Environment (WAE) includes a microbrowser environment with WML, WMLScript, wireless telephony serv-ices and programming interfaces (WTA, Wireless Telephony Application),and a set of well-defined content formats (e.g., images, phone book records).The Wireless Session Protocol (WSP) provides an interface for two types of session services, a connectionless one over WTP, and a connection-oriented one over WDP. WSP/B includes the HTTP/1.1 functionality (seeChapter 15), which allows a WAP proxy to connect a mobile client to a stan-

dard HTTP server. The Wireless Transaction Protocol (WTP) runs on top of a datagram protocol (i.e., the Wireless Datagram Protocol, WDP, or UDP). WTP is a lightweight protocol suitable for implementation in thin clients. The Wireless Transport Security Layer (WTLS) is discussed in Section 21.4.1. WAP can be used in both IP and non-IP networks (i.e., it is network-bearerindependent). Different bearers were discussed in Section 21.1.

A typical WAP configuration is shown in Figure 21.4. A mobile WAPclient can communicate directly with a WAP server, which is connected tothe wireless network and provides WML content. Because of the

362 Security Fundamentals for E-Commerce

Wireless Application Environment (WAE)

Wireless Session Protocol (WSP)

Wireless Transaction Protocol (WTP)

Wireless Transport

Layer Security (WTLS)

Wireless Datagram

Protocol (WDP)

User Datagram

Protocol (UDP)

IP

(e.g., GPRS, CSD)

non-IP

(e.g., SMS, USSD)

WAP technology

Non-WAP technology

Figure 21.3 WAP layers.



narrowband network connection, the WML data is exchanged in binary for-mat. If the mobile user wants to access HTML files, they should first betranslated into WML by an HTML filter. A Web server in the Internet canalso be a WML content provider. In this case the connection should gothrough a WAP proxy that carries out translation into the binary WML

format.

21.4.1 Wireless Transport Layer Security (WTLS)

The Wireless Transport Layer Security Specification (WTLS) [9] defines a secure protocol very similar to TLS 1.0 (see Section 13.4). Like TLS, WTLSprovides peer authentication, data confidentiality, and data integrity.

Whereas TLS must be layered over a reliable transport protocol, WTLS can

be layered over an unreliable transport protocol (i.e., it adds datagram sup-port). However, the handshake protocol (i.e., negotiation of security parame-ters, key exchange, and authentication) must always be reliable. This isachieved by concatenating several TLS records into one message (i.e., servicedata unit, SDU) on the one hand, and by retransmission and acknowledg-ment messages on the other.

In addition, WTLS defines both an abbreviated and an optimized TLShandshake protocol because the data rates in a mobile network are much

lower than in the Internet. WTLS also defines dynamic key refreshing so thatthe cryptographic keys may be exchanged within an already establishedsecure connection. This feature is useful because it avoids the handshakeoverhead. It also provides higher security because the keys are not exposed tobrute force attacks at any time during a secure connection.

Mobile Commerce Security 363

Web

server Wireless

network

WAP

proxyWML

Binary WMLHTML

filter

HTML

WML WAP

mobile

clientWAP

server

Figure 21.4 A typical WAP configuration.



21.4.2 WAP Identity Module

The WAP Identity Module (WIM [10]) performs the WTLS and applica-tion layer security functions (e.g., digital signature for authentication, key exchange) and serves as a secure storage of a users personal and security-related information (e.g., private and secure cryptographic keys). WIM mustbe implemented as a tamper-resistant device, so the logical choice is a smartcard (e.g., SIM card) which can be inserted into a mobile device. The struc-ture of the card information is based on the PKCS #15 cryptographic tokenspecification [11].

21.4.3 WML Security Issues

Wireless Markup Language (WML) is a markup language based on XML(see Section 15.1) and designed for use in mobile devices [12]. A WML deck ,

which consists of one or more WML cards , is similar to an HTML page: It isalso identified by a URI and comprises a transmission unit. After loading a deck, the microbrowser displays the first card.

WML has a mechanism for user agent (i.e., microbrowser) state man-

agement including variables that can change the characteristics and contentof a WML card or deck. Their values are stored in the browser context . Theuser may consider the values of certain variables private, however, so it mustnot be possible for a malicious service to retrieve the private information.

The access element specifies access control for the entire deck (i.e.,deck-level access control). The access element attributes domain and path define which other decks are allowed to access this deck. When the user navi-gates from one deck to another, the access control mechanism defines

whether the destination deck may be accessed from the current (i.e., refer-ring) deck. If the sendreferer attribute is set to TRUE, the microbrowser mustspecify the URI of the referring deck. Specifically, the server (providing thedestination deck) may perform URI-based access control and thus limit theset of URIs whose decks are allowed to refer to the servers deck.

21.5 SIM Application Toolkit

The SIM card initially played a passive role, providing the user with theauthentication necessary to access the network and encryption keys toachieve speech confidentiality. SIM Application Toolkit, a part of the GSMstandard (GSM 11.14), extends the cards role such that it becomes the inter-face between the mobile device and the network. SIM Toolkit supports the




development of smart card applications for GSM networks. It is based on theclient-server principle, with SMS as the bearer service. In the future, other

transport mechanisms such as USSD or GPRS will be used. With SIMToolkit it is possible to personalize a SIM card, to update existing SIM func-tions/services, and to install new functions/services by downloading data overthe network. This has usually been done by adding or modifying data in thecard files and records, not by downloading executable code. In November1999, however, ETSI adopted the Java Card technology (see Section 22.5)for inclusion in SIM Toolkit. Cryptographically protected data is sent overthe air interface with SMS messages used as containers.

Although some people see SIM Toolkit and WAP as competitors, thetwo concepts can actually complement each other. Specifically, SIM Toolkitcan be used for highly secure applications, such as mobile banking, as well asfor information services with content that does not change so frequently,such as hotlines, company directories, and yellow pages. WAP, on the otherhand, is better suited for more dynamic services, such as Internet browsing and access to constantly changing information .

Security requirements in SIM Toolkit (GSM 02.48 and 03.48) coverthe usual transport layer security issues such as peer authentication, messageintegrity, replay detection and sequence integrity, proof of receipt, and mes-sage confidentiality. Basically, each application message is divided into pack-ets that are individually secured by protecting the payload and adding security headers (see Part 3 for the principles of communication security).Proof of execution is required as well, to assure the sending application (e.g., a bank application) that the receiving application (e.g., the home banking application on a SIM card) has performed an action initiated by the sending application. This proof should be provided at the application layer, so no

mechanism for it is defined in the GSM specifications.

21.6 Mobile Station Application Execution Environment (MExE)

The Mobile Station Application Execution Environment (MExE), which is a new part of the GSM standard (GSM 02.57), will provide a standardized and

platform-independent way of

• Transferring applications, applets, and content between a serviceprovider and a mobile device;




• Executing applications and applets in a standardized execution envi-ronment within mobile equipment and SIM (i.e., parts of a mobile

device, but only a SIM is personalized).

MExE is network-bearer independent, so different bearers may bedeployed (e.g., SMS, GPRS). It can make WAP-enabled devices capable of offering a wider range of features with greater security and flexibility by allowing full application programming (in contrast to WAP scripting).MExE builds the Java Virtual Machine into the mobile device. The security issues are therefore very similar to those addressed in Chapter 18. Basically,untrusted code must be executed in a sandbox (i.e., with a very restrictedset of access permissions). Trusted code is granted permissions on the basis of the type of authorization that has been assigned to its security domain . Thefollowing four security domains are defined:

• Security Operator Domain for code authorized by the network operator;

• Security Manufacturer Domain for code authorized by the mobiledevice manufacturer;

• Security User Trusted Domain for code authorized by softwaredevelopers that are trusted by the user (on the basis of a digital cer-tificate);

• Security Untrusted for untrusted code.

MExE will significantly extend the functionality of SIM cards. WAPcan thus be seen as an application running in MExE. MExE is targeted at themobile station as a whole, which includes both mobile equipment and SIM(in contrast to SIM Application Toolkit, which is targeted at the SIM cardonly).

21.7 Outlook

It is expected that mobile devices (especially mobile phones) will developinto the most important e-payment and e-banking platform in the Internet.One obstacle, however, is that customer authentication based on digital sig-natures does not yet work properly (i.e., in connection with WAP). Anotherobstacle is that mobile devices do not yet provide a true multi-application




platform (with all security implications). There is, for example, a dual slotmobile phone by Motorola 10 in which one slot is intended for a SIM card

and the other for a third-party smart card (e.g., e-payment provider, or digi-tal signature). It is not clear whether this solution will be accepted by other

vendors.In contrast to many other areas, research and development in the area

of m-commerce are predominantly initiated and performed by industry. Thereason is that the platform (i.e., mobile devices) is already in widespread use,so vendors are developing new value-adding services (e.g., mobile surfingthrough WAP). In the course of this process, the old paradigms such as the

Web are basically being accommodated. This allows faster development andimmediate customer acceptance because no new concepts have to be tested,and because customers are already familiar with the services. On the otherhand, mobile platforms will be rather limited in capability (thin client) fora long time. Through new technical possibilities, such as physically locating the customer at any time, mobile platforms lead to the development of com-pletely new, highly personalized services. Many of them, however, also raiseprivacy concerns and need advanced security concepts in order to beaccepted by a broad audience.

References

[1] Durlacher Research Ltd., Mobile Commerce Report, Free Research Report, 1999,http://www.durlacher.com/fr-research-reps.htm.

[2] Mobile Lifestreams Ltd., Free White Papers, 2000, http://www.mobileipworld.com/ wp/wp.htm.

[3] The European Telecommunications Standards Institute, Digital cellular telecommu-nications system (Phase 2+): Security related network functions, GSM 03.20, Version7.2.0, Release 1998, ETSI TS 100.929, November 1999.

[4] Mehrotra, A., GSM System Engineering , Norwood, MA: Artech House, 1997.

[5] Pütz, S., Mobiltelefone: Gefährdungen & Sicherheitsmaßnahmen, BSI Broschüre,October 1999, http://www.bsi.bund.de/literat/studien/mobiltel.htm.

[6] GSM World, An Overview of Wireless Application Protocol, 1999, http://www.

gsmworld.com/technology/wap.html.


10. http://www.motorola.com/GSS/CSG/Help /PR/pr990318_startacddualslot.htm



[7] Wireless Application Protocol Forum, Ltd, Wireless Application Protocol: Archi-tecture Specification, Approved Specification, April 1998, http://www.wapfo-rum.org/what/technical.htm.

[8] Wireless Application Protocol Forum, Ltd, WMLScript Crypto Library, ApprovedSpecification, Nov. 1999, http://www.gsmworld.com/technology/wap.html.

[9] Wireless Application Protocol Forum, Ltd, Wireless Transport Layer Security Spe-cification, Approved Specification, Nov. 1999, http://www.wapforum.org/what/technical.htm.

[10] Wireless Application Protocol Forum, Ltd, Wireless Application Protocol Identity Module Specification, Approved Specification, Nov. 1999, http://www.wapforum.org/what/technical.htm.

[11] RSA Laboratories, PKCS#15 v1.0: Cryptographic Token Information Standard, April 1999, http://www.rsasecurity.com/rsalabs/pkcs/.

[12] Wireless Application Protocol Forum, Ltd, Wireless Markup Language Specification, Version 1.2, Approved Specification, http://www.wapforum.org/what/technical.htm.


Team-Fly®



22Smart Card Security

The following chapter is included in this part of the book for two reasons.First, cardholders can carry their smart cards anywhere, so the cards givethem mobility in requesting various personalized services. Second, smartcards are one of the key enabling technologies for mobile commerce. The fol-

lowing chapter gives a general overview of smart card security issues. In addi-tion, it provides a brief overview of Java Card technology and biometrics.

22.1 Introduction

The evolution of the smart card is linked to two product developments: themicrocomputer chip and the magnetic stripe card. These two developmentsmerged into one product in the 1970s, when the French journalist Roland

Moreno patented his idea of putting a chip inside a conventional plastic card. Actually, the first person to apply for patent protection for a plasticintegrated circuit card was the Japanese scientist Kunitaka Arimura, fouryears earlier, but for Japan only. Today, applications using smart cardsinclude phone cards, health insurance cards, pay TV, banking and paymentapplications, GSM, authentication, and digital signature. For the latestinformation on smart cards, see the homepage of the Smart Card Industry

Association.1

369

1. http://www.scia.org



The components of a smart card are the same as for a normal com-puter: a microprocessor as an intelligent element (i.e., CPU), a memory,

input/output parts, and a power source. For the purpose of better perform-ance, there is often a separate cryptographic coprocessor (e.g., a modulararithmetic coprocessor for public key computations). The input/output partsand the power source differ for different types of smart cards: there are con-tact cards with metallic contacts, contactless cards using inductive coupling,and super smart cards with a keyboard and a display. A processor chip of a typical smart card contains three different types of memories: the working memory RAM (random access memory), the maskable memory ROM (read

only memory), and the data storage EEPROM (electrically erasable pro-grammable memory). The procedures and, if possible, cryptographic algo-rithms for general use are stored in the ROM. When an application running on an application terminal (e.g., a PC) wishes to communicate with a smartcard, the card must be inserted into a card reader (also called card terminal orcard accepting device ).

The most important international smart card standards are theISO/IEC 7816 standards. For e-commerce applications there are also theEMV specification2 and the inter-sector electronic purse standard EN 1546.3

The EMV specification, which is defined by Europay, MasterCard, and Visa,is based on ISO 7816 with additional proprietary features to meet the spe-cific needs of the financial industry. For GSM, the SIM-ME specificationGSM 11.11 is the most relevant. For programmers who develop terminalapplications for smart cards, the best known APIs are currently PC/SC andOCF. In PC/SC4 much emphasis was placed on the interoperability of smartcards and card readers, and on the integration of those readers into theMicrosoft Windows operating system. OCF5 took advantage of some fea-

tures already available within PC/SC and other smart card standards, andfocused on two new areas: independence from the host operating system, andtransparent support of different multi-application cards and managementschemes.

Smart card security issues can be divided into four areas:

• Card-body security;

• Hardware (i.e., chip) security;

• Operating system security;

• Card application security.



Most card-body security measures, such as embossing or hologram pic-tures, are designed to allow humans to check whether a card is genuine. They

will not be discussed further in this book. Other issues are addressed inSections 22.2 to 22.4.

The main source for the following sections is the excellent in-depthsmart card book by Rankl and Effing [1]. Schneier and Shostack give a classi-fication of smart card-related security attacks [2]. A more lightweightintroduction to smart cards can be found in, for example, [3]. FIPS PUB140-1, a U.S. federal standard [4], defines security requirements for crypto-graphic modules, including smart cards.

22.2 Hardware Security

The smart card microcontroller (i.e., chip) must be as tamper resistant aspossible. This effectively means that the cost of breaking the chip security mechanisms must be higher than the potential gain from doing so. It shouldbe impossible to read the secret data stored on the card, such as crypto-graphic keys, or monitor processes running on the card and thus draw con-clusions about sensitive information. Attacks against chip security can beperformed at any phase of the card life cyclecard development, card manu-facturing, card personalization (i.e., storing of personal identification data relating to the ultimate cardholder)or card use. Moreover, different attacksare performed when the chip is active (i.e., has a power supply) or inactive.Therefore, it should be noted that tamper resistance does not solve all secu-rity problems and must be carefully analyzed and upgraded if necessary [5].

Security measures during card development and manufacturing

include control of physical access to card data. It is also very important toimplement only documented features, because undocumented features arenot considered in evaluation and testing and thus can open a security hole.Each chip obtains a unique serial number, which in itself cannot protectagainst attacks, but serves as information for deriving cryptographic keys.During manufacture, chips are protected by authorization mechanisms basedon transport codes, which can even be chip specific.

Smart Card Security 371

2. http://www.visa.com

3. http://www.cenelec.be

4. http://www.pcscworkgroup.com

5. http://www.opencard.org



Most attacks on smart card hardware are performed during card usebecause there is practically no physical access protection. For such attacks,

various rather sophisticated tools may be used, such as microscopes, laser cut-ters, micromanipulators, or very fast computers for probing and analyzing the electrical processes on the chip. Static analysis can be made extremely dif-ficult through special design principles such as [13]:

• Embedding of tamper-detection mechanisms such as cover switchesor motion detectors to detect, for example, cutting or drilling;

• Opaque tamper-evident coating to hamper direct observation, prob-

ing, or manipulation of the chip surface;• Dummy structures to confuse attackers;

• Special memory design and scrambling to hide content;

• Hiding and scrambling of buses to prevent eavesdropping.

Mechanisms that protect against dynamic analysis include:

• A voltage watchdog that switches off a chip module if the power voltage is not within a specified interval;

• Mechanisms that set to zero any parameters representing secret orprivate information (i.e., cryptographic keys);

• Environmental failure protection that shuts down the chip or setssensitive parameters to zero whenever environmental conditions areoutside the normal operating range (i.e., chip heating).

A dynamic attack that can determine which card command is being executed on the card (and thus potentially reveals sensitive information) isbased on differential power analysis [6]. The attack works if different com-mands have different power consumption, so one protection mechanism is touse only commands with very similar power consumption. Another possibil-ity is to perform the same computation (e.g., in a cryptographic algorithm)in several different ways, so that each time one way is chosen randomly.

Another well-known attack is the timing attack, in which time intervalsneeded by the card for specific computations are measured and analyzed [7].For example, if the card encrypts data, the greater the differences in the dura-tion of computation for different keys and data, the easier it is to reduce theset of possible keys. A protection mechanism is to make the duration of




cryptographic computations independent from input data (noise-free algo-rithms).

Attacks based on differential fault analysis try to disturb the functioning of the card (e.g., by changing the power voltage or the frequency of the exter-nal clock, or by exposing the card to different kinds of radiation). Each timethe card performs symmetric or asymmetric cryptographic computation, onebit in the key is changed at some position [8]. The results of a series of suchcomputations, which are all different because the bit position is different ineach, are analyzed and used to compute the (previously unknown) key. Thesimplest protection mechanism is to let the card perform each cryptographic

computation twice and to compare the results (they must be identical). Thismethod is, however, rather time-consuming. A more practical approach isalways to append a random number to the data to be encrypted so thatattackers cannot analyze different results for the same plaintext. Of course,the random number generator on the smart card should ideally never repeatthe random numbers at any time during the card life cycle.

22.3 Card Operating System Security

Development of card operating systems (COS) began in the early 1980s;today there are a dozen operating systems on the market (e.g., CardOS by Siemens, Cyberflex by Schlumberger, Multos by Maosco). COS must bekept as small (e.g., 16K) and simple as possible in order to make testing andevaluation easy as well as to make it possible to verify whether the high-security requirements are satisfied. The operating system code is written inROM, which means that once a ROM mask has been defined and possibly

millions of cards produced, no changes can be made without considerableloss of image and money. With normal operating systems, usually a patchor a new version is released. If it is necessary to have modifiable programs forcards, they are written in the much more expensive EEPROM. The numberof EEPROM write/delete operations is limited (i.e., up to 105 ). Some newerCOSs, such as Java Card (Section 22.5), SIM card (Section 21.5), and Mul-tos, provide an API and allow downloading of application code onto thecard.

There is a range of mechanisms to make a smart card operating systemas secure as possible [1]:

• Performance of hardware, software, and memory tests based onchecksums at initialization;

Smart Card Security 373



• Operating system design with a modular or layered structure so thaterror propagation is minimal;

• Hardware support to strictly separate memory regions belonging todifferent applications (e.g., through the addition of a memory man-agement unit (MMU));

• Access control based on PINs.

A well-known attack is a sudden interruption of power supply, such as when a card is removed from a card reader. If performed at a precise

moment, this type of attack may cause serious problems. For example, anelectronic purse may be loaded at a terminal and then removed from thereader at the very moment when the balance on the card has been increased.If the card has not yet responded to the terminal or no new audit record hasbeen generated on the card, the terminal will believe that the load transaction

was unsuccessful. The best protection against such attacks is always to useatomic transactions . This effectively means that a transaction is performedeither completely or not at all. Protection mechanisms can use a buffer flag ,

so that when data to be copied to some memory location is ready in thebuffer, the flag is set (buffer data valid). Should the power supply be turnedoff at this moment, the next time it is on again the operating system willknow that the buffer data is to be copied. As soon as the data is copied, theflag is unset (buffer data invalid).

File access control in most COSs is command based. This means that a specific command must be successfully executed before access is granted. Forexample, write access may be granted only after the PIN has been successfully

verified by a specific command (i.e., VERIFY). An alternative is state-based access control. Basically, a state automaton is defined which specifies allallowed execution flows (i.e., command sequences) on the card. The thirdpossibility is object-oriented access control, in which the object to be pro-tected carries its own access control information.

22.4 Card Application Security

A PIN, also called cardholder verification (CHV), is the most commonmechanism for controlling access to smart card applications. Usually thecardholder is allowed three attempts to type in the correct PIN, after whichthe card is blocked. To unblock it, another number must be typed in, theso-called personal unblocking key (PUK). The PIN approach has the


bao mat co ban trong thuong mai dien tu

Documents