The MIDP security model is built on two concepts:
Trusted MIDlet suites
are those whose origin and integrity can be trusted by the device on
the basis of some objective criterion.
Protected
APIs are APIs to which access is restricted, with the level of access
being determined by the permissions (Allowed or User) allocated to the
API.
A protection domain defines a set
of permissions which grant, or potentially grant, access to an
associated set of protected APIs. An installed MIDlet suite is bound to a
protection domain, thereby determining its access to protected APIs.
An MIDP device must support
at least one protection domain, the untrusted domain, and may support
several protection domains, although a given MIDlet suite can only be
bound to one protection domain. The set of protection domains supported
by an implementation defines the security policy. If installed, an
unsigned MIDlet suite is always bound to the untrusted domain, in which
access to protected APIs may be denied or require explicit user
permission. Since a requirement of the MIDP specification is that a
MIDlet suite written to the MIDP 1.0 specification runs unaltered in an
MIDP environment, MIDP 1.0 MIDlets are automatically treated as
untrusted.
1. The X.509 PKI
The mechanism for
identifying and verifying that a signed MIDlet suite should be bound to a
trusted domain is not mandated by the MIDP specification but is left to
the manufacturer of the device and other stakeholders with an interest
in the security of the device, for example, network operators. The
specification does, however, define how the X.509 Public Key
Infrastructure (PKI) can be used to identify and verify a signed MIDlet
suite.
The PKI is a system for
managing the creation and distribution of digital certificates. At the
heart of the PKI lies the system of public key cryptography. Public key
cryptography involves the creation of a key pair consisting of a private
key and a public key. The creator of the key pair keeps the private key
secret, but can freely distribute the public key. Public and private
key pairs have two principal uses: they enable secure communication
using cryptography and authentication using digital signatures. In the
first case, someone wishing to communicate with the holder of the
private key uses the public key to encrypt the communication. The
encrypted communication is secure since it can only be decrypted by the
holder of the private key.
In the current context, however,
we are more interested in the second use of public-private key pairs:
enabling authentication using digital signatures. A digital signature is
an electronic analogy of a conventional signature. It authenticates the
source of the document and verifies that the document has not been
tampered with in transit. Signing a document is a two-stage process: a
message digest is created that is a unique representation of the
contents of the document; the message digest is then encrypted using the
private key of the sender (see Figure 1).
The receiver of the document
then uses the public key of the sender to decrypt the message digest,
creates a digest of the received contents, and checks that it matches
the decrypted digest that accompanied the document. Hence, a digital
signature is used to verify that a document was sent by the holder of
the private key, not some third party masquerading as the sender, and
that the contents have not been tampered with in transit. This raises
the issue of key management and how the receiver of a public key can
verify the source of the public key. For instance, if I receive a
digitally signed JAR file, I need the public key of the signer to verify
the signature, but how do I verify the source of the public key? The
public key itself is just a series of numbers, with no clue as to the
identity of the owner. I need to have confidence that a public key
purporting to belong to a legitimate organization does in fact originate
from that organization and has not been distributed by an impostor,
enabling the impostor to masquerade as the legitimate organization,
signing files using the private key of a bogus key pair. The solution is
to distribute the public key in the form of a certificate from a
trusted certificate authority (CA).
A certificate authority
distributes a certificate that contains details of a person's or
organization's identity, the public key belonging to that person or
organization, and the identity of the issuing CA. The CA vouches that
the public key contained in the certificate does indeed belong to the
person or organization identified on the certificate. To verify that the
certificate was issued by the CA, the certificate is digitally signed
by the CA using its private key. The format of certificates used in
X509.PKI is known as the X509 format.
Of course, this raises the
question of how the recipient of the certificate verifies the digital
signature contained therein. This is resolved using root certificates or
root keys. The root certificate contains details of the identity of the
CA and the public key of the CA (the root key) and is signed by the CA
itself (self-signed). For mobile phones that support one or more trusted
protection domains, one or more certificates ship with the device,
placed on the phone by the manufacturer or embedded in the WIM/SIM card
by the network operator. Each certificate is associated with a trusted
protection domain, so that a signed MIDlet that is authenticated against
a certificate is bound to the protection domain associated with that
certificate.
2. Certification Paths
In practice, the authentication of
a signed file using the root certificate may be more complex than the
simplified approach described above. The PKI allows for a hierarchy of
certificate authorities (see Figure 2)
whose validity can be traced back to a root certification authority,
the uppermost CA in the hierarchy, also known as the trust anchor. In
this case the root certificate on the device (the trust root) belongs to
the root certification authority in the hierarchy (the trust anchor)
which directly or indirectly validates all the other CAs in the
certification path. The certificate supplied with the signed JAR file
does not need to be validated (signed) by the trust anchor whose
certificate is supplied with the device, as long as a valid
certification path can be established between the certificate
accompanying the signed JAR file and the root CA. It is not actually
necessary for a device to have various self-signed top-level
certificates from CAs, manufacturers and operators installed. In
practice, it only needs access to one or more certificates which are
known to be trustworthy, for example, because they are in ROM or secure
storage on a WIM/SIM, or because the user has decided that they are.
These certificates act as trust
roots. If the authentication of an arbitrary certificate chains back to a
trust root known to the device, and the trust root is also identified
as being suitable for authenticating certificates being used for a given
purpose, for example, code-signing, website identification, and so on,
then the arbitrary certificate is considered to have been authenticated.
