|
Oracle® Application Server Wireless Administrator's Guide
10g Release 2 (10.1.2) B13820-02 |
|
 Previous |
 Next |
|
Oracle® Application Server Wireless Administrator's Guide
10g Release 2 (10.1.2) B13820-02 |
|
|
Previous |
Next |
This chapter includes the following:
Section 10.2, "Resources Protected by Oracle Application Server Wireless"
Section 10.3, "Configuring the Security Infrastructure to Support Wireless"
Section 10.4, "Installing and Configuring Oracle Application Server Wireless Security"
OracleAS Wireless combines advanced content transformation, device adaptation and network adaptation services with end-user customization, providing enterprises, mobile operators, content providers, or wireless ISPs with a platform to create and deploy mobile applications. OracleAS Wireless incorporates various security mechanisms that enable the deployment of end-to-end secure, unbreakable applications.
To provide a clear understanding of security and its application in the wireless world, this section provides brief descriptions of the principles of security and describes common application deployment models for both the wired and wireless world, explaining their similarities and differences in regards to security. Subsequent sections describe these security principles in more detail, provide available deployment scenarios, and identify any issues that are wireless-specific and the present OracleAS Wireless solution.
The principles of security are:
Communication Data Privacy: Unintended parties cannot observe data during transmission (on the network).
Data Privacy usually denotes encryption of data, either at the transport layer or at the application layer.
Technologies for communication data privacy are Virtual Private Networks (VPNs) and secure transport layer protocols (for example, WTLS, TLS).
Authentication: Verifying the identity of one or more parties (that is, who is the user?).
Authentication denotes a wide range of technologies with different requirements and degrees of security, including user names and passwords, certificate-based 2- (or 3-) factor authentication.
Authorization: Access control of authenticated parties (that is, what can the user do?).
Authorization involves checking bindings between user identities with user capabilities: "what is this user allowed to do?"
Most authorization systems involve the concepts of Users, Groups, Roles, Policies and Access Control Lists (ACLs).
Data Integrity: Data cannot be tampered with when in transit or in storage.
Data Integrity means protection from malicious or accidental data alteration, data omission and data replay (that is, avoid replay attacks).
Several technologies provide data integrity in such forms as Message Authentication Codes (MACs), digital signatures, protection through encryption.
Non-Repudiation: Authenticated users cannot disclaim the transactions that they have made.
Non-repudiation allows for digital content signing and enables contract enforcement by making transactions undeniable and openly verifiable (that is, verifiable to a third party).
Non-repudiation is usually achieved using digital signatures.
Storage Data Privacy: Unintended parties cannot observe sensitive data (for example, credit card numbers) during storage (on the database or file system).
Storage Data Privacy usually denotes a combination of access controls and encryption of highly sensitive data.
AES (Advanced Encryption Standard) is the new symmetric encryption algorithm approved by the U.S. Federal Information Processing Standard (FIPS).
Accountability: As part of accountability, auditing enables logging of security-related traces for all other security principles.
Availability: Includes attack countermeasures to protect the system from attacks such as denial of service attacks.
|
Note: This chapter discusses the security principles which are specific to OracleAS Wireless (Communication Data Privacy, Authentication, Authorization and Non-Repudiation). Beyond this overview, this chapter does not describe the non-OracleAS Wireless principles, such as Storage Data Privacy. |
This section describes the differences and similarities of security in both wired deployment and wireless deployment.
Figure 10-1 depicts the basic arrangement of deployment in the wired world: a wired device, such as a PC, connects over the network to an application server.
The main security characteristics of the wired deployment scenario are:
Data travels across the wire. This data may be protected by a secure communication protocol, such as SSL. Encrypted communication between the device and the application server is regarded as end-to-end secure, as the communication can be carried out without intermediate nodes that intercept and modify the information.
Online application access is usually controlled through user name and password authentication (traveling over the protected communication link). More secure schemes make use of digital certificate-based technology or tokens (for example, RSA SecurIDs).
Access control is carried out at the application server side by checking the permissions set for the authenticated user.
Data integrity is provided along with communication data privacy through encryption.
Wired applications requiring some measure of non-repudiation usually resort to using transaction logs. Strong non-repudiation can be carried out through digital signatures.
Sensitive data residing at the server side in the database can be protected through encryption and access controls.
Log files provide security auditing of transactions and malicious activity.
Attack countermeasures, which usually include fire walls and demilitarized zones (DMZs), restrict direct application server exposure to the public network (that is, the Internet).
Figure 10-2 depicts the deployment scenario for wireless devices. The wireless device, a device limited in both power and bandwidth, stands at one end of the transaction. The wireless device communicates over the air through a wireless network to a gateway component which performs the translation from the wireless network protocol to the wired network protocol so that the device can contact the application server.
Figure 10-2 Security Chain in Wireless Transaction Flow
The wired side of the wireless network is practically the same as the wired deployment scenario explained in Section 10.1.1.1. However, because of the added components in the transaction flow, the following security considerations arise:
Network protocol conversions: In contrast to the wired deployment scenario, wireless application deployment requires that the wireless gateway intervenes in the communication to perform protocol conversions from the wireless network to the wired network. The problem arises when the wireless protocol is not directly interoperable with the wired protocol (as it is in many cases), causing network level communications to no longer be end-to-end secure and thus becoming only point-to-point secure. Such "leg-based" communication may be justifiable where there is need for little or no security (for example, a public news server) but may not be acceptable for the most security-conscious applications, such as mobile banking or corporate applications.
Limited computational power and bandwidth in the wireless network and device: The restricted power of the wireless device along with the low bandwidth of wireless networks requires the deployment of more efficient and economical encryption mechanisms such as Elliptic Curve Cryptography (ECC) in WPKI. This requires special support by the application server in terms of integration.
Lack of well-defined authentication standards: While password authentication is both common and standard in the wired world, it is not perceived as being highly secure, especially in the context of mobile applications. This causes the introduction of various authentication mechanisms with tight coupling to the physical wireless device causing authentication (and other types of security such as non-repudiation) mechanisms to be dependent on the device.
There are two classes of OracleAS Wireless users: registered users and anonymous users. The registered users are users whose user information is registered with the Oracle Internet Directory (OID). These users can be created, modified, or deleted through the User Manger or the OID DAS tool. Anonymous users are these users that have not been registered with OID. Anonymous users can only access the wireless and voice applications assigned to the Guest group. A registered user can only access the wireless and voice applications assigned to the groups to which that user belongs. For more information on anonymous users and assigning users to groups, see Chapter 5, "Managing Users". For information on assigning applications to user groups, see Section 6.5. For more information on creating users with OID, see the Oracle Internet Directory Administrator's Guide.
The OracleAS Wireless Tools, such as the User Manager, are role-specific; OracleAS Wireless users can only access the tool which corresponds to the role or roles that they have been granted. The User Manager assigns these roles when creating (or updating) a user. A user can have one or several roles, which include System Administrator, Application Developer, Foundation Developer, Content Manager, User Administrator, and End User. These roles span all of the OracleAS Wireless resources, from server management, application development, application publishing, and help desk to subscription to the OracleAS Wireless applications. For more information on OracleAS Wireless user roles, see Section 10.2.
The OracleAS Wireless meta data repository does not store any sensitive information. Instead, information such as the user passwords, voice-accessed PINs, and the password to the OracleAS Wireless meta data schema are stored in Oracle OID.
Sensitive resources (such as the OracleAS Wireless Tools) are protected through access controls and various authentication mechanisms, such as user names and passwords. Service access is also protected the user names and passwords.
Access to the OracleAS Wireless tools is controlled through user roles, which not only provide access to the tools, but define the capabilities of the OracleAS Wireless user as well. Table 10-1 describes the user roles, their capabilities and the resources that these roles enable.
Table 10-1 Wireless User Roles
| User Role | Description | Available Tools |
|---|---|---|
|
Application Developer |
Users assigned the Application Developer role perform the following functions:
|
Service Manager |
|
Foundation Developer |
Users assigned the Foundation Developer role perform the following functions:
|
Foundation Manager |
|
Content Manager |
Users assigned the Content Manager role perform the following functions:
|
Content Manager |
|
System Administrator |
Users assigned the System role manage the system using the System Management Tool. |
Wireless system management functions (through the Oracle Enterprise Manager Application Server Control). |
|
User Manager |
Users assigned the User Manager role perform the following functions:
|
User Manager |
|
Sensor Services Administrator |
User assigned the Oracle SensorEdge Services Administrator role manage the devices and filters used with the Edge Server. These functions inlcude:
|
Sensor Services Tool |
|
End User |
Users assigned the end user role are the consumers of OracleAS Wireless services. End-users create their own accounts when they register with OracleAS Wireless using the OracleAS Wireless Customization. End users can also customize their own services either from a desktop or from a device. Customization for end-users includes:
Mobile studio users also have the end user role; a user belonging to the StudioUser group can access the Mobile Studio. Every OracleAS Wireless user is granted the Mobile Customer Role by default. This role is implicit to all users. |
Wireless Customization Portal Mobile Studio (for users assigned to the StudioUser group) |
In OracleAS Wireless, a user group is the means by which users can access any voice and wireless application; any application that has been published to a user group is available to all of that group's members. The Content Manager can both create a user group and assign applications to a user group, which is a collection of users. The user manager assigns users to user groups. See Section 6.5 for information on publishing an application to a user group and Section 6.5 for assigning a user to a user group.
Access Control to applications in Oracle Application Server Wireless is provided according to the channel used to connect to the server. For visual HTTP-based channels such as WAP, Oracle Application Server Wireless authenticates users through user names and passwords; for voice-accessed applications, OracleAS Wireless uses account numbers and PINs; for message-related applications, OracleAS Wireless checks the user account information (for example, OracleAS Wireless checks the e-mail headers). For web services related to the messaging infrastructure, OracleAS Wireless authenticates users through user names and passwords.
Besides user name and passwords, OracleAS Wireless allows for other authentication mechanisms, depending on the device. However, the application developer is responsible for choosing and integrating the appropriate mechanism for the target device. The authentication mechanisms available in the various channels and how they can be used are as follows:
WAP: With WPKI, the end users can utilize their WAP device to sign a "challenge" (a randomly generated string) sent by an authentication service. The authentication service requests the signature through WMLScript's signtext() function. Upon receiving a signature request, the WAP device prompts the user to enter his or her local PIN (which authenticates the user only to the WAP device) and then retrieves the user's WPKI private key (stored in a SIM chip in the WAP phone) to sign the challenge. Once the authentication service receives the signed challenge, it is verified with the user's WPKI public key (possibly stored in a user's certificate repository such as the Oracle Wallet Manager) and notifies the requesting application of the result. WMLScript's signtext() function is available with WAP 2.0.
SMS: SMS-based authentication can occur in two ways with varying degrees of security. The most basic authentication is to reply (with a PIN) to an SMS received from the authentication service. Another SMS-based authentication mechanism relies on digital signatures; this mechanism is similar to the WAP case.
E-mail: Authentication consists of sending a reply (with a PIN) to an e-mail sent by the authentication service.
Voice: The authentication service calls the user and asks for a PIN. Once the user provides the PIN, the system then authenticates the user.
The OracleAS Wireless tools and the Customization Portal are protected by the Oracle HTTP Server SSO (Single Sign-On) plugin module (mod_osso). The mod_sso protects all the URL access to the OracleAS Wireless tools. If any part of the URL access is not authenticated, then the mod_sso redirects the request to SSO for authentication. For more information, see the Oracle Application Server Single Sign-On Administration Guide.
To further secure the communication channel between the browser and the OracleAS Wireless tools, or the wireless gateway (for example, the WAP gateway, or the voice gateway), you can enable SSL on the Oracle HTTP Server. For more information on configuring SSL on the Oracle HTTP Server, see the Oracle HTTP Server Administrator's Guide.
In addition, you can also enable the SSL-based secured communication channel between the OracleAS Wireless Multi-Channel Server and remote application server by installing either Base64 certificate or PKCS#7 formatted certificate at the OracleAS Wireless Multi-Channel Server. You can install such a certificate through the System Manager (accessed through Oracle Enterprise Manager). For information on using the System Manager to configure an SSL certificate, see Section 3.9.1.
SSO is a feature (one not specific to OracleAS Wireless) that eliminates the need for repeated authentication (within a period of time) when crossing application boundaries for the same trusted domain. It also provides for centralized user credentials, which avoids the problem of having to remember passwords for different applications, thereby increasing security for the whole system, as passwords do not need to be written down.
OracleAS Wireless is fully integrated with SSO, which currently supports authentication through user names and passwords over all visual HTTP-based channels and through account number and PIN for voice-based channels.
SSO also integrates with the Oracle Internet Directory (OID), an LDAP server that stores, among other things, valid end-user authentication information such as passwords and digital certificates.
The user information stored in OID is replicated to the OracleAS Wireless meta data schema when a user logs in, or through asynchronous synchronization from OID to the OracleAS Wireless schema. Table 10-2 lists the user attributes (stored in OID) that are replicated in OracleAS Wireless schema.
Table 10-2 User Attributes Stored in the OracleAS Wireless Schema
| Attribute Name | Description |
|---|---|
|
orclCommonNickNameAttribute |
The user name used for authentication for all channels, except voice. By default this is cn (as specified in OID configuration). |
|
userPassword |
The user password, used for authentication for all channels, except voice. |
|
orclPasswordHint |
The password hint |
|
orclPasswordHintAnswer |
The answer to the password hint |
|
orclWirelessAccountNumber |
The account number, used for authentication from voice channel. This must be comprised of digits only. |
|
orclPasswordVerifier; orclCommonPIN |
The PIN used for voice authentication. This must be comprised of digits only. |
|
displayName |
The display name of the user |
|
orclIsEnabled |
A flag whether the user is enabled |
|
preferredLanguage |
The Locale, such as the. language and country, for example en_US indicates English and USA |
|
orclTimeZone |
The user's default time zone |
|
orclDateOfBirth |
The user's date of birth |
|
orclGender |
The user's gender |
OracleAS Wireless depends on the security infrastructure to be up both during installation time and runtime. Refer to the Oracle Application Server Administrator's guide for details on the security infrastructure.
OracleAS Wireless relies on Directory Integration Platform (DIP) server, as one of the mechanisms, to asynchronously replicate the essential modified user information from OID to the OracleAS Wireless schema. Refer to the Oracle Internet Directory Administrator's Guide for details on how to start the DIP server.
By default, the OID server does not enforce unique constraints on account number (that is, the orclWirelessAccountNumber attribute of orclUserV2 object class). The account number is required for users accessing wireless applications from a regular voice line with the account number and PIN used for the authentication. As part of the OracleAS Wireless installation, the OracleAS Wireless configuration assistant enables the policy to enforce a unique constraint on the orclWirelessAccountNumber attribute of orcluserV2 object class. The OID server must be restarted after the first OracleAS Wireless installation for this unique constraint policy to take effect. Refer to Oracle Internet Directory Administrator's guide for details on how to restart the OID server.
OracleAS Wireless connects to the OID as a OracleAS Wireless application entity after users have been authenticated through SSO. The OracleAS Wireless application entity is assigned following privileges:
Common user attributes: privilege to read common attributes of a user.
OracleDASCreateUser: The privilege to create users in OID.
OracleDASDeleteUser: The privilege to delete users in OID.
OracleDASEditUser: The privilege to edit common attributes of users.
verifierServices: The privilege to read application verifiers (the user PIN) which are stored in the user.
authenticationServices: The privilege to perform compare operations on password attributes of a user.
By default, the OracleAS Wireless application entity does not have the privileges to change the user password. Consequently, out-of-the-box users cannot change their password from theOracleAS Wireless server. However you can enable the functionality to change passwords by assigning the UserSecurityAdmins privilege to the OracleAS Wireless application entity. To do this, execute assignUserSecurityAdminsPrivilege.sh (or assignUserSecurityAdminsPrivilege.bat, depending on the operating system) on the machine on which OracleAS Wireless is installed. The script is available in the ORACLE_HOME/wireless/bin directory.
The syntax for invoking the utility is as follows:
assignUserSecurityAdminsPrivilege.sh oid_super_user_dn user_password
where
oid_super_user_dn is the Distinguished Name (DN) of the OID super user. The user should have privileges to grant UserSecurityAdmins privilege to application entities
user_passord is the password of the OID super user
For example:
assignUserSecurityAdminsPrivilege.sh cn=orcladmin welcome1
This section describes Communication Data Privacy and Non-Repudiation principles of wireless security. In discussing these principles, this section provides alternatives available to application developers when incorporating security in OracleAS Wireless. In some cases, OracleAS Wireless does not provide direct support for security on a given channel, leaving the responsibility to the application developer to recognize the security needed for the application and to deploy the appropriate security mechanisms.
Communication Data Privacy is the principle of security that prevents data in transit (on the network) from being partially or completely observed by unintended parties or eavesdroppers. Along with authentication, communication data privacy is one of the most important aspects of wireless application security.
This section focuses on end-to-end data privacy, where no intermediate nodes (or actors) are able to understand the data that passes through them. For example, the wireless carrier's WAP gateway should not be able to understand the sensitive information, even when all the data passes through it. End-to-end data privacy stands in contrast to point-to-point (or leg-based) data privacy, where data is secured between servers and devices but intermediate nodes can see the data in "the clear".
Given the variety of (wireless) networks and protocols, communication data privacy differs among the various communication channels. The following sections describe communication data privacy deployment solutions based on the communication channels:
Internet Protocol (Web) communication is currently used today in the wired world with standardized security through SSL encryption. PCs connect to the application server directly with point-to-point privacy using HTTPS, which is HTTP running over an SSL-secured link (Figure 10-3). Since there are no intermediate nodes performing protocol translations at the security layer (as there are WAP 1.x), data communication is end-to-end private between the browser and the application server.
Because OracleAS Wireless supports HTTPS connections, PC browser connections are point-to-point secure.
The wireless extension to the PC browser is through the use of HTTP devices that connect to a wireless LAN gateway, as it is in the case of Pocket PCs with wireless LAN card adapter. The connection from the device to the wireless LAN gateway follows the 802.11b standard for wireless communication, which is interoperable with the wired Internet protocol since it uses the Ethernet protocol. Since both protocols (wired and wireless) are interoperable at the security layer, point-to-point secure communication is also carried out through HTTPS from the device to the Application Server (as depicted in Figure 10-4).
Figure 10-4 Wireless LANs and Other HTTP-Based Devices
Without HTTPS security at the application layer, wireless LANs are insecure even with the use of the Wired Equivalent Privacy (WEP) protocol, a protocol operating at the data link layer designed to protect communication but which has been shown to be insecure. Therefore, wireless networks that depend solely on WEP for privacy are found to be vulnerable to "war-driving", an attack where the eavesdropper 'drives by' with a wireless receiver to break WEP security and decode wireless information.
Figure 10-5 Wireless Application Protocol (WAP)
Security in the Wireless Application Protocol (WAP) is currently specified in the WTLS (Wireless Transport Layer Security) protocol. Similar in design to SSL (TLS), but optimized for bandwidth and power, WTLS provides privacy from the wireless device to the WAP gateway, allowing for server authentication and mutual authentication modes.
WAP has been widely criticized by the security sector on what is commonly called the 'WAP gap', which breaks end-to-end communication data privacy. The WAP device communicates with the WAP gateway through WTLS (the WAP pictured in Figure 10-5) and the WAP gateway, in turn, communicates with the application server using SSL (Internet zone.) Since WTLS is not compatible with SSL because of handshake optimizations, a protocol translation needs to occur at the WAP gateway (the Grey Zone pictured in Figure 10-5): that is, WTLS-encrypted data must be decrypted and be SSL-encrypted. The 'WAP gap' refers to this split second when the data is in the clear at the WAP gateway; this alone breaks end-to-end privacy and is a cause of concern for the banking industry and the most security-conscious.
For WAP 1.x deployments, bridging the WAP gap can be accomplished by redirection to subordinate pull proxy (gateway) with WAP 1.2. If, in addition to the WAP gateway at the carrier side, there is another WAP gateway residing within the same physically secured, trusted domain as the application server (that is, both are owned by the same company), then communication can be redirected to this enterprise gateway and can thus be considered end-to-end private. In this way, the WTLS connection would be established with a gateway located at the site of the application service provider and it would also allow for WTLS class 3 (client and server authentication).
Some gateways, such as the OpenWave's Mobile Gateway server, already support the deployment of proxy gateways at the premises of the content provider. In this model, after the subordinate proxy discovery process, requests will be rerouted to the proxy gateway installed within the secure premises of the provider hosting the OracleAS Wireless application server. The network operator retains the control of the calls at the cost of sharing the burden of supporting the infrastructure required for end-to-end secure communications.
The disadvantage of this solution is that the company hosting the application server must deploy and maintain its own WAP gateway. User Agent devices, such as Nokia Mobile Browser 3.0, already support this deployment model.
In the next generation of WAP (WAP 2.0), WAP designers will eliminate WAP gap by introducing Internet Protocols. That is, WAP devices which can securely communicate using SSL. In addition, no translation will be necessary at the WAP gateway, thus providing end-to-end privacy. This is a step to ensure that WAP devices are interoperable with the wired Internet.
The Short Message Service (SMS) deployment architecture dictates that messages be routed through a Short Message Service Center (SMSC) from the application server to the wireless device (as depicted in Figure 10-6).
Under SMS, required security for a given deployment scenario depends largely on the business model (for example, carriers versus corporations) of the enterprise deploying the solution. Given these different business models, secure deployment alternatives are as follows:
No Transport Security Needed: This scenario relies on the existing security of the wireless network protocol provided from the SMSC to the wireless device (for example, GSM network security.) In this scenario, there is no secure link between the application server and the SMSC. This deployment alternative is end-to-end secure only when the application server and the SMSC reside within the same secure domain (that is, both SMSC and application server are co-located in the same physically secured zone to reduce risk from internal eavesdroppers or attackers); carriers providing applications to their subscribers benefit the most from this solution as it fits their business model.
Point-to-point security: Another alternative consists in securing the link between the application server and the SMSC with the use of VPN (virtual private network) or SSL-secured connections. This deployment alternative applies when the application server and the SMSC reside in different (albeit secure) domains. Unfortunately, a problem similar to the 'WAP gap' (see Section 10.4.2.2) occurs here because there is a translation from the wireless protocol (used for communication between the wireless device and the SMSC) to the wired protocol (used for the communication between the SMSC and the application server) that leaves the data exposed at the SMSC. In other words, this deployment solution is not considered end-to-end secure. However, given current technology, this is the optimum deployment scenario for businesses that do not have a pre-existing relationship with their customers, as is the case for merchants.
Application Level security with Symmetric Shared Encryption Keys: This deployment scenario provides end-to-end data privacy by performing symmetric encryption at the device and at the application server: since data is encrypted above the network protocol, no intermediate nodes can observe the data while en route. End-to-end communication data privacy under this deployment scenario requires application level encryption support through a SIM/WIM card with encryption capabilities. OracleAS Wireless currently supports Triple DES symmetric key encryption at the application layer. This means that tag content information (that is, not all of the payload) is encrypted and decrypted at the device and is then decrypted and encrypted at the application server.and that there is a shared secret encryption key between each user and the OracleAS Wireless application server. The encryption key is stored in the SIM card and is initially produced at time of manufacture and re-keying on a periodic (or other) basis is possible under a set of well-defined security conditions. This deployment scenario best fits corporations that want to provide applications to their mobile field forces.
A more scalable and generic alternative is the use of application layer PKI encryption, which eliminates the need of a pre-existing relationship between end-consumer and the business. Unfortunately, there are currently no SIM card vendors that offer PKI encryption capabilities (only signature capabilities) as there is no standardized way for key generation and certificate provisioning for SMS.
Just as in SMS, end-to-end private e-mail communication depends on the deployment scenario.
Depending on such factors as the capabilities of the e-mail device and the location of the end-user e-mail server in respect to the application server, several alternative solutions exist:
No Transport Security Needed: In this deployment scenario, an end-user's e-mail server and the application server both reside within the carrier's secure domain. Since e-mail communication never leaves the secure domain (that is, the only direction of communication is from within the carrier to the device), there is no need to additionally secure the communication beyond the security provided by the wireless network protocol in the "air." The disadvantage of this solution is that it applies only to carriers that offer at the same time both e-mail and application services to their subscribers.
Point-to-point security: In this deployment scenario, the e-mail server and the application server both reside within the same secure domain at an enterprise other than the carrier. This solution secures communication from the carrier to the enterprise e-mail server by establishing a TLS- or SSL-secured connection such as Secure SMTP. In this scenario, the wireless device uses the carrier's system to retrieve the e-mail message, and in turn the carrier system communicates with the e-mail server using a TLS or SSL secured connection. Unfortunately, this solution is not end-to-end secure given the fact that the wireless carrier can "see" the e-mail message before it is sent to the end-user.
Symmetric Key encryption security: Certain devices such as RIM's Blackberries are built-in with symmetric encryption capabilities to access corporate e-mail. In this case, the deployment assumptions are the same as those for the 'Point-to-point security' scenario. However, e-mail communication is secured by encrypting the e-mail at the enterprise side with a shared encryption key, which is also present at the wireless device. Under this solution, the link between the carrier and the e-mail server does not have to be secured, as the payload is encrypted at the application layer. This benefit of this solution is that it is end-to-end private. The limitation of this solution is that it assumes a pre-existing relationship between the enterprise sending the e-mail and the end-user; therefore this solution is best applied to corporate wireless applications.
End-to-end data privacy over e-mail can also be enabled with PKI, which would allow for secure e-mail communication between parties that do not have a pre-existing relationship. E-mail privacy is carried out in the wired world with the use of S\MIME and PGP, a hybrid of symmetric and PKI-based encryption algorithms. Although S\MIME is supported in PC e-mail browsers such as Outlook or Netscape, it is not supported by current Palm e-mail applications and RIM Blackberries.
Voice communication over regular (wired or wireless) phone lines is not end-to-end secure in general. In fact, governments such as that of the United States have taken steps (through laws such as the Digital Telephony Bill or the Digital Wiretap Law) to facilitate the wiretap of phone communication systems.
Despite these non-technical issues, voice line security can be implemented in the data network, thus discouraging eavesdroppers on a digital network. The following secure solutions are available in the voice channel:
No Transport Security Needed: As in SMS and e-mail, this deployment scenario depicts both the voice gateway and the application server residing within the same (trusted) domain. Since no data passes through a public digital network such as the Internet, then there is no need to secure the transport communication between the application server and the voice gateway from outsider threats (however, insider threats still remain.) Therefore, communication security relies upon the phone line security itself.
HTTPS-secured connections between Voice Gateway and the Application Server: In this solution scenario, there is a secure HTTPS connection established between the voice gateway and the application server. This point-to-point security solution makes most sense when the voice gateway and the application server reside in different domains such as when the voice gateway is hosted by a third party. HTTPS is enabled with all major voice gateways (for example, Motorola and VoiceGenie) for SSL-secured connection between the gateway and the application server.
Finally, there are phone devices and third-party mechanisms that claim to provide voice encryption technology that protects communication between two ends of the phone conversation. However, the security of these technologies is not well established and some mechanisms have been breached. In addition, these mechanisms are expensive and not scalable, as they require hardware deployment at the client side.
Non-Repudiation refers to the mechanism where accepted transactions cannot be disclaimed and can be openly verified as valid. For example, in the mobile commerce world, payments cannot be denied. Non-repudiation would allow for such transactions to be openly verifiable and undeniable by the parties involved.
Non-repudiation mechanisms are based on digital signatures, which are analogous to regular ink signatures. Among the many digital signature schemes are DSA (Digital Signature Algorithm), Schnorr's signature and RSA signature - DSA being the most widely used, since the U.S. government has used it as the Digital Signature Standard (FIPS 186). In the wireless world, digital signature mechanisms vary from device to device based on the device's capabilities.
Below are the different means of generating digital signatures across several devices. However, the developer must provide code integration for these non-repudiation mechanisms.
WAP: Digital signature mechanism is carried out through WMLScript's signtext() mechanism (available with WAP 2.0.)
SMS: the non-repudiation service sends an SMS to the end user GSM phone requesting a signature. The SMS device detects the signature request and asks the user to enter a PIN (to authenticate the user locally) to start the signing process. The end user, after reviewing the content to be signed, authorizes (or rejects) the signing and the encryption-enabled SIM chip on the device proceeds with the signature.
E-mail: non-repudiation can be enabled for e-mail clients that have signature capabilities such as SMIME enabled clients. This is currently only possible for PC e-mail clients.
