We are designing a computer based test system where the examinees use their own computers to write their answers. The examinees' computers are booted to a custom Linux OS from USB drives provided by the examiner.

The USB drives that are used to boot the examinees' computers all contain exactly the same OS image.

The exam itself is provided by a central server and the answers are transferred back to the central server as they are being written. All the involved computers are in a closed LAN.

The system must support resuming the exam from the latest state transferred to the server in case of a hardware failure. The USB drive used as a permanent storage can potentially fail, as can the examinee's laptop computer.

The identities of the examinees are verified by trusted people at some point at the event (before, during, or after the examinees take the exam). The identity verification should cause minimal disruption for the examinees and minimal work for the trusted people. There can be up to a couple of hundred people taking the exam in the same space with approximately one trusted person per every 20 examinees.

Current design

Our current design is to generate a strong token on the examinee's computer when the examinee starts the exam. The token would be calculated using the SSN provided by the examinee, and some hardware UUIDs (CPU, USB drive). This token would be stored on the USB drive. When the examinee finishes the exam, she would pass the drive to a trusted person. The trusted person would then, using a dedicated computer, verify the identity of the examinee and the token stored on the drive against the token stored on the central server.

The pros of this design are that it is easy for a group of examinees to start the exam, and the verification is a read-only activity at the end of the exam. This design has at least one weakness: in case the hardware used for the tokens of two or more examinees breaks down simultaneously, it's no longer possible to verify who had hold of which device. For example, a power surge could cause multiple laptops and drives to break down at the same exact moment.


What other attack vectors come to mind and how could they be mitigated? Any better alternative designs?

| improve this question | | | | |
  • 1
    Could you add intermittent photos of the test takers? If those are stored with the results on the server, it would help with the multiple-failure case that you mention. – Neil Smithline Jul 29 '15 at 15:57
  • Thanks! This is an interesting idea to explore. Our current specification for the laptops of the examinees does not require them to have cameras so for the time being we have to make do without. – hvrauhal Jul 29 '15 at 19:58

Attack vector:

Examinees may easily swap drives during or after the test, if there is no pre-authentication of which examinee gets assigned which token. Using just the token is not sufficient, as examinees may pre-arrange an SSN swap.

  1. A gives B his SSN.
  2. B startes the exam, generating a token for A's SSN on his usb stick.
  3. After the exam is completed, B gives his USB stick to A.
  4. A turns the USB stick over to the trusted person, who verifies that the token is correct for the supplied SSN.

Mitigation: USB sticks are collected by a trusted person (who also verifies identitiy on the spot and matches it to token on USB stick) prior to anyone being allowed to leave their desk. At no point can anyone leave their desks without supervision. Even in this configuration, it may be possible for students to have swapped sticks prior to ID confirmation.

IMO, a better configuration is not to store anything on physical media.

Instead, the test is served remotely in its entirety. In order to start the test, the examinee must supply not only his personal credentials (SSN, password, whatever your facility/institution uses) in combination with a random, pre-written key that the examinee is given access to only after (1) their identity has been verified, and (2) they can no longer interact with anyone unsupervised.

| improve this answer | | | | |
  • We trust the physical surveillance that no hardware can be swapped between examinees during the exam. This is analogous to passing notes between examinees during the exam. – hvrauhal Jul 30 '15 at 8:10
  • The suggestion of verifying identities at the start of the exam would be more secure, but it has scaling issues. There are a lot of people starting the exam at the exact same moment, but they are allowed to leave the exam after the first hour when they are ready. Verifying the identities during or after the exam spreads the load better. – hvrauhal Jul 30 '15 at 8:14
  • @hvrauhal If you are confident that no hardware can be swapped at any time, that's good and well, but this alone does not mitigate against a pre-arranged swap of credentials. The attack surface is larger by an order of magnitude if there is no authentication of whether the examinee's presence can be verified as legitimate or not prior to or at the start of the exam. – Vegard Jul 30 '15 at 8:54
  • @hvrauhal If you have access to additional hardware, biometrics might serve your purpose. It's a pretty large project to take on, but I'd mention it just in case... you can pre-record fingerprints in a trusted environment, store these on central server, and use hardware-reading at the start of the exam to verify identity. – Vegard Jul 30 '15 at 8:57
  • the examinees use their own laptops in the exam, and we would not like to require additional hardware. The webcams are something that could be used in the future, but not for now. – hvrauhal Jul 30 '15 at 9:30

Why not keep it very simple:

Examinee enters name + other identifying information (e.g. drivers license or passport number) on first page of test.

That info will be shown an all subsequent test screens somewhere in the header or footer.

Then he puts his drivers license on the table in front of him.

Meanwhile you print out an ordered list of license number and name.

Trusted person then goes around and checks correspondence of ID and person and information shown on the screen. Then he checks off the person of the list.

No crypto needed + you have a paper trail. If it fails at all, it fails at the beginning of the test when you print out your list.

If you ask people to return the drive afterwards, there will be a long line, a few people will mix up their drives, some will loose it, a few will just run out and forget it in their pocket or leave it on the table.

Other point: Do you really have to use SSNs? I don't feel good about this. If it is only for verification, you can put sensitive info like driver's license number on the far right edge of your printout and then cut it off and discard, but keep the checked list.

| improve this answer | | | | |
  • The examinees use an ordinary web browser to answer the exam served from the central server, so they could modify what is shown on the screen during the exam. To overcome this, the suggested mechanism could be combined with a token exchange between the central server and the examinees' laptops, and then the token would then also need to be verified by the trusted person visually. One goal of the project is to convert the whole examination from paper to digital so we would like to avoid all papers. – hvrauhal Jul 30 '15 at 8:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.