[ back ]

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 is secure.

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 separate passwords.

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

1. Name or Key: This holds the name of the variable or key, an arbitrary string.
2. Magic: This column handles the access security of the variable and its value. The value of magic can be one of four possible types.
   • 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.
   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'.
3. 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.

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.

Inquiries & questions to <simputer AT csa dot iisc dot ernet> dot in.
design:corrosive

This page maintained by <manohar AT csa dot iisc dot ernet dot in> with scripts and support from <vinay AT csa dot iisc dot ernet dot in>