Faculdade de Ciências e Tecnologia
Departamento de Informática
Dissertação de Mestrado
Context-aware multi-factor authentication
Luís Henrique Fernandes Moura Miranda (aluno nº 27169)
Orientador:
Prof. Doutor Henrique João Lemos Domingos
Trabalho apresentado no âmbito do Mestrado em Engenha-ria Informática, como requisito parcial para obtenção do grau de Mestre em Engenharia Informática.
I would like to thank Professor Henrique João L. Domingos for his supervision as teacher and adviser, to the department of informatics of Faculdade de Ciências e Tecnologia at Universidade Nova de Lisboa (DI-FCT-UNL) for conceding a scholarship for introduction to investigation during the past year, to my colleagues at DI-FCT-UNL for their friendship and availability to help me during the last five years, to my friends who were always there despite my absence and most of all to Andreia and to my parents for their patience and unconditional support.
Authentication systems, as available today, are inappropriate for the requirements of ubiqui-tous, heterogeneous and large scale distributed systems. Some important limitations are: (i) the use of weak or rigid authentication factors as principal’s identity proofs, (ii) non flexibility to combine different authentication modes for dynamic and context-aware interaction criteria, (iii) not being extensible models to integrate new or emergent pervasive authentication factors and (iv) difficulty to manage the coexistence of multi-factor authentication proofs in a unified single sign-on solution. The objective of this dissertation is the design, implementation and experimental evaluation of a platform supporting multi-factor authentication services, as a con-tribution to overcome the above limitations. The devised platform will provide a uniform and flexible authentication base for multi-factor authentication requirements and context-aware au-thentication modes for ubiquitous applications and services. The main contribution is focused on the design and implementation of an extensible authentication framework model, integrat-ing classic as well as new pervasive authentication factors that can be composed for different context-aware dynamic requirements. Flexibility criteria are addressed by the establishment of a unified authentication back-end, supporting authentication modes as defined processes and rules expressed in a SAML based declarative markup language. The authentication base supports an extended single sign-on system that can be dynamically tailored for multi-factor authentication policies, considering large scale distributed applications and according with ubiquitous interac-tion needs.
Keywords: authentication, context, multi-modal, multi-factor, SSO, ubiquity
Tal como são conhecidos nos dias de hoje, os sistemas de autenticação são inapropriados, considerando os requisitos dos serviços e aplicações de sistemas distribuídos de grande es-cala, heterogéneos e ubíquos. Algumas destas limitações são: (i) o uso de factores de auten-ticação demasiado fracos ou rígidos como provas de identidade de principais, (ii) a falta de flexibilidade para combinação de diferentes modos de autenticação que considerem interacções dinâmicas e dependentes do contexto, (iii) o facto de não terem por base modelos extensíveis a factores de autenticação novos e emergentes e (iv) a dificuldade em gerir provas de autenticação multi-factor com base em sistemassingle sign-onpara autenticação uniforme e normalizada. O objectivo desta dissertação considera o desenho, a implementação e a avaliação experimental de uma plataforma que suporte autenticação multi-factor, como uma contribuição para superar as limitações mencionadas. As principais contribuições passam pela implementação de um mo-delo de autenticação extensível, que integre simultaneamente factores de autenticação clássicos e emergentes, podendo estes ser compostos de acordo com requisitos dinâmicos e dependentes do contexto de utilização. O critério de flexibilidade é conseguido através da concretização de uma base uniforme de autenticação, que suporte diferentes modos de autenticação segundo um conjunto de regras e processos expressos numa linguagem declarativa baseada na especifica-ção SAML. A base de autenticaespecifica-ção suporta e estende um sistemasingle sign-onpara que este permita a configuração dinâmica de regras e politicas de autenticação multi-factor, bem como as necessidades de interacção ubíqua em serviços e aplicações usados em ambientes de grande escala.
Palavras-chave: Autenticação, contexto, multi-modal, multi-factor, SSO, ubiquidade
1 Introduction 1
1.1 Motivation 1
1.2 Context 2
1.2.1 Authentication and distributed systems 2
1.2.2 Access control models 3
1.2.2.1 Discretionary access control (DAC) 3
1.2.2.2 Mandatory access control (MAC) 3
1.2.2.3 Role based access control (RBAC) 4
1.2.2.4 Access control lists 4
1.2.2.5 Capabilities 4
1.2.3 Authentication mechanisms, factors and services 5
1.2.3.1 Classic authentication factors 5
1.2.3.2 Emerging authentication factors 5
1.2.3.3 Authentication mechanisms 6
1.2.4 Uni-factor drawbacks 6
1.2.5 Multi-factor and multi-modal authentication systems 7
1.2.6 Ubiquitous systems 7
1.2.7 Single sign-on systems 8
1.3 Identified limitations 8
1.4 Contributions 10
1.5 Document structure 10
2 Related Work 11
2.1 Authentication in classic modes 11
2.1.1 Static passwords 11
2.1.2 Token based systems 13
2.1.2.1 Hardware security tokens 13
2.1.2.2 Software security tokens 14
2.1.3 Multi-modal authentication with biometrics 15 2.1.3.1 Biometric authentication system architecture 15 2.1.3.2 Issues concerning authentication trough biometrics 16 2.1.3.3 Multi-modal biometric authentication systems 18 2.2 Authentication factors for ubiquitous environments 19
2.2.1 Something the user sees 19
2.2.2 Something the user makes 20
2.2.3 Somewhere the user is 21
2.3 Multi-factor and multi-modal authentication 23
2.4 Single sign-on mechanisms and protocols 23
2.4.1 Java authentication and authorization API 25
2.4.2 SAML 27
2.4.3 OpenID 28
2.4.4 OpenSSO 30
2.4.5 Enterprise sign-on engine 31
2.4.6 Kerberos and the PKINIT approach 32
2.5 Summary and contributions 34
2.5.1 Overview 34
2.5.2 Context based authentication and multi-factor authentication 35
2.5.3 Contribution 36
3 A context-aware multi-factor authentication system 37
3.1 Scope and requirements 37
3.2 Core concepts 37
3.3 Interaction model 39
3.4 CAM2ML 40
3.4.1 Assertions 40
3.4.2 Requests 41
3.4.3 Reference protocol 43
3.4.3.1 Security analysis 44
3.4.4 CAM2ML vs SAML 44
3.5 CAM2 identity platform 45
3.5.1 Client integration tier 46
3.5.2 Authentication logic tier 47
3.5.3 Data integration tier 48
3.6 Application scenarios 48
3.6.1 Web authentication 49
3.6.2 Mobile authentication 49
3.6.3 Spontaneous authentication 50
3.6.4 Kerberos extended by CAM2 50
3.6.5 Asynchronous authentication 51
4 Architecture for CAM2 authentication platform 53
4.1 CAM2ML Object model 53
4.1.1 CAM2MLExportable interface 53
4.1.2 Context Item 54
4.1.3 Authentication modes 55
4.1.4 Assertion 55
4.1.5 Request 56
4.2 CAM2 Identity platform 57
4.2.1.1 CAM2ML front end services 57 4.2.1.2 Web authentication integration module 59 4.2.1.3 SOAP authentication integration module 60 4.2.1.4 RESTful authentication integration module 61 4.2.1.5 Kerberos legacy integration modules 61
4.2.1.6 CAM2ML Extended Kerberos V5 63
4.2.1.7 Admin console integration services 64
4.2.2 Authentication logic layer 65
4.2.2.1 Policy manager 65
4.2.2.2 Authentication core 66
4.2.2.3 Platform services 68
4.2.3 Data integration layer 68
4.2.3.1 onetime passwords synchronization server 69
4.2.3.2 LDAP server 69
4.2.3.3 Kerberos data interface 69
4.2.3.4 Bluetooth token validation server 70
4.2.3.5 Movement template matcher 71
4.2.3.6 Visual proof repository 72
5 Implementation 73
5.1 Chosen technologies 73
5.1.1 J2EE Platform 73
5.1.2 J2ME 75
5.1.3 Python and Symbian C++ 75
5.1.4 JavaServer Pages 76
5.1.5 OpenSSO 76
5.1.6 GlassFish 76
5.1.7 eXist 77
5.1.8 Web services and security 77
5.2 Runtime 77
5.3 Protocol Integration modules 78
5.3.1 Web integration authentication module 78
5.3.2 Web services integration authentication modules 81 5.3.3 Kerberos integration authentication module 81
5.4 Authentication modules 81
5.5 Validators 85
5.5.1 CAM2 Secure CLIP 85
5.5.2 CAM2 Mobile payment application 87
5.5.3 CAM2 Kerberos 87
6 Performance evaluations 89
6.1 Workbench 89
6.2 Benchmarks 90
6.3 Local tests 92
6.4 Internet tests 97
6.5 Results overview 101
7 Requirement validations 103
Expression of dynamic context aware authentication processes 103
Multi-factor and multi-modal authentication 103
Dynamic and context-aware proof requirement 104
Extensibility for new authentication models 104
Generic usage 104
Performance 105
8 Conclusions and future work 107
8.1 Future work 109
Bibliography 115
A CAM2ML XML Schema 121
A.1 Assertion.xsd 121
A.2 Request.xsd 122
A.3 AuthenticationModes.xsd 123
A.4 Context.xsd 124
A.5 Policy.xsd 126
2.1 Hardware security tokens 14
2.2 Biometric traits comparison 16
2.3 Relation betweenFNMRandFMR 18
2.4 Mobile phones performing SiB protocol 20
2.5 Single sign-on middleware architecture 25
2.6 JAAS architecture 26
2.7 SAML protocol 28
2.8 OpenID interaction model. 29
2.9 OpenSSO architecture 31
2.10 ESOE architecture 32
3.1 CAM2 Utilization 39
3.2 CAM2 interaction model 39
3.3 Example of a policy assertion 42
3.4 Example of policy request 43
3.5 CAM2 Identity Provider: Reference architecture 46
4.1 Object model for CAM2ML mapping 54
4.2 Context item and context manager class diagram 55
4.3 Component diagram for CAM2 IdP architecture 58
4.4 Activity diagram for the authentication process 67
5.1 Authentication platform implementation blueprint 74
5.2 Deployment diagram 79
5.3 Bluetooth OTP authentication 83
5.4 Visual based authentication 84
5.5 Gesture Identification 84
5.6 Example of an authentication event on CAM2 version of CLIP system 86
5.7 Bank application WEB interface 87
5.8 Kerberos client GUI 88
5.9 CAM2 Web Administration console 88
6.1 OpenSSO load test with 1 client 92
6.2 CAM2 load test with 1 client 92
6.3 OpenSSO load test with 50 concurrent clients 93
6.4 CAM2 load test with 50 concurrent clients 94
6.6 CAM2 load test with 100 concurrent clients 94
6.5 OpenSSO load test with 100 concurrent clients 95
6.7 CAM2 latency distribution 95
6.8 OpenSSO load test with 1 client 97
6.9 CAM2 load test with 1 client 97
6.10 OpenSSO load test with 50 concurrent clients 98
6.11 CAM2 load test with 50 concurrent clients 99
6.12 OpenSSO load test with 100 concurrent clients 99
6.13 CAM2 load test with 100 concurrent clients 100
1.1
Motivation
In the nowadays society, services and resources are shared between entities trough large scale and ubiquitous distributed information systems. Many times these systems are based on het-erogeneous and ubiquitous computer systems and devices, interconnected by different commu-nication infrastructures including mobile and stationary commucommu-nication settings. Large scale ubiquitous systems and applications are used as services available with different context-aware interaction requirements and specific access conditions. Today, ubiquitous and large scale sys-tems are composed by multi-application environments or services composed by different appli-cation components, more or less specialized for different devices, ranging from personal and convenient devices (as mobile phones, handhelds, etc), to well-managed computers with su-pervised security conditions in enterprises and institutions. Authentication methods became mandatory as part of any resource sharing system. The above conditions demand new context-aware authentication requirements that will be discussed during this dissertation.
Today, authentication systems are typically based on one of three classic factors: something
the user knows(as passwords, PINs, shared secrets, etc.)something the user has(dynamic
one-time-password tokens, smart cards, etc.) andsomething the user is or does(biometric factors). However, each one of those factors has limitations. Passwords are easy to guess and users tend to misuse them, tokens can be lost, stolen or reproduced and are difficult to manage and biometry is an expensive solution, with possible accuracy limitations and personal intrusion issues. Multi-factor and multi-modal authentication comes as better solution since it combines multiple authentication factors, therefore hiding their flaws while enforcing the overall accuracy, convenience and assurance levels. This motivates the objective of the current dissertation that is focused in the design, implementation and experimental evaluation of a platform supporting multi-factor authentication services, as a contribution to overcome the introduced limitations. The devised middleware will provide a uniform and flexible authentication extension for multi-factor authentication requirements and context-aware authentication modes for the ubiquitous applications and services currently available.
1.2
Context
1.2.1 Authentication and distributed systems
Making ubiquitous environments secure essentially boils down to different security properties and issues. As addressed in the classical distributed systems security vision, these properties appear as categorizations of fundamental concepts, such as: authentication, confidentiality, in-tegrity, availability, access-control and auditing [4].
Security properties, adversary models, attacks typology and security services (used as counter measures against attacks to establish security properties) are extensively described in the clas-sical approach and literature of distributed systems security [18],[50] and computer networks security services, protocols and standards [9],[40]. Adversary models, the typology of attacks and adversary hypothesis are usually defined, discussed and formalized in security frameworks [47] inspiring the design of security services and standards.
Security standards also evolve according with new security conditions, new technology, considering possible limitations and context-aware conditions, new adversary models and new attack hypothesis.
For authentication purposes, principals are primarily defined as abstract entities, associated to digital unique identifiers, at different abstraction levels of distributed systems. From this viewpoint, a principal can be an interface, a device, a data-link address, a network address, a software component or a user. Depending on the abstraction level, authentication must be established as an essential property of secure interaction channels, from point-to-point com-munication (establishing authenticated data-link or network-level endpoints) to end-to-end user level (involving user’s identity authentication proofs).
also used as seed values to generate cryptographic keys or other shared secret values or parame-ters to establish security associations in secure protocols protected by cryptographic algorithms [1],[47],[21]. The second issue is concerned with access-control (based on the previous au-thentication and evaluation of proofs or evidences of each principal identity). Access-control addresses the problem of controlling the access to resources, objects and operations over those resources and objects). Authentication and access-control are different security properties, even if can be closely related and sometimes are two faces of the same coin.
Authorization is the process of granting access to a resource based on the identification of the interested entity [47]. Access control is achieved by verifying if authentic subjects satisfy one or more permission policies. For that, it is necessary to validate in advance the identities of the subjects involved on the process.
1.2.2 Access control models
There are three classic models for access control: Discretionary Access Control (), Mandatory Access Control () [35] and Role Based Access Control (RBAC) [44]. Access control models may rely on multiple mechanisms. Access control lists and capabilities are the most common among them.
1.2.2.1 Discretionary access control (DAC)
DAC Is an object centric model which, consists on setting permission to objects in a decen-tralized way. A system based on this model doesn’t define any hierarchy between subjects and objects. In this model, it is the subject who sets the access policies to his own objects. As an example there is the UNIX’s file permission system, where an administrator can set different policies for three groups of users: the subject himself, other users and for the work-group. A DAC model requires that the identifiers used to map subjects to its resources must be previously authenticated in order to warrant the security concerns related to access control.
1.2.2.2 Mandatory access control (MAC)
model it is possible to apply security policies to the whole system at once, which is much more difficult to make in systems based on DAC model. A typical example where the MAC model can be seen is on a Database Management System. In a MAC model, the identifiers associated to subjects representing users and policy administrators must previously authenticated in order to warrant the security concerns associated to access control model.
1.2.2.3 Role based access control (RBAC)
Some systems must deal with different levels of granularity. While in file systems the grain blocks are users and objects, the same may not be appropriated for large systems with large amounts of objects and users. Considering this scenario, a system using DAC or MAC based models is limited in what concerns to scale, since all entities must be managed independently. An alternative is the use of Role Based Access Control Model [44]. RBAC is a neutral and flexi-ble access control model sufficiently powerful to simulate Discretionary Access Control (DAC) and Mandatory Access Control (MAC). With RBAC the permissions to perform certain oper-ations are assigned to specific roles. Subjects are assigned particular roles, and through those role assignments acquire the permissions to perform particular system functions. Since subjects are not assigned permissions directly, but only acquire them through their role (or roles), the management of individual user rights becomes a matter of simply setting the appropriate roles to those subjects, which simplifies common operations such as adding a user, or changing the user’s department.
1.2.2.4 Access control lists
ACLs are data structures that store information about objects and the operations that users are able to perform on them [4]. Systems based on DAC model attach ACLs to objects that must be protected, that way user centric policing is achieved. MAC based systems hold centralized ACLs that are crosscutting to all objects.
1.2.2.5 Capabilities
and respective permissions for a specified user. Every time the user wants to access an object, he must provide his capabilities, which are used by the resource holder in order to perform access control.
1.2.3 Authentication mechanisms, factors and services
1.2.3.1 Classic authentication factors
Authentication processes require digital identities and proofs in order to validate subjects. Those proofs are usually classified in three classes: something the subject has, something the subject
knows, orsomething the subject is or does[4]. The first factor relies on proofs as objects that
must be kept by subjects, such as smart cards, SIM cards or cell phones. The second factor is related to information that must be memorized by subjects, like passwords, PINs or passphrases. Finally the third factor depends on biometric traits such as fingertips, face, hand geometry, iris, or voice patterns and rhythm recognition [17].
1.2.3.2 Emerging authentication factors
1.2.3.3 Authentication mechanisms
Authentication mechanisms are defined as abstractions which can be used as trustable base building block components. They can be combined in different ways to implement authen-tication services with different security properties. Examples of authenauthen-tication mechanisms are: cryptographic algorithms or primitives, authentication protocols or authentication audit-ing tools. Authentication mechanisms can be categorized as specific mechanisms (correspond-ing to mechanisms with verifiable formal properties that map specific security properties) and pervasive security mechanisms (no specific to a well-defined security property) [40]. Follow-ing the definition existFollow-ing on related literature, examples of specific security mechanisms are: encipherment based on computational cryptography, digital signatures or public-key certifica-tion or notarizacertifica-tion or authenticacertifica-tion exchange protocols. Examples of pervasive mechanisms are: event-detection evidences, security logging and audit-trails, trust-management or reputa-tion control. According to these noreputa-tions, authenticareputa-tion factors embrace both authenticated proofs used as input parameters to specific authentication mechanisms as well as complemen-tary evidences to set up pervasive mechanisms.
1.2.4 Uni-factor drawbacks
Authentication schemes uniquely based onsomething the user knowsauthentication factor have the advantage of uniquely relying on information that it’s supposed to be known only by the participating entities, thus being difficult to steal or to duplicate. Nevertheless what really hap-pens is that users tend to use guessable passwords, share them with other users or even write them down, giving origin to security vulnerabilities [4].
Systems based on security tokens can prevent most of the disadvantages previously shown, but the utilization of objects tends to be less practical or non convenient, since they can be lost, stolen, or reproduced. On the other hand, solutions based on security tokens in a large scale system environment are in general difficult to manage and have high operational costs. Some devices used as security tokens can be expensive according with their functionality.
intrusion and lack of accuracy that is determined by their False Rejection Rate(FRR) and False Accepting Rate (FAR)[19, 18].
Emergent authentication factors, as introduced before, are in general application specific and cannot be used by themselves as uni-factors for the majority of the existing scenarios.
1.2.5 Multi-factor and multi-modal authentication systems
One approach to solve the problem of uni-factor authentication is to combine multiple fac-tors [12], [23], [55]. The multi-factor approach improves the assurance level of authentication processes, by combining the advantages of all authentication factors and covering the draw-backs of the remaining. For instance, one classic type of multi-factor authentication, known as two factor authentication, is present on ATMs. Here, users introduce a card (first factor) and a PIN code (second factor). It is considered that any access control system that uses more than one factor supports strong authentication.
Factors can even be used in a multi-modal fashion. In this case different types of information related to the same factor are combined to get uni-factor authentication. A typical example of this approach is present on biometric multi-modal systems that combine two biometric modes like iris and fingertip recognition. The usage of multi-factor and multi-modal authentication improves the level of assurance granted by the validation processes, since the disadvantages of each factor is overlapped by the advantages of the remaining types of proofs.
1.2.6 Ubiquitous systems
authentication processes. The works described on [27], [45] and [26] show alternative authen-tication factors, namely something the user sees, somewhere the user is andsome gesture the user makes.
1.2.7 Single sign-on systems
Considering an organization where multiple authentication systems are used, the management and validation of digital identities becomes a hard process both for users and system adminis-trators. Users must keep multiple credentials (typically passwords) and log-in at least as many times as the number of resources they want to access. On the other hand, administrators must manage the identities and respective authentication data from multiple subjects.
Single sign-on systems (SSO) address these problems by supplying a centrally managed identity provider accessed by all resources. With a single sign-on system, users only have to pass through the login process once. Therefore, SSO systems act as a unique and uniform authentication base used by all components in the organization. Systems like, OpenSSO [32], Enterprise SignOn Engine (ESOE) [36] and Kerberos protocol, with a new vision using public cryptography [56], are examples ofstate-of-artsingle sign-on based approaches. Some of these authentication platforms support reliable extension mechanisms, such as OSID [16] and JAAS, [24] and provide interfaces for interoperability with other systems relying on open standards like such SAML [2] and OpenID [41].
1.3
Identified limitations
Authentication services as systems combining different authentication mechanisms - as avail-able today - are inappropriate for the requirements of ubiquitous and heterogeneous large scale distributed systems, applications and services.
functionality specialization, dynamic profiling and other context-aware conditions. These cri-teria impose different security concerns and tradeoffs with a relevant impact on the need of different and new authentication mechanisms.
The major drawbacks of the current authentication services are the following:
• In general, authentication services make use of weak or rigid authentication factors used as proofs of identity of principals. Most of them are based on secret-sharing, which are very vulnerable such as password-attacks, and social engineering [49].
• Non flexibility for multi-factor authentication purposes adapted to dynamic context-aware interaction criteria. Available technology allows the installation of authentication plat-forms based on the multi-factor authentication principle to overcome the limitations or risks associated to specific factors stronger than passwords. However, these are propri-etary systems; with a limited vision on very specific factors for specific applications and environments (examples include two-factor schemes merging passwords and specific de-vices such as: tokens or smart cards or biometric authentication servers including support for a specific biometric factor, such as fingerprints). Furthermore, these systems con-figure authentication factors in a rigid and static way in a user-centered perspective and for a specific application. The available systems don’t have a combined vision of user and ubiquitous context-aware centered perspective oriented for different applications and heterogeneous devices. Finally, due to the rigid behavior of available technology, these kinds of systems aren’t extensible to emerging pervasive factors such as something the
user sees, somewhere the user isorsomething the user makes.
1.4
Contributions
Given the limitations identified on the last subsection, the objective of this dissertation is the design, implementation and experimental evaluation of a middleware platform supporting multi-factor and multi-modal authentication services, as a contribution to overcome the limi-tations discussed on the previous section. The devised platform must provide a uniform and flexible authentication base for multi-factor authentication requirements and context-aware au-thentication modes that can be used in ubiquitous applications and services. The main goal is to implement an extensible authentication framework model integrating classic as well as new and emergent authentication factors. These factors must be composed according to context-aware dynamic requirements and user interaction conditions. The flexibility criteria will be addressed by the establishment of a unified authentication back-end, supporting authentication modes as processes and rules expressed in a context-aware multi-factor and multi-modal markup language (CAM2ML).
The management of multi-factor and multi-modal identities and their authentication data is assured by the utilization ofstate-of-artsingle sign-on authentication platforms, which already support extension mechanisms for new and emergent authentication factors as well as primitives for interoperability with other systems, relying on open standards. Therefore, the objective of the proposed solution is accomplished reusing the services provided by single sign-on systems, which can be dynamically tailored to combine multi-factor authentication rules and policies for multi-device supported applications and different interaction needs.
1.5
Document structure
This chapter presents a related work overview according with the motivations and objectives of the current dissertation. The related work presented covers different issues and topics as follow: first a brief overview on authentication factors and classic authentication systems is presented, as well as a discussion on the drawbacks of these systems for the requirements of ubiquitous context-aware and multi-channel interaction platforms; as an approach to overcome those drawbacks, multi-factor and multi-modal authentication systems are introduced. Standard framework specifications for integration of authentication systems are also discussed, as well as the approach of single sign-on based systems and protocols. Finally the chapter presents a critical analysis concerning the design of a multi-factor and multi-modal authentication plat-form providing uniplat-form and flexible authentication services for context-aware and ubiquitous applications and services.
2.1
Authentication in classic modes
In this section the classic authentication factors will be discussed. Despite their individual drawbacks, they are still usedas isin the majority of authentication systems.
2.1.1 Static passwords
Most of the current authentication systems use static passwords as authentication proofs. In these systems users must provide passwords in order to get authorization to access resources. Validating the authenticity of an electronic component is a trivial process. However the same is not applicable for humans. The utilization of passwords brings a set of drawbacks and vulner-abilities associated to: user’s psychological factors, problems while entering passwords, pass-word design and generation, and passpass-word management. In the following paragraphs, these drawbacks are discussed.
to user’s psychology. Users can supply their passwords to a third party on purpose, ac-cidentally or by deception. Users usually share their passwords with other people they trust. This compromises any authentication system by granting access to users that are eventually unknown. An unconscious way of giving a password to an undesired entity is by being victimof Phishing, also known as social engineering [4]. Phishingis the act of extracting secret information from an authentic user by telling a plausible untruth, for example, a user replying his credentials to a malicious sender who pretends to be a system administrator.
• Problems while entering passwords - Another issue that has to be considered is the difficulty that users may experience while entering passwords that are too long or too complex. In those cases, authentication could be a confusing and error prone process creating many unnecessary requests to be treated by the authentication server. In critic systems, where some operations that require authentication must be urgently executed, this issue can bring safety implications.
• Password design and generation- Password design must be aware of the fact that user’s memorizing capacities are limited. It is hard to remember long and strong passwords and this is one of the main reasons for user’s complaints [38], [57]. Organizations where strict policies are adopted ensuring that each password must respect an extensive and rigorous list of rules, see their users either choosing “simple to guess” passwords or writing them down making them easy to steal. On the other hand, passwords with predefined creation rules are more difficult to memorize. With the widespread of systems that require au-thentication, users have to manage a large number of passwords, which tempts the user to define the same password for different systems. This can lead to vulnerabilities in all systems at the same time if the password becomes compromised. At the same time, this practice exposes passwords in different systems and also causes a lack on user’s privacy control when private information is maintained by those different systems.
last, even the login interfaces should be authenticated in some sort of way that a user knows he is dealing with the right system.
Other kinds of issues refer to how the password repository must be protected. Password files must only store one-way representations of the passwords - such as message digests - instead of maintaining them in clear. Otherwise an attacker that has access to the file-system would have instant access to all user accounts. In fact even if the password file has the passwords protected by a one-way-function, a dictionary attack [47] could be executed by generating random pass-words and comparing its one-way representations with the ones present on the password file. Therefore, password files must be somehow protected, for instance by using cryptography or cryptographic tamper-proof devices or modules.
2.1.2 Token based systems
A security token is an electronically represented set of claims about an entity that should be presented when certain types of authentication are requested. Representingsomething the user hasauthentication factor, they do not force users to memorize any secret information. Instead, this information is stored or processed by software or hardware. Both variations are presented below.
2.1.2.1 Hardware security tokens
Figure 2.1 Hardware security tokens
are the deployment costs, since tokens have to be distributed among all users. On other hand, their usage implies that users have to carry an extra object, which is suitable for being stolen or being lost. Finally, fully disconnected tokens are limited by the batteries life time. The usage of Smart cards is also solution that consumes less energy however it leads to poorer processing capacities and security limitations due to the weaker structure of paper/plastic based cards [4].
2.1.2.2 Software security tokens
- since users don’t need to memorize any information - and the fact that they don’t need inde-pendent batteries - as they are inherent to the system holding them. Despite that, authentication systems using software tokens have to deal with the common storage vulnerabilities that pass-words do. On the other hand, these tokens are more exposed to virus and other kind of software attacks, which makes them a weaker solution comparing with hardware tokens.
2.1.3 Multi-modal authentication with biometrics
Biometrics can be used as an authentication factor. They can identify and authenticate users given their physiological and behavioral traits. Traditional systems rely on the evidence of fingertips, hand geometry, iris, retina, face, hand veins, facial thermogram, signature, voice [17] and recently EEG pattern recognition [25]. Combined with classic factors they can be used to build stronger authentication mechanisms, however, they are not an efficient solution when used as part of unifactor authentication. The following paragraphs will tackle the main issues concerning authentication trough biometry.
Biometrics overcomes most of the problems noticed on systems based on the first two fac-tors due to their intrinsic nature. Users do not have to remember any passwords. A brute force attack to the feature space is more difficult to perform than in a password based system. That is because it is easier to generate valid passwords than to create or capture biometric samples. On the other hand, it’s always possible to increase security by extracting more information from users’ traits. The same is not applicable to passwords where making them more complex makes them harder to remember. Finally, users do not have to carry any object as they are forced by token based authentication systems. Other great advantage over the two first factors is that biometry is one of the few available techniques that can be used to prove negative recognition. Negative recognition is the ability of ensuring that one person only uses one identity that is not shared with anyone [18].
2.1.3.1 Biometric authentication system architecture
H= high, M=medium, L=low
Figure 2.2 Biometric traits comparison
Finally the decision module uses the obtained score to accept or reject the user as authentic. Thus, it’s necessary that biometric systems decide when to accept an user as authentic given the extracted features. For scores that are higher than a specific threshold, authentication is accepted.
2.1.3.2 Issues concerning authentication trough biometrics
Each of the mentioned biometrics has to deal with a set of concerns, which are noise in sensed data, intra-class variations, performance, acceptability, distinctiveness, non universality, collectability, permanence and circumvention [18].
• Noisy data- Noise in sensed data can be noticed when a fingerprint image with a scar is
collected, when the user’s voice is altered due to a cold or finally when the place where the sensor acquire data is poorly illuminated.
• Intra-class variation - By intra-class variation are understood the cases when by some
reason there is the need of comparing features extracted by sensors that have the same purpose but achieve it using different techniques.
• Performance - Performance is related to the set of issues related to trait extraction and
factors.
• Privacy and acceptability- Due to intrinsic nature relation between users and their
bio-metric traits, authentication data can be logged and used to gather personal information that users don’t want to share. Acceptability defines whether users are comfortable using biometrics. Some of them need physical contact, a fact that raises hygienic questions. On the other hand the lesser collaboration is required, easier will be to forge authentication.
• Distinctiveness- It is the capacity that one trait has to identify uniquely one person. For
two of the most commonly used representations of hand geometry and face the total recognized patterns that can be mapped on user identification are respectively 105and 103 [14].This can be critical on a system with many users.
• Universality and collectability -Is the likeliness that a specific trait has of being extracted
with the necessary quality from a single user, while collectability measures the effort needed to extract it. For example, quality fingertip features cannot be always extracted, the reason is that some people have low quality skin ridges.
• Permanence- Permanence is known as the likeliness of a certain trait still can be extracted
regardless the users age. A user may loose access to a certain system if the biometric trait that is being evaluated disappears while he becomes older. On other hand, once a user sees one of its traits compromised, it cannot be used anymore.
• Circumvention - Finally, circumvention is one of the most important issues related to
biometrics. If somehow user’s traits are reproduced by an attacker, it can be used to fool the authentication system through spoofing attacks.
Figure 2.2 [18], shows some biometric systems and their level of resistance to the issues pre-sented on the last paragraphs.
Due to the issues mentioned above, the biometric authentication process is limited by the quality of the extractions and by the variability of its accuracy. Establishing the authentication threshold is a trade-off. By setting a lower value, the likeliness of accepting false users as authentic is bigger, on the other hand by increasing the threshold, some users that are actually authentic may fail to enroll to the system. The first case is measured by aFalse Matching Rate
Figure 2.3 Relation betweenFNMRandFMR
related concerned with the previous discussed trade-off between False Rejection Rate (FRR) and False Accepting Rate (FAR) for each factor in current biometric technology. The optimization of this balance is specific to each biometric factor. On the other hand, the optimization of this trade-off for fine grained accuracy systems imply on very expensive devices that are not possible to adopt in widespread ubiquitous applications, Figure 2.3 [18]shows how FNMR and FMR are correlated.
2.1.3.3 Multi-modal biometric authentication systems
Most of the existent biometric systems are unimodal [19] thus suffering from the disadvan-tages introduced above. One technique to reduce the disadvandisadvan-tages while maintaining to some extent the advantages is by combining biometric extractions from different traits. Doing this makes the system more accurate since the likelihood of two trait extractions lead to a False
Non-Matching or False Matchingauthentication is smaller. Universality, intra-class variation
to authenticate himself through a challenge-response based approach. It would be harder to an attacker to spoof many traits at the same time. The design issues to take in consideration during the conception of multi-modal biometric systems are the choice and number of traits to extract, the methodology adopted to extract them, the level of trait integration and the cost-performance trade-off. Traits to be available are a decision that is application driven, since it depends on the available sensors and the application requirements. For instance, it is plausible to build a multi-modal biometric system with voice, fingertip and face recognition to be used on a last generation Smart Phone.
Although the accuracy is improved, multi-modal biometric systems are even more expen-sive solutions as they have to combine many sensors.
2.2
Authentication factors for ubiquitous environments
Ubiquitous computing is concerned with the integration of processing capacity on objects that people daily use. The vision that Mark Weiser had in 1991 [53] was ahead from his time, however nowadays it is already available the required technology for building a word like the one he has predicted. Wireless LANs, cell phones, Smart Phones and PDAs are already widespread among nowadays society.
As referred before, ubiquity brings challenges and opportunities to authentication systems. Classic mechanisms aren’t sufficient anymore as they can’t deal with context variations imposed by users mobility. The following paragraphs illustrate alternative authentication factors that are suited for context-aware authentication.
2.2.1 Something the user sees
In [27] the authors propose the utilization of the cameras existent on mobile phones as a new visual channel to achieve demonstrative identification of communicating devices formerly unattainable in an intuitive way. on
With Seeing-is-Believing (SiB) protocol, bidirectional Authentication can be accomplished by the following procedure based on data matrices used as two dimensional bar codes.
Figure 2.4 Mobile phones performing SiB protocol
• when user A wants to communicate with user B he takes a picture from B’s data matrix;
• then user B makes the same from A’s data matrix.
• based on the obtained pictures, both users know each others public key and therefore they can build a secure channel trough Bluetooth or WI-FI.
An example of two devices performing SiB protocol is illustrated on figure 2.4 [27].
Unidirectional authentication can also be accomplished between a cell phone and a display-less device with a sticker containing the bar code. Users wanting to communicate with the displayless device start by taking a picture from the sticker, then a secure channel is negotiated trough the wireless channel.
Besides the security of the underlying cryptographic primitives, the security of SiB is based on the assumption that an attacker is unable to perform an active attack on the visual channel, and is unable to compromise the mobile device itself.
2.2.2 Something the user makes
which doesn’t force the principals to share any initial information.
Imagine two devices, AandB, trying to communicate with each other. The candidate key protocol describes a key generation method to be used on a secure channel:
• assuming thatAandBshare the same environment, they use the same sensors to collect data streams;
• the digests of the features extracted from the streams, called candidate parts, are ex-changed and then compared, in order to select only those which are in common to both devices.
• Akey is generated from the concatenation of common parts and then their digest is ex-changed to confirm that they are equal. Man-in-the-middle attacks are then mitigated if a third device, say itE, tries to guess the generated key, considering that it doesn’t have access to the context shared betweenAandB.
As demonstration, the author materialized the idea of sharing contexts by making two devices shaking together. The data collected by their accelerometers was then used to generate the se-cret key. Ewould not be able to generate the same key because it would have to make exactly the same movements at the same time that A and B do. The experiments made on this type of attack shown that imitate the exactly movements is almost impossible even when there is cooperation between the attacker and the victim [26]. The security of the algorithm is based on the entropy achieved trough the process of data collection and feature extraction.
2.2.3 Somewhere the user is
Accuracy Usability Assurance TCO Performance Pervasive usage Applicable domains Passwords, PINS + ++ - - ++ ++ + ++ Security Tokens + - - + - - - ++
Biometry - - ++ ++ - - -
-Location - ++ - - ~ - -
-Ubiquitous technology
~ ++ - + ~ ++ ++
++ very good behavior / ~ neutral / - - very bad behavior
Table 2.1 Comparison between authentication factors
All the work made about mobile and pervasive computing brought many improvements on location sensing techniques. They can be divided in three categories, triangulation, scene analysis and proximity [6].
In [11], signed geodetic information is used in combination with the classic factors to asso-ciate a request to a physic place, then preventing an attacker of being untraceable and constrain-ing the access to some places in the globe. For that purpose any user would have to possess a transceiver in order to obtain his signed position.
2.3
Multi-factor and multi-modal authentication
The last section have provided a detailed description for the authentication factors typically used nowadays. We can easily conclude that the utilization of any of those factors introduce dis-advantages, which can be more or less critical considering multiple criterions. Table 2.1 makes the comparison between the authentication factors discussed throughout the current section in terms of the following criterions:
• Accuracy - Relation between false positives and false negatives assured by the
authenti-cation factor.
• Usability- Commodity felt by user during the authentication process.
• Assurance - Confidence and level of assurance granted by the authentication factor.
• TCO -Total cost of ownership and maintenance.
• Performance- Time consumed by the authentication process as well as resource
manage-ment.
• Pervasive usage- applicability to ubiquitous environments.
• Applicable domains - Possible situations where the authentication factor can be used as
valid proof category.
Composing authentication factors and modes is one solution for achieving higher assurance levels. Combining multiple authentication modes enables to benefit from the advantages of all involved factors while hiding their individual drawbacks. On the other hand, and similarly to what happens in multi-modal biometric authentication, supplying multiple authentication alternatives for the same operations allows to establish richer interaction models considering security and convenience.
2.4
Single sign-on mechanisms and protocols
• Each application manages authentication and authorization issues independently from the others using their own directories. The study presented [52] on shows that the in average, the Fortune 1000 top American companies manage more than 150 directories. Each application requires its own authentication proofs, typically based on shared secrets, therefore forcing users to memorize multiple passwords. On section 2.1 the disadvantages of forcing users to keep multiple passwords were already discussed.
• If the attributes of an user changes that must be replicated on all systems, which is a con-siderable burden to system administrators. The operation costs are high. It’s estimated that a great portion of help desk calls are related to password recovery and other authen-tication issues [52]. The same is applied to the extension to new authenauthen-tication modules based on different factors. All directories must be synchronized and the applications re-adapted.
• The notion of roles cannot be applied globally to the organization, since the identities for the same subject are different and widespread among the multiple directories.
Single sign-on systems address these limitations acting as a middleware service reused by dif-ferent applications, providing centralized management and authentication data access. Appli-cations rely on the platform to retrieve user credentials, which are submitted only once for each session, in order to perform context-aware multi-factor and multi-modal authentication. Fig-ure 2.5 shows the comparison between an organization using traditional logon procedFig-ures and other using SSO. This method allows to centrally monitoring all authentication processes and data repositories reducing the number of different passwords. Users only authenticate once and the credentials are reused by all applications. Operation costs are decreased since changes, configurations and fixes are made at only one point.
Figure 2.5 Single sign-on middleware architecture
a unique interface relying on well established standards.
Java Authentication and Authorization API [24] is an example of a strong extension mecha-nism for the inclusion of multiple authentication methods. Security Assertion Markup Language [2] and OpenID [41] are examples of interoperability standards for single sign-on authentica-tion.
Among all single sign-on solutions, OpenSSO[32] and Enterprise Single Sign-On [36] were chosen as fully integrated and tested platform and Kerberos V5[22] as a SSO compliant proto-col.
These systems were chosen due to their openness. Therefore it is possible and easier to integrate them on the authentication middleware framework devised by the current dissertation.
2.4.1 Java authentication and authorization API
Figure 2.6 JAAS architecture
and user-roles which are defined either by programing or through the setting of rules on a spe-cific file following the recommendations of Enterprise Java Beans Spespe-cification (EJB) [15]. Although these mechanisms allow the development of specific authentication modules to java applications, they are not able to integrate existent authentication systems, which don’t have access to Java’s security layer, neither support easily reconfiguration of the mechanisms used in the authentication processes. This led Sun to design Java Authentication and Authorization API (JAAS). It is an interface that provides authentication and assigns privileges to users in an abstract way so that the applications are unaware of what authentication mechanisms are being used.
Authentication is a two phase process, first all the Login Modules are called and only if all of them succeed the authentication credentials are returned to the applications.
JAAS is then a good solution for integrating different authentication providers in Java sys-tems. Extensibility is achieved by simply changing a configuration file, without the awareness of the top applications.
2.4.2 SAML
Security Assertion Markup Language (SAML) [2] is an emergent standard specification de-veloped by the OASIS Security Services Technical Committee. It is currently on version 2.0 and it defines a set of protocols, bindings and profiles for single sign-on authentication using XML based assertions. An assertion is a message that contains statements about subjects and other information that may be used by applications in order to recognize them as authentic.Assertions can be categorized as the following three types:
• Authentication assertions - which carry user credentials and information that concerns
whether the user was successfully authenticated or not by a identification provider.
• Attribute assertions- which contain information about an entity that is used in the
autho-rization decision process.
• Authorization assertions- which contain basic information about users permission to
ac-cess specified resources.
1.S→SP : S
2.SP→S : AuthReq(ID,S,SP),IdP
3.S→IdP: AuthReq(ID,S,SP)
4.IdP→S: [AuthenticationAssert(ID,S,SP)]Kid p 5.S→SP : [AuthenticationAssert(ID,S,SP,IdP)]Kid p
R: resource identifier
LOA: level of assurance identifier C: Context info
AM: authentication modes AD: authentication proofs V: validity period,
[...]Kid p: message signed by the identity provider principal
Figure 2.7 SAML protocol
First versions of SAML did not have support for information sharing between organizations, in such a way that SSO could be spanned to more than one authentication realm. Liberty Al-liance proposed a federation based framework, named Liberty Identification Federation Frame-work (ID-FF) [3], as a standard reference for communication between authentication domains. It is a super-set of the early versions of SAML and describes a circle of trust where the orga-nizations plug their service and identification providers. Each organization it is responsible for managing their access control data as described on the standard. This issue was overcome by the version 2.0, which brings integrated support for federation relying on ID-FF.
Despite being a standard protocol that improves single sign-on and interoperability between organizations, SAML does not consider the description of dynamic mappings between muta-ble authentication contexts and multi-factor as well as associated multi-modal authentication credentials and proofs.
2.4.3 OpenID
Figure 2.8 OpenID interaction model.
can be inconvenient for users, since there is no guaranty that the identification they normally use is not already taken. On the other hand, multiple authentication systems mean multiple login processes. Security issues are related to the way websites manage users and passwords, some can do it more securely than others. Assuming the fact that sometimes users take the same passwords to different services, if an user does it at a website that has poor or malicious credentials management, he will compromise all his accounts on the other websites.
Open ID relies on global identifiers which may be an URL or an Extensible Resource Identi-fier (XRI ), a specification defining the structure and protocol for abstract identiIdenti-fiers [34]. Users, also known as end-users, may obtain identifiers from two different ways, giving the address of their own blog website or after enrollment process on a XRI compliant identity provider. In the first case, the web server hosting the blog provides a dedicated identity provider. Let’s consider a subjectS, a relying partyRP (service provider) and an identification provider denoted asIdP.
and if it is correct the provider returns the secret shared with the relying party as an authentica-tion credential. Finally the user-agent forwards the secret to the relying party which compares the generated secret with the one given by the user who now can decide whether to authorize him or not. Figure 2.8 [19] demonstrates the interaction model mentioned above.
OpenID is focused on Web authentication, namely for blog users. Despite of being a platform authentication standard, it is not suited for the representation of context-aware multi-factor and multi-modal abstractions.
2.4.4 OpenSSO
OpenSSO [32] is an open source single sign-on framework developed by Sun Microsystems. It can be used as a support system for web servers and other kind of systems that share multiple resources and therefore need centralized authentication and access control mechanisms.
As it can be seen on Figure 2.9 [32], OpenSSO provides authentication, authorization, ses-sion management, federation, and logging as base services. Its architecture is divided in six layers, but its functionality is distributed by three tiers, the client side, the core services and the plug-in modules or data integration. The client side is composed by policy agents. These com-ponents are located near to the shared resources, every time a subject requests a resource, agents intercept it. If the agent hasn’t cached any credential for that subject it prompts the subject to login.
The core services integrate the main functionality of the system. Each service is made avail-able to the client side trough web services. Policy agents access those services using Open SSO Client SDK, an API relying on OpenSSO web services. Internally, Authentication and Autho-rization services interact with specific components, which in conjunction with the OpenSSO framework core decide when to grant access to a specified object.
Single sign-on is managed by the Session component, which maintains information about authenticated sessions. The policy agents get the users session state through this service, this way users only need to authenticate once.
Figure 2.9 OpenSSO architecture
Finally the plug-in modules are systems external to the OpenSSO framework that provide user data, policies, configuration information and autonomous authentication systems. This way, authentication can be delegated to external systems using Service Program Interfaces (SPI) which are made available through a JAAS back-end.
2.4.5 Enterprise sign-on engine
Enterprise sign-on engine (ESOE) [36] is an open source authentication technology for ac-cess and data transfer management. It is currently developed by Queensland University of Technology and its main concerns are supporting user authentication at the web tier, federa-tion with business partners, applicafedera-tion single sign-on, multi-factor authenticafedera-tion, identity data transfer to applications in real time, access control policies enforcement, services management and platform extensibility. ESOE relies on open standards such as SAML 2.0 for secure data transfer and XACML [33] for standard and fine grained policy definition.
Figure 2.10 ESOE architecture
to special components, which interact directly with the protected resources. These elements are called Service Policy Enforcer Points (SPEPs) and they perform authentication requests to the ESOE, as well as they perform caching and policy enforcement. Since all SPEPs are connected to the same ESOE system, authentication is centrally managed. The components of the architecture are shown on Figure 2.10 [36].
ESOE supports off-the-shelf module connection in order to plug in custom data repositories. Multiple identity resolution sources can be combined and presented to core modules which use them in a transparent way. Federation is limited to the integration with systems that use OpenID and SAML. However ESOE permits the integration of custom modules that deal with different external authentication systems.
ESOE suffers from the same limitations that OpenSSO does. It is most suited for web authentication and doesn’t provide mechanisms for dynamic combination of authentication fac-tors. On the other hand, it does not have native support for the integration of ubiquitous systems and devices with specific requirements and interaction models.
2.4.6 Kerberos and the PKINIT approach
Kerberos [22] is an authentication protocol developed at the Massachusetts Institute of Tech-nology (MIT). It is now on its 5th version and it was created in order to address the common authentication problems on a organization with many protected resources. To some extent, Ker-beros can be seen as single sign-on system, since authentication services are centrally managed.
specification defines two main components, the authentication server (AS) and the ticket grant-ing server (TGS). The authentication server is responsible for users initial authentication. The ticket granting server supplies credentials for specific service providers. Separating the authen-tication in two steps allows users to login only once on the authenauthen-tication server. The access to different services is made using different credentials created on demand.
In the first step of the protocol both the clientCand theASgenerate the same cryptographic key. The authentication server uses that key to encrypt a message containing a new key for communication between theclient and the TGS. Then the client securely communicates with the TGS retrieving a third key, for communication with the service providerV. Finally bothC
andV negotiate a session key. The authentication protocol runs as follows: 1.C→AS : Options||IDc||Realmc||IDtgs||Times||Nonce1||
2.AS→C : Realmc||IDc||Tickettgs||{IDtgs||T S2||Tickettgs}Kgc
Tickettgs={Flags||Kc,tgs||Realmc||IDc||ADc||Times}Ktgs
3.C→T GS:Options||IDv||Times||Nonce2||Tickettgs||Authenticatorc
Authenticatorc={IDc||ADc||T S1}Kc,tgs
4.T GS→C: Realmc||IDc||Ticketv||{Kc,v||Nonce2||Realmv||IDv}
Ticketv={Flags||Kc,v||Realmc||IDc||ADc||Times}Kc,tgs
5.C→V : Options||Ticketv||Authenticatorc
Authenticatorc={IDc||Realmc||T S2||Subkey||Seq#}Kc,v 6.V →C : {T S2||Subkey||Seq#}Kc,v
high costs of ownership, which may not be reasonable for all situations where authentication is required.
2.5
Summary and contributions
2.5.1 Overview
In this section, multiple authentication issues were presented. It was shown that each of the three classic authentication factors has its own drawbacks. Systems based on shared secrets are vulnerable due to password misusage by humans, who make them easy to guess and share them with third parties either voluntarily or by social engineering. The utilization of security tokens may not be convenient for users, as they are forced to carry an extra object that can be easily lost, stolen or reproduced. Biometrics seam to overcome the problems mentioned above due to the fact that human traits are difficult to steal and don’t force users to memorize any information. However their considerableFalse MatchandFalse Non-Matchrates allied to their intrusive nature, makes biometrics inefficient and poorly accepted. Other factors such as
somewhere the user is, something the user makes orsomething the user seescan be used, but
they are very application specific and typically can’t be used by themselves.
Considering the above drawbacks, a possible solution is to combine authentication factors in a multi-factor and multi-modal way, so that it is possible to take benefit from all the advan-tages of each factor while its flaws are overcame by the remaining factors. With this approach, authentication processes are more reliable and higher levels of assurance can be achieved. At the same time, this approach can introduce a high degree of flexibility for authentication man-agement according to different systems needs, providing a more appropriate environment to manage different authentication policies for ubiquitous and pervasive systems and applications.
JAAS. Finally, integration with applications, storage bases and other authentication platforms is improved due to the usage of standard protocols like SAML and OpenID. On the other hand, users don’t have to memorize multiple authentication information for each application. They can log-on once and their credentials are accepted by all applications.
Despite of being a complete and integrated solution for most of the actual scenarios, single sign-on systems and protocols as we know today are limited when dealing with multi-modal and multi-factor authentication. Typically, these kind of systems adopt aone size fits allphilosophy, where the same factors, or combination of factors are used to user authentication regardless the context of the authentication request. SSO systems allow defining static authentication process involving the validation of multiple factors and modes, however they are not flexible to adapt to different context criteria such as device type, location, period of the day, used network and protocols or users and device capabilities.
Considering the new opportunities brought by ubiquitous computation, it is possible to iden-tify a gap that it is not addressed yet. The dynamic adaptation of authentication processes to different context conditions is not addressed by the systems and protocols that are available today. This dissertation has the objective of designing and developing a context-aware multi-factor and multi-modal authentication framework, acting as a middleware platform between single sign-on systems and multi-type and multi-device applications.
2.5.2 Context based authentication and multi-factor authentication
According to the previous considerations, the approach of context based multi-factor authen-tication seems to be an interesting direction that can be implemented in universal authenauthen-tication platforms.
mobile phone, in a period of the day that is not typical. Probably it was made by the correct user, however the authentication context is different. The required assurance level doesn’t change, since the operation is the same, however the necessary proofs to attain the same assurance level must be different. This scenario can be assumed as more suspicious, then a larger combination of factors must be requested.
2.5.3 Contribution
This dissertation presents an integrated authentication framework entitled Context-Aware Multi-factor Multi-modal authentication framework (CAM2). The authentication platform de-vised by the proposed framework is sufficiently generic to integrate any kind of application that needs authentication services, supporting classic as well as new and emergent authentication modes. For the interaction with the platform using
Considering multiple types of devices, contexts and authentication modes, it is necessary to express uniform context-aware multi-factor authentication protocols and new interaction mod-els. For this purpose, CAM2 specifies a markup language (CAM2ML) supporting SAML ab-stractions. CAM2ML define the structure of authentication policies describing authentication processes given different authentication contexts.
This dissertation presents the architecture and the implementation of a context-aware multi-factor and multi-modal authentication platform, as a middleware extending the functionalities of underlying authentication systems and protocols such as the ones presented on this chapter. The main contribution is focused on leveraging a base SSO system to provide context-aware multi-factor authentication abstractions and services. This can be achieved by an extensible middleware layer approach that uses SSO base services to provide those abstractions.
3.1
Scope and requirements
This chapter proposes and presents a context aware multi–factor authentication framework (CAM2) that introduces new interaction models and single sign-on authentication architectures. The issues mentioned above are addressed by developing a middleware that extends the func-tionality of the current single sign-on solutions. It introduces dynamic authentication processes that adapt the number and type of required proofs to authentication contexts. The design of this framework is focused on the following requirements:
• Multi-factor and multi-modal authentication- The framework must provide mechanisms
for the implementation of multi-factor and multi-modal authentication, improving the assurance level on authentication processes.
• Dynamic and context-aware proof requirement- The framework must consider the
detec-tion and evaluadetec-tion of context states, relying on that informadetec-tion for choosing the appro-priate combination of authentication modes.
• Extensibility for new authentication models - The framework must provide extension
mechanisms that allow the inclusion of new authentication modes, without having to change the authentication platform. The modes to be supported must represent the classic factors as well as the ubiquitous and emergent ones.
• Generic usage - The framework must be usable by multiple types of base single
sign-on systems. It must be used by multiple types of applicatisign-ons using different interactisign-on models and identities.
• Acceptable performance- The logic added by the new services must have low impact on
the latency of the authentication processes, when compared with the existent solutions.
3.2
Core concepts
With the aim of implementing context aware multi-factor authentication processes, we have to consider three key concepts: contexts, assurance levels and authentication policies.
