TeSLA aims at providing learners with an innovative environment that allows them to take assessments remotely, thus avoiding mandatory attendance constraints. TeSLA is designed as a complex architecture in which traditional Learning Management Systems (LMS) and Virtual Learning Environment (VLE) are the entry points.
The TeSLA architecture is comprised of several entities, some of them located on the institution side, establishing communications with the LMS/VLE or with external tools embedded into the learners browsers; others belong to a separate domain independent of the institution. Securing such an architecture is a difficult task, and consists in expressing the security needs regarding sensitive and personal data on one hand, and analyzing threats both on hosts and network on the other hand. The choices made on security measures must ensure that TeSLA will be compliant with existing technical standards, and also with legal requirements, such as the European General Data Protection Regulation.
The main security services to ensure in the global TeSLA architecture are basically authentication, confidentiality, and integrity. Authentication aims at proving an entity’s identity to another, confidentiality consists in encrypting data to prevent information disclosure to unauthorized parties, while integrity aims at preventing fraudulent data alteration. Over the network, the most convenient way to implement these security services is to deploy the well known Transport Layer Security (TLS) protocol, which allows entities to authenticate to each other and creates a secure tunnel with data encryption and integrity check.
Authentication in TLS does not rely on passwords, but on X.509 certificates. These certificates rely on asymmetric cryptography, and create an association between a public key and an identity. Any entity can authenticate itself thanks to its certificate, as long as it owns the associated private key, which is never transmitted over the network. The certificate management requires a Public Key Infrastructure (PKI), in which specific trusted entities, called Certification Authorities, are in charge of certificate delivery. Hence, TeSLA will have its own PKI to manage the certificates within the TeSLA domain on one hand, and within the institution domain on the other hand. This way, the communications between the various entities of the TeSLA architecture can be entirely secured.
However, other aspects have to be taken into account. For instance, for privacy reasons, the identity of the learners should not be disclosed to TeSLA. To provide partial anonymity to the learners, a randomized TeSLA ID will be generated for each TeSLA user and represent their identity within the TeSLA domain, where the full name of the user will remain unknown.
Finally, an in-depth security analysis must also be conducted on the host side of the architecture. Deploying the software components of TeSLA in Docker containers provides a lighter and more flexible virtualization solution than relying on traditional virtual machines, but fails to provide isolation with the host operating system. Should the host system be compromised, every container running on it will also be compromised, which can turn into a major threat for TeSLA. This issue is merely one of the several challenges that have been addressed in order to succeed in securing the whole TeSLA architecture.
FUNDED BY THE EUROPEAN UNION
TeSLA is not responsible for any contents linked or referred to from these pages. It does not associate or identify itself with the content of third parties to which it refers via a link. Furthermore TESLA is not liable for any postings or messages published by users of discussion boards, guest books or mailing lists provided on its page. We have no control over the nature, content and availability of any links that may appear on our site. The inclusion of any links does not necessarily imply a recommendation or endorse the views expressed within them.
TeSLA is coordinated by Universitat Oberta de Catalunya (UOC) and funded by the European Commission’s Horizon 2020 ICT Programme. This website reflects the views only of the authors, and the Commission cannot be held responsible for any use which may be made of the information contained therein.