security fundamentals for e commerce phần 9 pps

The Electronic Commerce Modeling Language (ECML 9 ) defines a standard set of information fields to enable electronic wallets from multiple vendors to fill in their Web forms. The fields can be defined by, for example, an HTML form or by the IOTP Authenticate transaction (see Chapter 9). No special security mechanisms are defined, but it is recommended to use SSL/TLS or IPsec. The Signed Document Markup Language (SDML, current version 2.0) defines a generic method for digitally signing a text-based document, one or more sections of a document, or multiple documents together (e.g., Web pages, e-mail messages). As usual, it applies public key cryptography and cryptographic hash functions. The SDML structure is in part defined by the Standard Generalized Markup Language (SGML). SDML is a gener- alization of the Financial Services Markup Language (FSML) developed by the Financial Services Technology Consortium. 10 FSML defines the specific document parts needed for electronic checks (e.g., the tags needed to iden- tify check specific data items, the semantics of the data items, and process- ing requirements for electronic checks). On the other hand, the IETF XML Digital Signatures Working Group and the W3C XML-Signature Working Group are jointly developing specifications for an XML signature (see Section 15.1). Currently it is not clear how those two specifications are related. Finally, the Commerce eXtensible Markup Language (cXML) by Ariba, Inc., is a simple XML-based protocol for business-to-business e-commerce transactions over the Internet. 11 Its development was initiated by Microsoft and Ariba and was supported by a number of other companies (e.g., Visa, Cisco Systems, Philips, NCR). cXML supports supplier content and catalog models, including content management services, electronic mar- ketplaces and Web-based sourcing organizations. In version 1.0 the Creden- tial element is used for authentication on the basis of either a password (SharedSecret) or a digital signature (DigitalSignature). Web-Based E-Commerce Concepts 323 8. http://www.w3.org/ECommerce/ 9. http://www.ecml.org 10. http://www.fstc.org 11. http://www.cxml.org/files /cxml.zip 19.3 Micropayment Markup The W3C Micropayment Markup Working Group is working on a proposal for an extensible and interoperable way to embed all the information neces- sary to initialize a micropayment in a Web page (sent from a merchant/server to the consumer/client) [1]. Micropayment content can be reached by click- ing on a special, newly defined type of link referred to as the per-fee link. The proposal specifies a method for encoding per-fee links within an HTML document. It does not address security issues related to the transmission of the per-fee link from merchant to consumer, such as authentication of the parameters in the per-fee link (e.g., price) or confidentiality of the per-fee link. Applications with security requirements can use, for example, SSL/TLS. 19.4 Joint Electronic Payments Initiative (JEPI) JEPI (Joint Electronic Payments Initiative) is a cooperative effort of Com- merceNet and W3C involving a number of companies that are members of one or both consortia. JEPIs goal is to specify a standard method for negoti- ating payment methods and protocols between clients, payment middleware, and servers across the Web. JEPI Phase 1 specified an automatable payment selection process based on an extension to HTTP called UPP (Universal Pay- ment Preamble) [2]. UPP is used to negotiate about the payment instrument (e.g., check, credit card, debit card, electronic cash), brand (e.g., Visa, Mas- terCard, American Express), and payment protocol (e.g., SET, CyberCash, GlobeID). UPP is implemented as a PEP extension identified by a special URL (http://w3.org/UPP). JEPI architecture itself does not address security issues. The specific payment system negotiated by UPP is responsible for the secure transmission of the corresponding information. The Protocol Extension Protocol (PEP) is a generic framework for describing extensions within HTTP. In JEPI , the Protocol Extension Proto- col is used as a general-purpose negotiation protocol by which a Web client and a server can agree on which extension modules to use, negotiate parame- ters for these modules, and ask the other end to begin using a negotiated extension. Each PEP extension represents an extension to HTTP and is asso- ciated with a URL. A PEP extension uses several new header fields to carry the extension identifier and related information from Web clients, through intermediaries, to servers, and vice versa. Each payment system in JEPI is considered to be a PEP extension identified by a URL. It seems, however, that JEPI is no longer supported: PICS (Platform for Internet Content Selec- tion [3]) no longer uses PEP, and SEA (a Security Extension Architecture for 324 Security Fundamentals for E-Commerce HTTP/1.x, a W3C Working Draft from 1996) has never come into wide- spread use. JEPI specification is only a W3C technical note, so it is not clear whether W3C will pursue the work on JEPI. 19.5 Java Commerce Java Commerce (JC) is a Java-based framework for developing Internet- based e-commerce applications. Currently (as of April 2000) only the client side (i.e., Java Commerce Client, JCC) is available. 12 The only common fea- ture required from servers is the ability to send Java Commerce Messages (JCM), which can be generated by applets, CGI programs, or servlets. Also, the servers must be configured to accept selected payment instruments and understand the corresponding payment protocols. The Java Commerce tech- nology was introduced in 1996, but unfortunately not much progress has been noted since then, so it is still in the development phase. The main technologies in JCC are Java Wallet and Commercial Java- Beans. Java Wallet is a user interface for online purchasing and other finan- cial transactions (e.g., home banking). The JavaBeans API makes it possible to write component software in Java (components are self-contained, reus- able software units). Specifically, JCC consists of the following subsystems: • The graphical user interface (a wallet) is used for interaction with a user (e.g., select and edit payment instruments, edit users prefer- ences, review transactions). • JCM is a message format in which commerce servers communicate with clients. A JCM sent by a commerce server requests that a client perform an operation (e.g., purchase) and provides information about which protocols (e.g., SET) and instruments (e.g., VisaCard) may be used for this operation. Since operations, protocols, and instruments are all Commerce JavaBeans components, a JCM also provides information about the beans that need to be loaded over the network and installed in the wallet. A JCM file has the extension .jcm and the MIME type application/x-java-commerce. • Cassettes are digitally signed JAR (Java Archive) files containing one or more Commerce JavaBeans components and their resources. The Java Wallet is designed to automatically download and install the Web-Based E-Commerce Concepts 325 12. http://java.sun.com/products/commerce/ cassettes that are specified by a particular transaction. Merchants applets may include interfaces to certain cassettes. • An encrypted relational database securely stores user information (e.g., credit card numbers), registers cassettes and cassette compati- bility information, and logs transactions. • The Gateway Security Model (GSM) extends the Java security model [4]. It supports multiple application environments requiring interactions between applications from multiple vendors; such envi- ronments are based on limited trust. No business relationship is based on absolute trust between two parties. The latest Java security model (see Section 18.3) can be used to model limited trust relationships only between a piece of code and the services and resources of the system on which the code is executing. For example, an applet may be allowed to read a certain file, but not to read and write all files in the file system. This model cannot, however, model trust between differ- ent commerce software (e.g., applets, beans) coming from different parties. For example, a tax reporting application may be able to import capital gains information from a home brokers application database, but it should not be able to read the portfolio advisor information from the users investment database [4]. To solve this problem, GSM defines roles, so that each piece of software is assigned one or more roles (e.g., home broker, tax report, portfo- lio advisor). Roles are based on contractual agreements between parties involved in commercial relationships. Roles are implemented with digital 326 Security Fundamentals for E-Commerce Code time Gatekeeper Credential checker Capability service request with credentials check credentials create new capability object (if credentials valid) capability object (if credent. valid) Figure 19.1 Capability model. signatures: a cassette (i.e., a JAR file) is signed for the roles its Commercial JavaBeans will have in JCC. Thus, if the tax authority wishes to gain access to the home brokers cassette, it should first sign a contract with the broker. The broker will then sign the tax authoritys cassette for the tax report role, thus allowing it to read only certain parts of the home brokers application data- base. Some roles are already defined in the JCC, and new roles may be defined by applications. GSM is an object-oriented security model in which rights (i.e., privi- leges) can be transferred from one principal to another, as described above. GSM is based on the capabilities model illustrated in Figure 19.1 [4]. When a piece of code requests a service for which it needs specific access rights, it must submit its credentials to the gatekeeper. The gatekeeper verifies whether the credentials are valid by passing them to the credential checker. If the credentials are valid, the capability service creates a new capability object which is returned to the piece of code by the gatekeeper. In GSM, a capability object returned by a Gate is a Java object called Permit. Figure 19.2 shows a simplified security control flow in GSM. A Ticket is a Role token (i.e., credential) that is passed to the Gate by the Bean and may be used only once. As explained before, a Role represents a digital signature and is used to prove the validity of a Ticket. A Gate represents an authentication method, in this case based on verifying a digital signature. The Gate passes the Ticket to the Role Manager, which verifies the signature and tries to find the corresponding public key in a table of principals which may be granted the requested access rights. A ticket is valid if the signer has been assigned a role that can be verified with the corresponding public key, Web-Based E-Commerce Concepts 327 JavaBean Gate time Role manager Permit Ticket (Role) check signature on Ticket (Role) stamp Ticket (Role) (if signature valid) Permit (Role) (if signature valid) Figure 19.2 Gateway security model. and if the ticket was created specifically for the role for which it is trying to obtain a permit. If the Ticket is valid, the Role Manager stamps it and returns it to the Gate. In this way the Ticket is invalidated so it cannot be used for another, possibly malicious, purpose. The Gate creates a Permit object that is finally passed to the Bean. For example, a cassette that contains an OperationBean must be signed for the Operation role. The Operation role enables the OperationBean to obtain an OperationPermit from an OperationGate. Or, in order to add an item to the pull-down menu in the wallet GUI, an OperationBean cassette must be signed for the Menu role. The Menu role allows the OperationBean to obtain a MenuPermit from the MenuGate [5]. References [1] W3C Micropayment Markup Working Group, Common Markup for micropayment per-fee-links, W3C Working Draft, August 25, 1999, http://www.w3.org/TR/ WD-Micropayment-Markup/. [2] Chung, E S., and D. Dardailler, White Paper: Joint Electronic Payment Initiative, W3C Note, May 19, 1997, http://www.w3.org/TR/NOTE-jepi. [3] W3C Digital Signature Working Group, PICS Signed Labels (DSig) 1.0 Specification, W3C Recommendation, May 27, 1998, http://www.w3.org/TR/ REC-DSig-label/. [4] Goldstein, T., The Gateway Security Model in the Java Commerce Client, Sun Microsystems, Inc., Sept. 2, 1998, http://java.sun.com/products/commerce/docs/ index.html#3. [5] Sun Microsystems, Inc., The Java Wallet Architecture White Paper, Alpha Draft, March 2, 1998, http://java.sun.com/products/commerce/docs/whitepapers/arch/ architecture.pdf. 328 Security Fundamentals for E-Commerce TEAMFLY Team-Fly ® Part 5 Mobile Security The last part of this book deals with security issues of mobile technolo- gies. Mobile commerce and smart cards have already entered our everyday lives, but mobile agents are still in the experimental phase. Chapter 20 addresses mobile agents, which actually represent a special type of mobile code. Chapter 21 provides a look at mobile commerce from a security per- spective. Chapter 22 explains the main security concepts for smart cards, including a brief overview of biometrics. 329 20 Mobile Agent Security Mobile agents are an exciting new paradigm that has been a subject of research by both academia and industry for the past several years. The Inter- net worm described in Section 10.6.1 was actually a predecessor of mobile agents because it could migrate autonomously from host to host. That was an example of a quite malicious agent, so at the time many security experts warned generally against executing code received over the network. Luckily, mobile agents may also be employed for useful purposes. They represent a new and interesting paradigm in the field of distributed systems, but also introduce some new security concerns requiring specially tailored protection mechanisms. 20.1 Introduction The term mobile agent was introduced by Telescript [1], which supported mobility at the programming language level. Mobile agent technology has not yet come into widespread use, although commercial enterprises as well as universities have been working on its development for several years. Voyager, Odyssey, Aglets, Concordia, and Jumping Beans, for example, were devel- oped at companies, and DAgents, Tacoma, Mole, and Sumatra at universi- ties. Opponents of mobile agents believe that all existing or proposed applications based on mobile agents can be equally well and more securely 331 solved on the basis of the client-server paradigm. Proponents of mobile agents do not claim that there is a killer application for mobile agents (i.e., a highly successful application that can be developed only with mobile agent technology), but rather that a number of distributed applications may benefit from using it. The following list of such benefits is based on [2]: • Reduction of network traffic: Mobile agents make it possible to move the computation to the data rather than the data to the com- putation. For example, a client can send a mobile agent to a server hosting large volumes of data. The agent can do the processing on the server and return with the result so that no significant network traffic is generated. Obviously, this reduces traffic only if the agent is significantly smaller than the amount of data that would be exchanged otherwise (i.e., if no agents were used). On the other hand, by using SQL (Structured Query Language) it is possible to package a set of queries to be sent in one message to a database server, which is a solution based on the client-server paradigm [3]. If the processing requires interaction with a remote group of servers, however, the advantages of mobile agents may be significant: they can be launched to the remote group, do the processing, and then return to the originator, with the result that the long-distance net- work path need be traversed only twice. • Elimination of network latency for real-time applications: In critical real-time systems such as factory networks, it is important that con- trol instructions be received without delay. Mobile agents can solve this problem because they can be dispatched from a central control- ler to the controlled component and thus overcome network latency. • Encapsulation of communication protocols: To accommodate new requirements, many existing applications need new or modified communication protocols (e.g., new features, security). This often poses a problem, because the application must be upgraded on all hosts (network nodes) on which it runs. To solve this problem, mobile agents can be sent out to all application hosts to install the new protocol. This approach is used in active networks in which packets are treated as programs [4]. • Enhanced processing capabilities for mobile devices: Many leading mobile agent experts expect mobile agent technology to be applied in mobile computing, mobile phones, PDAs (personal digital 332 Security Fundamentals for E-Commerce [...]... contains the current platform’s identity and the identity of the next platform to be visited The current platform’s signature includes this entry as well as the previous entry (i .e. , the entry generated by the previously visited platform) Including the previous path entry 338 Security Fundamentals for E- Commerce ensures that no undetected tampering is possible because the entries are “chained” together If... Security Fundamentals for E- Commerce results) collected by the agent on different platforms are not protected, a hostile platform can delete or modify all offers which seem to be better than its own Partial result-chaining mechanisms try to protect the agent data collected on one platform before the agent reaches another, potentially hostile, platform These mechanisms help detect modification or removal... platform This is called composite delegation The receiving platform may choose to weaken the agent’s credentials if the sending platform is less trusted than the client on whose behalf the agent acts • Agent and agent platform security policies: Generally, when a secure CORBA object implementation receives a request, it checks the requestor’s credentials and uses the resulting information for its access... control decisions • Integrity, confidentiality, replay detection, and authentication: With secure CORBA, an application may specify which security services should be applied when an operation is requested (e. g., agent transfer) Security requirements may be specified in the requestor’s credentials (e. g., the agent owner’s credentials) or in an object reference (e. g., the agent reference) 350 Security Fundamentals. .. an agent is transferred from the sending to the receiving platform, the receiving platform may use the CORBA security interface to obtain a reference to the credentials object containing the sending platform’s identifier (if authenticated) • Agent authentication and delegation: When an agent migrates between platforms, both the agent’s and the sending platform’s credentials are sent to the receiving... new paradigm for mobile commerce has yet to be invented, so the old paradigm is basically being accommodated for mobile networks and devices There is nevertheless a variety of new, more strongly personalized services specially tailored for mobile subscribers, because mobile devices are personal as well The following chapter gives an overview of mobile commerce technologies 21.1 Introduction Mobile commerce. .. (see Section 20.2) The agent code does not change as the agent moves from platform to platform If the agent owner and/or agent creator and/or the home platform sign(s) the code, all other receiving platforms can verify the signature(s) and thus authenticate the agent On the basis of the trust relationships between the receiving platforms and the signer(s), the platforms can decide whether to execute... infrastructure is a necessary prerequisite for the implementation of mobile payment services The security issues in m -commerce applications are not different from those in other e- commerce applications Section 20.1 briefly explains the GSM security concept (i .e. , mobile network layer security) Section 21.4 gives an overview of the WAP security issues SIM Application Toolkit has been around longer than WAP,... services there is usually no need for a permanent network connection, so it is much more efficient to use packet switching, since it uses the network resources only when there is data to be sent General Packet Radio Service (GPRS) adds a packet-switching facility to GSM and TIA/EIA-136 networks and thus makes internetworking between the Internet and the mobile telephone networks possible The GPRS network... Environmental Key Generation Since an agent’s data can generally be read by the platform on which it is executing, the agent must never carry the encryption keys that are used to hide confidential information from the platform The proposal in [ 19] is based on the idea that a piece of information that the agent needs to compute a cryptographic key is hidden in the agent’s environment The agent needs the key . digital 326 Security Fundamentals for E- Commerce Code time Gatekeeper Credential checker Capability service request with credentials check credentials create new capability object (if credentials. the time many security experts warned generally against executing code received over the network. Luckily, mobile agents may also be employed for useful purposes. They represent a new and interesting. When a piece of code requests a service for which it needs specific access rights, it must submit its credentials to the gatekeeper. The gatekeeper verifies whether the credentials are valid by