Access Control

Implementation of access control is be based the golden standard of authentication, authorization and audit [Lam00].

The palm provides data security as individual records marked private in the applications. They are available on presenting correct password. The beaming of data can be prevented by using the beam bit. However this comprises a very primitive and easily breakable access control. Consequently the palm-debugger can gain unauthorised system access easily. This can be relieved by logging all Palm debugger actions with timestamping for audit purpose.

In simputer access control is based on the IML access model. IML deals with the user in sessions. Each session has a database having the following 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 individual entries). The three columns of the table are [sima]:

Name or key : This holds the name of the variable or key, an arbitrary string.

Magic: This column handles the access security of the varibale 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 with out 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'.

Value: This holds another arbitrary string that will be interpreted as the value of the variable or key named above. An example of a table is given below:

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 readbale 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 databsae varibales is given below.

<page>

<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>

</page>

Note: this data can come from the smart card too!!! IML restricts access to session DB variables 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.