There are two issues with regard to security in the WAP
environment. There are ways of addressing both of these issues, but
they both remain issues that need to be addressed.
The Gateway
We have established that there is a security gap in the WAP
model in the form of the WAP gateway. Because of the way that WAP
works it is not feasible to do away with the gateway, so we need to
establish to what extent it actually is a risk and what the
alternative ways of addressing the risk are.
It can be argued that the WAP gateway is not actually a security
risk because the gateway vendors are aware of the issue and
therefore take steps to ensure that the process of decrypting from
WTLS and re-encrypting into TLS cannot easily be compromised.
Typical of the steps taken will be to ensure that the decryption
and re-encryption takes place in memory, that keys and unencrypted
data are never saved to disk, and that all memory used as part of
the encryption and decryption process is cleared before being
handed back to the operating system.
The first problem with all of this is that there are no
standards of guarantees about these precautions. You have no way of
ascertaining how robust your vendor's implementation actually is,
and in the case of a gateway that is hosted by a network operator
you may not even be able to tell whose implementation it is. One
can also questions of the vendor's promises: in a heavily loaded
server, how exactly does the gateway prevent the operating system
from swapping memory pages out to swap space?
In a sense, saying that the vendors are aware of the issue and
taking steps to address it is comforting. However, it must also be
remembered that Microsoft are aware of the security exposures of
the Internet Explorer browser and the Outlook mail client, but they
continually take flack as a result of a seemingly unending stream
of security loopholes and exposures that are constantly being
discovered and exploited. I am sure that a vendor that has
extremely competent programming staff and designers, and which
implements their product only on a very secure operating system in
a thoroughly secured environment under the control of extremely
competent administrators, could provide a reasonably secure
implementation. Still, I am equally sure that there is still an
exposure around the gateway and that sooner or later it will become
a target for hackers.
What you need to consider is how much of an exposure it is for
the kinds of applications that you are developing. For some
applications the risk-reward ratio, when compared to the cost of
implementing a more secure solution, may be small enough that the
vendor decides to take the risk. For others, where the risk by far
outweighs any possible reward, there is no question that it is a
complete show stopper.
If we accept that there is an exposure at the gateway, no matter
how small or how hard the vendors work to protect the unencrypted
data, the real question then becomes: who hosts the gateway?
Whoever hosts the gateway has the responsibility for protecting it
and the data that goes through it, and also has access
(potentially, at least) to all of the data that goes through the
gateway in unencrypted form.
The good news is that it is entirely possible for you to host
your own gateway, although before doing so you should consider the
implications, in terms of cost and otherwise, of doing so. There
are also two different architectures that can be implemented to
facilitate hosting your own gateway, and each has different
characteristics in terms of security and cost overheads.
The first model, which is shown in the following diagram, is
probably only suitable if you want to provide access to a limited
number of people who are not the general public, possibly
employees:
Here, security is absolutely paramount. In this scenario you
would choose to establish an environment similar to any other
highly secure dial-up environment. You would establish a bank of
dial-up modems connected to one or more RAS servers on your local
network. You would be responsible for establishing, maintaining and
administering the environment, including details such as dial-up
security (possibly through RADIUS or similar). You would then be
able to strictly control who has access to the gateway, when this
access is possible, and via what telephone numbers. You could
implement dial-back to a limited set of numbers, control the IP
addresses available, issue and use your own certificates for
authentication, and anything else that would contribute to your
secure environment. All of the relevant servers would be a secure
segment of your local network, and access to and from the Internet
may or may not be available. If it is available it will almost
certainly be protected by one or more firewalls.
In this environment, as illustrated below, the network
operator's sphere of influence is almost non-existent:
The network operator is restricted to connecting the call and
has no influence over any of the communications between the client
and server. The network operator does not have a gateway that
participates in the communication process, and has no role to play
with regard to security. The mobile device establishes a WTLS
session that tunnels through the RAS server to the gateway, and a
TLS session from the gateway to the web server, all on your own
secure network.
The second model eliminates the need for the modems and RAS
server by making use of the services provided by an ISP. The
diagram below shows this model:
This model is in fact very similar to the Internet model,
although there are some differences. The remote mobile device will
establish a dial-up connection with the ISP's RAS server through a
modem hosted by the ISP. The network operator is restricted to
connecting the call and has no further influence on the session or
the security environment. The RAS server at the ISP acts as a proxy
for the mobile device on the ISPs network, and provides all the
services that it would to a fixed-wire dial-up client. The ISP
network is connected to the Internet via a gateway and is protected
by a firewall.
The host's environment would usually be similar to an
environment for access by fixed-wire clients over the network. The
major difference would be that the host would have a WAP gateway
available on the network, typically in the DMZ. Any secure
connection from the mobile device would establish a secure session
that tunnels through the ISP's RAS server to the WAP gateway. The
WAP gateway would then establish a secure TLS session through to
the web server, which would make use of services on the application
servers hosted on the secure network behind the firewall.
In this scenario we are making use of WTLS in a similar way to a
Virtual Private Network (VPN), in that the mobile device
establishes a secure tunnel through to the target network. In the
case of a VPN, the tunnel is typically to the router on the
network, although it doesn't have to be, whereas in this model the
'VPN' tunnels to the WAP gateway. You will need to examine the
security requirements of your application to determine whether WTLS
provides a secure enough 'VPN' for your application.
The other thing to be aware of in this model is that the WAP
gateway is typically on the DMZ, which means that it is not as
heavily protected as it would be if it were behind the firewall on
the secure network segment. This makes it more vulnerable to attack
by hackers. If there is little chance of the WAP gateway being
targeted then this is probably not an issue, but for a large retail
bank, for example, where the gains to be had from cracking the
gateway may be significant, it may present a temptation. On the
other hand, if you have to provide public access to your WAP
gateway then there is little in the way of feasible alternatives,
unless you want to become a network provider in your own right. The
span of control of the network operator, ISP and host are shown in
the diagram below:
For almost all applications that have security requirements that
prohibit the use of a network provider's gateway, one of these two
models will almost certainly be sufficient. The trick is to match
the trade-offs, in terms of cost and overheads, against your
security requirements and risk to achieve an optimal solution.
User versus Device
The second issue that is worth considering with mobile devices,
and which is not really a consideration for fixed-wire devices, is
the issue of who or what is being authenticated by the certificate.
I mentioned previously that a certificate is a reasonably large and
complex thing, certainly too complex to type in each time it is
required. The result is that the certificate usually ends up being
held on your computer, often without you even being aware that it
is there, and the system will take card of presenting and
validating certificates as and when required.
While this is very convenient, it does have some security
implications, in that anyone who gains access to your computer can
make use of your certificates. The prerequisite is for the person
to gain access to your computer. In many cases this is not that
easy to achieve, requiring breaking and entering or something
similar.
Mobile devices are different in that they are mobile and are
therefore carried around. This also leads to them being lost, left
on trains, and so on. In 1999, Railtrack, the company responsible
for the rail network in the UK, announced that for the first time
this century the umbrella has been overtaken as the most popular
item to leave on a train - by mobile phones. This gives us a
feeling for the magnitude of the problem. Clearly, where access to
data or services has to be strictly controlled it will not be an
acceptable solution to store certificates on the phone if those
certificates provide access to data and services.
The most immediate way of tackling this problem is to accept
that the certificate is going to be stored on the phone, and the
phone may be lost. The certificate is still made use of to validate
that the mobile device is entitled to access the network, which at
least serves to eliminate all of those mobile devices that do not
have the required certificate. Once the mobile device is reported
missing the certificate can be placed on a certificate revocation
list to ensure that it does not provide access in the future.
To further validate that the current user of the authenticated
device is the rightful user you can make use of a variety of
systems, which vary in their complexity and robustness from a
simple PIN number through to a SecureID token. While it is easy to
dismiss a PIN as being inadequate, pause to remember that almost
all of us make use of automated teller machines, and in doing so
daily rely on simple PIN numbers to protect our financial assets.
Of course when asking users to enter PIN numbers on a mobile device
the necessary precautions must be taken, such as masking the
numbers with asterisks, and so on.
Email TopXML