For those of us interested in wireless m-commerce (and let's
face it - who isn't?), the enhancements to wireless security
are the most interesting part of WAP v1.2. They provide for
additional, robust, application-level security, over and above that
specified in version 1.1.
In v1.1, WTLS provides the capability to generate Master
secrets, which are used as a source of entropy, to calculate MAC
(Message Authentication Code) keys and message encryption keys that
are used to secure a limited number of messages, depending on usage
of WTLS. It also allows for server and client authentication.
In v1.2, the WIM allows secure storage and use of permanent
private keys. It provides secure storage of the Master secrets
defined for WAP 1.1, and the client keys used for client
authentication. In addition, using the new WMLScript crypto
library, it allows for digital signatures to be generated for use
in end-to-end security at the application level.
Crucial to this is a tamper-proof module in the mobile device
called the WIM (Wireless Identity Module). This has been defined
with smart cards in mind, although the physical packaging of the
WIM has been left to the discretion of manufacturers. Often it will
be combined with the existing mobile phone SIM (which is, after
all, a kind of smart card), giving rise to the rather unfortunately
named SWIM.
For optimum security, some parts of the security functionality
need to be performed by a tamper-resistant device, so that
an attacker cannot retrieve sensitive data. This especially applies
to data such as the permanent private keys used in the WTLS
handshake with client authentication, and for making
application-level electronic signatures (such as confirming an
application-level transaction).
The WIM uses generic cryptographic features, so it could also be
used for non-WAP applications, like SSL, TLS, S/MIME, etc.
The WAP v1.1 Security "Loophole"
There is strong pressure within the industry for the adoption of
public key infrastructure (PKI) as the way of securing Internet
(and particularly wireless) e‑commerce.
Banking and commercial organizations are generally not satisfied
with the security offered by WAP v1.1. Some of the reasons for this
are due to the patchy levels of implementation that are
characteristic of an emerging technology - some of the first
WAP phones available on the market didn't support WTLS encryption
at all. Of those that do, at the time of presenting only one (the
Nokia 7110) does any WAP gateway authentication - that is,
the ability to request a WAP gateway's certificate, authenticate
it, and ask the consumer whether it should be accepted. All of the
other phones that support WTLS use it only for encryption, not for
the additional safeguard of authentication.
Furthermore, many of the WAP gateways deployed early on didn't
support WTLS either, and some didn't even support TLS/SSL
interaction with the content servers. However, these problems will
surely disappear as the industry develops.
Even when the above problems are resolved, though, there still
remains the issue of the role of the WAP gateway. This has the job
of linking the WAP protocols on the wireless side to the web
protocols of the wired world. For a secure data transfer, this
requires that the WTLS-encrypted data sent from the WAP client must
be momentarily decrypted to clear text, then immediately encrypted
for onward transmission to the content servers over TLS/SSL.
Since this only happens for an instant, and WAP gateways tend to
be operated by mobile phone network operators (which we would like
to think are trusted organizations), it could be argued that to all
intents and purposes, this is a secure connection. However,
that can't be absolutely guaranteed, and consequently the gateway
represents the most vulnerable link in an end-to-end
transaction.
Email TopXML