Techniques for implementing security on a small footprint...

Details Techniques for implementing security on a small footprint... Techniques for implementing security on a small footprint...

1999-01-22

2004-11-23

Bullock, Jr., Lewis A. (Department: 2126)

Electrical computers and digital processing systems: interprogra

Interprogram communication using message

Object oriented message

C719S313000, C718S108000, C713S167000

Reexamination Certificate

active

06823520

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
The invention relates to computer security and more particularly to techniques for implementing a security on small footprint devices, such as smart cards.
2. Description of Related Art
A number of object oriented programming languages are well known in the art. Examples of these include the C++ language and the Smalltalk language.
Another such object oriented language is the JAVA™ language. This language is described in the book
Java™ Language Specification
, by James Gosling et al. and published by Addison-Wesley. This work is incorporated herein by reference in its entirety. The JAVA™ language is particularly well suited to run on a Java™ Virtual Machine. Such a machine is described in the book
Java™ Virtual Machine Specification
, by Tim Lindholm and Frank Yellin which is also published by Addison-Wesley and which is also incorporated herein by reference in its entirety.
A number of small footprint devices are also well known in the art. These include smart cards, cellular telephones, and various other small or miniature devices.
Smart cards are similar in size and shape to a credit card but contain, typically, data processing capabilities within the card (e.g. a processor or logic performing processing functions) and a set of contacts through which programs, data and other communications with the smart card may be achieved. Typically, the set of contacts includes a power source connection and a return as well as a clock input, a reset input and a data port through which data communications can be achieved.
Information can be written to a smart card and retrieved from a smart card using a card acceptance device. A card acceptance device is typically a peripheral attached to a host computer and contains a card port, such as a slot, in to which a smart card can be inserted. Once inserted, contacts or brushes from a connector press against the surface connection area on the smart card to provide power and to permit communications with the processor and memory typically found on a smart card.
Smart cards and card acceptance devices (CADS) are the subject of extensive standardization efforts, e.g. ISO 7816.
The use of firewalls to separate authorized from unauthorized users is well known in the network environment. For example, such a firewall is disclosed in U.S. patent application Ser. No. 09/203,719, filed Dec. 1, 1998 and entitled “AUTHENTICATED FIREWALL TUNNELLING FRAMEWORK” in the name of inventor David Brownell, which application is incorporated herein by reference in its entirety.
A subset of the full Java™ platform capabilities has been defined for small footprint devices, such as smart cards. This subset is called the Java Card™ platform. The uses of the Java Card™ platform are described in the following publications.
JAVA CARD™ 2.0—LANGUAGE SUBSET AND VIRTUAL MACHINE SPECIFICATION;
JAVA CARD™ 2.1—APPLICATION PROGRAMMING INTERFACES;
JAVA CARD™ 2.0—PROGRAMMING CONCEPTS;
JAVA CARD™ APPLET DEVELOPER'S GUIDE.
These publications are incorporated herein by reference in their entirety.
A working draft of ISO 7816—Part 11 has been circulated for comment. That draft specifies standards for permitting separate execution contexts to operate on a smart card. A copy of that working draft is hereby incorporated by reference in its entirety.
The notion of an execution context is well known in computer science. Generally speaking, the use of multiple execution contexts in a computing environment provides a way to separate or isolate different program modules or processes from one another, so that each can operate without undue interference from the others. Interactions—if any—between different contexts are deliberate rather than accidental, and are carefully controlled so as to preserve the integrity of each context. An example of multiple contexts is seen in larger hardware devices, such as mainframes, where a plurality of virtual machines may be defined, each such virtual machine having its own execution context. Another example is seen in U.S. Pat. No. 5,802,519 in the name of inventor De Jong, which describes the use of multiple execution contexts on a smart card. It will be appreciated by those of skill in the art that a computing environment which provides multiple execution contexts also needs to provide a mechanism for associating any given executing code with its corresponding context.
Also well known is the notion of a current context. Certain computing environments that support multiple contexts will, at any given time, treat one context in particular as an active focus of computation. The context can be referred to as the “current context.” When the current context changes, so that some other context becomes the current context, a “context switch” is said to occur. As will be appreciated by those of skill in the art, these computing environments provide mechanisms for keeping track of which context is the current one and for facilitating context switching.
In the prior art, in the world of small footprint devices, and particularly in the world of smart cards, there was no inter-operation between contexts operating on the small footprint devices. Each context operated totally separately and could operate or malfunction within its context space without affecting other applications or processes in a different context.
One layer of security protection utilized by the Java™ platform is commonly referred to as a sandbox model. Untrusted code is placed into a “sandbox” where it can “play” safely without doing any damage to the “real world” or full Java™ environment. In such an environment, Java™ applets don't communicate, but each has its own name space.
Some smart card operating systems don't permit execution contexts to communicate directly, but do permit communications through an operating system, or through a server.
The Problems
A number of problems exist when trying to place computer programs and other information on a small footprint device. One of the compelling problems is the existence of very limited memory space. This requires often extraordinary efforts to provide needed functionality within the memory space.
A second problem associated with small footprint devices is the fact that different small footprint device manufacturers can utilize different operating systems. As a result, applications developed for one operating system are not necessarily portable to small footprint devices manufactured by a different manufacturer.
If programs from more than one source of programs (manufacturer or vendor) are to be applied to a single small footprint device, security becomes a factor as one attempts to avoid corruption of existing programs and data when a new program is loaded on to the small footprint device. The same concern exists when one wishes to prevent a hacker or a malicious person from accessing programs and data.
It is clear that small footprint devices such as smart cards don't have the resources necessary to implement separate virtual machines. Nevertheless, it is desirable to maintain strict security between separate execution contexts.
In the past, security was provided by loading only applications from the same source or from a known trusted source onto a smart card or other small footprint device.
Accordingly, it would be desirable to allow object-oriented interaction between selected execution contexts only in safe ways via fast efficient peer to peer communications which do not impose undue burdens on the programmer but facilitate dynamic loading of applets written at different times by untrusted sources.
SUMMARY OF THE INVENTION
The invention is directed to providing a context barrier (sometimes referred to as a firewall) for providing separation and isolation of one context from another and to provide controlled access across the barrier when that is needed.
In accordance with the invention, two execution contexts, e.g. each containing one or more applets, running in the same logical (i.e., virtual or real) machine, protected from each other, can share information in

Affiliated with

Also associated with

Rating

Techniques for implementing security on a small footprint... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Techniques for implementing security on a small footprint..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Techniques for implementing security on a small footprint... will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3306069