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

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.
3.1 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 de-
rived 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 touch-
stone in delivering nonces is the method used in the generation of (pseudo) ran-
dom numbers. There are many deterministic procedures to implement PRNGs,
but we must choose a secure (by means of randomness tests) and ecient one. In
this sense, we should adhere to the commitments of eSTREAM project 4 .Inthis
regard, chaos-based PRNGs can be considered as an option. Certainly, chaotic
systems can be employed as skeleton of new, secure and ecient PRNGs ([4]).
Furthermore, cryptanalysis work in the field of chaos-based cryptography shows
that security and eciency can be achieved when there exists a proper combina-
tion of chaotic dynamics and the standards of conventional cryptography [3,7,6].
3 Here, additional functionality can be added, e.g., to use different certificate profiles
depending on the email subdomain.
4 http://www.ecrypt.eu.org/stream/