wtls.xml

The Kannel Open Source WAP and SMS gateway works as both an SMS gateway, for implementing keyword b

					</listitem>
					<listitem>
						<para>The certificate&apos;s validity period</para>
					</listitem>
					<listitem>
						<para>The server&apos;s domain name</para>
					</listitem>
					<listitem>
						<para>The domain name of the CA that issued the certificate</para>
					</listitem>
				</itemizedlist>
				<para>The certificate is supplied with its hashed digest (see Section 2.5.1). The digest is encrypted using the private key of the CA that issued the certificate; this encrypted digest constitutes the CA&apos;s digital signature. If the digital signature can be decrypted using the CA&apos;s public key, then the certificate must have originated with the CA. (See Section 2.7 for more on digital signatures.)
</para>
				<para>Upon receiving the server&apos;s certificate, the client validates it by checking the following criteria:
</para>
				<itemizedlist>
					<listitem>
						<para>That it is valid for the current date.</para>
					</listitem>
					<listitem>
						<para>That it applies to the server that sent it.</para>
					</listitem>
					<listitem>
						<para>That the CA that issued it is known and trusted. (To do this, the client checks the CA&apos;s own certificate, which is signed by the CA itself.)</para>
					</listitem>
					<listitem>
						<para>That the CA&apos;s digital signature can be decrypted using the CA&apos;s public key. (Most Web clients contain a list of the public keys of the best known CAs, so they do not need to search the Internet for them.)</para>
					</listitem>
				</itemizedlist>
				<para>The client warns the user if the certificate fails any of these tests. The user may continue with the session at their own risk, if they wish.
 </para>
				<para>Digital certificates can be issued in chains. For example, a large CA might issue a certificate to a smaller CA, which issues a certificate to a still smaller CA, which issues end-entity certificates to Internet traders. This helps distribute the task of administering digital certificates. When an Internet client receives a certificate from a chain, it checks the certificate of every CA in the chain as described above, until it reaches the self-signed certificate of a top-level CA. 
</para>
				<para>Digital certificates are not only used by Internet servers: they can also be obtained for Internet clients. In practice, though, demand for client certificates has proved minimal. Authentication of a client by a server, where it is implemented at all, is usually through use of a user name and a password. While this method is not infallible, it nevertheless adds a layer of security to Internet transactions that is absent from many non-Internet confidential transactions ( for example, ordering goods by credit card over the telephone).</para>
			</section>
		</section>
		<section>
			<title>2.7 Non-repudiation
</title>
			<para>The final requirement of secure communications is non-repudiation: a message&apos;s source must be provable upon demand. Non-repudiation is normally achieved using <emphasis role="bold">digital signatures</emphasis>.
</para>
			<section>
				<title>2.7.1 Digital Signatures
</title>
				<para>A digital signature is simply a way of encoding data so that its source and its integrity are verifiable. Digital signatures use the same techniques of cryptography and hashing that are used to provide privacy and integrity protection (see Sections 2.3 and 2.4). The difference is that the roles of public and private keys are reversed.
</para>
				<para>Let us suppose that Abigail wants to stamp a message with her digital signature. First she passes the message through a hash function to create a message digest. She then uses her private key to encrypt the digest, and attaches the encrypted digest to the message. This encrypted digest constitutes her digital signature. (Of course, Abigail could encrypt the entire message using her private key; however, encrypting the digest is sufficient and much quicker.)
</para>
				<para>If Brian is the recipient of Abigail&apos;s message and wants to verify that it originated with her, he uses Abigail&apos;s public key to decrypt her signature. He then runs the message through the same hash function that Abigail used to create the digest, and compares it with the value of Abigail&apos;s decrypted signature.
</para>
				<para>The main users of digital signatures on the Internet at present are CAs, who stamp them on every certificate they issue (see Section 2.6). Although client-side digital signatures are an effective means of non-repudiation, demand for them has so far been minimal. This suggests that businesses and customers are happy to carry out transactions without them. Instead, client-side non-repudiation is normally implemented using password protection, which is regarded as an acceptable compromise between practicality and guaranteed security.
</para>
			</section>
		</section>
		<section>
			<title>2.8 Example Secure Transaction
</title>
			<para>Secure Internet transactions rely on quite complex combinations of public key cryptography, symmetric key cryptography, hash functions, digital certificates and digital signatures. The following example illustrates the sequence of steps involved in a typical SSL session.
</para>
			<para>Note that by far the most complex part of a secure Internet session is the initial <emphasis role="bold">handshake</emphasis>, whereby the parties agree on a secure data format for the rest of the session and, if necessary, establish each other&apos;s credentials.
</para>
			<para>This example demonstrates the most usual type of SSL handshake, with the client authenticating the server, but without the server authenticating the client. The transaction is summarised graphically in Figures 4, 5 and 6.
</para>
			<section>
				<title>Part One: SSL Handshake
</title>
				<orderedlist inheritnum="ignore" continuation="restarts">
					<listitem>
						<para>Abigail, a Web surfer, sees an item she would like to buy on Brian&apos;s Web site. </para>
					</listitem>
					<listitem>
						<para>Abigail clicks a button on Brian&apos;s Web site that sends a request for a secure Internet session to Brian. The following items are appended to the request:
</para>
						<para>- Various information about what versions of SSL Abigail&apos;s Web browser supports, what encryption algorithms it supports, and so on.
</para>
						<para>- Some randomly generated data. This will be used, along with other data, to generate the session key (see step X).

</para>
					</listitem>
					<listitem>
						<para>Brian receives Abigail&apos;s request for a secure session and sends her the following items:
</para>
						<para>- His digital certificate, including his public key. The certificate is signed by a trusted CA using its private key.
</para>
						<para>- Information about what versions of SSL Brian&apos;s Web server supports, what encryption algorithms it supports, and so on.
</para>
						<para>- Some randomly generated data which will be used in the generation of the session key.
</para>
						<para>Brian could also request Abigail&apos;s digital certificate. However, in practice it is very rare for a server to require a certificate from a client.
</para>
					</listitem>
					<listitem>
						<para>Abigail validates Brian&apos;s certificate as outlined in Section 2.6.1. If the validation is successful, she is happy that Brian is who he says he is, and that he is a reputable trader.</para>
					</listitem>
					<listitem>
						<para>Abigail performs a series of operations on the random data she sent to Brian, and the random data Brian sent to her, to produce a piece of data called the <emphasis role="bold">premaster secret</emphasis>.
</para>
					</listitem>
					<listitem>
						<para>Abigail encrypts the premaster secret using Brian&apos;s public key and sends it to Brian. (If Brian had requested her digital certificate, she would also send her certificate for Brian to validate.)
</para>
					</listitem>
					<listitem>
						<para>Brian receives the premaster secret from Abigail.
</para>
					</listitem>
					<listitem>
						<para>Brian decrypts the premaster secret. He and Abigail simultaneously perform a series of operations on it, to arrive at a piece of data called the <emphasis role="bold">master secret</emphasis>.</para>
					</listitem>
					<listitem>
						<para>Abigail and Brian simultaneously perform a series of operations on the master secret to arrive at the session key (see Section 2.4.3), which will be used to encrypt the information they want to send to each other.
</para>
					</listitem>
					<listitem>
						<para>Abigail sends Brian two messages. The first confirms that all further messages from her will be encrypted using the session key. The second is an encrypted message that formally ends the handshake from her side.
</para>
					</listitem>
					<listitem>
						<para>Brian sends Abigail two messages. The first confirms that all further messages from him will be encrypted using the session key. The second is an encrypted message that formally ends the handshake from his side.
</para>
					</listitem>
				</orderedlist>
				<mediaobject>
					<imageobject>
						<imagedata fileref="fig4out&figtype;">
					</imageobject>
					<caption>
						<para>Figure 4: SSL handshake. Step numbers correspond to those in the textual account
</para>
					</caption>
				</mediaobject>
			</section>
			<section>
				<title>Part Two: Transfer of Confidential Information
</title>
				<orderedlist inheritnum="ignore" continuation="continues">
					<listitem>
						<para>Abigail fills in the relevant form on Brian&apos;s Web site, including her credit card details. She presses a button which sends the form to Brian, encrypted using the session key.
</para>
					</listitem>
					<listitem>
						<para>Brian receives Abigail&apos;s credit card details and decrypts them using the session key.
</para>
					</listitem>
				</orderedlist>
				<mediaobject>
					<imageobject>
						<imagedata fileref="fig8o&figtype;">
					</imageobject>
					<caption>
						<para>Figure 5: Transfer of confidential information using SSL. Step numbers correspond to those in the textual account
</para>
					</caption>
				</mediaobject>
			</section>
			<section>
				<title>Part Three: Secure Session Closure
</title>
				<orderedlist inheritnum="ignore" continuation="continues">
					<listitem>
						<para>Abigail and Brian both discard their session keys.</para>
					</listitem>
					<listitem>
						<para>Brian closes the secure session.</para>
					</listitem>
				</orderedlist>
				<para>Finally, Brian sends Abigail her item and her credit card company the bill.</para>
				<mediaobject>
					<imageobject>
						<imagedata fileref="fig7o&figtype;">
					</imageobject>
					<caption>
						<para>Figure 6: SSL session closure. Step numbers correspond to those in the textual account
</para>
					</caption>
				</mediaobject>
			</section>
		</section>
	</chapter>
	<chapter>
		<title>3  Mobile Internet Security</title>
		<section>
			<title>3.1 Wireless Transport Layer Security (WTLS)</title>
			<para>Mobile Internet security uses the same methods of encryption, hashing, digital certificates and digital signatures that SSL provides for the terrestrial Internet. However, instead of SSL, the Mobile Internet is served by a streamlined protocol called Wireless Transport Layer Security (WTLS). WTLS is an optional component of the Mobile Internet&apos;s Wireless Application Protocol (WAP) stack. It resides between the Wireless Datagram Protocol (WDP) and the Wireless Transaction Protocol (WTP) layers of the WAP stack. The structure of the WAP stack is shown in Figure 7. 
</para>
			<mediaobject>
				<imageobject>
					<imagedata fileref="fig10o&figtype;">
				</imageobject>
				<caption>
					<para>Figure 7: The WAP stack
</para>
				</caption>
			</mediaobject>
			<para>Like any Mobile Internet transaction, a secure Mobile Internet transaction extends across both the mobile telephone network and the Internet, using WAP for the wireless part of the journey, the Hypertext Transfer Protocol (HTTP) suite for the Internet part, and a WAP gateway in the middle to translate between the two. Figure 8 shows an overview of Mobile Internet communication, from the mobile device at one end to the HTTP server at the other. If security is required across the whole communication channel, SSL can be used between the WAP gateway and the HTTP server. Alternatively, the content provider can host the gateway themselves. (As will be seen later, this arrangement provides optimum security.)
</para>
			<mediaobject>
				<imageobject>
					<imagedata fileref="fig9o&figtype;">
				</imageobject>
				<caption>
					<para>Figure 8: WAP communication overview
</para>
				</caption>
			</mediaobject>
			<para>Like WAP as a whole, WTLS uses the Internet as a model for its procedures and is very similar, in outline, to SSL. However, it has a number of additional characteristics:</para>
			<itemizedlist>
				<listitem>
					<para>
						<emphasis role="bold">Compact coding.</emphasis> WTLS employs more compact coding than SSL, in order to keep messages as short as possible and to minimise the time and processing power required by the client device to interpret and transmit them. These measures help to offset the speed limitations imposed by the high latency and low bandwidth of wireless networks. They also compensate for the low power and computational resources of mobile devices.</para>
				</listitem>