Abstract
Moodle is one of the most popular open source e-learning platforms. It makes available a very easy-to-deploy environment, which once installed, is ready to be used. These two characteristics, make it a very attractive choice. But regarding information security and privacy, it presents several and important drawbacks. This is mainly due to the fact that it leaves the most serious tasks, like server configuration or access control in the hands of the system administrator or third-party module developers. This approach is understandable, as is that very fact what makes Moodle easy and therefore attractive. The aim of this paper is not to discredit this option, but to enhance it by means of standard cryptographic and information security infrastructures. We focus in the registration process, which ends with the distribution of a user certificate. To link the users’ real identity with their virtual one, we have taken an approach that merges EBIAS (Email Based Identification and Authentication System) with a kind of challenge-response method involving secure pseudo random number generation based in a fast chaos-based Pseudo Random Number Generator.
Introduction
Moodle is one of the most popular e-learning platforms, due to its easy installation and deployment. Nevertheless, a standard Moodle installation encloses some security and privacy drawbacks (see [21,12]). To avoid them, we present a registration protocol that allows the incorporation of a PKI into a Moodle platform. In this scenario, any user can use the cryptographic funcionalities of his/her personal certificate. Additionally, an important challenge for interactive systems is to make the underlying security infrastructure as invisible as possible. Indeed, security cannot be achieved at the cost of ease of use [22, Principle 6]. One could make a perfectly secure tool, but if the human interface is not easy to use, nobody will employ it. Even worst, someone could use it incorrectly leading to a false feeling of security. Beyond the problem of usability, the need for security and privacy improvements in e-learning systems has been studied in the last years and considered as a very necessary and desirable property. In [19] the benefits of a secured e-learning system are shown in an empirical test. This work compares a secure environment against a non-secure one, concluding that a major users’ trust in the secured environment produced a higher participation. Nevertheless, we want to emphasize that our proposal does not make a so extended Moodle distribution an impenetrable fortress. However, it will enormously ease the task of incorporating any cryptographic functionality into the platform. Actually, it endorses an increase of the overall security of the system information, providing the basic protocols to implement desired security requirements like demanding from every user to sign every document he/she uploads to the system.
The rest of the paper is organized as follows: in Sec. 2 we introduce the context in which our work has been developed, and the requirements to provide cryptographic functionality in a proper way; in Sec. 3 we explain the main protocol used for remote digital certificate distribution; finally, Sec. 4 will introduce some basic functionality we have provided to a default Moodle distribution thanks to the integration with a PKI, concluding with some potentially uses one could give to it.
Description of Moodle’s Default Framework and Proposed Improvements
Moodle is an open source e-learning environment. Although the default distribution comes ready to be used, its modular architecture is what makes it a powerful and successful tool. This, together with being open source, makes possible to any third party developer to add new modules and extend Moodle’s functionality without the need of touching its "core". Just by adding some basic files and folders, one can add his own contribution to Moodle by copying them into the corresponding directory. For the registration protocol proposed here, an authentication module has been created. Also, for testing some basic functionality (digital signatures), new upload and quiz modules have been created.
Regarding the main functionality we are dealing with, which is the registration process, Moodle has several registration modules available. Maybe, the most used is the one called email based authentication, which allows users to be registered in the system using their email address as identifier. With a default Moodle installation, it is possible to enhance security by limiting the valid email accounts to those pertaining to the organizational domain. A pure Email Based Identification and Authentication System (EBIAS, see [10]) bases users registration solely in the assumption that if someone can access an email account, then he is the legitimate owner of the email account. Its major advantage against other authentication methods is the ease of use and the familiarity of users with emails. Even assuming that a user who has access to an organizational email account demonstrates he is its legitimate owner, one cannot be certain that the email communications have not been intercepted and a man in the middle attack is being performed. An approach suggested at the end of [10], consists of using a hybrid system which makes use of EBIAS and PKI. This method provides the ease of use of EBIAS, and the cryptographic security provided by PKI. Since our goal is to achieve security without eroding users’ activity, we have designed an authentication procedure combining the main properties of both techniques. Other approaches for adapting emails with public key cryptography are those based on Shamir’s Identity-Based Cryptosystems (see [20,1]).
Once we have pointed out the basics required from Moodle, it is time to go into the details of PKI and email configuration. First of all, we have adopted the general recommendation for PKI architectures and, consequently, we have distinguished between Registration Authority (RA) and a Certification Authority (CA)2 [18, p. 437]. The RA plays the role of intermediary between users and the CA, whereas the CA is on charge of generating new certificates according to the different requests from the RA. This being the case, the user will interact with the Moodle Server and with the RA, but never with the CA directly. Furthermore, users’ applications must be recorded. This task is performed by the RA, which implies a communication channel between the RA and the Moodle Server. On the other hand, with respect to the email service, a highly recommended measure is to use SSL/TLS enabled email clients and servers. Almost every email provider offers this possibility. Although enabling SSL/TLS in this step does not guarantee the security of transmitted emails, it makes the access to the email server secure, preventing, e.g., impersonation attacks [9, p. 406]. But, as this will depend on users configuring correctly their email clients, we have introduced another control measure based on the generation of a ticket ID. If this ticket is unique, it prevents, e.g., man in the middle attacks, possible when the registration depends only on responding to the received email.
Finally, all the communications, except the email sending, are protected with the SSL protocol.
Registration Protocol
In short, the registration protocol is a two step verification based in the generation of a nonce (see [5, topic 3]) that will be presented to the user at the first step. This nonce will serve as response for a challenge sent by the RA server at the second step (see [13, topic 10] for an explanation of challenge-response methods involving nonces). We explain it in more detail below.
The very first step in the registration phase is to request for registration. The user does this through the usual registration Moodle web page, by filling up some personal information data. Once the user submits the form, the Moodle Server sends to the RA the data introduced by the user. This information will be used later by the CA to generate the user’s digital certificate. The RA replies with a ticket ID, which is a SHA-2 hash generated from the concatenation of a random number and the username. The RA will also store the generated pseudo random number in order to finalize the user’s registration in a subsequent step. To end this first step, the user has to download his ticket ID, which he will have to provide later in order to confirm his identity. This prevents an attacker from asking for certificates directly, as one must first pass the Moodle registration form and obtain a valid ticket ID. We have to underline that all communications between the user and the Moodle Server (MS), and between the MS and the RA are protected with SSL.
Once this first step is completed, the user receives an email with a link (just as in a default Moodle distribution), requesting him to access the site provided by the link, to confirm he is the owner of the email account. The user is challenged by the RA to provide a valid ticket ID, along with his username. The RA will check the result of the ticket ID by repeating its calculation from the pseudo random number stored in the previous step and the username provided in the current step. If the result matches the ticket ID provided by the user, then the challenge will be successfully passed, and the RA will proceed to request the CA to issue a new certificate for the new user.3
Finally, the user will be shown a dialog to download his new certificate, in PKCS#12 format, and the password used to armor it. The complete process is depicted in figure 1. It is very important to emphasize the use of SSL to secure every communication between the user and the MS and between the user and the RA, making all the information exchanges secure during the registration process. The only step not protected with SSL is the activation email sending and receiving, but this weak link is strengthen by the introduction of the ticket ID, provided securely through SSL.
Chaos-Based Generation of Nonces
A critical element in our authentication scheme is the procedure to create nonces associated to the different users. As it has been underlined above, nonces are derived from the SHA-2 hash of the concatenation of a pseudo random number and the username. Since the username is accessible to a possible attacker, the touchstone in delivering nonces is the method used in the generation of (pseudo) random numbers. There are many deterministic procedures to implement PRNGs, but we must choose a secure (by means of randomness tests) and efficient one. In this sense, we should adhere to the commitments of eSTREAM project4. In this regard, chaos-based PRNGs can be considered as an option. Certainly, chaotic systems can be employed as skeleton of new, secure and efficient PRNGs ([4]). Furthermore, cryptanalysis work in the field of chaos-based cryptography shows that security and efficiency can be achieved when there exists a proper combination of chaotic dynamics and the standards of conventional cryptography [3,7,6].
Fig. 1. Users registration protocol. (1): User requests registration (2): Moodle Server sends to the RA the user info (3): RA generates a new Ticket ID (nonce) and sends it to the Moodle Server (4.1): The Moodle Server sends the Ticket ID to the user (4.2) The Moodle Server sends an email with an activation link to the user (5): The user accesses the activation link (6): The RA asks the user for his Ticket ID and user name (7): The user sends his user name and the Ticket ID he received in step 4 (8): If the challenge result is successful, the RA asks the CA to send the user his new certificate (9) The CA sends the user his new certificate
This is the case of the PRNG proposed in [16], which is the PRNG used in our implementation.
Preliminary Analyisis of Usability
We have emphasized that usability is of major importance for interactive systems, and maybe even more when securing environments, because a misuse of the functionality could lead to huge losses. This is why we expose here some thoughts on this matter. Also, some reflections about the ease of use of the functionality are presented. Nevertheless, we are planning to test our contribution in a real scenario, which will provide us real users’ feedback to improve our functionality.
The analysis we have carried out for the introduced overload is not intended to be exhaustive. For a detailed study of the extra cost introduced by the SSL protocol one can consult existing works like [11,15], where it is proved that a well designed server architecture can provide good results in terms of throughput and response time. We have performed some tests simulating a basic scenario, consisting in sending a file of 400 KB every 30 seconds, during 10 minutes.
Fig. 2. Overload introduced by the SSL secured communications, in terms of the time response seen by the user compared to not SSL secured communications
In one case, the files were sent just like a normal Moodle distribution will do it; in the other, they are signed by the client, sent using SSL, and verified (the signature) by the server. The tests have been carried out in an Intel Core Duo with 2.80 GHz, 1MB L2 cache size and 2GB RAM, acting as MS, RA and CA. Therefore, and following the results in [11], a much better performance could be achieved with a better designed architecture (e.g. using different machines for the MS, RA and CA). Nevertheless, our tests show that, for this basic scenario, the differences in terms of time responses are not too high. We show the results obtained of one of the runs of the test in image 2. For the sake of clarity we only depict the time response for the last 40 samples (which behave like the 80 previous samples) and the evolution of the mean values obtained from them. We can observe that the time responses are quite similar, although the mean values are a little bigger for SSL protected communications than for not protected communications. The mean value of the response time obtained for unprotected communications and SSL protected communications, is of roughly 2471 ms and 2560 ms, respectively, although in some tests the difference was slightly bigger, but no more than a few hundreds of ms.
With respect to the changes a user will experience in the way he/she must interact with the system, they are just minor ones. During the registration protocol, there are only two extra steps to the eyes of the user: the ticket ID and the certificate that he will have to download. Once this is done, the added functionalities affect users’ day to day experience only when signing files and quizzes (through the private keys stored in users’ certificate to sign files and quizzes). In order to do this, the user just have to tell the browser where his/her certificate is located and introduce the corresponding password. As we have explained above, these are just minor changes. Nevertheless, we are planning to make some tests involving real users to obtain true feedback in this matter.
Conclusions and Future Work
In the current work, a registration protocol that allows the incorporation of a PKI infrastructure into an interactive environment like Moodle has been designed, making possible the introduction of all the functionalities that public key cryptography provides. This incorporation means a big step towards a more robust, privacy enhancing and secure system, a matter that does not usually get the deserved attention in this kind of systems, probably due to the fact that they are oriented to make third-party contributions easier and system configuration faster. Also, we have made a preliminary analysis showing that the added functionality does not worsen usability and the introduced overload is bearable.
We have developed Moodle modules to sign files and quizzes by students, which can be afterwards verified by the teachers in the corresponding course. This will allow to further expand system functionalities. For example, it has been studied the benefits that an adequate anonymity model can provide in order to improve the students experience (see [2,8]). E.g., an exam being submitted anonymously will ensure the maximum level of neutrality during correction, or an option for making anonymous posts in a forum could make introverted students to lose fear and have a more active participation in a course. Or even an anonymous model with direct non-repudiation (similar to the one in [17]) can be used to avoid "hooligans" to take advantage of anonymity. Also, public key watermarking methods can be used to protect digital contents uploaded to the system ([23]).
Currently, we are also working on the verification of the proposed protocol, using tools for secure protocols verification and preparing a test involving real users to measure their acceptance to the system.
