[ back ]
Simputer, IML and smartcard
The Simputer is meant to be a shared device, shared between members of
a family, or shared in public places like STD booths, shops and banks
and other establishments. For this reason, and for the reason that
there is no hard disk or other long-term storage medium on the simputer,
the smartcard is conceived as the presonalizing agent. That is an
individual's personal information will be securely carried in a
smartcard, and then this information will be introduced into the
simputer during a user session. At the end of the session, all traces of the data from the smartcard will be deleted so that the personal information
Sharing is a way of life in developing countries like India. Unique
innovations like person-to-person calls where neither party owns
a telephone have evolved to handle the resource constraints.
Thus it is expected that, eventhough smartcards may be considered
'inexpensive' in developed countries, a cost of Rs 200-Rs 300 is
still very high and hence we believe that even smartcards
will be shared among members of a family, or a group of friends,
or fellow-workers. This sharing can be secure since all smartcards
come with several user zones that are accessed through possibly
The Information Markup Language has been designed to facilitate this
smarcard usage scenario, and we believe that it is the first
such langauge to do so. In this note we outline the smartcard architecture
of the simputer. The general software architecture of the simputer
is illustrated in Figure 1. The user
accesses the simputer only through the IMLi browser interface.
We propose the following usage method for a smartcard.
From the User point of view:
- get access to use a simputer
- insert smartcard into the slot
- click on "get started" or "Logon" or some such icon on the screen
- enter password
- Proceed with usage of simputer
- Remove smartcard and click on "logout" "good bye" or some such message from the simputer.
From the browser (IMLI, in our case) point of view:
When the user logs in with a smart card, the contents of
the smartcard are read in, after obtaining the password of
the user. The simputer data on a smartcard is saved
in a simple format called the IML encoding . The data from all zones on the simputer that are accessible
through the supplied password are read by IMLI,
decoded and stored in a session database.
This brings us to the notion of a current session and
that of a session database. The simputer, IML and smartcards
are tied together by the notion of a session database
that is maintained by the IML browser. The session database
is stored in the form of a table as described below.
Session database format:
The session database is simply a three-column
table of variable number of rows (limited by the size of the smartcard
and the size of the individaul entries). The three columns
of the table are
An example of a table is given below:
- Name or Key: This holds the name of the variable or key, an arbitrary
- Magic: This column handles the access security of the variable and its value.
The value of magic can be one of four possible types.
Each of the four types of magic, except type s is a string starting with
the single letter that denotes the type followed by a password string,
that should be supplied by the user to be allowed access. For secure
variables, the magic is single character 's'.
- Read (r): the variable can be read by anyone without a password, but to modify it requires a password
- Exclusive (e): Password is required to read as well as write to this variable
- Secure (s): The variable is readable by anyone without a password, but cannot be changed from within IML environment.
- Transient (t): variable requires password to read and write, but is not stored beyond the current session.
- Value: This holds another arbitrary string that will be interpreted as the value of the variable or key named above.
Name Magic Value
name s Manohar
address s CSA Department, IISc, Bangalore 560012
DOB s June 21 1960
Status e567rty Married
phone r87iii89 3092368
choice t345tyu pizza
The first three variables are publicly readable values. Status (married
or single) being a sensitive
information is accessible only through a password, in this case
the string '567rty'. Since the status can change quite quickly
in modern times, it is possible to modify the value after
the user provides the same password. The phone number is
information that is readable without a password, but needs
a password (87iii89) to be modified. The last variable
is the choice of food this user has made during a particular
session. This value is accessible (read/write) by the
production of a password (345tyu), but will not be
saved beyond the current session.
Accesing the data from IML:
Any application that needs to use the data from the session
database (or equivalently from a smartcard) can do so by the
simple expedient of using the name/key of the data item
preceded by an underscore. An example IML segment that uses
the database variables is given below.
<tr><td> Name: </td><td><input type="text" width="15" height="1"
var="var0" value="_name" magic="s"/></td></tr>
<tr><td> Occupation: </td><td><input type="text" width="15" height="1"
var="var0" value="_occupation" magic="s"/></td></tr>
IML restricts access to session DB varibles to the input element.
The value attribute of this element can be given a database key
name (preceded by an underscore) as shown in the
example above. When the browser renders the above form, the value of the
name key is extracted from the database and filled in the form.
This restriction is to ensure complete user control of
the session data. Reading or writing of session data
has to be at the express approval (as indicated by the
correct password) of the user. In addition, transfer of such data
to an application (especially an application on a remote machine)
can only be through a form (input) element. The user
is shown the data that will be sent to the application,
and has the ability to delete or modify some fields
before submitting the data.