ericssonhistory.com

More documents

Recommendations

Info

Figure 8Access features with push-and-pull services.Access featuresPull requestsWhen used for browsing, the mobile terminalcommunicates with content providersvia a gateway—for example, a WAP gateway.A pull request occurs when the contentprovider directs a request (authentication orsign operation) from the mobile terminal toMobile e-Pay (Figure 8). Mobile e-Payprocesses the request and returns the resultsto the content provider, either directly or viaa mobile-terminal redirect. Mobile e-Paydoes not support pull requests using SMSand the SMS center (SMSC).Push requestsPush requests are initiated from devicesother than mobile terminals (for instance, aPC). Push requests are made to Mobile e-Pay through an interface to the contentprovider—in the example shown in Figure8, this is done using the hypertext transferprotocol (HTTP). Until WAP-based pushrequests become available, push requests arehandled using the SMSC. A push request issent to an SMS gateway, which forwards therequest to the SMSC using a vendorspecificSMSC communication protocol.Mobile networkA WAP gateway or SMSC provides accessto Mobile e-Pay (Figure 8). Mobile e-Paycurrently supports WAP 1.1 and providesan HTTP interface to the WAP gateway,which should be able to provide an end-userID. If necessary, an SSL connection to theWAP gateway can also be supported.InternetContent providers can access Mobile e-Payusing HTTP from an intranet or Internetconnection. The interface to the contentprovider supports payment, authentication,digital signatures, and receipt handling. Italso permits an SSL connection to be established.Mobile e-Pay might request the SSLconnection during a pull request; similarly,the content provider might request the SSLconnection during a push request.Receipt handlingDepending on the application, a contentprovider might provide receipts (scriptsavailable for end-users). This solution mightnot be acceptable, however, since end-userssometimes prefer to access receipts locallyfrom their devices. Since WAP does not currentlysupport persistent storage, Mobile e-Pay provides an "Info" interface that can beused to send receipts as short messages toend-user devices.SecuritySecurity is a key issue for mobile e-commerce,and application security systems areEricsson Review No. 2, 2000
eing included in Ericsson's mobile e-commercesolutions. Designed primarily for financialservices, such as banking and trading,Ericsson's security systems enable thecompletion of high-security transactionsfrom a mobile phone. These transactions caninclude account balance inquiries, the transferof money between accounts, billing services,and stock trading.End-to-end security in the system meansthat the user's personal identification number(PIN), which is used to authenticate thegeneration of a digital signature, offers thenecessary authentication and data integrityrequired to verify banking transactions.Each authentication is unique and does notrely on intermediary network functionality.The system also supports established techniquesfor data integrity and encryption, includingwireless public key infrastructure(WPKI). The system can thus be integratedinto existing IT infrastructure and securityfeatures.WPKI, which consists of protocol extensionsand software and hardware additionsto terminals and networks that expand traditionalPKI to wireless networks, is intendedto enable the implementation of scalablesecurity solutions that are independentof the application, network, and supplier.PKI is an application-independent securityinfrastructure that is based on publickey cryptography services for data integrity,confidentiality, authentication and nonrepudiation.Using applied cryptography,PKIs govern the distribution and managementof cryptographic keys and digital certificatesthat allow users to take advantageof several fundamental features.• Confidentiality of information ensuresthat user communications are safe and cansolely be read by the intended recipient.Message encryption using digital certificatesguarantees confidentiality.• Integrity of data guarantees that messagecontents are not altered during transmissionbetween the originator and the recipient.PKIs provide digital signaturesto ensure the integrity of all transmittedinformation.• User authentication enables systems andapplications to verify that users are whothey claim to be and that they have beenauthorized to access resources. PKIs usedigital signatures and user certificates toguarantee the authentication of all end entitiesand system resources.• Non-repudiation prevents users of thePKI from falsely denying that they haveparticipated in a transaction or sent a messageto another user or resource. With alegitimate digital signature in hand and alegitimate digital certificate to accompanyit, the chances of a message being forgedor originating elsewhere are next to nil.Security features and optional packagesMobile e-Pay offers flexible packages of securityfeatures suitable for high- and lowvaluetransactions.• Two-zone (PIN) security. SSL is used toverify the identity of the parties and to encryptthe connection from the Mobile e-Pay node to the connected Internet node.In GSM, native network security is usedfor authenticating end-users. This schemeis enhanced with user pass-code schemes,which require end-users to know andinput a pass code (a specific e-commercePIN) to approve ttansactions.• Two-zone PKI security. Using aPKI/RSA digital signature, Mobile e-Paysigns a contract after having presented itto the end-user. The digital signature istriggered when the end-user enters a staticpass code to confirm a purchase. Thisfeature, which does not require SIM applicationtoolkit (SAT) support, can beused to receive and sign contracts from- WAP 1.1 terminals; or- plain SMS.• End-to-end triple digital encryption standard(3DES) SAT security. End-users canauthorize digital contracts with SAT-enabledphones. On a combined WAP1.1/SAT phone, this means that messageauthentication code (MAC) authenticationcan be used to verify that the enduserapproves the transaction. The 3DESkey is stored in the SAT application. AnySAT phone—including non-WAPphones—can be used for push paymentsthat are initiated from another terminal.• End-to-end WPKI SAT security. Theend-user can sign a digital contract usinga SAT-enabled phone. RSA asymmetricalkeys are supported. The private key isstored in the SIM, which enables the useof true end-to-end RSA keys with nonrepudiation.Any SAT phone—includingnon-WAP phones—can be used for pushpayments that are initiated from anotherterminal.For end-to-end SAT security schemes, theSAT applications are also protected by a personalPIN on the SIM. This protects endusersagainst misuse by persons who find orsteal an authenticated GSM phone.Ericsson Review No. 2, 2000 89
Page 1: Ericsson 2/2000REVIEWTHE TELECOMMUN
Page 4 and 5: ContributorsIn this issueLuis Barri
Page 6 and 7: Ericsson Review is also published o
Page 8 and 9: Evolving from cdmaOne to third-gene
Page 10 and 11: Figure 2Operators Harmonization Agr
Page 12 and 13: more features, and greater reliabil
Page 14 and 15: Figure 7Ericsson's third-generation
Page 16 and 17: Figure 11Ericsson's timeline for ev
Page 18 and 19: Third-generation TDMAChristofer Lin
Page 20 and 21: TABLE 1 MODULATION AND CODING SCHEM
Page 22 and 23: Figure 3An example of a cell patter
Page 24 and 25: Figure 5Curves illustrating maximum
Page 26 and 27: TABLE 3. DYNAMIC PACKET DATA SIMULA
Page 28 and 29: erage can be achieved in existing c
Page 30 and 31: Business solutions for mobile e-com
Page 32 and 33: Figure 2Comparison of traditional a
Page 34 and 35: BOX B, THE E-COMMERCE TIMELINE1999E
Page 36 and 37: Figure 6Mobile e-Pay end-user servi
Page 40 and 41: AuthenticationTo verify that end-us
Page 42 and 43: BOX C, MARKET HARMONIZATIONOn Tuesd
Page 44 and 45: Figure 2The footprint of the RBS 22
Page 46 and 47: Communications security in an all-I
Page 48 and 49: BOX B, SYMMETRIC KEY SYSTEMSGood sy
Page 50 and 51: Figure 4Construction of an ESP-prot
Page 52 and 53: Figure 7An X.500 database structure
Page 54 and 55: Figure 9GPRS VPN scenarios.Figure 1
Page 56 and 57: TRADEMARKSRC4 and RC4 are registere
Page 58 and 59: HIPERLAN type 2 for broadband wirel
Page 60 and 61: Figure 3Typical usage of communicat
Page 62 and 63: Figure 6Mapping of higher layer pac
Page 64 and 65: TABLE 1PHYSICAL LAYER MODES OF HIPE
Page 66 and 67: Queen City WaterfrontEMERGING PROJE
Page 68 and 69: TABLE 2. IMPORTANT PARAMETERS FOR N
Page 70: Previous issuesNo. 1,2000IPv6—The

ericssonhistory.com

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?