Virtualization Methods for Securing Online Exam
Abstract-The advancement of technology brings various changes to numerous fields, including education. Online exam usages are increasing, since it brings several benefits, including the possibility of automated grading. However, online exam also brings new possibilities for a cheating exam taker to access forbidden resources. Both manual and computer aided mechanisms to prevent cheating are needed. After conducting preliminary research on cheating in online exams and its detection and prevention, in this research, we present virtualization methods for securing online exams from cheating attempts in an exam client in real time. We analyzed and compared two virtualization methods, which are hardware level virtualization and operating system level virtualization, for implementing secure exam sandboxes. Based on our experiments, hardware level virtualization is the optimal method. The result of this research is a set of tools that can be used to enhance the existing proctoring methods used for securing online exam. The benefits of our proposed system are a better process isolation and low bandwidth usage. Keywords-online exam; virtualization; sandbox; process isolation; process monitoring; Windows
I. INTRODUCTION
The advent of Web technologies introduces a new dimension in examinations. Exams that were once held using pen and paper are now done with the help of the computer and the internet. On one side, this enables exam to be conducted remotely. Exam takers may not be required to come to a designated place to take an exam. On the other side, however, this also introduces new ways of cheating. An examinee may ask another person to impersonate him/her for the exam, or use the Internet to access resources for answers. Relevant control procedures are required to verify the integrity of the online exam. We have analyzed the features/capabilities, phases of the exam, and securing online exam from fraud/cheating attempts, as part of our previous research [1]. A secure online exam, which puts a student/exam taker in a restricted environment to prevent cheating, is necessary for protecting the integrity of the exam. Our programming classes at School of Electrical Engineering and Informatics, Institut Teknologi Bandung (SEEI ITB) conducts online exam using an auto-grading system. The online exam is conducted in a managed environment [2], conducted in a local environment. To take an exam, the examinees are required to present themselves in his/her designated room. Before entering the examination room, examinees are required to show valid proof of identification to the proctors. Each room is equipped with computers, which are sanitized before the exam. These computers are only installed with exam-related software, checked and cleaned regularly for files that may be used for seeking answers, can only access allowed directories, and have their network configured so that they can only access the exam website and cannot communicate with each other. These mechanisms are enforced and effective in detecting and preventing cheating. However, these methods cannot be applied on online exams in which the students are using their computers. For a large class of 400 students, the online exam cannot be conducted in a single shift, due to an inadequate number of available computers. On the other hand, it is not possible to sanitize the students’ own devices for the exam. Therefore, during the exam, each student should only be allowed to access a virtual machine that functions as a sanitized computer. Web-based software used for conducting exams can be configured such that examinees can take the exam remotely. Through a web browser, examinees can access the web browser via self-provided computers/devices, which acts as the exam client. To prevent cheating, examiners may inquire thirdparty remote proctoring services for aid, in form of applications such as ProctorU [3] and RPNow [4]. These apps enable remote administration of the exam clients. For example, the app can limit the process runing on the device, or monitor inputs from the device. This exam environment can be defmed as a managed environment [1], conducted remotely. Besides remote proctoring, other methods for securing online exam has been researched and implemented, such as shell sandbox [5] and group cryptography [6]. However, these methods do not offer a fine level of isolation. The use of virtualization enables the possibility of conducting the exam with a fmer level of control. Virtualization is one of the possible methods to achieve a particular level of control to the underlying resources of a system. In the operating system, a virtual machine, a software layer that applies virtualization concept, enables a user to control access to resources of an operating system, such as file system and networking.
In an exam environment, this gives proctors/administrators control over the exam clients, which can be used to enhance the security of the exam. Therefore, it may be possible to achieve the same level of control of a managed, local exam environment, in a managed, remote exam environment. Even though the idea of conducting online exam remotely is not relatively new [3, 4, 8], most of the current implementation requires an exam environment equipped with a high-bandwidth network. Such feature is not available in our current condition, in which the throughput of our local network is not adequate for deployment of applications that require
high-bandwidth, i.e., virtual desktop infrastructure (VDI). Besides VDI, there exist virtualization solutions that can be deployed offline [9]. A possibility of using virtualization for low-bandwidth online exam exists. Finally, through virtualization, one can emulate a computer with a similar user interface, which eases training and usage. The rest of this paper is organized as the following. Problem statement and our proposed solution are presented in Section 2. Section 3 of this paper gives some relevant works in the domain. In section 4, we present the virtualization methods explored and implemented. Section 5 presents some testing results done using the methods described in Section 4. We conclude this paper by discussion and conclusion. II. PROBLEM STATEMENT AND PROPOSED SOLUTION In our managed exam environment, means of control over an exam client’s operating system are achieved through conducting the exam on a local network. Specifically, the examiner/exam committee provides a room, equipped with sanitized computers/devices, to be used in an online exam. Such method cannot be used when conducting an online exam remotely, in which the number of available computers is not enough to serve the exam takers. In this situation, the exam then would be either held in shifts, or the exam takers would be allowed to use their computers/devices. Both of these options allow opportunities for cheating, either by giving out exam questions to exam takers taking the exam in later shifts or by access to forbidden resources during the exam. In this research, we explored and implemented virtualization methods that can be used by examiners/administrators to control an exam client remotely. Specifically, the platform that we’re using for this research is Windows, since most of the students in ITB use it on their laptops. Furthermore, we limit the security to only cover the device being used as the exam client, especially during the exam [1]. Moreover, this research only covers low-stakes online exams (exams for evaluation purposes, e.g. class quizzes), which less likely to require the level of security applied for high-stakes exams (exams used for decisionmaking, e.g. recruitment and worldwide fmal programming competitions, like ACM-ICPC and 101).
III. RELATED WORKS
Citysteer
Building Construction Planner
Android App For Employee Management System For Monitoring And Controlling Process
erestaurant Android App – Real-Time Process Management System By Sharing Food Order Information
Catering Booking Android App
Sandbox refers to a controlled environment for code execution. It imposes artificial limits on processes running on top of it. These limits may include limits to file system access, execution time limit, blocked access to other processes, and/or memory/disk usage limit. Sandbox has been widely used for various purposes, ranging from the auto-grader for programming contests [10] to web browser isolation [11]. The idea of securing online exam remotely has been implemented by various research [6, 12] and software packages [5, 2, 3]. Jung et. al. presents a system for securing remote exam without proctor supervision, using group cryptography and remote monitoring of various inputs [6], while [12] proposes various control procedures for securing exam and the use of custom software packages. SWITCH [5] presents SafeExamBrowser (SEB), a shell sandbox for the online exam. When running, it locks the desktop, defines a list of allowed processes that can be run during the exam, defmes a list of white listed and blacklisted IPs for the exam, and blocks several functionalities of the OS, such as task manager, keyboard shortcuts, context menu (right click), log out, system services, locking the workstation, and exiting the app itself. Moreover, [2, 3] provides a proctoring-as-a-service model, which, in addition to providing software packages similar to [5], each exam taker is also remotely monitored by a human proctor through webcam and microphone. Virtualization is a method that defmes a set of interfaces that maps a system/a subsystem onto the interfaces and resources of a real system, which implements these virtualized interfaces. Formally, it involves the construction of an isomorphism between a guest system and a host [7]. Let S1. and Sj. represents states of a system in the guest system, while S[ and Sj represents states of a system in the host system. For every state S, there is a virtualization function V that maps S to 51. As a corollary, for function ,9, a sequence of operations that maps S[ to Sj in the guest, there is a corresponding sequence of operations ‘ll that maps S[ to SJ. Virtualization is used for various purposes, such as testing/running binaries from another OS or for creating a sandbox [9]. It should be highlighted, however, that virtualization is not always used for sandboxing purposes, and vice versa. The virtualization methods explored in this research are hardware level virtualization and operating system level virtualization. Hardware level virtualization is defined as emulating a set of hardware, usually for running a full-fledged, sandboxed operating system, through a hypervisor. A hypervisor, software that manages such virtual machines, emulates various elements of the hardware, such as a processor, memory, hard disk, and network cards. Hardware system calls from the guest operating system are intercepted by the hypervisor. This allows applications on the guest system to be run on a different kernel than the host. Based on which it is installed, hypervisor implementations are categorized to Type-1 and Type-2. Type-l hypervisor runs directly on top of the hardware, whereas Type-2 hypervisor runs on top of the host OS. Fig. 1 illustrates the differences between the two types of hypervisors. Securing online exam through hardware level virtualization method has been explored by Reuter et. al.. In [8], Reuter et. a!. describes the general concept for online exams using VDI and SEB, including process descriptions for planning and conducting such exams [8]. It should be highlighted that the exam in [8] is conducted in a managed, local environment, that is equipped with a high bandwidth, redundant network. Such a network setup is common for VDI since a large amount of data – especially image/graphics data from and to the virtual desktops -is transferred across the network. Operating system (OS) level virtualization is a virtualization layer implemented on top of the operating system. It is achieved through isolating running applications in a separate, isolated, user space instances, which is more commonly known as containers [13]. Compared to hardware level virtualization, OS level virtualization incurs lower perfonnance overhead. All applications running on the container uses the same system calls provided by the host system, whereas both types of hardware virtualization emulate the whole system – both the kernel and the system calls. As a consequence, OS-level virtualization is only capable of running applications that run on the same kernel as the host OS. [14] provides measurements comparing the perfonnance of hardware level virtualization and OS level virtualization. OS level virtualization in Windows has been explored in various research [15, 16, 14]. In [15], Allayes presents a method of creating a lightweight virtual machine for the purpose of creating a portable application, i.e. application that preserves its settings when executed in different clients, via user-mode hooks. Moreover, Yu et. al. [16] describes a method for creating a lightweight virtual machine, called FVM. FVM uses Detours library [17], implemented as a Windows minifilter driver at the kernel space, that intercepts particular system calls and redirects them. It covers isolation and control of various operating system resources, which include file system isolation, registry isolation, object isolation (mutex, semaphore, event, timer, ports, etc.), network interface isolation, interprocess communication isolation, and daemon service isolation. Finally, Porter et. al. [14] presents a method of creating a fixed set of abstractions over Windows to construct a library OS, that encapsulates application services over a fixed set of abstractions, i.e. hardware services and user services. The library OS prototype aims for security, host independence, and ease migration of processes across different computers. By isolating the process and serving it over Remote Desktop Protocol (RDP), it achieves its isolation purposes. Hooking is a technique that can be used to implement isolation of user space instances. By hooking, or also known as runtime code patching, a programmer may alter the behavior of a particular operating system or program, by intercepting function calls of the application and redirect it to a custom function. One of the ways of achieving this during runtime is to replace the first few code instructions of the runtime function to jump to the injected code. This technique is possible on an operating system that allows dynamic modules to be loaded by applications during runtime. Examples of libraries that implement this technique are Detours [17], the original library, and EasyHook [18], which expands upon the techniques of [17].
Cruise Ship Management Mobile App Ieee Android App
Edupad A Tablet Based Educational System For Improving Adult Literacy In Rural India
Health Diet Online Search And Proposal System
PG LOCATOR For Searching PG Hostel Or Rental Houses
Smart Health Care – Like GO GREEN And ALLOPATHIC
Smart University Student Information Management System
IV. SECURING ONLINE EXAM WITH VIRTUALIZATION
A. Requirements of a secure online exam During an online exam, an exam taker should only be able to access allowed resources via the exam client. For exams that do not require access to applications installed on the client, a special browser (ex. Safe exam browser) that can only access the exam website is adequate. However, exams that require using applications and files installed on the client, such as in auto-graded programming exam at SEE I ITB, the exam taker should also be allowed access to applications and white listed files. A cheating exam taker may want to abuse vulnerabilities of the client to access forbidden resources. Fig. 2 describes the use cases of a normal exam taker (the white ellipses) and the abuse cases of a cheating exam taker (the black ellipses). To prove that the proctoring software works well, the user should be successfully executing the use cases. On the other hand, the execution of the abuse cases should fail. Online Exam Client (with allowed files & apps) Fig. 2. The use case and abuse case of an online exam client with allowed files & apps. By default, Windows shell, which is used to interact with the resources of the OS, allows access to installed applications and mounted file system. Since no monitoring, blocking, or prevention mechanism is applied, the user may freely access any resources available. Such access is not desired, since some of the resources may contain clues on how to answer the exam questions. One of the possible ways to prevent this is to use a sandbox [5, 2, 3]. We designed a system that works on four assumptions. First, it is assumed that only bundled applications are trusted. Any installed application that is similar to the bundled version is assumed as un trusted. Second, the user cannot tamper to any of the component of the system, e.g. bundled applications, hypervisor, and VM image. Third, the system assumes that the network has been pre-configured so that the exam taker can only access the exam website. Fourth, the computer/device used is capable of running the virtual machine. We hypothesize that hardware virtualization will be more suitable for implementing a sandbox for exam client. The main reason is due to the better isolation of hardware virtualization and more effort required for the development of OS level virtualization in Windows, compared to hardware level virtualization.
B. Hardware Level Virtualization One of the ways of creating a sandbox is through hardware level virtualization. For implementing our system through this method, we create a Linux live image, using existing tools, e.g. archiso. archiso includes a set of scripts that can be used to build a fully functional Arch Linux live image [19]. archiso allows customization of various aspects of the live image. For deployment purposes, it is relatively easier to use a type 2 hypervisor than a type 1 hypervisor. Since a type 2 hypervisor is installed like a normal application, users should fmd less difficulty in setting the hypervisor. Compared to type 1 hypervisors, type 2 hypervisors require fewer configurations and knowledge in order to make it work. Therefore, we choose to implement the system using a type 2 hypervisor. In this research, we use VirtualBox, an open source hypervisor, for implementing a virtual machine. By default, all applications are installed and accessed inside the virtual machine. In order to restrict the virtual machine, we propose of using RDP client to communicate with the virtual machine instance. This method can be used to prevent access to VM hardware configuration. It also bars the exam taker to access forbidden resources through the VM. Furthermore, we also used SEB to provide the shell sandbox needed, so that an exam taker cannot access non-allowed apps. C. Operating System-Level Virtualization Besides hardware level virtualization, a sandbox can also be created using OS-level virtualization via implementing system call hooks. Hooks allow modifications over default system calls used by applications. In an online exam client, system call hooks can be used to apply various levels of protection to the file system access. On the lowest level, hooks can be applied to monitor file system access. Optionally, a notification function can be added to enhance the monitoring application. Based on Fig. 3, user applications in Windows use core Windows subsystem DLLs to make system calls. In Windows, most applications reside within Win32 subsystem. Some of the DLL in this subsystem is kerne132 . dll, which includes system calls to the file system. On the other hand, at a level closer to the kernel mode, ntdll. dll is used as system service dispatch stubs to executive functions residing in the kernel [20]. Hooks to the file system-related system calls can be created by intercepting these two DLLs. Based on our analysis of the documentation on MSDN [21] and other sites [22], we found out that file-system-related system calls can be categorized into two categories: (a) handlegenerating functions, receives a string that represents path to a resource as input and outputs a handle to such resource, and (b) handle-accepting functions, that uses generated handles from handle-generating functions. Our hypothesis is that only handle-generating functions need to hook the handlegenerating functions. In total, we created hooks for 6 (out of 131) file system-related functions of kerne132 . dll and 7 (out of 30) file system-related functions ofntdll. dll.
V. EXPERIMENTS AND PROOF OF CONCEPT
Based on the use cases illustrated in Fig. 2, we created seven test scenarios to test our implementation of the abuse cases. These test scenarios are used both by the hardware level implementation and the OS level implementation (one using ntdll. dll hooks, another one using kerne132. dll hooks). In total, there are 25 tests run on each of virtualization implementation, both covering the use cases (18 test cases) and the abuse cases (7 test cases). Any error or application crash is treated as a failure. A. Test Environment Our hardware level virtualization implementation uses a customized Arch Linux live image, run on top of VirtualBox. In the live image, applications used in our online exam are bundled. These include Geany, an IDE built on GTK+2 runtime, Mozilla Firefox a web browser, MATE Terminal, the command line shell for MATE Desktop Environment, and Caja, the graphical file manager. Moreover, we also bundled gee and JDK, as compilers for C/C++ and Java, respectively, inside the image. On the other hand, our OS level virtualization implementation is run directly on top of Windows. Similar to our hardware level implementation, inside it, applications used in our online exam are bundled, i.e. Geany and Mozilla Firefox. However, since Windows already has its graphical file manager (Windows Explorer) and command line shell (Command Prompt), these two are used instead. Moreover, since our current implementations of the hooks are limited (i.e. an application cannot be hooked since it was created; it can only be hooked when it is running), we do not use installed compilers, since their running time is short (around 1-5 seconds), especially for compiling programs used for online exams (these programs consists of less than 1000 line of codes). Currently, both of our OS level implementation only logs access to the filesystem. No further action is done by them. B. Use case tests This section describes the tests for implementation of hardware level virtualization and OS level virtualization. All of these tests are taken from the normal scenarios of the use cases illustrated in Fig. 2. 1) Hardware level virtualization All test cases are passed by our implementation. The client can use the virtual machine as it is. All of the tasks, including programming, compiling, testing program, accessing the exam
website, and uploading/downloading files, can normally be done. Therefore, the hardware level virtualization passes all of our 18 test cases. 2) OS level virtualization Since our current implementation only logs access to the filesystem, there are no differences in the functions of our tested applications. All of our applications can run nonnally. Also, all accesses to the file system are recorded by both of the implementation of our applications. No crashes or errors occur by using these applications. A different behavior is shown by our as level implementations. The kerne132. dll hooks only detect accesses to file system made by Geany and Mozilla Firefox. Accesses to file system made by Command Prompt and Windows Explorer are not detected. Only the ntdll. dll hooks successfully detect all file system accesses made by all applications, including Command Prompt and Windows Explorer. Since it fails to detect such access, the kerne132 . dll hooks fail on all test cases of Command Prompt and Windows Explorer, while the ntdll. dll hooks pass all test cases. C. Abuse case tests This section describes the tests of the implementation of hardware level virtualization and as level virtualization. These tests are taken from scenarios of abuse cases in Fig. 2. 1) Hardware level virtualization SEB blocks access to the host OS’s shell. Therefore, access to files of the host as is also blocked. So far, we have not found a possible way for a regular exam taker to get out of the sandbox. In addition, network access is blocked through the configuration of the VM. Moreover, an exam taker cannot exit SEB if he/she does not have an exit password. This prevents him/her to access files on the host as during an exam. In summary, all abuse test cases are passed. 2) OS level virtualization As mentioned at Section B.2, only ntdll. dll hooks can capture file system accesses made by all applications. However, since only monitoring is done, no actual protection can be applied during the application runtime. Therefore, the users may still cheat during exams through the bundled applications. Cheats can only be detected post-exams. In addition, file system hooks cannot detect any access to websites other than the exam website. In summary, both of the as level virtualization implementations fail on all of the four test cases. Fig. 4 illustrates 25 test cases that cover the number of minimum test cases derived from the use case/abuse case diagram in Fig. 2 (9 cases) and extra cases (16 test cases). Test cases from the abuse cases in Fig 2 are related to the prevention of fraud/cheating during an online exam. The number of minimum test cases from Fig. 2 is calculated by counting the number of terminal use cases/abuse cases. Extra test cases are due to different applications being used for testing (e.g. for OS-level implementation, Create File use case is tested using Geany, Windows Explorer, and MATE Terminal).
ecom online Shopping For Retail With QR payment based Mobile Application
Geo Location Enabled Employee Registration And Attendance Tracking System
Urbis A Touristic Virtual Guide
“Development Of Smartphone Based Student Attendance System
”Integration Of Google Map In Android Shop Alliance
VI. RESUL IS AND DISCUSSION
The first part of this section analyzes and explains the experiment results of Section V. Later, the second part compares and contrasts both types of virtualization methods. A. Results Based on our experiments, hardware-level virtualization passes all test cases. It should be highlighted, however, that the tests conducted may not reflect all possible ways of detecting cheating on exams, since cheating, in general, may involve methods beyond of the test cases used to test the abuse cases on IV.C (e.g. using malicious program that can circumvent the security before the exam). For the as level virtualization, kerne132. dll hooks fail to detect accesses to the file system made by Command Prompt and Windows Explorer, while ntdll. dll hooks successfully detect these accesses. One possible explanation is that these programs do not reside on the Win32 subsystem since this subsystem is commonly used by third-party applications. B. Comparing the virtualization methods From the level of isolation provided, hardware level virtualization provides better isolation compared to as level virtualization. The hypervisor executes a separate kernel, on which isolated applications run on top of it. Since by default the guest as and host as are isolated, no communication between these two OSes can occur. From the ease of implementation aspect, hardware level virtualization is better than as level virtualization. Since the hypervisor used during the test, VirtualBox, can emulate various x86 instructions, it is easier to use operating systems that support x86 (e.g. Windows, Linux, *BSD). This enables the examiner in SEEI ITB to match the virtual image with the computers currently in use during exams. Moreover, VirtualBox is also cross-platform. This enables it to be used in different OSes. In addition, VirtualBox is stable and also provides its users with well-written documents and flexibility of configurations. This is contrasted by as level virtualization, which is OS-specific. A different implementation of this type of virtualization requires a different analysis of the file systemrelated system calls used by the as. Furthermore, as of this writing, the library used for implementing as level virtualization, EasyHook, is still in beta version. Lack of documentation and stability issues may arise when developing using this library. Besides, not all of Windows internal functions, especially functions of ntdll. dll, are welldocumented. Therefore, from our experience, OS-level virtualization requires more effort in implementation compared to hardware level virtualization. In addition, it should be highlighted that usage of SEB also aids in isolating the hypervisor from user-made customizations. SEB adds a protection to VirtualBox, since by default, VirtualBox allows customization of the guest VM. Since SEB is not available on Linux (as of this writing, it is available only on Windows and OS X), a similar application should be used when developing an exam client sandbox for Linux. From the performance aspect, OS level virtualization gains an advantage over hardware level virtualization. As presented by [7, 16], OS-level virtualization causes less overhead compared to the hardware level. This may be beneficial for online exams that use low-end hardware. However, performance gain may result in reduced security, since from a conceptual level, OS level virtualization only isolates the user spaces of the applications. It cannot detect any cheating attempts that use a modification of the host OS’s kernel. Even though hardware level virtualization is not fully safe from the same cheating method, such method requires more effort to be implemented for the hardware level virtualization, since hardware level virtualization uses a separate kernel to execute the applications.
Facilitating Examination Process Via Exam Monitoring System
Survey Land Registration System App
eRestranut Online Shopping For Food
ebanking App to Manage Account And Transfer
Nexus Mobile App For Searching Contractor And Worker In Cities
EGG Production Management System Based Mobile App
VII. CONCLUSION
This paper has presented two methods of virtualization, which is used for securing online exam clients. Based on our experiment, it can be concluded that hardware level virtualization is a better solution for securing online exam client than OS-level virtualization. The advantages include a better level of isolation and ease of implementation. In order to implement a proper OS-level virtualization solution, further research on the behavior of OS system calls is necessary. This research only covers system calls related to file system access. Other system calls is beyond the scope of this research. A proper OS-level virtualization solution would need to implement hooks to these other system calls. In addition, development of OS-level virtualization solutions, especially on Windows, is an interesting topic for research. One possible topic that can be explored is how to develop a toolkit for creating a lightweight sandbox, that can be applied to any binary runtimes. A particular interesting subject would be a toolkit for doing automated testing of hooks, that can be used to test the correctness of hooks that modifies an application from a set of test scenarios.
