Security in the Java TVTM
API
This document describes the security model used in
the Java TVTM API, including an overview
of security in the JavaTM language, who
assigns
permissions in the Java TV API, and the permissions
architecture.
Overview
The Java language's security model addresses permitting
or denying access to resources, based on the source of the code requesting
access. It is a tried and proven architecture that has benefited from years
of experience. In computer workstations and personal computers, the "source"
from which code comes is primarily determined by the site from which the
code is downloaded (often a URL), or by a trusted signer who has signed
the code.
The Java language's security model is readily
applicable to interactive television and provides clear benefits. It allows
a responsible party to reliably prevent classes of code from accessing
resources that the code shouldn't need access to. For example, an advertising
application can be prevented from changing the channel to a network owned
by the advertiser, an application can be granted access to select only
certain services (such as those within a bouquet), an application can be
prevented from accessing the return channel, or it can be denied access
to a users' in-home network. Providing a simple, reliable mechanism to
deny such access provides important benefits, including cost reductions,
particularly in a horizontal market.
It can be argued that applications could be exhaustively
tested to ensure that they don't misbehave. However, such testing is expensive
and difficult. The Java language's security model frees the broadcaster
from some of this testing, by allowing it to establish a "sandbox," which
constrains the actions of applications; the Java 2 Platform, Standard Edition
(J2SE), security model allows that sandbox to be easily configurable so
it can be expanded to fit the needs of a given application.
In the J2SE security model, permissions are expressed
as subclasses of java.security.Permission. A method that detects
the violation of a security constraint does so by throwing a java.lang.SecurityException.
This is a subclass of java.lang.RuntimeException, but despite
this, any method of the Java TV API that can exit due to a SecurityException
must document this fact by:
-
Declaring "throws SecurityException" in the method
signature.
-
Containing "@throws SecurityException" in the method's
documentation.
-
Describing the permission required in the method's
documentation.
The J2SE security model is described in depth in
the book Inside Java 2 Platform
Security by Li Gong, ISBN 0-201-31000-7.
For a horizontal market, the underlying platform
security should be based on the J2SE security model. The Java TV API might,
however, be applied in certain vertical markets that have modest security
requirements. For platforms such as this, the permission classes described
below will be considered optional if the underlying platform does not support
the J2SE security architecture. For all platforms that support the J2SE
security model, the permission classes are a required part of the Java
TV API.
Who Assigns Permissions
Who is allowed to assign permissions is a critical
issue. The Java TV API does not dictate the policy underlying permission
setting. The model for who is trusted and who assigns permissions is an
important part of the business model underlying a complete platform for
interactive television. The Java technologies provide support for a variety
of signing models, but it is ultimately up to the entity that specifies
the complete platform to determine the model for granting permissions.
In a closed network where the set-top box is owned
by the network operator, the responsible party would likely be the network
operator. In a horizontal market, the answer is less clear, given the following
considerations:
-
It is possible to establish a "minimum sandbox" that
allows applications to do interesting things, but does not allow them to
do anything damaging. This minimum sandbox will include at least all methods
that are not declared as throwing SecurityException. A given platform may
guarantee that a security exception is not thrown under certain
circumstances, thereby enlarging the minimum sandbox, but it may not allow
a security exception to be thrown where one is not declared.
-
In a horizontal market, it is very useful if the
broadcaster can signal the set of permissions that they would like a given
application to have. In no case should the box give an application permissions
that the broadcaster didn't ask for. This relieves the broadcaster from
the responsibility of testing for access to these resources.
-
If an application is signaled as wanting access to
a resource, that access might not be granted. Specifically, the owner of
the set-top box (i.e., the user at home, or a network operator who subsidizes
the box) might want to configure who is and isn't trusted to grant various
resources.
-
In any given standards environment, it is possible
for the standards organization to define a set of permissions that must
be granted, if requested in the application signaling. For example, service
selection is a feature that probably should be granted to any application
that requests it, because a broadcaster can only use this feature to tune
away
from their service.
-
For more sensitive resources, the application and
the list of permissions should be signed by the broadcaster. This avoids
attacks where an attacker spoofs a broadcaster, or otherwise illegally
inserts content. This signing requires legal and technical infrastructure
for each broadcaster to obtain a unique certificate from a trusted party,
and for the box to validate these certificates.
Java TV API Permissions
Architecture
This section describes the permissions that exist
for the Java TV APIs. In addition to these permissions, there are the permissions
that exist in the underlying Java platform, and permissions for any other
APIs that are defined as part of a complete platform.
In the Java TV API, many resources are accessed
with a Locator. Locators are used to:
-
Access SI data
-
Select a different service (i.e., tune to a different
channel)
-
Retrieve program guide data
-
Play a Media Stream
In many ways, a Locator is analogous to a file name
in a computer file system. In computers, a file name is often associated
with a hardware device, such as a printer and the screen ("prn:" and "con:"
in DOS-based systems, and /dev/lp* and /dev/tty in UNIX systems). Associating
permissions with files is a well established mechanism for restricting
access to data files, hardware devices, and other resources in computer
systems.
The Java language model for access to a file system
is twofold: There is a file object (java.io.File), which represents
the path to an object in the file system, and there is a security check
based on that name. In the J2SE security model, that security check is
reified in the class java.io.FilePermission. A FilePermission
contains a path (or a regular expression denoting a set of paths), and
an action string. The action string can be read,
write,
execute
or delete. In the JDK 1.1 security model, the same facility is exposed
through a small number of check methods on java.lang.SecrityManager
(checkRead(String),
etc.).
The FilePermission object allows access to a set
of files based on a wildcarding mechanism. A set of FilePermission objects
may be combined to give any desired degree of access. For example, it is
straightforward to construct a set of two permissions that gives code read-write
access to one directory, and read-only access to a different directory.
FilePermission is described in detail in Inside
Java 2 Platform Security, section 3.6.4.
A mechanism similar to FilePermission is ideally
suited to the needs of resources that are accessed via Locators. For example,
consider the following set of permissions for an application:
-
An application may select services corresponding
to "channel" 3, 7, or 9 through 11
-
An application may receive program events for "program
X"
This is analogous to the kinds of access that FilePermission
grants. For this reason, important permissions in the Java TV API have
a Locator in their constructor. Using a Locator in this way does not place
any requirements on the internal representation an implementation maintains
for a Locator. It does, however, imply a requirement on the signaling
of permissions. Namely, a permission that relates to a given Locator needs
to be signaled in such a way that the permission object can determine if
it grants access for a given Locator. A signaling specification would probably
define some kind of wildcarding scheme based on paths for Locators, to
facilitate the natural expression of a set of permissions. For example,
the Locator for a service might have a representation equivalent to "/service/physical/channel007"
or "/service/logical/ESPN/TheDeuce". Doing so would allow logical wildcarding
in the signaling of permissions.
The Java TV API does not mandate a particular
format for Locators. This format must be specified as part of a complete
platform. Despite this, an application running on a platform that implements
the J2SE security model can test whether or not it has access to the resource
corresponding to a given Locator using code similar to the following:
boolean hasAccessTo(Locator l) {
boolean allowed =
true;
SecurityManager m = System.getSecurityManager();
if (m != null) {
Permission p = new javax.tv.mumble.MumblePermission(l);
try {
m.checkPermission(p);
} catch (SecurityException ex) {
allowed = false;
}
}
return allowed;
}
Copyright © 2000 Sun Microsystems, Inc.