Interworking Public Key Certification Infrastructure
for Commerce, Administration and Research
UCL Secure Conference Store
We have provided a web-based system for the storage and access of information
in a way that can be secure. Currently, the system can be used in two ways:
to store and access PGP keys for use with secured SDR, and to store and
access session details for multicast conferences. The second use is so
arranged that users can join the sessions easily via their web browser
(using our SPAR Java applet to start the media tools in
secure mode). While we have designed the system to allow participation in
secured conferences, its use is not restricted to this case.
Groups of users can be created for access control to the information and
group managers can add/remove users, create/delete sessions, change keys.
Users only have access to the information for the groups to which they belong.
User details: Server access
The web server uses HTTP-S for the transport, so the browser-server
dialogue is encrypted over the network. Currently, this uses a UCL
self-signed SSL certificate. Since this is "unknown" to browsers, it is
untrusted so needs to be accepted by the user initially.
The URL is https://www-secure.cs.ucl.ac.uk/
and the main page frame has
clickable options (e.g. to register, manage groups, show sessions etc.)
Users first need to register on the server by creating a user-profile.
Currently this is a simple form to provide name/organisation/PGP-key details
and set a user-id and password for future authentication and access to the
server. Currently, no authentication checks are made on who can register,
an only basic checks are made on the user data supplied.
Registered users can create/manage "groups" and assign members (other
registered users) who may access them. A "random" PGP key-pair is created
for each group (e.g. for use with SDR if encrypted sessions need to be
announced). A group manager can also create secure conference sessions by
submitting a form giving the details (title/media used/expiry time/scope etc.)
Registered users can also access "pages" for the groups to which they
belong, and retrieve the information: PGP keys or list of sessions and
join active conferences. Such conferences can be joined in several ways:
- manually - the user needs to start the conference media tools on their
host with the addressing/attribute details shown
- automatically by using a small platform specific "helper" program and
MIME-type (which needs special configuration on the browser). This method
is obsolete but can be used if a Java-capable browser is not available.
- automaticaly using the SPAR Java Applet - which is platform independent
and needs no browser configuration. This is the preferred/recommended way
but currently only Netscape's Communicator and Microsoft's Internet Explorer
4/5 are supported.
Note: for creating and joining sessions defined on the server, PGP
keys are not needed or used. The MBONE tool SDR is not used either.
Any web browser that supports HTTP-S can access the secure server. Joining
conferences using the SPAR Java Applet requires either Netscape's
Communicator or Microsoft's Internet Explorer 4/5. Users of other browsers
should use one of the alternative methods of starting the MBone tools.
The server consists of set of CGI scripts (written in Perl for efficiency
and ease of coding) that control access, generate dynamic HTML pages, and
The server maintains a database of conference sessions (created using
user-supplied details plus a random set of multicast addresses, ports and
encryption keys). The server picks multicast address from our "glop"
range although other scope ranges can be used. The addresses are random
but unique across
all active sessions defined. The ports are random (even numbered) but
unique for each media defined for the session. The session encryption
keys are random
alphabetic strings - they can be changed at any time (e.g. when a group
manager removes a user). The server automatically removes a session after
the expiry time (as set when created).
When a user joins a session, a server script generates an HTML page
referencing the SPAR Java applet and encodes the session details as SDP
data (passed in the HTML as a parameter to the applet). The applet is run
by the browser and parses the SDP to execute the media tools on the
host with the correct addresses/ports/keys required for the session.
Sdp PARser (SPAR) Java Applet
Simplistically, the Java applet parses the SDP, extracts essential
parameters and then starts the tools with the parameters on the client
machine. The SDP content is embedded within the HTML as a parameter to the
applet. The field terminator used in the SDP is replaced with a 'browser
friendly' alternative, as SDP's CR/LF field terminator is removed by the
browser. The advantage of using HTTP to communicate the SDP content between
client and server is that the SDP content (with encryption keys) will also
For obvious security reasons standard Java applets do not have permissions
to access local resources and thus cannot execute software on the client
machine. To overcome this, both Netscape Communicator and Microsoft
Internet Explorer 4 allow applets to be digitally signed with a private key
associated to a RSA object-signing certificate. If the user accepts the
certificate, therefore trusting the applet, then the browser allows the
applet access permissions outside the Java security sandbox. Communicator
and Internet Explorer implement different methods and technologies for
digitally signing and distributing objects:
- Communicator requires Java applets to be signed using Netscape's Netscape
Object Signing software. The certificate and Java code are then packaged
using the JAR file structure. Signed Java applets need to explicitly
request permission to access local resources, such as executing software
using the Netscapes Capabilities API extensions. The request causes
Communicator to prompt the user, asking them to either accept or deny the
relevant permission. The dialog box also contains the certificate as
verification of the source and authenticity of the code.
- Internet Explorer requires Java applets to be signed using Microsoft's
Authenticode software and packaged using a CAB file structure. A signed
Java applet also has to request permission to access local resources by
using Microsoft's Com API extensions. However unlike Communicator, the
specific request doesn't prompt any user action. Instead the user is asked
to accept the applets' certificate when the applet is encountered by the
browser and by doing so grants universal access to local system resources.
More information regarding the applet can be found on the SPAR web page:
We expect to extend the server function to store arbitrary data, possibly
unrelated to conferences. For example we plan to provide a secure
certificate repository/depository, and to hold documents that require secure
Users should be able to change/update their profile (e.g. change password
etc.). Users should be able to request to join a group. Groups managers
should be able to set a mode to allow users to create sessions. We will
extend to full strength encryption when suitable servers are located.
The current userid/password authentication will be extended so that users
can identify themselves with a browser-supplied certificate. Also, if the
certificate is signed by a trusted CA, proof of identity at registration
could be accepted. We expect to provide some mechanism for using both roles
and user names with such certificates, and to make provision for
Certificate Revocation Lists.
The system will be extended to work with IPv6, but this will require a web
server and browser that supports IPv6 and HTTP-S.
If the browser does not
support Java applets then SUN's Java plugin could be used (see below).
scripts/databases would need minor additions to process IPv6 addresses
(e.g. to generate SDP, media attributes etc. suitable for IPv6 working).
To avoid the single point of failure, the server will be replicated so that
alternative/backup/secondary servers can be accessed. This will be simple
to do if the secondary servers have read-only copies of the
information (e.g. updated daily/hourly), but more involved if users can
update information on any server.
SPAR & Alternative Browsers
Browser's that do not support signed applets but do have a "plug-in"
architecture could use SUN's Java Plugin to view the applet. The Plugin
requires the applet to be signed and packaged using Netscape's Netscape
Object Signing software but it does not implement Netscape's Capabilities
API. Since the API is not supported by the Plugin, any certificate accepted
by the user, would grant universal access to local system resources.
The server and SPAR Java Applet will be extended to process further media
options/attributes (ie. improve on the SDP support). Currently only the
following part of the SDP is processed:
Different methods of choosing/obtaining
multicast addresses will be supported eventually. We expect to study the
integration and trade-off between this type of system and use of SAP and SIP.
- the session title and description
- the multicast address, port, TTL and encryption key for each media
- audio, video, whiteboard and text media types