A Quantitative Analysis into the Economics of Correcting Software Bugs - Computational Intelligence in Security for Information Systems - page 216

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 Author-
ity (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. Fur-
thermore, 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 recom-
mended 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.
3 Registration Protocol
In short, the registration protocol is a twostepverificationbasedinthegenera-
tion of a nonce (see [5, Chapter 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, Chapter 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
2 An example of secure architecture can be seen in http://www.ejbca.org/
architecture.html