The WAP Forum's technical documentation defines a handshake as "the procedure of agreeing on the protocol options to be used between a client and a server. It includes the negotiation of security parameters (e.g., algorithms and key lengths, key exchange, and authentication). Handshaking occurs in the beginning of each secure connection."

Handshakes set the stage for the rest of the secured session. As a developer, it's beneficial to understand handshakes, especially considering the growing emphasis on security among businesses adopting "m-commerce" (mobile commerce) models.

Handshakes All Around
There are three different types of handshakes: full, abbreviated, and optimized. After a handshake is completed and all the parameters are agreed upon, secured transmission of data can occur. Both server and client know which algorithm to use to encrypt and decrypt data, and recognize each other as authenticated information sources. This allows you, as a WAP developer, to write wireless apps that securely transmit information such as credit card numbers and financial transactions.

How do these types of handshakes differ? A full handshake establishes an entirely new secured connection for each connection. (I'll discuss later exactly how this occurs.) An abbreviated handshake uses an existing, secured connection. For example, suppose a cell phone has already established a secured connection to a server. It then requests an additional connection. The information established in the previous connection is "recycled" so that fewer resources are consumed. Credentials provided in the previous handshake are reused to establish additional secured channels more quickly. An optimized handshake is a new secured session, but the authenticating server relies exclusively upon information it has on its own servers for authenticating the requesting gateway/device. Think of it as a cached, secured connection.

Role of Service Primitives
Handshakes are the first stages of communication between the different layers of the protocol stack and—particularly in this case—the security layer and the layers above and below it. This handshake consists of a series of service primitives, which are basically pre-designed, arranged messages that can be sent from one layer to other layers adjacent to it.

There are four primitives:

• Request (.req): A higher layer requests a service from a lower layer
  
• Indication (.ind): The lower layer responds to the higher layer's request
  
• Response (.res): The higher layer acknowledges receipt of the indication
  
• Confirm (.cnf): The requested layer confirms that the activity was completed

Figure 1. Click here.

Figure 1 takes what I've just covered and applies it to a simple full handshake. (Click on it to read the details.) Here's how the particular service primitives fit into the scenario:

• Create initiates a new secure connection
  
• Exchange is used when the server wants to use public-key authentication or key exchange with the client
  
• Commit is used when all the security parameter negotiations have been completed in the initiation, and the two layers agree to move to a secured connection state
  
• Unidata is the secured data that is sent between the two layers

Figure 2. Click here.

Compared to a full handshake, abbreviated and optimized handshakes (see Figure 2) have a much quicker sequence of primitives—hence their advantage with regards to system resources and associated overhead. Essentially, you save processor cycles on both the server and the client because they access their system resources less frequently, so the transaction, in general, proceeds much more quickly. Bandwidth is also conserved, simply because you are using less time to establish the connection and move to a secured connection state.

Understanding these basic concepts of layer communication—in particular, with regards to security—helps you understand overall how the protocol stack works and gives you a much clearer picture about what's going on when the application requests secured resources over a wireless network on your behalf.

Return to Get Help with Wireless Dev Page

Return to Main Get Help Page