Newsletter sign-up

View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Restricted-channel multicast in Java

How a desktop stock-ticker app was converted into a secure system, using an applet running on a smart card device

By Jason Scherer with Rinaldo Di Giorgio, JavaWorld.com, 09/01/98

This article describes the modifications made to an existing multicast application during research and development at Sun Microsystems. The goal was to convert an application bundled with Java Reliable Multicast Service (JRMS) to something we are calling a restricted-channel system. In a restricted-channel system, the multicast server transmits encrypted information that can be deciphered only by authorized multicast client programs or multicast client programs operating under authorized conditions. For security reasons, a Java Card was chosen as the device on which to perform decryption. The program performing the decryption was run by the smart card chip itself. The system envisioned in this project is a complete one, where both decryption and payment are handled by the Java Card device. This article also demonstrates the use of the Java Card as a "purse," performing debit and credit card functions and actually "holding" money.

Over the past month we have been working on a project to create a prototype for a restricted-channel multicast system using rudimentary Java Card encryption. Multicast describes a system in which one message is transmitted to many listeners at the same time. On the Internet, or any network with a bus architecture, every machine on the network receives all packets -- no matter who the packets are meant for. This situation is invisible to users because a network node ignores any packets not specifically addressed to it. However, there is a special "multicast address" reserved on the Internet for communication intended for many recipients.

In this restricted-channel system, the multicast server transmits encrypted information, which can only be deciphered by either: (a) authorized multicast client programs, or (b) multicast client programs operating under authorized conditions, such as those submitting payment for the service.

Our goal has been to investigate the feasibility of creating such a system using the Java Reliable Multicast Service (JRMS). Reliable multicast is distinguished from standard multicast in that any and all packets transmitted over the network must be received correctly, or the client will ask the server to continually retransmit until a correct packet is received. (TCP, the reliable unicast protocol used by the Internet, and UDP, its unreliable cousin, may be more familiar to some readers). For our project, we chose to take an existing demo system, designed merely to illustrate a possible use for JRMS, and change it into a restricted-channel system. The original client end of the system was a desktop stock-ticker window, implemented using standard Abstract Windowing Toolkit (AWT) classes and a JRMS multicast client socket. The original server provided the channel content (stock quotes) through a JRMS server socket. For the purposes of the demo only, the stock quotes were obtained either from a disk file or from a public Web site (Yahoo), which was parsed and retransmitted as multicast data.

Restricted-channel multicast
Why restricted-channel multicast? More than one person has asked us this. One possible application we've repeatedly invoked is the model of a reserved-for-top-executives information service within a corporation -- possibly a stock ticker or other, more sensitive information. However, other models exist.

 

XpoLog Center Correlate application logs with server metrics - XpoLog

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.