REMOTE MANAGEMENT OF FACE-TO-FACE WRITTEN

AUTHENTICATED THOUGH ANONYMOUS EXAMS

Giampaolo Bella

Software Technology Research Lab, De Montfort University, Leicester, U.K.

Dip. Matematica e Informatica, Universit

a di Catania, Catania, Italy

Gianpiero Costantino

Istituto di Informatica e Telematica, CNR Pisa, Pisa, Italy

Lizzie Coles-Kemp

Information Security Group, Royal Holloway University of London, Egham, U.K.

Salvatore Riccobene

Dip. Matematica e Informatica, Universit

a di Catania, Catania, Italy

Keywords:

University exam, Public competition, e-Learning, Secret sharing, Exclusive OR.

Abstract:

Authentication and anonymity are inherently difﬁcult to combine. In case of face-to-face, written, university

exams or public competitions, the candidates should be authenticated to prevent exchange of person, but the

written exams they produce should be anonymous during the marking to ensure fairness of the marking. Com-

plications rise still when the entire exam management should take place remotely, that is via the Internet, thus

involving remote publication of marks and remote consultation/acceptance of those marks. This management

would be useful, for example, also for the ﬁnal, face-to-face, written exam concluding lectures delivered via

electronic learning techniques. To our knowledge, no software currently exists beside ours to support this

delicate combination of authentication and anonymity along with other typical exam preparation utilities.

WATA2.0 (Bella et al., 2009) supports the management of Written Authenticated Though Anonymous exams

non-remotely, that is by having WATA2.0 run locally on the examiner’s computer. Upgrading the system

towards remote management turns out far from trivial because novel though fundamental security threats arise.

These have required much more than SSL-secured connections to a remote WATA server: a complete redesign.

In particular, the identity of a candidate is no longer matched to a written exam through identical barcodes but,

rather, through barcodes that decrypt via exclusive-OR to the candidate’s details. The new system, WATA3.0,

is currently used at the University of Catania, and the migration from the previous version has been seamless.

The innovative design of WATA3.0, its user experience, interface and implementation are presented.

1 INTRODUCTION

Modern societies incrementally base their wealth on

actual people’s merits, which are normally assessed

through tests, exams or public competitions. Depend-

ing on the speciﬁc context, a speciﬁc terminology and

method are adopted. For example, a student normally

progresses towards a university Bachelor degree by

sitting for an exam, which they ﬁll in, and which is

later marked by the lecturer.

The actual notiﬁcation of the marks to the exami-

nee can be done in various ways. The main ones are

two: the examiner sets an appointment to meet the ex-

aminee in person and reveal the marks; or the marks

are published on the Internet, as would be more ap-

propriate, for example, for the remote management of

the ﬁnal, face-to-face, written exam concluding lec-

tures delivered via e-learning techniques. In all cases,

431

Bella G., Costantino G., Coles-Kemp L. and Riccobene S..

REMOTE MANAGEMENT OF FACE-TO-FACE WRITTEN AUTHENTICATED THOUGH ANONYMOUS EXAMS.

DOI: 10.5220/0003481404310437

In Proceedings of the 3rd International Conference on Computer Supported Education (ATTeL-2011), pages 431-437

ISBN: 978-989-8425-50-8

 2011 SCITEPRESS (Science and Technology Publications, Lda.)

the examiner knows the personal details (name, sur-

name, etc.) of the examinees as well as which mark

goes to which candidate. The examinees customarily

accept the examiner’s knowledge of such association.

However, knowledge of such association is often

considered sensitive information, such as at public

competitions towards a prestigious post. Also, under-

graduates may feel that disclosing that information to

an examiner cannot be accepted by their righteous pri-

vacy requirements. A potential practical implication

of the disclosure is the examiner’s unfair marking,

which could ultimately hinder meritocracy. Hence

the need for anonymity. By contrast, an anonymous

exam sheet might invite cheating at the examinee’s

side, with a realistic chance of person exchange.

WATA is a system for written, authenticated

though anonymous exams (Bella et al., 2009). It runs

locally on the examiner’s computer, and therefore has

two main limitations: the notiﬁcation of marks must

be carried out classically, as outlined above; the sys-

tem must be installed on the machine of each exam-

iner who wishes to use it. These motivations con-

vinced us to upgrading the system towards a remote

platform, which any student interested in being no-

tiﬁed his mark, or any examiner wishing to use its

facilities might easily access.

However, we soon realised that making the sys-

tem remotely available entails new threats. Not only

are these due to the obvious need to securely com-

municate with a server, but also to the basic design

becoming ﬂawed when hosted on a remote platform.

The main security requirement to meet is examinees’

remote authentication, for at least two reasons. One is

to avoid a clever examinee’s selling his vote to other,

possibly less skilled, examinees.

Another one is due to the fact that certain exam

policies allow examinees to refuse marks till the mo-

ment these are notiﬁed. Hence an examinee can

refuse his mark prior to knowing it, while “fail” marks

may ofﬁcially be accounted for throughout the rest

of his studies. However, once marks are notiﬁed,

they cannot be refused and are automatically regis-

tered. The gist of such an exam policy seems to be

to favour examinees’ self evaluation. Therefore, from

our security perspective, lack of examinee authenti-

cation would allow an examinee to illegally register

another examinee’s mark on behalf of the latter. This

would be a serious attack in case the latter examinee,

possibly after pondering his answers, did not want to

have his exam marked.

In consequence, in the new setting, the existing

design of WATA, which was version 2.0, has to be dis-

posed with entirely — more explanation will follow.

Various ideas were tried out towards a new design,

and the exclusive-or function was found to be the right

technology. The main strength of the XOR is the sym-

metry of its truth table, while its drawback is cancel-

lation of the key, which implies the need of fresh keys

every time a new and robust ciphertext must be built.

Barcodes were used in WATA2.0 to match an exam-

inee’s credentials to his exam sheet. Their use in the

new version, which we name WATA3.0, is completely

different: each barcode encodes either the encrypted

version of a set of credentials or the key that must be

used to decipher it.

This paper fully describes the latest version of our

sytem, WATA3.0. A brief history of the previous ver-

sions (§2) introduces the design and user experience

of WATA3.0 (§3). Then, the new interface (§4) and

implementation (§5) are outlined. Some evaluation

(§6) and conclusions (§7) close up.

2 A BRIEF HISTORY OF WATA

The original goal of WATA was to mechanise in a

software the classical method of the double envelope,

which is often used during open competitions. The

examinee inserts his personal details in a small enve-

lope, and seals it. He then inserts that envelope along

with his anonymous, ﬁlled-in exam sheet in a bigger

envelope. The examiner is trusted to mark the exam

sheet prior to opening the smaller envelope, when the

association of marks and examinee can be done.

WATA stores the exam questions in a database. It

offers a printing facility to generate as many exam

sheets as needed, with the required number of ques-

tions. These are randomly extracted from the database

and shufﬂed further to ensure that no two identical

exam sheets exist. A typical exam sheet can be seen in

Figure 1. The security token on the left hand side must

be ﬁlled in and signed by the examinee. The examiner

checks this information to match the examinee’s iden-

tiﬁcation card and ﬁnally authenticates the token with

his overlay signature and institution stamp, to make it

physically tamperproof. The two occurrences of the

same barcode can be noted. They will be used later to

match personal details with marks.

The examinee ﬁnally tears off the token, hands in

the anonymous manuscript and walks away with the

token. The examiner will mark anonymous sheets and

will organise a mark notiﬁcation phase as outlined

above. During that phase each examinee will hand

in his token, whose barcode is scanned through an ap-

propriate scanner, entered in WATA2.0 and matched

to a mark that was stored previously: the examiner

stored that mark during the actual marking phase next

to a barcode scanned from an exam sheet. The only

CSEDU 2011 - 3rd International Conference on Computer Supported Education

432

Figure 1: The exam sheet of WATA2.0.

real limitation of this system is against collusion of

examinee and examiner.

These facilities were available in WATA1.0, which

was written in Visual Basic and based on a Microsoft

Access database. WATA2.0 (Bella et al., 2009) was

a big step towards portability, being implemented in

Java and over a MySQL database. However, it still

had to run locally on the examiner’s database.

We set out to make WATA remotely available. Ex-

aminee authentication was soon felt to be a must, oth-

erwise a signiﬁcant attack could see an examinee sell

his mark. Another attack, already sketched, exists:

WATA is accessible on a remote server; an examinee

reads (by any means such as circumstances or theft)

another examinee’s barcode and enters it in the sys-

tem. This is serious when it is the case that, while an

examinee can decide to skip the notiﬁcation phase re-

nouncing to whatever mark and having the exam fees

waived, an examinee who goes for the notiﬁcation by

handing his token over, cannot refuse the mark.

It is then clear why the design of WATA3.0, which

works on a remote server and is immune to the previ-

ous attacks, is entirely new with respect to the design

of the previous versions.

3 SPECIFICATION

We begin by describing the system requirements

(§3.1) and continue by describing our solution to meet

them (§3.2).

3.1 Requirements

3.1.1 System Requirements

• The entire system should be centralised on a ma-

chine that is maintained by an administrator.

• Both examiner and examinee should be able to ac-

cess the system remotely and securely.

3.1.2 Examiner’s Requirements

• Any number of examiners should be supported

(subject to obvious machine speed/memory lim-

itations).

• Each examiner should be able to register a number

of exams, depending on exam subject/date.

• The examiner should then be allowed to upload

the exam questions for each exam.

• It should be possible to upload questions interac-

tively or as a batch in an ascii ﬁle with standard

format.

• Exam questions should be securely stored in a re-

mote database.

• A printing facility should allow the preparation

of exam sheets in PDF format — any number of

exam sheets, corresponding to the number of ex-

aminees, and any number of questions per sheet.

• Each exam sheet should be authenticated in the

classical sense face-to-face.

• The marking facility should allow a mark to be

stored for each exam sheet.

• The notiﬁcation facility should allow marks to be

securely accessible by their respective authors.

• Each examinee should be allowed to access his

mark only or, at least, examinees should not be

able to steal marks from each other or trade marks

between each other.

3.1.3 Examinee’s Requirements

• Each exam sheet should be anonymous when it is

being marked.

• Notiﬁcation should be remote.

• The same requirements about notiﬁcation as the

last two in the examiner’s list.

3.2 Our Innovative Solution

The requirements set above can be met as described

in the sequel of this section.

The system requirements can be met by hosting

the WATA system on a remote and publicly accessible

server, not necessarily of the institution hosting the

exam. It can be assumed that the server is maintained

by a dedicated administrator, as with all institutional

servers. Access is done via HTTPS, which ensures

that all communication is encrypted and secured via

the SSL protocol. Each user registers with the server

as is customary, gaining personal credentials for con-

REMOTE MANAGEMENT OF FACE-TO-FACE WRITTEN AUTHENTICATED THOUGH ANONYMOUS EXAMS

433

ﬁdential and authenticated access (this typically in-

volves delivery of an initial password via email, and

its change into a robust one at ﬁrst login). This also

meets the requirement for multi-user support, as the

server stores the hashed versions of the passwords.

Users are required to enter their role, such as ‘ex-

aminee’ or ‘examiner’, which the system can verify

against an available list of examiners. This allows the

system to present the right menu to each user.

3.3 Preparing the Exam Sheets

Exam registration and various forms of question up-

load can be achieved by equipping the server with

a suitable database. The printing facility, includ-

ing question re-use/re-shufﬂing, can be inherited from

WATA2.0. However, contrarily to WATA2.0, it is no

longer necessary to print the two occurrences of the

same barcode, while the rest of the security token is

unchanged.

The absence of the barcode simpliﬁes the handling

of the printed, blank exam sheets. They were grouped

by a barcode in WATA2.0 such that an exam of three

questions relied on three sheets with one question

each, all having the same barcode. By contrast,

WATA3.0 is dependable also against potential mix-

ing of the unﬁlled exam question sheets before they

are handed out to the examinees, because there exists

no a priori sorting or relationship between them. This

of course assumes that it is ﬁne to ask the examinees

random questions from the database.

As explained below, this simpliﬁcation has some

price in terms of complication of the exam experience

for both parties.

3.4 Taking the Exam

The exam experience takes place as follows.

• The examiner has a laptop with connected printer.

• He feeds in the paper drawer of the printer the pre-

printed exam sheets using a prescribed orientation

(see below).

• An examinee approaches the examiner’s desk and

hands his identity card over to the examiner.

• The examiner authenticates the examinee and

feeds the latter’s personal details (name, surname,

matriculation/registration number, etc.) into the

system. Alternatively, the examiner ﬁnds those

details on a precompiled list of registered exam-

inees, which may be available.

• WATA3.0 generates a random key, whose bit

length matches that of the examinee’s details, plus

some randomness. This key is XOR-ed to the de-

tails, building the encrypted details. Key and cor-

responding ciphertext will be addressed as shares

of the personal details for brevity.

• The key for each examinee is stored in the

database next to the examinee’s details.

• The corresponding ciphertext is not stored in the

table to ensure anonymity during the marking

phase. To remove the examinees’ trust that this is

actually the case, various software security mea-

sures ca be adopted, such as: publishing the code

with its ﬁngerprint to allow examinees’ inspec-

tion; calculating the live ﬁngerprint of the code

used at the exam; check that the two match. In

practice, we have realised that this trust issue is re-

solved by the examiner’s using a machine belong-

ing to a random examinee, inserting a (read-only)

DVD with WATA3.0 in it, and using that machine

for the rest of the process. A further level of pro-

tection from the host machine can be achieved by

building a DVD with a virtual machine running

WATA3.0.

• The printer then prints the key on each of the re-

quired sheets — three sheets, for example, if three

questions are required per exam.

• The printer prints the corresponding ciphertext on

the ﬁrst exam sheet, exactly inside the security to-

ken. The ciphertext is then erased from memory.

• The examinee takes his exam sheets, walks away

to ﬁll in the security token as required, and com-

plete the exam answers. He ﬁnally tears off the

token and walks away with it, as with WATA2.0.

3.5 Marking the Exam Sheets

The marking phase is unchanged: the examiner scans

the exam barcode and enters the corresponding mark.

When ﬁnished, he publishes the results.

3.6 Notifying the Marks

The notiﬁcation experience is now available to the ex-

aminees, and can be summarised as follows.

• An examinee logs into the system, and enters the

barcode number of his token — in the assump-

tion that barcode scanners are not widespread, the

sytem can print the exadecimal version in the to-

ken so that it can be read and keyed in.

• The examinee is also required to enter his main

personal details.

• After customary conﬁrmation messages, the sys-

tem reads the input, queries the database using the

CSEDU 2011 - 3rd International Conference on Computer Supported Education

434

personal details, and then gets the corresponding

share.

• This is XOR-ed to the live share. If the outcome

matches the personal details, then the vote is suc-

cessfully registered, and a corresponding informa-

tive message is sent to the examinee. Otherwise,

a notiﬁcation of potential fraud is batched for the

examiner, while a corresponding error message is

sent of to the examinee.

• There exists a public time window for validity

of the notiﬁcation phase, such as one week. Af-

ter the corresponding deadline, WATA3.0 disables

the notiﬁcation menu for all examinees. This is

taken to mean that those who have not undergone

notiﬁcation wish to refuse the outcome.

It is clear that this system addresses the issue of

examinees authentication. Even if security tokens are

stolen or traded, no mark can be registered with the

wrong personal details. A similar attempt would lead

to failure of decryption of the personal details during

the notiﬁcation phase. All remaining requirements

formulated above are therefore satisﬁed.

4 USER INTERFACE

The user interface for examiners features a simple

menu, here omitted for brevity, with intuitive buttons

described in the following.

For example, an ‘Add Questions’ button provides

the various facilities for question upload, asking to en-

ter a new exam name/date or select an existing one.

A ‘Print Exam Sheets’ button opens up the printing

facilities through the interface in Figure 2. The exam-

iner can select the exam name among those for which

questions are available — “Computer Security” in this

case. It can be seen that the number of tests, and the

number of questions per test can be entered. It can

also be chosen whether to have a white page per ques-

tion, for the examinee’s convenience to ﬁll in. Once a

‘Create’ button is clicked, the system invokes the un-

derlying printing interface for either immediate print-

ing or creation of a PDF ﬁle to print later.

A ‘Build Shares’ button opens up the menu to

compute the two shares out of the examinee’s full

personal information (registration number alone for

brevity in the current version). It can be seen in Fig-

ure 3. The two shares are treated as described in the

previous Section, that is printed appropriately and re-

spectively recorded and discarded. Text capture is for-

bidden to increase protection of the share that must

be deleted. The risk of potential screen capture by an

unfair examiner is minimised by the whole process

Figure 2: The printing interface.

taking place under the scrutiny of the examinee, who

should be prevented from using mobile phone cam-

eras. It was considered to increase public inspection

by projecting the whole screen by a video projector,

but this would impair the prevention of mobile phone

picture taking. We have not yet evaluated examinees’

response if the shares were not displayed at all, but

directly sent off to the printer.

Figure 3: The sharing interface.

A ‘Show Tables’ buttons allows the examiner to

interact with all existing tables through simpliﬁed in-

terfaces. For example, he may like to search for a spe-

ciﬁc keyword in the question table, or delete a ques-

tion. The same could be useful over the exam table

after the marking phase. This is implemented behind

the ‘Mark Exam Sheets’ button. It leads to the inter-

face in Figure 4. It can be seen that the examiner can

enter or scan the share from the exam sheet, and then

select the appropriate mark — for example, “18” is

the minimum required to pass in an Italian university.

After selection, the mark can be saved. At completion

REMOTE MANAGEMENT OF FACE-TO-FACE WRITTEN AUTHENTICATED THOUGH ANONYMOUS EXAMS

435

of the entire marking phase, the examiner may click

“Publish Results” to enable the users registered with

role of examinee to compute their marks.

Figure 4: The marking interface.

When the deadline for notiﬁcation validity has

passed, the examiner can inspect which examinee has

had his vote registered by clicking on ‘Show Results’.

The examinee menu is simple, hence omitted here:

a ‘Notiﬁcation’ button allows the examinee to enter

his personal details and share, and then outputs the

corresponding mark, which is deﬁnitively registered.

5 IMPLEMENTATION

WATA3.0 is currently hosted on an Apache server

with support enabled for OpenSSL. It is then entirely

written in PHP and Javascript, and continues to rely

on a MySQL database.

The structure of the database is the obvious one,

with tables storing users with their roles, exam names,

exam questions, and exam marks. The PHP code

prescribes frequent accesses to the MySQL database.

These can be made transparent by storing the creden-

tials of the MySQL user ‘wata’ in a dedicated ﬁle,

called ‘wata.conf.php’. This choice may seem ques-

tionable in terms of security, but the WATA adminis-

trator will keep those ﬁles in his own disc quota.

A ﬂavour of the implementation can be obtained

by looking at the following Javascript fragments. Fig-

ure 5 shows two example functions. Function ‘Se-

cretSharing.prototype.randomString’ returns an array

of given length containing random bits. It will be in-

voked to generate the random key share by function

‘SecretSharing.prototype.encode’. This computes the

ciphertext share by bitwise XOR-ing the key share to

the personal details given as input. It can be seen that

if ﬁnally returns the share pair.

Figure 5: Two Javascript functions used in WATA3.0.

6 EVALUATION

WATA2.0 was released under the Creative Commons

licence, “Attribution Non-Commercial No Deriva-

tives”. It has vastly been adopted at the Department

of Mathematics and Informatics of the University of

Catania since 2004. The migration to WATA3.0,

which took place at the beginning of the present aca-

demic year, has been seamless. The students reported

no irregularity and enthusiastically engaged with the

web service. It is expeceted that the remote availabil-

ity of a service such as WATA3.0 can only favour its

acceptance and international diffusion.

WATA offers a rather unique service, hence the

limited related work to the previous version (Bella

et al., 2009). To the best of our knowledge, the present

version seems to have none, which explains the very

short bibliography. Moreover, WATA is under con-

tinuous development. Future work includes the im-

plementation of additional roles for other members of

the examining committe or for third-party inspectors.

7 CONCLUSIONS

WATA3.0 has been fully redesigned with respect to

the previous version to become a web service. It can

the be claimed that written exams can be now man-

aged remotely, from sheet preparation to notiﬁcation

CSEDU 2011 - 3rd International Conference on Computer Supported Education

436

and registration, while ensuring authentication of the

examinees and anonymity during the marking.

ACKNOWLEDGEMENTS

We are grateful to Stefano D’amico and Giuseppe

Gurgone for helping with the implementation.

REFERENCES

Bella, G., Costantino, G., and Riccobene, S. (2009). A sys-

tem for written authenticated though anonymous ex-

ams. In Cordeiro, J. and B.Shishkov, editors, Proc. of

the 2nd International Conference on Computer Sup-

ported Education (CSEDU09), page 132 137. IN-

STICC Press.

REMOTE MANAGEMENT OF FACE-TO-FACE WRITTEN AUTHENTICATED THOUGH ANONYMOUS EXAMS

437