eperspace wp 8 requirementswiki.unik.no/media/m2005homeinfoaccess/eps_del53_final_r... · web...

IST Project N° 506775 02/12/2005

ePerSpace – IST Integrated Project

EPS_D5.3_Telenor_R1 Confidential of 115

Document Title Security enabling ePerSpace services, implementation issues of a seamless login

Date 02/12/2005

Reference EPS_D5.3_Telenor_R1

Author Alf Sollund (editor), Remi Bars, Diane Cheng, Eric Delacour, Yonathathan Zetuny, Pierre Plaza, Celine Borsier, Josef Noll, Gaute Nygreen, Juan Carlso Lopez Calvet, Javier Carbonell, Tor Hjalmar Johannssen, Christos Xenakis, Miguel Casado Pinna, Jeff Foley

Abstract Report of security architecture enabling ePerSpace services, implementation issues of a seamless login.

Confidentiality Restricted

Target audience Project partners, EC

Comment

IST Project N° 506775 02/12/2005

Disclaimer

This document contains material, which is the copyright of certain ePerSpace consortium partners and may not be reproduced or copied without permission. The information contained in this document is the proprietary confidential information of certain ePerSpace consortium partners and may not be disclosed except in accordance with Section IV of Part II of the consortium agreement. The commercial use of any information contained in this document may require a licence from the proprietor of that information.

Neither the ePerSpace consortium as a whole, nor any partners of the ePerSpace consortium warrant that the information contained in this document is capable of use, or that use of the information is free from risk, and accept no liability for loss or damage suffered by any person using the information.


IST Project N° 506775 02/12/2005

Table of Content

1 EXECUTIVE SUMMARY................................................................................................................. 5

2 INTRODUCTION AND SCOPE.......................................................................................................7

2.1 OVERVIEW.................................................................................................................................. 7

2.2 DOCUMENT STRUCTURE...............................................................................................................7

3 GLOBAL SECURITY REQUIREMENTS.........................................................................................8

3.1 THREAT ANALYSIS....................................................................................................................... 83.1.1 Scenario 1: A day in the van Epers family........................................................................................83.1.2 Scenario 2: A day in the life of a businessman.................................................................................93.1.3 Scenario 3: At home......................................................................................................................103.1.4 Scenario 4: Hospital stay...............................................................................................................103.1.5 Scenario 5: Children in the weekend..............................................................................................12

3.2 GLOBAL SECURITY REQUIREMENTS SUMMARY...............................................................................12

3.3 EVALUATION AGAINST ISO17799 SECURITY STANDARD AND TOOLSETS..........................................14

3.4 EPERSPACE SECURITY POLICIES.................................................................................................163.4.1 Global Security Requirements........................................................................................................16

4 EPERSPACE SECURITY..............................................................................................................18

4.1 AUTHENTICATION MECHANISMS...................................................................................................184.1.1 The ePerSpace context.................................................................................................................184.1.2 Username, password service access.............................................................................................184.1.3 Smart Card and PKI based............................................................................................................194.1.4 Biometric authentication.................................................................................................................25

4.2 END TO END AUTHENTICATION....................................................................................................254.2.1 Single Sign on (SSO).....................................................................................................................26

4.3 FEDERATION OF IDENTITY THROUGH LIBERTY ALLIANCE................................................................284.3.1 Liberty Alliance Main roles.............................................................................................................294.3.2 Liberty standard subsets and main concepts..................................................................................304.3.3 ID-FF/SAML for Liberty SSO..........................................................................................................334.3.4 Liberty alliance applicability to ePerSpace architecture...................................................................344.3.5 Other initiatives related to Identity management.............................................................................37

4.4 COMMUNICATION SECURITY INSIDE HOME AREA NETWORK............................................................424.4.1 IEEE 802.11.................................................................................................................................. 424.4.2 Bluetooth....................................................................................................................................... 424.4.3 Security requirements and risks.....................................................................................................424.4.4 Security in IEEE 802.11.................................................................................................................444.4.5 Standard-based solutions (IEEE 802.1x, IEEE802.11i)...................................................................464.4.6 WPA............................................................................................................................................. 464.4.7 IEEE 802.1x..................................................................................................................................464.4.8 RFID............................................................................................................................................. 494.4.9 RFID from the mobile phone through NFC.....................................................................................54


IST Project N° 506775 02/12/2005

4.5 COMMUNICATION SECURITY IN WAN...........................................................................................574.5.1 Technical assumptions..................................................................................................................574.5.2 Security over HTTP-based communications...................................................................................58

4.10 PERSONAL PROFILE SECURITY....................................................................................................604.5.3 Access control from end user point of view....................................................................................604.5.4 Access control mechanisms for accessing parts of personal profile................................................614.10.1 Data protection.............................................................................................................................. 62

5 AUTHENTICATION IMPLEMENTATIONS IN EPERSPACE.........................................................64

5.1 GLOBAL AUTHENTICATION & AUTHORIZATION SERVICES UTILIZING THE GSEM.................................64

5.2 LOCAL AUTHENTICATION (RG BASED).........................................................................................655.2.1 Local Authentication Scenarios (RG Based)...................................................................................665.2.2 Local Authentication Requirements................................................................................................665.2.3 Local Authentication Manager High Level Specification..................................................................695.2.4 Authentication Means Descriptions................................................................................................715.2.5 Local Authentication with SIM card................................................................................................76

5.3 ELSEWHERE AUTHENTICATION....................................................................................................775.3.1 Functional description....................................................................................................................775.3.2 Main modules description..............................................................................................................785.3.3 Sequence diagram........................................................................................................................ 795.3.4 Manual Authentication...................................................................................................................79

5.4 EVALUATION OF IMPLEMENTATIONS.............................................................................................805.4.1 Introduction................................................................................................................................... 805.4.2 Authentication Criteria...................................................................................................................805.4.3 User Authentication criteria............................................................................................................825.4.4 Level of security............................................................................................................................ 845.4.5 Standards...................................................................................................................................... 845.4.6 Evaluation conclusion....................................................................................................................86

6 OPEN ITEMS FOR FUTURE EPERSPACE WORK......................................................................87

7 CONCLUSION.............................................................................................................................. 89

8 REFERENCES.............................................................................................................................. 92

9 ANNEX.......................................................................................................................................... 93

9.1 WIRELESS SECURITY................................................................................................................. 939.1.1 GPRS............................................................................................................................................ 939.1.2 UMTS............................................................................................................................................ 95

9.2 AAA ARCHITECTURE................................................................................................................102

9.3 EAP AUTHENTICATION TYPES..................................................................................................105

9.4 BLUETOOTH SECURITY.............................................................................................................1089.4.1 Key Management........................................................................................................................ 1089.4.2 Encryption................................................................................................................................... 1109.4.3 Authentication.............................................................................................................................. 111


IST Project N° 506775 02/12/2005

1 Executive Summary

This deliverable is a part of WP5; Personalisation and Security, and aims to serve as a recommendation for security considerations and mechanisms. WP5 is responsible for defining the key mechanisms for a personalized and seamless login, supported by appropriate security architecture, enabling a seamless service and content adaptation to the different user devices according to the personal preferences and context of a user captured in various parts of personal profile.

This deliverable is a continuation of the results documented in D5.1, where an overview of the state of the art has been done with regard to personalization in different sectors of the industry such as telecom global network and home and audiovisual.

The focus is on high-level security considerations, wireless security and authentication implementations.

Threat analysis and global Security requirementsIn order to generate global security requirements a threat analysis is performed to identify the threats that may result in damage for the user or for the service provider, in each of the service scenarios. Based on the scenario analysis, the global security requirements are identified and classified in critical and medium. The global security requirements also dictate the global security policies.

Furthermore an evaluation against ISO17799 main sections is performed. The ISO17799 security standard applies to all aspects of the ePerSpace framework relating to security, so all ePerSpace services should be compliant with this extensive European security standard.

ePerSpace security – Authentication mechanismsAuthentication is of highest importance to achieve ePerSpace access and services. The end user authentication mechanisms used for exchange of user credentials are Form based (http, username / password), Smartcard, SIM-based and Biometric authentication.

Our preliminary assumption on authentication is that users want to see a seamless authentication in their homes. The indication from our work is that either biometrics (voice, finger print) or seamless access mechanisms (SIM card, NFC) should be used to provide authentication to services in and from the home.

ePerSpace security – end-to-end authenticationIn order to create adaptive and multilevel security, some key building architecture blocks must be in place, e.g. Single Sign On (SSO) and support through authentication by different means. The objective of SSO is to allow users access to all applications from one logon.

Assuming that an authentication has taken place, a trusted identity provider must provide a ”distribution of identity” in order to realise SSO. The main candidate is the de facto standard Liberty Alliance Identity Federation Framework (ID-FF), with main focus on the provision of ID distribution, through the distribution of a “federated key”, originated from an ID provider (IDP) and distributed to an ID requestor.

Liberty SSO aims to provide federated identity management of all network devices, but is designed to be independent of authentication mechanisms. ePerSpace on the other hand focuses on the authentication mechanisms, summing up to a complementary solution.

Although ePerSpace has studied the Liberty Alliance framework as a candidate for SSO/federation of identities, no implementations have been made due to difficulties to deploy a complete framework in a short time. However, ePerSpace has developed a service management platform to handle customers, providers and operators (Global Service Manager - GSeM) and to support service delivery (Global Service Provisioner - GSeP) that is compliant with the Liberty Alliance framework.

ePerSpace security – communication security in LAN/WANDue to the strong ePerSpace focus on home services security considerations for HAN access methods must be met, e.g. WiFi and Bluetooth.

Due to the strong ePerSpace focus on home services security considerations for HAN access methods must be met, e.g. WiFi and Bluetooth.


IST Project N° 506775 02/12/2005

Also there is a strong interest within ePerSpace in usage of RFID for automated identification. RFID (Radio Frequency Identification) is a means of storing and retrieving data through electromagnetic transmission to an RF compatible integrated circuit. RFid could be used in cooperation with NFC technology. For example, including RFID into the mobile phone gives contactless cards the advantage of being able to be installed, updated and cancelled over the air through the services offered by GSM.

As to WAN communication security, this can be divided in two main parts;

1) The communication between service providers, service and management platform and residential gateway based on SOAP over HTTP. Firewalls and proxies can be deployed to secure access to the content provider platforms and to the service management platform.

2) Home gateway and residential devices are connected through wireless communications (WiFi or Bluetooth), and mobile phones are used to access (through the cellular network) the services of the service and management platform and to connect (through the cellular network) or directly (wireless) to the home gateway and to the home appliances. For this wireless security ePerSpace must rely on the security mechanism in WiFi or Bluetooth, GSM/GPRS, UMTS and RFID.

ePerSpace security – Personal Profile SecurityCentral in the ePerSpace personalisation work are the Personal Profile with a taxonomy covering both semi-permanent information and links to contextual info, user’s interests, context information, identity information, etc. The ePerSpace user will assign specific access rights to each Service Provider (at the moment of a service subscription) following a Role Base access model; in other words the user will select a role for a SP. This information (mapping between roles and service providers) is stored at the Global Service Management (GSeM) level.

Each SP that wants to access/update the profile will contact the GSeM, which will forward the request to the Personalisation Platform (SPOE as an entry point) . The SPOE will contact the correspondent Personalization Engine, passing the service’s role and the userId as parameters. The Personalization engine will query/update the UserProfile, first checking (internally) the access rights for the calling role and returning appropriate results.

Authentication implementations: A proposal is made on a component handling multiple authentication methods (such as the Form-based, RFID, SIM-based and Fingerprint) integrated in order to support a global authentication. We have focused on the local authentication components needed in order to a provide local authentication means to the user that is accessing the local services, or wants to log into the Management system: The Terminal Manager (developed within WP8) will ask the Local Authentication Manager to authenticate the user through one of the authentication methods. The Local Authentication Manager will be in charge of registering the users that are allowed to access the Home Platform. To be able to handle the local authentication methods, drivers will be incorporated in the Middleware platform.

The following Authentication means will be supported through the local authentication manager: Doorkeeper (Biometric), Icode and NFC RFIDs, Smartcard linked to a PC and Mobile Phone SIM-card linked via Bluetooth to a PC. All these can be used in combination of Form-based (username / password).

Moreover, the GSeM contains a remote method (accessible as a Web service) for authenticating a security subject. This method is used by the RFID, SIM and Fingerprint authentication methods through local components in HAN, e.g. by sending the user’s credential (i.e. username and password) over the network into the authentication handling code at GSeM. The same manual authentication method (Form based HTTP-Auth) will be used in both HAN and elsewhere scenarios. The GSeM will declaratively assign http-auth headers requirements so both the terminal manager, and devices outside the home can be authenticated in the same manner.

For elsewhere authentication an implementation of service is described that can allow authentication towards the GSeM Web portal using a SIM card as for the authentication data storage mean (some authentication data for example a login/password), and then uses this data to connect automatically to a Web portal e.g. the GSeM portal. Also this allows to manage the portfolio of authentication data so as to delete or change any data stored in the SIM card.


IST Project N° 506775 02/12/2005

2 Introduction and scope

2.1 Overview

Deliverable D5.3 is the deliverable released by WP5 task T5.3 “Personalization & Security” and its main objective is to define a user-friendly adaptive security supporting the personalisation architecture.

Please also note that this deliverable is following D5.1, which contains review of key concepts, technologies and standards, and first release of D5.2, which outlines the Personalisation architecture.

Security in itself is an activity that applies across different ePerSpace activities. This deliverable will not cover all these detailed applied securities, but focus on defining a high level view of security, and evaluate the basis for an applied personalised service security, namely the identification and authentication. ePerSpace focuses on working towards a distributed global-local authentication solution, with a proposal on local authentication methods (HAN) implementations including a local authentication manager. In order to enable single-sign-on and service security, the federation of identity needs to be elaborated. This report gives an overview on how the identification management (“federation of identity”) can be achieved, but no implementations on the emerging de-facto standard by Liberty Alliance has been undertaken considering time and resources needed to deploy a complete framework.

2.2 Document structureThis deliverable is structured into the following main parts:

Chapter 3 Global Security requirements. Through threat analysis establishes high-level end-to-end security requirements (criteria’s) that can be used for evaluation in other parts of deliverable, establishes high level security policy and evaluates against SO17799 criterias.

In chapter 4 a broad overview and analysis of security are given. This encompasses, authentication methods, end-to-end security including SSO and federation of Identity, LAN/WAN communication security and finally personal profile security.

Chapter 5 “Authentication implementations in ePerSpace” proposes architecture for global-local authentication and shows how this is realised within the project, including an evaluation.

And finally the last two chapters provide an overview of open issues for further work, the main points contained in the deliverable and some recommendations towards the Project.


https://eperspace.rd.francetelecom.com/eperspace/Public/deliverables/wp5/d5.1_final_version/view

IST Project N° 506775 02/12/2005

3 Global Security requirements

The purpose of this chapter is to establish the high-level end-to-end security requirements (criteria’s) that can be used for evaluation in other parts of deliverable.

3.1 Threat analysisThis part documents the threats that may result in damage for the user or for the service provider, in each of the service scenarios as identified by WP1. The impact of possible damage is estimated and classified against three values "Low", "Medium" and "High" with the corresponding rationale for this valuation.

We will try to assign a maximum of "high" or "low" values to impacts in order to avoid a common tendency to classify most of impacts as "Medium".

3.1.1 Scenario 1: A day in the van Epers family.Scene 1: breakfast and preparation for the day ahead (personalized news).

Scene 2: in the car, on the way to work (acquiring relevant traffic information)

Scene 3: In the office, a small interruption from home (remote signature for a parcel with a required proof of receipt). In this scenario, the recipient's signature is seen as a graphic representation of her hand-written signature: actually, according to the European directive on electronic signature, an advanced electronic signature on some data bound to the identification of the parcel, using a qualified certificate, should have the same legal recognition.

Scene 4: Lunch break at the office (looking for travel information)

Scene 5: New interruption from home (children back from school, remote babysitting)

Scene 6: Evening relaxation (downloading a video from a personal database somewhere in the network)

Threats Impact Security measures to mitigate risks

Scene 1: -Malicious modification of the personalization data

Low (unpleasant but not harmful)

Integrity of the personalization dataAccess control for modification of personalization data

Scene 2: -Malicious modification of the location data-Malicious modification of the traffic data

High, in case of a large scale attack (may result in huge traffic jams)

Integrity of personalization data and location dataAccess control based on strong authentication for modification of personalization data and location data

Scene 3:1) Postman impersonation2) Error on signature data, which may entail liability problems for the signatory.

1) Low (video identification, it is assumed that the same postman delivers mail regularly)2) High (legal responsibility involved)

-Authentication of individuals (personal ID token)-Data origin authentication (digital signature)-Secure forwarding of authentication assertions


IST Project N° 506775 02/12/2005

-End to end integrity of data

Scene 4 : no significant threat

Scene 5 : -Communication failure during babysitting

High (child at risk) Not a real security problem: it is a matter of reliability of the communication system

Scene 6 :-Impersonation of user

Medium (privacy of personal data involved)

-Authentication of individuals-Access control based on strong authentication for database access (implies end-to-end integrity and authentication)

Table 1 threat analysis for scenario 1: A day in the van Epers family

3.1.2 Scenario 2: A day in the life of a businessmanScene 1: Before traveling

Scene 2: On the way to the airport

Scene 3: In the airport

Scene 4: In the air

Scene 5: From the airport to the conference (provision of a temporary wireless key, using the mobile phone, to unlock the rental car in case of key loss).

Scene 6: at the conference and reaching the hotel


Scene 1: -Malicious modification of re-routing information-Mistake on the intended recipient of the information

High (may result in no-show at the conference)

-Integrity of re-routing data-Access control based on strong authentication for modification of re-routing data-Authentication of intended recipient

Scene 2:-Any malicious modification of data

High (may result in no-show at the conference)

End-to-end Data Integrity throughout the whole communication system

Scene 3:-Traveller impersonation

High (high jacking) -Integrity of prepaid ticket-Authentication of individuals(relates to airline security and government security rather than to ePerSpace


IST Project N° 506775 02/12/2005

security)Scene 4: -Malicious modification of personal profile

Medium Integrity of personalization data

Scene 5:-Traveller impersonation

High (the car may be stolen)

-Strong authentication of request originator-Strong authentication of intended recipient of the temporary key-End-to-end Integrity of data

Scene 6:No real security threat-however, reliability is necessary to avoid unpleasant events such as booking error, mistakes between travel agency and hotel, etc.Table 2 threat analysis for scenario 2: A day in the life of a businessman

3.1.3 Scenario 3: At homeScene 1: Automatic alarm connection

Scene 2: Arriving at home

Scene 3: Watching TV (remote Home control)

Scene 4: Preparing the dinner

Scene 5: Receiving people at home

Scene 6: Time to sleep


Scene 1: Error on user location

High (alarm not switched on as the mobile phone is -erroneously or truly- detected at home)

Integrity of location data

Comment: this scenario puts a risky assumption on human behaviour as the user is supposed to NEVER forget his/her mobile at home.

Scene 2:Error on user identification

High (theft) Depends on the used doorkeeper authentication system:-Biometric-Mobile phone-Personal ID token-Combination of previous means

Scene 3: High (Home management -Strong authentication of


IST Project N° 506775 02/12/2005

Impersonation of Home owner

under control of insiders) owner-Secure forwarding of authentication assertion from Home system to Home system

Scene 4:Malicious modification of information (e.g. recipe)

High (in case of harmful components or bad quantities)

-Data Integrity

Scene 5:Corrupted connection to remote home system

High (data privacy and home management at risk)

-Strong authentication of request originator-Secure forwarding of authentication assertion from Home system to Home system for seamless login-Data Integrity

Scene 6:No particular security threatTable 3 threat analysis for scenario 3: At home

3.1.4 Scenario 4: Hospital stayScene 1: At home

Scene 2: On the way to hospital

Scene 3: Registering at the hospital

Scene 4: In the room

Scene 5: Pre-operative procedure

Scene 6: In the operating room

Scene 7: After the operation

Scene 8: Kids visit (watching a movie and downloading homework)

Scene 9: Starving fish

Scene 10: Customer calls

Scene 11: Back on the feet and Goodbye hospital


Scene 1: Disclosure of medical data

Medium (infringement of privacy laws, but probably not harmful for the patient)

-Medical data encipherment-Access control

Scene 2:Malicious modification of routing information

Medium -Data Integrity-Access control

Scene 3:1) Error on patient's identification2) Malicious modification

High (wrong medical process)

-Authentication of individuals-Access control based on strong authentication


IST Project N° 506775 02/12/2005

of medical data -Data IntegrityScene 4: No crucial security riskScene 5:Risks specific to Hospital system, not relevant for ePerSpace infrastructureScene 6:Malicious modification of personal medical data

High (obvious) -Data Integrity

Scene 7:Communication failure between Hospital and personnel on duty

High (obvious) -Availability and reliability of communications system (not a security problem)

Scene 8:Modification or disclosure of the authorization code

Medium (the addressed content is simply some homework)

-Data Confidentiality-Data Integrity

Scene 9:Modification or disclosure of one-time admittance keys

High (home at risk) -Strong User Authentication (both originator and recipient)-Data confidentiality-Data Integrity

Scene 10:-Modification of VIP clearance-Impersonation of employee identity to access the company's intranet-Denial of service attack by setting fraudulently the "unavailable" option on employee's personal device

High (specially in 2: company's private data at risk)

-Strong User Authentication (end-to-end)-Access Control based on strong authentication

Scene 11:Improper termination of process at hospital

Medium Not related to specific ePerSpace security

Table 4 threat analysis for scenario 4: Hospital stay

3.1.5 Scenario 5: Children in the weekendScene 1: Olivia comes back from school

Scene 2: Fun time at the swimming pool

Scene 3: Saturday evening, going to cinema


Scene 1: 1) High (home safety) 1) Strong authentication


IST Project N° 506775 02/12/2005

-1) Impersonation of child's identity-2) Mobile overflow by too many short messages and ring tones

2) High, if it is significant enough to discourage the user to enable theses functions

by the doorkeeper2) Filtering messages according to detailed parameters (originator, priority level…) chosen by the receiver

Scene 2:No major risk (specific to ePerSpace enhancements)Scene 3:No major risk (specific to ePerSpace enhancements)Table 5 threat analysis for scenario 5: Children in the weekend

3.2 Global security requirements summaryThe most needed security measures can be derived from the preceding threat analysis if the number of occurrence of a need for a certain security measure is retained as consistent classification criteria. This is consistent if measures mitigating risks with the same impact –e.g. "High" to get the most crucial measures- only are retained.

Table 6 results from this numbering of the security needs in the various scenes:

Data Integrity 17

Authentication of individuals 10

Access Control 8

Data origin authentication or digital signature 4

End to end authentication or forwarding authentication assertions 3

Confidentiality 2

Filtering 1

Table 6 summary of security needs in the various scenes

Comments on the table:

1) Authentication is divided into 3 sub-categories of authentication, with respect to the quite different characteristics and supporting technologies of various types of authentication: authentication of individuals (human beings) is generally local and relies on PIN codes or Biometrics, unlike other forms of authentication; Data origin authentication (the procedure of ascertaining the identity of the originator of a message, either human being or technical artefact) relies on Digital signature or Message Authentication Codes; and end to end authentication (mutual authentication or forwarding authentication assertions) relies respectively on challenge-response mechanisms and authentication assertions e.g. SAML. This subdivision must not mislead the reader to under-estimate the relative importance of Authentication in general, compared to Data Integrity. Actually, Data Integrity and Authentication are, in equal terms, the most necessary security services.

2) Filtering arises from one scene only, but it might be more significant if Denial of Service attacks are to be taken into account in large scale. As the potential scope of DDoS attacks is rather vague and general, DDoS attacks have not been addressed as a specific ePerSpace security problem; nevertheless, it should not be completely dropped out.

The global security requirements are classified in: critical and medium (as security is not the cornerstone of the study as a whole, it is not worth spending time and effort on low security).


IST Project N° 506775 02/12/2005

Critical value is assigned if no security solution could result in a severe loss of business or user confidence in case of security attack.

Medium value is assigned if a security solution is desirable or can be provided on demand, but it is not necessary to ensure the correct operations of the system.

Based on the scenario analysis, the global security requirements are identified and classified as follows:

Critical:

1) Data Integrity (provide a means to detect any modification of the exchanged data) .

Integrity protection is the most critical security requirement that emerges from the threat analysis. If it is not ensured, the requests conveyed throughout the networks could be modified in such a way that the identity of the originator could be impersonated, or the parameters could be modified with harmful results.

Data Integrity should be applied not only on hop-by-hop communications, but also on end-to-end communication, in order to avoid "man-in-the-middle" type attacks.

Little concern about “man-in-the-middle”, more secure is stealing of access rights (authentication)., thus link to 2).

2) Authentication of individuals and data origin authentication (ascertain the identity of the originator of any request to any resource).

A basis of the whole security is to provide a resource with the indisputable assurance that the originator of a request is the right person he/she claims to be. If it is not ensured, then access control and authorization processes are performed on a fuzzy basis and are irrelevant.

This requirement does not necessarily mean that the resource must authenticate on its own the request originator. The authentication can be delegated to a third party, which acts as authentication provider. The delegation can be performed only provided that the resource and the authentication provider belongs to a common circle of trust.

In order to avoid "man-in-the-middle" attacks, the authentication must be established from end to end with no possibility for an attacker to forward protocol elements so as to masquerade the client for the provider and the provider to the client.

3) Access control (provide a means to check the right of a request originator to perform the requested action on the requested resource).

Once the identity is ascertained, a system is needed to check whether the originator of a request can perform the requested function on the requested resource, inline with the subscribed services, the security policies and the privacy rules.

Percentage needs ensured authentication, access control is part of ePerSpace service platform.

4) End to end authentication or forwarding authentication assertions .

It is critical that the user can be confident that he is engaged in a transaction with the resource he believes. If it is not ensured, the system is open to a vast range of attacks based on creation of fake servers (e.g. impersonate a bank server to get passwords or information on accounts, create malicious pop-up windows over an authentic web page, etc).

This type of security service covers:

-End-to-end authentication by handshake protocol between communicating parties, e.g. client-server;

-Authentication provided by a trusted third party, e.g. a Liberty-compliant Authentication Authority providing an authentication assertion that can be verified by the entity that needs authentication of its peer.


IST Project N° 506775 02/12/2005

5) Data confidentiality .

Data confidentiality ensures that information is disclosed only to certain persons. There are different reasons to enforce data confidentiality: privacy protection or protection related to corporate or governmental policy. Data confidentiality emerges from the threat analysis as "critical" as it is required to avoid high impact of disclosure risks, mainly in the Hospital scenario.

6) Provide logs of actual requests for business and legal requirements (Non-repudiation)

Data about requests and interchange of data should be kept in order to meet requirements from Service platform (E.g. service level agreements (SLAs) between ePerSpace and Service providers / end users) and legislations.

Requirement is assumed to be covered between GSeM and SP through SLAs., and not further discussed in this deliverable.

Medium:

7) Filtering .

In the scenario analysis, filtering prevents from risk of messages overflow. The user sets it up. According to the technical architecture, filtering can be performed either by the service provider, or by the terminal equipment. How to meet this requirement is also partly detailed in ePerSpace deliverable D4.1, and will be further concluded in D4.4.

8) Digital Rights Management . This aspect is very closely related to Content Providers. DRM are likely to relate to contents and are not necessarily covered by communications security.

3.3 Evaluation against ISO17799 Security standard and toolsets

Refer to http://www.iso17799software.com/The ISO17799 security standard applies to all aspects of the ePerSpace framework relating to security, including global security requirements, service provisioning architecture, communication security, personal profile security, authentication implementations, etc. Therefore, all ePerSpace services should be compliant with this extensive European security standard.

1. Business Continuity Planning:Counteract interruptions to business activities and processes from the effects of major failures.

ePerSpace will have contingency planning for system failure or disaster, e.g. what if Broadband link becomes unavailable? Backups stored off-site and perhaps mirrored systems too.

2. System Access Control:Control access to information; prevent unauthorised access to information systems; protect networked services; prevent unauthorized computer access; detect unauthorized activities; ensure information security when using mobile computing and tele-networking.

Access control is achieved via numerous secure mechanisms including authentication through UID and password, RFID, biometrics, SIM-based authentication. Also access control system for managing the profile are outlined.


http://www.iso17799software.com/

IST Project N° 506775 02/12/2005

3. System Development and Maintenance:Build security into operational systems; prevent loss, modification or misuse of user data in application systems; protect confidentiality, authenticity and integrity of information; conduct IT projects securely; maintain the security of application system software and data.

GSeM is secure using single-sign-on, whether either proposed distributed or centralised system architecture is implemented.

4. Physical and Environmental Security:Prevent unauthorised access, damage and interference to business premises and information; prevent loss, damage or compromise of assets and interruption to business activities; prevent theft of information and processing facilities.

The ePerSpace framework is securely located at telecom premises where stringent physical barriers and proximity cards are employed. Likewise, the UoW has restricted access and secured rooms for ePerSpace components.

5. Compliance:Avoid breaches of criminal or civil law, statutory, regulatory or contractual obligations and security requirements; ensure compliance of systems with organisational security policies and standards; maximise the effectiveness of the system audit process.

Data Protection Act and regular audits.

6. Personal Security:Reduce risks of human error, theft, fraud, misuse; ensure users are aware of information security threats and are equipped to support security policy routinely; minimise the damage from security incidents and malfunctions.

Automation reduces risk of human error. For example, Web Services, XML feeds, OSGi bundles.

7. Security Organisation:Manage information security within the company; maintain the security of organizational information processing facilities and information assets accessed by third parties; maintain security even if information processing is outsourced.

Co-operative partners and associates who share contractual obligations and liability (non-disclosure agreements) should help to ensure that information is managed securely.

8. Computer & Operations Management:Ensure correct and secure operation of information processing facilities; minimise risk of system failures; protect integrity of software and information; maintain integrity and availability of information processing and communication; safeguard information in networks and protect supporting infrastructure; prevent damage to assets and interruptions to business activities; prevent loss, modification or misuse of information exchanged between organizations.

Virus utilities, regular back-ups, synchronisation with slave copies (of sub-sets of personal profile) if used, software updates and hardware upgrades. Better and more secure management of Home Area Network (including RG) through OSGI.

9. Asset Clarification and Control:Maintain appropriate protection of corporate assets and information assets.

Classify and control assets relative to sensitivity of information stored or processed on each asset. For example, authentication server and GSeM would warrant highest level of protection.

10. Security Policy:Provide management direction and support for information security.


IST Project N° 506775 02/12/2005

Management of ePerSpace aligned with security policy.

3.4 ePerSpace security policies

For authentication several principle ways might be feasible. We will analyse methods later on (please see 4.1), but have chosen the device based authentication for this example. Here the user gets a seamless authentication from her mobile phone. Depending on the need of the security requirements of the application, we agree with the authentication mechanisms as suggested by the ”Open Authentication Forum” [www.openauthentication.org]. We either use one-time-password (OTP), SIM card authentication, or PKI based authentication.

After the authentication the user has received an identity. Later in this document we provide an overview the Liberty Alliance as identity provider method. In order to protect the privacy, we suggest following the Liberty Alliance’s approach of using a ”federated identity”. This identity is used to approach the service world, and to get access to the services. The services itself will be set-up from service components, and finally adapted to the user preferences and his communication capabilities. We don’t focus here on the personalisation and adaptation, as these aspects are handled extensively in the other ePerSpace deliverables D5.2 and D5.4.

The ePerSpace security policies will be based on the highest priority Global Security Requirements, which are identified in section 3.2, and summarised below. Also, the security policies may acknowledge and comply with the European ISO17799 Security Standards. All the security policies govern the mechanisms used to access ePerSpace including basic login and password, smartcard, RFID, SIM-based and biometric (fingerprint) authentication mechanisms, (which will share common interfaces depending on whether they are located inside or outside of the home:

Authentication and access control to the home and to the outside will be enabled via different means: RFID, mobile phone SIM-RFID technology, Biometrics (fingerprint).

3.4.1 Global Security Requirements The following are high-level security requirements:

1. Data Integrity

2. Authentication of individuals and data origin authentication

3. Access Control

4. End-to-end authentication or forwarding authentication assertions

5. Data confidentiality

6. Provide logs of actual requests for business and legal requirements (Non-repudiation)

7. Filtering

8. DRM (Digital Rights Management)

Applying the following ePerSpace security mechanisms and safeguards can enforce the Global Security Requirements, listed above:

User authentication

Device authentication

Authorization

Mandatory Access Control (MAC)

Discretionary Access Control (DAC)

Confidentiality


IST Project N° 506775 02/12/2005

Integrity check

Anti-Theft and user/device termination


IST Project N° 506775 02/12/2005

4 ePerSpace security

The purpose of this chapter is to outline how ePerSpace can provide an adaptive and multilevel security supporting services and personalisation. This encompasses a user-friendly security single sign on for the different ePerSpace services, access control and plug-and-play features for new authentication means. The different solutions will be evaluated according to criteria found in previous chapter. This will lead to recommendations for appropriate mechanisms and implementations of authentication and authorisation as security measures for the ePerSpace platform within the framework of WP5 and WP6. (Please see chapter 5) There will be limited implementation of confidentiality, data integrity, privacy, or trust management.

4.1 Authentication mechanisms

4.1.1 The ePerSpace contextWireless networking can be used to connect different personal devices (PDA, mobile phone, etc.) in a home context. They can be linked to each other and also be connected to specific house automation resources.

The ePerSpace scenarios also show usages of these technologies in different (not private) context, like in an airport, hospital, etc. using personal devices to exchange information with a desk, a car, etc.

Authentication is of highest importance to achieve ePerSpace access and services, and will be based mainly on these principles: smartcard, SIM card or biometrics. Biometrics, as well as PIN code or username/password, are used to identify the user to a device. The device will then use it's own identity or the user identity to achieve network access. Service access depends on the security requirements of the application. The "Open Authentication Initiative" [www.openauthentication.org] suggests use one-time-password (OTP), SIM card authentication, or PKI based authentication. The use of these authentications is aligned with the ePerSpace security requirements, and will be subject to a more detailed analysis in the following chapters.

In this part of the report we will only deal with the principal being an individual end user, and the authentication process used to access ePerSpace services. Details on the authentication between service provider (SP) and identity provider (IdP, e.g. federation of identity) can be found in 4.3, and access to parts of personal profile mechanisms in chapter 4.5.4.

4.1.2 Username, password service accessThe simplest identification token typically considered “secure” is the ubiquitous “username / password” combination that is commonly used on the web for all ranges of applications. This authentication mechanism presents some advantages, namely the ease of use and familiarity from the users, and the fact that legislations in most countries have since a long time incorporated rulings for the acceptance and regulation of username / password pairs.

The most important downsides are that it requires the user to actually remember a pretty complex string (or to use the same one over and over, lowering security considerably) that it is very prone to social engineering attacks, and that in non-secured environments it requires the password to be sent unencrypted. These factors usually call for reinforcing the simple username / password mechanism with additional security in highly-secure environments; on internet banking systems, for example, it is usual to call for an additional secret token (which must be different from the “access” one) for enabling operations. The most important downside, however, especially when considering mobile or other “limited” devices, is that it requires the user to type a complicated string on the device itself. WAP usability studies from openwave.com (former Phone.com) in early 2000 showed that whenever an user is required to type on the screen in a mobile application, as many as 7 out of 8 users are lost to the next usage. Opening any mobile application with a “username / password” screen, if we consider these data, is simply unfeasible.


IST Project N° 506775 02/12/2005

4.1.2.1 FORM BASED AUTHENTICATION

Form-based authentication is the process of proving the identity of a user of a system by means of a set of username & password credentials. These credentials are the required proof needed by the system to validate the identity of the user. The user can be the actual customer, a process, or even another system.

Form-based authentication allows controlling the look and feel of the login page. It works similar to basic authentication, except that one can specify a login page that is displayed instead of a dialog and an error page that's displayed if login fails.

Like basic authentication, form-based authentication is not secure because passwords are transmitted as clear text. Unlike basic and digest authentication, form-based authentication is defined in the servlet specification, not the HTTP specification.

Form-based login allows customisation of the login page, but not the authentication process itself.

Form-based authentication requires three steps:

Implement a login page.

Implement an error page that will be displayed if login fails.

In the deployment descriptor, specify form-based authentication and the login and error pages from step 2

4.1.3 Smart Card and PKI basedThe use of sophisticated technologies such as PKI further enhances the security of identity verification in granting physical and logical access. PKI uses public and private keys for digital signatures and email encryption and decryption. If the digital signature is verified using the signer’s public key, then the recipient knows that it was signed by the owner of the public/private key pair and that it has not been changed in any way since it was signed. This assures both the sender and recipient that the information has not been altered. PKI can be used to more accurately identify an individual.

Smartcard technology could be interesting to provide security aspects to some of ePerSpace services. The global idea would be to include a smartcard reader to the Residential gateway as a device more; services provided by this device should be published in the Residential Gateway by using Web Services.

In this way any user that could access the network should be able to use smartcard technology without using one reader per device.

When a device needs to use the reader's services, a secured session will be established with it, then the user will introduce the smartcard in the reader and will be able to use the services offered.

Some of these services could be:

Authentication

Aleatory number generation

Key generation

Digital sign of documents

By means of WebServices, the access to the methods and security functions will be able using SOAP. The scheme could be as outlined in the next (Figure 1):


IST Project N° 506775 02/12/2005

Figure 1 access to the methods and security functions through security WEB Services.

To get this service, the connexion of a smartcard reader to the residential gateway is needed. A proposed architecture for this integration is the next:

A potential implementation strategy is suggested. Discussions are ongoing on what will be implemented in the current phase of ePerSpace:

To access the cryptographic functions in a standard way it would be useful to use the PKCS#11, there are different implementations of this library, called criptoki for different operative systems.

An OSGI driver should be developed to access PKCS11, so different services will be able to access to the smartcard within the OSGI framework.

At last we will have some OSGI services implemented as bundles able to offer functionality to the other bundles published in the OSGi registry.

Figure 2 proposed architecture for connexion of a smartcard reader to the residential gateway.


IST Project N° 506775 02/12/2005

4.1.3.1 SMARTCARD-PC

A smart card is a credit card-sized device that contains one or more integrated circuits (ICs).They may employ one or more of the following machine-readable technologies: magnetic stripe, bar code (linear or two-dimensional), contactless radio frequency transmitters, biometric information, encryption and authentication, or photo identification. The integrated circuit chip (ICC) embedded in the smart card can act as a microcontroller or computer. Data is stored in the chip’s memory and can be accessed to complete various processing applications. The memory also contains the microcontroller chip operating system (COS), communications software, and can also contain encryption algorithms to make the application software and data unreadable. When used in conjunction with the appropriate applications, smart cards can provide enhanced security and the ability to record, store, and update data.

Smart card technology can enable an organization to become more secure, efficient, and interoperable while delivering strong authentication and security, identity management, data management, customer support, and communications. The ICC, the technology on a card that makes it a “smart card,” provides a number of functions. Smart card technology is commercially active and therefore provides additional benefits through commercial off-the-shelf (COTS) products and well-established technology standards.

Smart card technology can address issues surrounding identity management and can also provide the means to eventually re-engineer inefficient processes with a high return on investment (ROI). In the identification of inefficient processes, outdated business practices, and low ROI programs, an organization can eliminate deficiencies, unnecessary costs, and under-used resources through the implementation of smart card technology. The combination of smart card technology with web-based applications, electronic commerce, and and other business uses of the Internet can improve the quality of life for citizens and employees.

Smart card technology provides a toolbox of enhanced capabilities that can be used to implement a smart identification card.

Smart cards can provide significantly enhanced security features that allow the card to operate as an authentication token for secure logical access to terminals and networks (such as local area networks (LANs) and the Internet), as well as for physical access to buildings, rooms, parking lots, transit and other facilities.

4.1.3.2 SIM CARD (SUBSCRIBER IDENTITY MODULE) BASED SECURITY

The mobile phone subscription is personalised through a terminal-to-terminal exchangeable Smart card, e.g. a card having microcomputer with processor, ROM, persistent EEPROM memory, volatile RAM, and a serial I/O interface. SIM software usually consists of an operating system, file system, and application programs.(e.g.. SIM Aplication Toolkit – GSM 11.14) The SIM-card can be considered to be a subset of smart Card, or SIM applications running on a smart-card. As with all smart cards, the SIM relies on the card terminal – the GSM handset – for battery and clock.

Remote wireless management of SIM Card is possible for operator through GSM/3G network (OTA) by encrypted (APDU) messages encapsulated in SMS-messages [ETSI 03.48]. This standard ensures security (message confidentiality, integrity, peers authentication and replay detection).

Each SIM card is unique, and related to a single user. The SIM card is responsible for authentication of user by prompting for PIN-code, identify user towards network through pair of keys, and to protect user data through cryptography. All mobile GSM phones have slot for one SIM card.

The SIM contains a set of objects hidden from intrusion:

A personal code (PIN – Personal Identity Number) which can be used to lock the card, e.g. preventing misuse by loosing card. To activate the SIM card a 4-digit code is used, and if incorrect code is used 3 recurrence times, a 8-digit code is needed to unlock card.

International Mobile Subscriber identification (IMSI), a unique number related to mobile phone number.

A secret 128 bit individual key Ki, used for authentication, but never sent over radio interface (also kept in an authentication DB in the GSM network).


IST Project N° 506775 02/12/2005

Authentication and cryptography algorithms (A3 and A8).

The SIM-card being an advanced Smart-card is considered to a have a much higher degree of protection (intrusion and cloning) than a ordinary Cash-macine card (with a magnetic storage), and can as such be considered tamper-resistant [Anderson, Ross, Security Engineering. John Wiley & Sons Inc. ISBN 0-471-38922-6. 2001]. A comment worth mentioning is that even such for Cash-machine card it is known that the abuse caused by technical weaknesses are by far less than the abuse caused by stolen cards and unfaithful servants.

For elder SIM-cards (pre-2000) there are known (lab) attacks, for instance finding Ki by sending RAND to SIM, and logging and computing the returned SRES and Kc (taking aprox 4-8 hrs due to response time of SIM card). By having Ki it possible to clone SIM card. See for instance [The Smartcard Developer Association, Smartcard Developer Association Clones Digital GSM Cellphones, SDA Press Release, San Francisco, April 13, 1998.] or [Marc Briceno and Ian Goldberg, GSM Cloning, Technical Report, ISAAC, University of California, Berkeley, April 13, 1998] Other attacks such as using weakness in Comp128 algorithm, and even finding Ki through use of removing SIM card protection and exposing individual transistors by light and reading through microscope are also known.

Most recently a method (and the improvement of SIM card to prevent this) have been shown that uses surveillance of leakage of radiation from processor, power consumption as a function of time, and the time delay of certain functions [J. Rao, P. Rohatgi, H. Scherzer, Partitioning Attacks: Or How to Rapidly Clone Some GSM Cards, IBM Watson Research Center, May 12, 2002]. This led to an improvement of COMP128 in order to prevent this.

The key issues are still that all such attacks requires:

Physical access to SIM card as well as time, causes damage to card

Quite advances knowledge and resources, known attacks are actually caused by researchers in advanced labs..

The SIM card must be removed from terminal without breaking power supply (or known PIN code).

SIM is manufactured, provisioned, distributed, and managed in trusted environments. This results in the SIM being tamper resistant devices. To prevent the possibility of fraud through cloned SIM-cards operators have implemented methods for detecting usage of such clones. This is however highly operator dependent.

Authentication The authentication process is a two-step, one-way since:

1. The user is being first authenticated towards the SIM-card in phone through entering the PIN number.

2. Towards the operator through SIM AAA (authentication, authorization, and accounting services) mechanism. The network authenticates the subscriber through the use of a challenge-response method.

Further work in ETSI/3GPP

The SIM has evolved in UMTS to become the USIM (in 3GPP, The Universal Subscriber Identity), and further work related to Smart cards continue within ETSI Smart Crad Platform project (EP SCP - the successor to SMG9) in order to standardize a common Integreted Circuit (IC) card (UICC). UICC will compromise the platform specifications implemented on the smart card, andd resident applications baesd on them, as well as the USIM as an applications for access to systems based on the 3GPP specifications, and/or the Removeable User identity Module (UIM) application for access to 3GPP2 systems.

4.1.3.3 SECURITY EXCHANGE BETWEEN PHONE AND PC

There are many ways to authenticate a user towards a PC or network and their services. The most common method used is by asking the user for a login and a password. Although this method works if a


IST Project N° 506775 02/12/2005

password is carefully selected, it puts all the burden into the user, since the user most remember both values for each service that requires authentication. Since most of the people are not able to remember a secure password for each service, the result is security breaches, where users tend to write down their passwords, select easier passwords to remember or use the same password for each service.

To avoid this problem, there are other methods that involve a Public Key Infrastructure or PKI in which the users are authenticated through a security token (something they have) and a password (something they know). Based on this principle, the mobile phone becomes a very adequate device for authentication since it is something that users always have and through the SIM card it meets all the security requirements of most common security infrastructures.

Figure 3 describes a method in which a mobile phone with a SIM card can be used to provide user authentication for personalized services with a one time password.

AuthenticationServer

InternetInternet

1. User wants to log-in to his personalized web page

2. Request login and password

3. Ask for phone number (user)and password (128 bit number

Stored in the SIM card)

Bluetooth

4. Return phone number and password 5. Forward login and password

Web Server

6. Authenticate user and redirect to personalized web page

7. Send a new 128 bit password

8.Write new 128 bit passwordto the SIM card

Figure 3 User authentication trough mobile SIM with one time password.

1. User tries to access his personalized web page with a PC

2. The authentication server detects that someone is attempting to access a service and returns a challenge for login and password.

3. The PC searches for the user’s phone in its surroundings (via Bluetooth) and when found requests the login (phone number) and the password (128 bit key stored in the SIM card)

4. The phone returns both values via Bluetooth (Note: Communication via Bluetooth is encrypted and requires previous authentication between the PC and the mobile phone. Done only once)

5. The PC forwards the authentication data, which can be encrypted from this stage between the PC and the authentication server using SSL.

6. The authentication server receives the authentication data and redirects the initial request to the correspondent service.

7. While forwarding the request the authentication server also sends a new 128 bit key back to the PC

8. The PC receives the new key and writes it in the SIM card of the mobile phone via Bluetooth.

The method described solves the problem of having to remember a difficult password by authenticating through a security token (mobile phone). Although this method could be secure enough in most cases, it does not challenge the user for a PIN code or password (something the user knows), which in some cases like payment is not good enough.


IST Project N° 506775 02/12/2005

The problem of providing higher security could be solved using the same method together with the PKI supported by the SIM card, in which case the method will only be changed on the described steps 3 and 4. Instead of requesting a login and password, the PC will send a signature challenge to the mobile phone. When the phone receives the challenge (via Bluetooth) it prompts the user for his PIN number. The user will then sign the challenge with a PIN number and the challenge is sent back to the PC to continue the authentication process.

Although both methods will provide an easy and secure authentication, there are still some practical difficulties that arise when authenticating the mobile phone and the PC for the first time via Bluetooth. This process is called pairing and requires both ends to agree on a password, and unfortunately the process is not that efficient in many cases. But a new technology called NFC (Near Field Communication) solves such problem by letting the users pair two Bluetooth devices by simply putting them next to each other (shown in the picture).

When two NFC devices are in proximity to each other, they automatically exchange the required pairing information. Such information is exchanged through the common RFID protocols in which the NFC technology is based.

In some cases there is also required to prove that the authenticated user is present while the services are being offered. The properties of the Bluetooth technology could provide a solution to such requirement.

~10m

Bluetooth Coverage

The PC pings for the mobile phone every15 seconds after receiving a positive answerfrom the phone

Request

Response


IST Project N° 506775 02/12/2005

~10m

Bluetooth Coverage

If the PC doesn’t receive an answer from the phoneIt locks the screen, mouse and keyboard and startsSearching for the mobile phone every 5 seconds

SIM based authentication could initiate a series of "background jobs" that the network would carry out to proactively provide personalized services the user may want to have regardless his location, the access network and the device being used.

4.1.4 Biometric authentication

The main advantage to use biometrics for authentication is that the user is not authenticated only by the knowledge of a PIN or the possession of a physical token, which are only derivative indicators of authenticity. There are several ways to use biometrics for authentication: one way uses a physical token like a mobile phone, smartphone or a PDA equipped with a biometric device like fingerprint reader. When the user wants to prove his identity, the token ask him to put his finger on the device. In case of success, the token sends a user ID to the application (web server or authentication server). This link must be secured by a cryptographic mechanism to avoid the listening of the user ID. The most problematic step is enrolment, indeed the user may not enroll himself on the token, the enrolment must be initiated by the server and should be strongly secured.

Another way, possibly used on a PC, is to use a device like fingerprint reader, iris or face recognition camera, or microphone (for speaker recognition). When the user wants to be authenticated, the PC ask him to use the device, and biometric data are sent to an authentication server, which verify their authenticity. An alternative way is to perform the verification with a soft installed on the PC. After verification, the PC sends the user ID with a cryptographic signature.

4.2 End to end Authentication

This chapter will concentrate on the single sign on solution (SSO). The objective of SSO is to allow users access to all applications from one logon. This is a key requirement to manage seamless access to services. Since ePerSpace is deploying a distributed architecture with a number of service providers and a central service aggregator SSO is a pre-requisite. This chapter will also discuss identity federation management, which must be considered when authentication tokens are exchanged between network entities.


IST Project N° 506775 02/12/2005

4.2.1 Single Sign on (SSO)

4.2.1.1 NEED FOR SINGLE SIGN ON (SSO)

As IT systems proliferate to support business processes, users and system administrators are faced with an increasingly complicated interface to accomplish their job functions. Users typically have to sign-on to multiple systems, necessitating an equivalent number of sign-on dialogues, each of which may involve different usernames and authentication information, which result in difficult memorization and eventually a security risk since users tend to write down this information. System administrators are also faced with the challenge of managing user accounts within each of the multiple systems to be accessed in a co-ordinated manner in order to maintain the integrity of security policy enforcement. Such situation presents a major obstacle to eService success.

Authentication is a horizontal requirement across multiple applications, platforms, and infrastructures. In general, there's no reason why a user should need multiple usernames. Ideally users should only need to identify once and then be provided with access to all authorized network resources.

The objective of SSO is to allow users access to all applications from one logon. It provides a unified mechanism to manage the authentication of users and implement business rules determining user access to applications and data.

Here are some of the benefits and risks of implementing single sign on.

Benefits:

Improved user productivity. Users are no longer bothered by multiple logins and they are not required to remember multiple IDs and passwords. Also, support personnel answer fewer requests to reset forgotten passwords.

Improved developer productivity. SSO provides developers with a common authentication framework. In fact, if the SSO mechanism is independent, then developers don't have to worry about authentication at all. They can assume that once a request for an application is accompanied by a username, then authentication has already taken place.

Simplified administration. When applications participate in a single sign-on protocol, the administration burden of managing user accounts is simplified. The degree of simplification depends on the applications since SSO only deals with authentication. So, applications may still require user-specific attributes (such as access privileges) to be set up.

Risks:

Difficult to retrofit. An SSO solution can be difficult, time-consuming, and expensive to retrofit to existing applications.

Unattended desktop. Implementing SSO reduces some security risks, but increases others. For example, a malicious user could gain access to a user's resources if the user walks away from his machine and leaves it logged in. Although this is a problem with security in general, it is worse with SSO because all authorized resources are compromised. At least with multiple logons, the user may only be logged into one system at the time and so only one resource is compromised.

Single point of attack. With single sign-on, a single, central authentication service is used by all applications. This is an attractive target for hackers who may decide to carry out a denial of service attack.

SSO Basic Scenario:


IST Project N° 506775 02/12/2005

In a basic SSO scenario, the authenticated party first calls the SSO server and requests the authentication token that identifies it in the particular domain. In order to get the token, it must first provide the correct authentication credentials. There are various forms for those credentials: it might be, for example, a simple username/password or certificate, but other methods can be implemented. The SSO server performs a validation of the users' credentials using the underlying security infrastructure, and only then issues a ticket that the calling application uses for authentication against other applications. In the simple scenario, the token doesn't impose any specific information, it is simply the unique identification of the user in some defined scope and time. After the invoked application receives the token, it validates it by passing it to the SSO server that then performs the actual checks.

The main technical advantages of the SSO approach are:

Encapsulation of the underlying security infrastructure in the SSO server. Implementation, deployment and maintenance are much easier as all communicating parties in the distributed system don't need to individually implement all of the security features and mechanisms.

The SOAP interface to the SSO server makes the SSO architecture universal. Since the SSO is itself a Web service.

The SSO server enhances security of the whole system as the security credentials don't need to be passed around. The only point that accepts security credentials is the SSO server itself. Moreover, the SSO solution often allows federation, so the authentication can be performed in a broad scope (outside of the particular security domain) while the security credentials stay within the particular security domain.

Advanced SSO - using SAML (Security Assertions Markup Language):

SSO server invocations were necessary in the previous simple SSO scenario each time the user was challenged for identity verification. A more advanced approach permits the token itself to contain some valuable security information that allows validation without having to call the SSO server each time. The token contains the authentication or authorization information. This information is 'signed' by the SSO server, so provided the token recipient trusts this server, it doesn't have to do any further verification.

There is a new standard for exchanging security-related information in XML called Security Assertions Markup Language (SAML). This is currently being completed at OASIS (http://www.oasis-open.org). Basically, the security information described by SAML is expressed in the form of assertion statements about security subjects (e.g. users, machines or services). SAML defines the protocol by which the service consumer issues the SAML request and the so-called SAML authority returns the SAML response with assertions. There are three kinds of assertions:

The Authentication statement informs about the authentication of a particular subject in a specific time and scope.

The Authorization decision allows or denies a subject access to a specific resource.

The Attributes further qualify the subject (e.g. credit line info, citizenship etc.).

4.2.1.2 SSO SOLUTIONS

SSO is most complex in mixed environments because no universal solutions apply to all OSs and environments. Therefore, an organization must identify the scope of SSO and limit the SSO solution to a few applications or platforms. Several SSO technologies are available for organizations to tailor solutions to specific problems. These SSO options include password synchronization, logon automation, and token-based authentication.


http://www.windowsitpro.com/Windows/Articles/ArticleID/7572/pg/1/

http://www.oasis-open.org/

IST Project N° 506775 02/12/2005

Password Synchronization

Synchronizing passwords across multiple OSs might be a sufficient solution for organizations that are primarily concerned about forgotten passwords.

Using password synchronization reduces the number of Help desk calls related to forgotten passwords and is a cost-effective solution to this problem. The user must remember only one password instead of multiple passwords. One problem with this approach, however, is that if someone decodes the password on one system, all the other systems are vulnerable. Therefore, if an organization chooses password synchronization, it needs to ensure the security of all its systems. (For a review of password synchronization products, see Randy F. Smith, "SAM/PS, P-Synch 3.5," October 1999.)

Logon Automation

Logon automation involves a centralized database that contains a user or a client computer with access to various resources. You modify the client interface to provide shortcuts or links to all the resources the user or computer can access. The logon process is automatic because the user doesn't need to log on to each resource.

With the combination of shortcuts and the centralized database, access to resources on disparate systems is transparent to the user. Each time a user clicks a link to a resource, stored scripts run from the database to give appropriate credentials to the target system for access without additional user logon.

The logon automation approach lets users who aren't part of an organization's SSO solution independently access specific servers. For example, a consultant can access a UNIX computer even though he or she isn't in the SSO authentication database. In a large enterprise network, however, letting non-authenticated users access a system might reduce security.

Compared with password synchronization, logon automation provides a higher level of security because each target system has a unique password. The password can be different on different systems, and you can tailor the strength of the password to individual applications.

Kerberos and Token-based Authentication

Kerberos is a token-based authentication scheme for users and servers to authenticate one another through a trusted third party, called the Kerberos Key Distribution Center (KDC). The Kerberos KDC provides tickets (or tokens) to authenticate clients and temporary session keys that clients use as temporary encryption keys during logon sessions.

An individual's token is unique and doesn't work for other users. Tokens let clients and servers identify one another, even on a nonsecure network, and encryption keys prevent security compromises. Each application service on a network must be capable of responding to valid tokens by allowing user access.

4.3 Federation of Identity through Liberty Alliance

This chapter presents the main initiatives in the area of identity management. EPerSpace are in favour of the ID federation as suggested through the Liberty Alliance Project’s ID-FF (Identity Federation Framework). The reasons in favour of the Liberty Alliance Framework are it’s strong consortium and members support, the ability to provide a global framework including support to enable various business models, the flexibility to allow a distributed architecture such as ePerSpace, and the framework allowing ID not to be kept centrally, but managed between different providers and that only “federation keys” are sent to the requesting entity.

There are numerous other specifications available for sharing identities across organisational boundaries. The main standards are SAML (Security Assertion Mark-up Language) by OASIS (Organisation for the Advancement of Structured Information standards), and the Web Services Federation specifications from Microsoft and IBM. In addition, there is P3P (Platform for Privacy Preferences Project) from W3C (World


http://www.windowsitpro.com/Windows/Articles/ArticleID/7572/pg/1/

IST Project N° 506775 02/12/2005

Wide Web Consortium), and UCI (Universal Communications Identifier) from ETSI (European Telecommunications Standards Institute).

The Microsoft Passport solution (4.3.5.1) is not favoured because of the less open solution, as well as the somewhat reluctant acceptance in the marked. The parallel initiatives between SAML/OASIS and Liberty alliance are now being resolved through submitting ID-FF 1.2 as input to SAML2.0 (See 4.3.3). The ETSI UCI proposal does not apply as a framework, but more as a set of recommendations focused on personal profile management, and in particular a identifier for all communications. In fact, ePerSpace have actively followed and contributed to these recommendations, and will implement some of the recommendations in the personal profile management (to be documented more in the upcoming release of D5.4). Other initiatives have not gained sufficient momentum.

To address the inefficiencies and complications of network identity management for businesses and consumers in today’s world, there is a strong need for a federated network identity infrastructure that allows users to ‘link’ elements of their identity between accounts without centrally storing all their personal information”. E.g. Driver’s license, passport, national ID cards, etc.

As explained on the SourceID (http://www.sourceid.org/index.html) website, “Federated identity infrastructure enables cross-boundary single sign-on, dynamic user provisioning and identity attribute sharing. By providing for identity portability, identity federation affords end-users with increased simplicity and control over the movement of personal identity information while simultaneously enabling companies to extend their security perimeter to trusted partners. New identity federation standards provide companies with the foundation for securing their outsourced business processes, hosted applications and web services while simultaneously addressing a host of other security, management and integration challenges”.

4.3.1 Liberty Alliance Main rolesLiberty Alliance was formed in Sept 2001. The members represent many nationalities and span from consumer-facing companies and technology vendors to policy and government organizations.

The work of the alliance has the following goals:

Provide open standard and business guidelines for federated identity management of all network devices

Provide open and secure standard for single sign-on with decentralized authentication and open authorization

Allow consumers/businesses to maintain personal information more securely, and on their terms

Phase 1 is referred to as the Liberty Alliance’s Identity Federation Framework (ID-FF). It provided standards for single sign-on/ single logout and linking of separate accounts within a group of service providers in a “circle of trust”. It is possible for users to browse various sites without signing-on again.

Phase 2, the Liberty Alliance’s Identity Web Services Framework (ID-WSF), specifies features to enhance identity federation and help the creation of interoperable identity-based web services.

Further work will be on Service Interface Specifications (ID-SIS) based on the Liberty Identity Web Services Framework (ID-WSF). This includes personalized services like Contact book, Geo location, Presence and Calendar. Essential for these services are the specification of the Liberty Personal Profile Service (ID-SIS) and the Liberty Employee Profile Service (ID-SIS). These web services provide a user or employee's basic profile information, such as their contact details, or name.

Main focus of the Liberty Alliance is the provision of ID distribution, through the distribution of a “federated key”, originated from an ID provider (IDP) and distributed to an ID requestor.

Within Liberty alliance the following roles apply in order to allow an architecture that allows a federated identity (SSO):

Principal


http://www.sourceid.org/index.html

IST Project N° 506775 02/12/2005

A system entity (e.g. individual users, groups of individuals, organizational entities or system components) that is capable of making decisions, and can acquire a federated identity and be authenticated and vouched for by an Identity Provider.

SP (Service Provider)An entity that provides services and/or goods to Principals. The SP may request that the IdP to authenticate the Principal.

IdP (Identity Provider)A Liberty-enabled provider that creates, maintains and manages identity information for Principals, and provides Principal authentication to other providers. The IdP authenticates and vouches for Principals within a Authentication domain.

Although Liberty separates the roles of SP and IdP, a provider may act as an IdP and a SP at the same time and forward authentication assertions to other SPs.

In Simplified Sign-On, the IdP is explicitly chosen by the principal (as MS Passport does).

In full SSO, the automatic selection of IdP is part of the SSO functionalities.

The Liberty Alliance provides a set of specifications of which objectives are to:

Drive a new level of trust in communications over the Internet, by establishing open technical specifications for secure management of identities.

Provide an open single sign-on standard that includes decentralized authentication and authorization for multiple providers.

Create a network identity infrastructure that supports current and emerging various network access devices.

A description of Liberty Alliance business models and applicability to ePerSpace has been provided in Deliverable 5.1, part 4.1.4. In this current chapter we can therefore move directly to technical discussion.

4.3.2 Liberty standard subsets and main concepts

4.3.2.1 AUTHENTICATION:

The action to confirm a Principal asserted identity with a specified level of confidence. A simple case may be that a Principal presents cresidentals to an IdP, which decides to/not to authenticate the Principal based on the cresidentals and the policy of the IdP. In the Liberty context the technique an IdP uses for authenticating an principal is not within Liberty scope, but Liberty offers transport mechanisms specifications for authentication exchange. Communications between Principals and Liberty sites must be integrity protected and ensuring confidentiality. E.g. the Liberty sites must use SSL 3.0 or TLS 1.0, and Liberty recommends at least 112-bit symmetric key: [https://www.projectliberty.org/resources/specifications.php#box3 , https://www.projectliberty.org/specs/liberty-idwsf-security-mechanisms-v1.2.pdf ]

For a federated IdP solution the SP requires and receives an alias of the identifier of a principal from an IdP. The alias mechanism is used to prevent from a unique user Id known from the service providers, which could infringe privacy protection. Aliases enable providers to identify an authenticated user without being able to trace the complete collection of the user's attributes.

In this case another level of authentication is needed, e.g. there must be a mutual authentication between SP and IdP. Liberty offers two sets of mechanisms for this [https://www.projectliberty.org/specs/liberty-idwsf-security-privacy-overview-v1.0.pdf]:

In the absence of active intermediates in the path: Peer Entity Authentication mechanisms to ensure confidentiality and integrity of message communication, with authentication of both sender and recipient. Required: SSL 3.0 or TLS 1.0 and X.509 client-server certificates [X.509 PKI].


https://www.projectliberty.org/specs/liberty-idwsf-security-mechanisms-v1.2.pdf

https://www.projectliberty.org/resources/specifications.php#box3

IST Project N° 506775 02/12/2005

If active intermediates are present: sender must use message authentication through WEB Services Security SOAP Message Security/SAML token profile sender authentication [https://www.projectliberty.org/resources/specifications.php#box3 https://www.projectliberty.org/specs/liberty-idwsf-security-mechanisms-v1.2.pdf ] or X.509 token profile sender authentication.

4.3.2.2 AUTHORISATION

Authorisation is the process of determining the types of activities an entity can perform, and only makes sense in the context of (first) authenticating the entity.

Authorisation is depending on a secure managed authentication system and a securely managed data describing authorisation policy (e.g. in the form of Access Control Lists (ACLs).

[ https://www.projectliberty.org/specs/liberty-idwsf-security-mechanisms-v1.2.pdf ].

4.3.2.3 FEDERATION OF IDENTITY AND SINGLE SIGN-ON

From a user perspective SSO is achived when the user logs onto a IdP and uses ascoiated SPs without having to sign on again. This achieved by having federated the principals (users) local Ids between IdPs and SPs, and having mechanisms that allows IdP/SP to convey to another IdP/SP that the user is authenticated, and as such allow the ‘reuse’ of authentication actions.

The federation of Identity is detailed in the Liberty ID-FF/SAML framework, and enables:

Authentication ‘reuse’ across sites.

A method for exchange of name identifiers allowing SPs to speak about a ‘subject’ in a common language (the federated name identifier) while the identifier is hidden from third parties (opaque).

Extending SAML authentication statements, adding session and authentication context.

Creates authentication Request/Response protocol

Creates “de-federation”, global single logout, name identifier registration and mapping protocol.

Specify profiles for request/send SAML assertions in a WEB SSO architecture, also with intermediates present.

4.3.2.4 COT (CIRCLE OF TRUST)

A federation of SP around a logically unique IdP; those SP are bound by business relationships and operational agreements so as users can perform transactions in a secure and apparently seamless environment throughout the entities belonging to the CoT. So SP’s (Service providers) shares linked Ids and have business prerequisites (relationships, SLAs) in order to permit a federated Id:

Well defined business agreement (business logic layer)

Notification and consent from user on information being collected

User giving consent for information being used

Recording of usage (non-repudiation)

This requires a certain trust between partners, but the trust mechanisms are not specified by Liberty Alliance.

Note on ID: In such a architecture with a federated ID through a CoT no global Account / ID namespace is needed, since the users ID is federated through the link.




https://www.projectliberty.org/resources/specifications.php#box3

IST Project N° 506775 02/12/2005

4.3.2.5 STANDARD SUBSETS

The Liberty Alliance architecture is composed of three main sets of standards:

ID-FF (Identity Federation Framework) enables identity federation and management through:

o Identity/account linkage

o SSO

o Session management

ID-WSF (Identity Web Services Framework) provides the framework for building over WS:

o Locating and invoking interoperable identity services

o Permission-based attribute sharing

o Identity services description and discovery, associated and invoked through Principals identity

Of special interest for ePerSpace is the Authentication and SSO service:

Authentication service (https://www.projectliberty.org/specs/liberty-idwsf-authn-svc-v1.1.pdf) wich allows general identity authentication over SOAP:

o SASL based SOAP Authentication

o General purpose exchange of authentication

o Support for several mechanisms (CRAM-MD5, PLAIN, X.509, SECURID, …)

o Client –to- Server or Server-to-server Autentication

o Possible to bootstrap to Discovery service

SSO service

o Allowing WSCs to interact with non-WSF SPs, e.g. non-SOAP/WSF capable (Liberty enabled User Agents / Devices are SOAP capable clients.

o A profile of the ID-FF SSO/Federation Protocol.

o Two step; 1) WSC uses the Authentication Service to provide security tokens from IdP. 2) WSC invokes the SSO Service at IdP in order to obtain authentication assertion presented towards (non-WSF) SP.

Permission based attribute sharing, e.g. invoking services under control of user, and Service Requestor doing so on behalf of user

Description of the related security profiles

The relationship between ID-FF/SAML (please see next subchapter for details):

o ID-FF/SAML (e.g. the usage of federated Id) can be used to short-circuit into ID-WSF: SP gets an Assertion which can include bootstrap information for invoking the Discovery service (DS), and the SP can then act as a Web Services client (WSC) in order to invoke ID-WSF services.

o Authentication Service (AS) provides a SOAP interface to the IdP to perform non-web “federation of identity” operations. This results in a ID-FF/SAML2 assertion provided (back to client), and client can invoke Discovery service

o WSF also specifies how SAML Assertions can be used to communicate between actors.

ID-SIS (Identity Service Interface Specifications) enables interoperable identity services such as:

- Personal identity profile service

- Contact book service


IST Project N° 506775 02/12/2005

- Geo-location service

- Presence service

4.3.3 ID-FF/SAML for Liberty SSO

The current version SAML 2.0 is ratified as OASIS standard in March 2005, and the parallel development between Liberty ID-FF and SSTC is resolved through submitting ID-FF 1.2 as input to SAML2.0 is now the preferred federation standard for liberty.

OASIS SAML standard protocol specification describes a set of Requests and Responses messages aiming at requiring and providing assertions that may be:

An Authentication assertion: a statement that a subject S has been authenticated at a time T by means of an authentication method M.

An Attribute Assertion: a statement that a subject S is associated with attributes A, B, C… with values a, b, c…

An Authorization Assertion: a statement that a subject S is authorized or not to access a resource R.

Liberty enriches the basic SAMLv1.1 standard by extensions dedicated to SSO. SAML messages are exchanged between IdP and SP to propagate authentication assertions enabling secure seamless login to various SP on the basis of one initial authentication.

Integrity of assertions is a cornerstone of SAML security for SSO. Any undetected modification of a SAML message would make the whole process meaningless. To ensure integrity, the entities involved in SSO must use Transport security (SSL/TLS) and/or digital signature of messages (XML DSig).

The relationship can be considered layered with the top down of: Profiles – Bindings – Protocols – assertions:

Profiles: how SAML assertions, protocols and bindings are combined in order to meet use case requirements

Bindings: how SAML protocols map onto standard messaging or communication protocols.

Protocol: Request/Response pair for obtaining Assertions and Federation Management.

Assertion: Authentication, Attribute and Authorisation information.

SAML specifies profiles on how SAML assertions, protocols and bindings are combined in order to meet use case requirements:

WEB browser SSO profile

Enhanced client and proxy (ECP) profile

Identity provider Discovery Profile

Single logout profile

Name Identifier Management Profile

Artefact resolution Profile

Assertion Query/Request profile

Name Identifier Mapping Profile


IST Project N° 506775 02/12/2005

4.3.4 Liberty alliance applicability to ePerSpace architecture In ePerSpace, we have various Service Providers proposing their services via a Service Aggregator (platform named GSeM in the project). In this model, beforehand, Service Providers and Service Aggregator would need to establish SLAs to define for example access control to user data, trust level, billing capabilities, etc…. If we apply the Liberty Alliance framework to our ePerSpace architecture the GSeM could play the role of IdP, and thus Services Providers would be part of the same CoT.

4.3.4.1 FEDERATION OF IDENTITIES

In the Liberty Architecture overview, one basic assumption for identity federation is the pre-requisite existence of a user account at each involved service, and the federation of identities is a voluntary process based on the explicit consent of the user.

However, it is possible to forward authentication assertions about a user, from an IdP to a service provider of the same CoT, so as dynamic (on-line) enrolment would be processed on the basis of a previous authentication.

In any case, there is a need for explicit consent of the human user before processing federation of identities.There is a possible exception to this rule: when a bundle of services is proposed at subscription time as a unique commercial offer. In this case, the various providers are seen as unique by the subscriber, therefore there is no rationale for strict separation of identities as the user is aware that his personal (subscription) data are handled by a unique entity (e.g. SSO Orange-Wanadoo).

4.3.4.2 SECURITY CONSIDERATIONS

Liberty SSO is designed to be independent of authentication mechanisms. However, when a certain security level is required, a SP, when it delegates authentication of accessing entities, should be confident that the used authentication method matches the requirements for his security level: for example, if a user establishes a first connection with SP1 requiring plain old username and password only, and in a second phase a connection with SP2 requiring cryptographically protected authentication, the user should be re-authenticated with a stronger method (introducing an exception in the normal SSO process that should not challenge one more time the end user for new authentication). This may occur e.g. when SP1 provides several sub-services with different security levels.

In order to address this requirement, Liberty protocol syntax includes an "Authentication Context" parameter, which indicates the type of used authentication method (e.g. Password, PasswordProtectedTransport, SmartCard, Mobile, etc…).

In ePerSpace architecture, authenticated identities may be one or a combination of the following basic types:

An identity associated with a mobile phone number.

An identity associated with a Login name on Desktop client software.

An identity certified by a Certification Authority in a Public Key Infrastructure.

An identity associated with a Biometric sensor on a device.

An identity associated with RFID/SIM

We should the further determine:

What the entities of CoT are likely to be for a scenario;

Whether pre-conditions are needed to ensure secure transactions, in each usage scenario (e.g. collaboration agreements between parties, or re-requisite establishment of CoTs, etc).

How personal profiles can be forwarded in line with the user requirements (public or private) and with the service requirements (need to know).


IST Project N° 506775 02/12/2005

4.3.4.3 APPLYING THE LIBERTY ALLIANCE TO OUR EPERSPACE ARCHITECTURE

If we apply the considerations above we can deduce (also shown in below).

The IdP would be associated to the Global Service Manager (GSeM). It will perform or delegate the end entity authentication to the Authentication Manager located in the Residential Gateway of the user (please see 5.2.3 for further description of implementation). It will deliver assertions in a secure way to ePerSpace service providers; The SOAP interfaces are currently in use in ePerSpace associated to Web services. The same could be used to implement the SSO server.

The entities of CoT are likely to be the Service Providers (content, applications, etc…). For each of them, we could define a level of trust that would be reflected in the SLA agreed between the GSeM and the SPs. This would define pre-conditions that are needed to ensure secure transactions, in each usage scenario (e.g. collaboration agreements between parties, or pre-requisite establishment of CoTs, etc). Please note that these sorts of pre-requisites are not within the scope of Liberty Alliance. We have however given a short analysis of levels of authentication, and hence a foundation for thrust, please see chapter 5.4.4.

We are currently using a Service Profile that is used by the Service Provider to define type of services it is providing. This allows us to describe the service requirements and could as well include type of authentication needed.

Figure 4 Overview; applying Liberty Alliance to ePerSpace architecture


Attribute Provider

GeolocationContact book…

Service and Management

Platform

Residential Gateway

Home network and residential

devices

Mobile phones

Content Provider

Application Provider

Cellular network for mobiles

SP SP SP

IdP

CoT

IST Project N° 506775 02/12/2005

4.3.4.4 SERVICE LEVEL EPERSPACE SECURITY REQUIREMENTS

The following items from Liberty are identified and should act as service level ePerSpace security requirements (checklist):

Id federation and SSO (between user and SP/IDP). E.g. meet the privacy requirements on permission-based consumer control as well as allow personalised service access.

o Identification of IDP to user (e.g. how do the user know what IDP she is logged onto?).

o Notice to user from IDP upon ID federation/defederation (user /IDP requesting that IDP no longer provide information to SP) With regards to rpivacy; normally the user gives consent to her ID being federated in a CoT (UI prompting for permission ) first time.

o Notice to user from IDP upon ID defederation (user /IDP requesting that IDP no longer provide information to SP)

Required authentication / confirmation / log of user by SP/IDP for defederation

Invalidation (revocation) of session information (only based on IDP assertion).

o Notice between SP / IDP; federation /defederation and termination.

o SP given anonymous temporary Id for a principal from IDP (upon request)

o Different SP’s should not be able to communicate directly about a user, but through IDP individually (policy and security enforcement). Different SP should not be able to identify a user in a unique manner (use of aliases).

o The user should be able to link different IDP’s to one SP. In case of several IDPs, Liberty-compliant SSOs should be able to manage IDP introduction in Liberty's terminology.

Authentication

o Support of different navigation methods between IDP / SP (hyperlinks, favorites, URL, …)

o Giving user authentication Id to the user prior to the user giving cresidentals /personal information to the IDP

o (Classical security) Confidentiality, integrity and authentication between IDP, SP, User agents [Authentication:].

o Mutual authentication between user and IDP/SP during authentication (for instance SSL/TLS).

o Mutual authentication between IDP/SP during authentication and SSO.

o Support for different authentication methods (authentication context), and identification of methods (LA does not as such specify these authentication methods) .

Authentication classes with different strengths (exchange of such information not in scope of LA)

o Authentication information exchange: status, instant, method, pseudonym (instant or persistent).

o SP requiring IDP to reauthenticate the user (possibly with stronger authentication). (Not in scope of LA 1.2). the reauthentication can be preformed by SP or IDP (depending on the risk of the service transaction, e.g. the SP may not be able to trust IDP to do reauthentication)..

o Mutual usage of authentication between different IDP’s (folloving discretion of SP).

Pseudonyms: unique per ID-federation across IDP’s and SP’s.

Support Anonymity: IDP to provide a temporary pseudonym securing the anonymity of entity.


IST Project N° 506775 02/12/2005

o Only to be generated to a single SP, not to be shared or reused (Policy/Security consideration).

Single (Global) logout: Notification to service providers when user logs out from IDP (SSO).

Note on ID: In such a architecture with a federated ID through a CoT no global Account / ID namespace is needed, since the users ID is federated through the link.

4.3.5 Other initiatives related to Identity management

4.3.5.1 MICROSOFT PASSPORT BASED SERVICE ACCESS

4.3.5.1.1 OVERVIEW MICROSOFT .NET PASSPORT

Microsoft .NET Passport is a suite of Web-based services for authentication designed to facilitate access and transmission of secure data. It aims to help make using the Internet and purchasing online easier and faster.

Microsoft .NET Passport consists of two services: a Single Sign-in service that allows members to use a single name and password to sign-in to a growing number of participating Web sites reducing the amount of information users must remember or retype, and a Wallet service that members can use to make fast online purchases.

In addition, Microsoft Kids Passport is a service that helps web sitesto be compliant with the Children's Online Privacy Protection Act, which requires that operators of online services or Web sites obtain parental consent prior to the collection, use, disclosure, or display of the personal information of children.

Microsoft .NET Passport can be implemented as a user-authentication solution for Internet applications. The .NET Passport service makes use of standard Internet technologies such as HTTP, Secure Sockets Layer (SSL), and XML. It also uses industry-standard security technologies to encrypt .NET Passport information for transmission over the Internet (i.e., when a user requests to have his profile sent to a .NET Passport participating site)

Microsoft .NET Passport provides a SDK for integrating the passport functionality into ASP.NET applications, the available documentation of this package explains the implementation process to make a web site and associated Passport site (which requires a compliance review of the site by .NET passport Services).

A lot has been said about the security issues that this technology might have and about the way it shares the information with participant sites of the single sing on. Breaches were reported that cause the information of users to be exposed, after which Microsoft corrected the flaw. Part of the industry still shows some scepticism regarding this technology. According to Microsoft, little information that users provide for a Passport account is shared with the participating Web sites. Users can control how much of the Passport profile information is shared (In fact, users can configure their Passport account to share nothing but the PUID with participating sites). However, individual sites might require additional information, which will be stored by the site itself, not in the user's Passport account.

Microsoft Passport also offers another kind of account call Limited .NET Passport, which allows the user to sign in to most .NET Passport participating sites, without requiring to provide the core profile information. No personal information is stored in a Limited Passport.

If Microsoft.NET Passport service is accessed via a mobile phone, the telephone number will also be collected for use as a sign-in name. The user will also be asked to create a PIN.

If the user registers for a .NET Passport at a .NET Passport participating site or service, that site is free to determine the personal information it wants the user to provide. The user will be opening two different accounts at the same time: one with the participating site or service and one with .NET Passport. How each .NET Passport participating site or service will use the information it collects is up to them, but the user is asked to review their privacy statement. All of the information the user provides during registration


IST Project N° 506775 02/12/2005

at a participating site may be stored by that site. However, the information described above is the most that .NET Passport stores.

4.3.5.1.2 ACCESS CONTROL

.NET Passport uses cookies whenever the user signs in to a .NET Passport participating site. .NET Passport stores the user’s unique identifier, the sign in time, and other information in an encrypted cookie on the user’s hard disk. This cookie allows the user to move from page to page at the participating site without having to sign in again on each page. When the user signs out of .NET Passport, these cookies are deleted from the computer. If the user forgets to sign out, the cookies are automatically deleted after a short time.

Getting the users' consent to access and use their .NET Passport profile information the first time they come to a site does not necessarily imply that the end user has granted the site permission to save that information. The end user may believe that the site is retaining the information only for the duration of the current session. If any particular site intends to store the user’s information, they must explicitly ask the end user for permission to save the .NET Passport profile information.

Microsoft .NET Passport participating sites should construct their code so that HTTP proxies for a user will not cache the user's personal data under any circumstances. Moreover, Digital Certificates are used to authenticate a true passport site (to avoid fake sites that would have just recorded the passport log-in and password).

4.3.5.1.3 UPDATE AND MANAGEMENT

Microsoft .NET Passport users modify their profile information and indicate which data they want to share with participating sites by using the Edit Profile page hosted by .NET Passport. If a user's profile does not contain data that a particular site needs, or if the user is currently not sharing that data, the site can display a link to the Edit Profile for the user to update this information.

From the .NET Passport site that shows all the possible changes that can be made to the user’s information, there is also a link to the Edit Profile page.


IST Project N° 506775 02/12/2005

Figure 5 .NET Passport user NET Passport site.

The Edit Profile page of Microsoft .NET Passport allows to edit information shown in the picture:


IST Project N° 506775 02/12/2005

Figure 6 .NET Passport user Edit page.

4.3.5.2 WS-FEDERATION

Microsoft, IBM and five companies that make Identity management software, (Netegrity acquired by Computer Associates, Oblix acquired by Oracle, RSA Security, OpenNetwork Technologies acquired by BMC, and Ping Identity), are working together to support a shared standard for online identities, which enables online consumers to log in once rather than every time they visit a different web site. The companies agreed to share the Web Services Architecture and WS-Federation standard for sharing user identities across corporate extranets and the Internet.

The project partners anticipate that WS standardisation will encourage the adoption of Web Services by making it easier to move user identities among different technology infrastructures, such as e-commerce sites, without having to manage different usernames and passwords and continually logging on and off.

4.3.5.3 W3C’S P3PP3P is emerging as an industry standard providing a simple, automated way for users to gain more control over the use of personal information on Web sites they visit. Basically, P3P is a standardized set of multiple-choice questions, covering all the major aspects of a Web site's privacy policies. Taken together, they present a clear snapshot of how a site handles personal information about its users. P3P-enabled Web sites make this information available in a standard, machine-readable format. P3P enabled browsers can "read" this snapshot automatically and compare it to the consumer's own set of privacy preferences. P3P enhances user control by putting privacy policies where users can find them, in a form users can understand, and, most importantly, enables users to act on what they see.


IST Project N° 506775 02/12/2005

4.3.5.4 ETSI’S UNIVERSAL COMMUNICATIONS IDENTIFIER (UCI)Refer to HFDH_17 Universal Communications Identifier (UCI) and profiles_Mike_Pluke.PPT, Mike Pluke, Castle Consulting Ltd., ETSI TC HF & STF265.

The final version of the draft for “Human Factors (HF); User Profile Management” by ETSI’s STF 265 was published in early June, 2005. The report includes an explanation of how the Universal Communications Identifier (UCI) is used via an Electronic Address Book and highlights the benefits of using UCI as detailed below.

The UCI is a single identifier for all communications incorporating fixed and mobile telephones, VOIP, fax, email, Internet/Web, Public Access Terminals, IM/SMS, videophones and pagers.

The UCI has three fundamental parts as follows:

1. A label: a user friendly description of the person/role

2. A unique numeric string: the UCI can be input from basic terminals and used in basic networks

3. An additional information field: not seen directly by the recipient but it conveys information about the sender

The UCI requires a system to handle it that does not depend on a particular technology platform. It includes:

The Personal User Agent (PUA) that contains your preferences, acts on your behalf and negotiates with other PUAs

The Service Agent (SA) that acts as the interface between a PUA and a communications network or service.

The master copy of a user’s electronic address book is held by PUA “secretary”, but this will be synchronised with all the terminal-based address books that the user accesses. The PUA “secretary” deals with communications from various people depending on the preferences set by the user. The labels of the UCIs are grouped, arranged and used for making calls and can be personalised.

If user 1 wants to contact another UCI holder (user 2) via a phone call, then user 1 makes a call in the usual way. Meanwhile, user 1’s PUA “secretary” contacts user 2’s PUA “secretary” and enquires if telephoning is acceptable. User 2’s PUA now has a variety of options. Usually the phone call will be accepted and routed to an appropriate mobile or fixed telephone. Alternatively, user 2’s PUA may route the call to voicemail or speech-to-text conversion via fax. There are numerous options available.

Presently, an email contains the senders email address, but there’s no guarantee that it correctly describes the sender. UCI enables the correct name of the sender to be seen, however they contact the receiver.

The benefits of UCI include the following:

Trust – e.g. All UCI labels and numbers registered with a trusted authority and only used by owner.

Stability – e.g. UCI remains the same even if the service provider changes.

Security - e.g. Able to request positive verification of a communication source.

Special requirements - e.g. Disability, language preferences, etc.

Simplified communications – e.g. Contacts now require only one identifier.

Automatic address book – e.g. Automatic updates to address book whenever contacted by a UCI owner. The address book can be accessed from any terminal.

Incoming and outgoing communications – e.g. Automatic rules can be applied to incoming communications since the sender is known. PUAs decide best way of delivering outgoing communications.

The first phase of the Liberty Alliance project is the establishment of a standardised, multi-vendor, Web-based single sign-on with simple federated identities based on today’s commonly deployed technologies.


IST Project N° 506775 02/12/2005

However, UCI is not targeting this domain, but focusing on person-to-person “trusted communication identity”.

4.4 Communication security inside Home Area Network

4.4.1 IEEE 802.11IEEE 802.11 [1] was first standardized in 1997. It defined a wireless local area network technology that supports maximum bandwidth of 2 Mbps, using three different physical layers: Frequency-Hopping Spread Spectrum (FHSS) and Direct-Sequence Spread Spectrum (DSSS) operating in the 2.4 GHz frequency band, and a third one operating in the infrared frequency range (850-950 nm). In addition to these, in 1999 two new physical layers were finalized:

(i) IEEE 802.11b [2] defined as an enhanced DSSS modulation scheme;

(ii) IEEE 802.11a [3] that deploys a modulation scheme called Orthogonal Frequency Division Multiplexing (OFDM).

IEEE 802.11b standard operates in the frequency range of 2.4 GHz and it is capable of 11 Mb/s, while IEEE 802.11a operates in the frequency range of 5 GHz and has a maximum bandwidth of 54 Mb/s. Further to the above improvements on the radio interface, specific task groups (TG) are working in order to enhance IEEE 802.11 with better security (TGi), quality of service (TGe), dynamic frequency selection and power control for 802.11a (TGh), an additional physical layer in the 2.4 GHz band (TGg), and an Inter Access Point Protocol (TGf).

IEEE 802.11 technology allows two different modes of operation. In the infrastructure mode an Access Point (AP) connects the radio cell (Basic Service Set, BSS) to an infrastructure network, thus forming an Extended Service Set (ESS). Each ESS has an identifier (ESSID), which aids the mobile terminal to associate to the right network. In this mode every communication is mediated by the APs, even between two Mobile Terminals (MTs) of the same cell. The ad-hoc mode (Independent Basic Service Set, IBSS) allows for the spontaneous, dynamic formation of a network, where the terminals communicate directly each other, without the mediation of an access point. The Medium Access Control (MAC) protocol in IEEE 802.11 is based on the Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) mechanism, which is an adaptation to the wireless case of the MAC protocol already used in IEEE 802.3.

4.4.2 Bluetooth Bluetooth is a technology for wireless communication. It was developed by a group called Bluetooth Special Interest Group (SIG), formed in May 1998. The founding members were Ericsson, Nokia, Intel, IBM and Toshiba. Since then, almost all of the biggest companies in the telecommunications business (e.g., 3Com, Microsoft, Motorola) have joined the Bluetooth SIG and the number of the participating companies is now over 1,500. Bluetooth has been standardized in three versions: Bluetooth 1.1 that offers communication rates of 1 Mbps; Bluetooth 1.2 that offers communication rates of 2 to 3 Mbps; and Bluetooth 2.0, which supports rates of 4, 8 and 12 Mbps.

Bluetooth can be used to connect almost any device to another device. The traditional example is to link a Personal Digital Assistant (PDA) or a laptop to a mobile phone. That way you can easily take remote connections with your PDA or laptop without getting your mobile phone from your pocket or messing around with cables. Bluetooth can also be used to form ad-hoc networks of several (up to eight) devices, called piconets. This can be useful for example in a meeting, where all participants have their own Bluetooth-compatible laptops, and want to share files with each other [13]. Some more detail on Bluetooth security can be found in Annex (9.4).


IST Project N° 506775 02/12/2005

4.4.3 Security requirements and risksWireless networks like Bluetooth or WiFi use the ISM and 5GHz frequency to communicate. At these frequencies, waves can pass the walls, doors, etc. So they can hardly be restricted in localized perimeter unlike IrDA or RFID technologies.

We can notice that the security level offered by IrDA and RFID technologies can be compared to the level of security offered by a cable: the user can check and visually authenticate which devices are getting connected through an IrDA or RFID link.

Before we go into the risks from using Wireless LANs, lets summarize the system requirements for secure communication on wireless networks.

Mutual Authentication: Before starting data communication, both the client (mobile) and the server (AP) need to be sure of the identity of the other node. This ensures that only authorized users access the network and rogue APs not hijack mobiles

Encryption: Data being exchanged between the nodes must be encrypted to ensure that an intruder cannot eavesdrop on the information.

Integrity: All data must be ‘signed’ in some fashion so that the receiving end can be sure that the data has not been tampered with.

Per-client keys: Keys must be unique for each authorized user.

Key Distribution: Key management should be a part of the protocol. Manual processes are both error-prone and subject to compromise.

Secure Handoffs: In case of centralized control, moving from one cell to another should not compromise any of the above mentioned security criteria.

Availability: means that data or services are accessible to authorized subscribers when needed and without unnecessary delay. Availability can be compromised by any Denial of Service (DoS) attack, which aims at hampering a service.

4.4.3.1 RISKS WITH WIRELESS LANS

This section describes the risks associated with wireless LANs.

4.4.3.1.1 SNIFFING

The nature of an RF based network leaves it open to packet interception by any radio within range of a transmitter. Interception can occur far outside the users ‘working’ range by using hi-gain antennas. With readily available tools, the eavesdropper is not limited to just collecting packets for later analysis, but can actually see interactive sessions like web pages viewed by a valid wireless user. An eavesdropper can also catch weak authentication exchanges, like some website logins. The eavesdropper could later duplicate the logon and gain access. Encrypting data between the STA ( Wireless STation ) and AP ( Access Point ) can mitigate eavesdropping of user data. However, the ability to sniff also makes attacks on encryption easier, and mandates requirements for strong encryption algorithms.

4.4.3.1.2 INVASION AND RESOURCE STEALING

Once an attacker has gained the knowledge of how a WLAN controls admittance, he may be able to either gain admittance to the network on his own, or steal a valid STA’s access. Stealing a STA’s access is simple if the attacker can mimic the valid STA’s MAC address and use its assigned IP address. The attacker waits until the valid system stops using the network and then takes over its position in the network. This would allow an attacker direct access to all devices within a network, or to use the network to gain access to the wider Internet, all the while appearing to be a valid user of the attacked network. To mitigate this danger the AP and STA need to support “message integrity”, which means that each “signs” every message sent to the other using a shared key.


IST Project N° 506775 02/12/2005

4.4.3.1.3 TRAFFIC REDIRECTION

An attacking STA can poison the ARP tables in switches on the wired network through the AP causing packets for a wired station to be routed to the attacking STA. The attacker can either passively capture these packets before forwarding them to the attacked wired system, or attempt a man-in-the-middle attack. In such an attack, all the susceptible systems could be on the wired network. Link-layer authentication stops an outsider from perpetrating this attack. Network-layer (e.g. IPsec) stops an insider from perpetrating this attack.

4.4.3.1.4 DENIAL OF SERVICE

Denial of service attacks against a WLAN can range from simple radio interference (a 2.4Ghz cordless phone is an example of such an attacking device) to more subtle attacks against a single STA or AP. An attacking system could replay a captured 802.11 disassociate message, or an 802.1x EAPOL-logoff message, and effectively disconnect a STA from the WLAN. It is considered impossible to build a network without some DOS attacks, thus the thrust is to minimize them and to be able to recognize and trace them back to their source.

4.4.3.1.5 ROGUE NETWORKS AND STATION REDIRECTION

An 802.11 wireless network is very susceptible to a rogue AP attack. A rogue AP is one owned by an attacker that accepts STA connections and then at a minimum intercepts traffic if not also performing man-in-the-middle attacks before allowing traffic to flow to the proper network. The goal of a rogue is pulling valid traffic from the WLAN to a wired network for attacking (or to conduct the attack directly within the rogue AP) and then reinserting the traffic into the proper network.

4.4.4 Security in IEEE 802.11IEEE 802.11 bases link security on the Wireless Equivalent Privacy (WEP) algorithm. It is a framework that defines an operation mode for the RC4 algorithm, specifying how to use the Initialization Vector (IV), how to work out a key stream and how to encapsulate encrypted information. Both encryption and authentication processes are based on WEP, which is presented in Figure 7.

The IV, which has a length of 24 bits, is concatenated to the secret key (40 or 104 bits), thus, resulting in a seed for the WEP Pseudo-Random Number Generator (PRNG) of 64 bits. The WEP PRNG is based on the RC4 algorithm. The output of the WEP PRNG is a key sequence of the same length as the text to be encrypted, given by the actual plaintext and an Integrity Check Value (ICV) corresponding to a Cyclic Redundancy Check (CRC-32) of the plaintext. Key sequence and the text to be encrypted are then ex-ored; the result of this operation is sent over the medium, concatenated with the IV (in clear). The standard specification suggests that the IV for every PDU to be sent over the air may be changed, but no clear directions are given. This means that every implementation can chose its own method.

Figure 7: WEP

IEEE 802.11 defines two different authentication methods: Open system authentication and Pre-shared key authentication. The Open system authentication method is actually a NULL authentication method, based on the transmission of the identity from the station being authenticated to the station performing authentication. The pre-shared key authentication mechanism is a challenge-response method. Station A


IST Project N° 506775 02/12/2005

sends an authentication request and its station identifier to station B, who replies with an authentication message containing a random challenge of 128 bits (see Figure 8). Station A copies the challenge in a new message, encrypts it with the shared WEP key and sends it to station B (response). Station B checks out the response and replies with the outcome of the authentication procedure. It has to be noticed that the key used for authentication is the same used for encryption.

Figure 8: IEEE 802.11 authentication exchange

The standard defines the possibility to use up to four different global WEP keys, shared by all the stations within a BSS; the same WEP keys are used for encryption and authentication by all stations in a BSS. Since WLANs assume the possibility for a station to move between different radio cells, this has led to a widely used bad practice that is to set up the same WEP key in all APs belonging to the same infrastructure. The loss of the one WEP key (i.e. the global key) thus compromises the security of the whole network (single point of risk). The standard considers the possibility to have per-user WEP keys, or better per-MAC address WEP keys, but currently only an extremely reduced number of products implements this part of the standard, because of the difficulty to administrate it.

Many flaws have recently been discovered in the RC4 algorithm as well as in the WEP framework. Fluhrer, Mantin and Shamir [4] identified a large class of weak RC4 keys, weaknesses in the key scheduling algorithm, and many flaws in the Pseudo Random Generator Algorithm (PRGA). Furthermore, the deployment of the RC4 PRGA within the WEP framework turned out to be completely insecure, made even worse by the common practice to reuse the same IV for multiple frames. Other descriptions of WEP weaknesses and how an attack can be launched have been described by Borisov, Goldberg and Wagner [5], and by Stubblefield, Ioannidis and Rubin [6], who implemented the attack and managed to discover the WEP key after 5,000,000 packets. The weak key scheduling algorithm [4] is exploited by AirSnort [6], a software tool that is able to find out the WEP key of a Wireless LAN by analysing 200 MB - 1 GB of data. By a simple passive traffic analysis attack, it gains more and more information about the key and is finally able to recover it. However, it has to be noticed that the success of this attack depends on the traffic conditions of the network: it might take several days to recover the key, and even more if all four available WEP keys are being used. Furthermore, it can monitor only one channel at any one time, which means only one AP at a time.

In addition to the above vulnerabilities, the WEP algorithm presents additional flaws that restrain its deployment in WLAN environments:

The IV is a part of the key used, which is not suitable from security point of view. Specifically, the input for the WEP PRNG is the WEP key concatenated with the IV.

The size of the IV is 24 bits (relatively small) that causes a high probability of key stream reusing in networks with high amount of traffic.

The size of WEP key (40 bits) is too small, since it corresponds to only five characters. Considering that passwords are usually chosen as ASCII strings, dictionary attacks have high probability of success.

Does not support actual integrity protection. The ICV used in WEP is a simple CRC-32, which is not keyed and can thus be obtained by anyone.


IST Project N° 506775 02/12/2005

Does not support reply protection.

The used stream cipher and the CRC are linear.

Finally, another issue concerns mutual authentication. Although mutual authentication is possible in IEEE 802.11 by repeating the same procedure twice but in different directions, it is not clearly specified in the standard specification.

4.4.5 Standard-based solutions (IEEE 802.1x, IEEE802.11i) This subsection provides an overview of the standard-based solutions (IEEE 802.1x, IEEE802.11i) that are used to overcome the security weaknesses presented in the standard 802.11 technology (previous section).

4.4.6 WPABecause of the WEP problems, the IEEE approved Wi-Fi Protected Access (WPA) as an interim solution to address those problems. WPA is an example of a software or firmware patch and does not require the hardware upgrade that 802.11i does. The 802.11i specifications provide a highly robust solution for the future but will require new hardware and protocol changes. The objective of WPA was to bring a standards-based security solution to the marketplace to replace WEP until the availability of the full-blown IEEE 802.11i Robust Security Network (RSN).

Two key features of WPA are its most significant improvements:

802.1X support: WPA uses 802.1X port access control to distribute per session keys. The 802.1X port-based access control provides a framework for mutual authentication between a client station and the AP, by including an authentication server (often RADIUS-based) and one of several possible Extensible Authentication Protocols (EAP) types. After mutual authentication, a key is derived for encryption. Since 802.1X derives a fresh key for each new session between a station and the AP, it is providing dynamic key management and replaces native 802.11 static keys.

Temporal Key Integrity Protocol (TKIP): WPA uses the Temporal Key Integrity Protocol (TKIP) to address WEP problems such as IV length and key management. There are two basic facts about TKIP:

The first fact is that TKIP does not use cryptographic keys directly. Instead, it manufactures different keys for each direction of communications over each link. TKIP accomplishes this by mixing the address of the transmitter into each encryption key, so that every station ends up with its own encryption key, even if each starts with the same key. The receiver repeats the mixing of the alleged translator into the key prior to using it to decrypt a packet received over the link. This means that every station could in principle use the full WEP IV space prior to rekeying, since no <key, IV> pair collisions result from normal use. This by itself represents a vast increase in confidentiality over WEP—on the basis of <key, IV> pair collisions alone, TKIP keys can be effective for minutes or hours instead of seconds before their use compromises the data being sent.

The second fact is that TKIP attempts to restrict access to the wireless link to authorized users. It accomplishes this by inserting a message integrity code (MIC) into each packet. The MIC can be thought of as a species of cryptographic Cyclic Redundancy Check (CRC), and it is constructed to detect attempts to forge packets. The MIC also increases the efficacy of the WEP encryption underlying TKIP, by making it computationally infeasible for an attacker to use the WEP infrastructure itself as a decryption oracle. However, this concern with authenticity opens the door to new and pressing security questions that were undecidable within the context of WEP. Being able to distinguish authorized packets from forged packets is equivalent to knowing who possesses the cryptographic keys. This means the TKIP cryptographic keys should be tied somehow to authentication, so that the parties in the communication know that received packets are genuinely authorized. That is, the use of a MIC transforms a cryptographic key into an authorization token. The use of the key to protect a message should prove that the sender was the party authorized to do so and not someone else. This linking of authorization to keying did not happen by accident; it was one of the TKIP design goals.


IST Project N° 506775 02/12/2005

4.4.7 IEEE 802.1x IEEE 802.1x [7], port-based network access control, is a way to enhance local area networks of the IEEE 802 series with increased security. It provides a framework for centralized authentication, access control and key exchange, but it does not specify any mandatory security mechanism or policy for achieving this goal. The basic rationale is to define an architecture for authentication and access control and a framework protocol where to exchange security information, but giving the possibility to use any mechanism or algorithm.

IEEE 802.1x can be used in local networks where the connection (port) between the device willing to access the network and the access point to such a network has point-to-point characteristics; in a WLAN, an association can be considered to have such features. The access point (the authenticator) is thus in charge of enforcing authentication and access control, granting or denying access to the device (supplicant) connected to the network port. The actual authentication function is performed by an authentication server, which usually is placed at a different site than the authenticator. Authentication server and authenticator share a security association, and communicate using in the normal case an Authentication–Authorization-Accounting (AAA) protocol. RADIUS [8] is a typical AAA protocol that can encapsulate authentication messages as they come from the terminal and send them to the RADIUS server, which will be able to carry on the conversation. The architecture is shown in Figure 9.

As mentioned previously, IEEE does not mandate any authentication mechanism; it defines an encapsulation technique known as EAP over LAN (EAPOL). The Enhanced Authentication Protocol (EAP) is a protocol aiming to enhance the Point-to-Point Protocol (PPP) with additional security. EAPOL defines a way to carry EAP packets in the frames of a local area network. This means that every authentication mechanism defined for EAP is available for LANs deploying IEEE 802.1x for authentication and authorization. Briefly, IEEE 802.1x and EAP represent a transport protocol for authentication information.

Figure 9: The IEEE 802.1x architecture

When a mobile terminal associates to a WLAN, the AP asks the terminal to authenticate itself. In this phase, only authentication information is allowed to traverse the port. The actual protocol exchange occurs between the supplicant and the authentication server, while the authenticator only relays and forwards authentication information. If the outcome from the authentication server is positive the network port is opened, otherwise the terminal is disassociated. Depending on the EAP method being used (not subject to negotiation, but preconfigured), it is also possible to exchange encryption keys between the supplicant and the authentication server. It is then necessary to transfer them to the authenticator, usually by carrying them in the messages of the AAA protocol being used between authenticator and authentication server.


IST Project N° 506775 02/12/2005

IEEE 802.1x represents a strong improvement to the weak security features of the IEEE 802.11 standard specifications. By introducing the authentication server, it allows to centralize authentication and authorization, thus facilitating management and administration. It is obviously still necessary for the parties involved in the authentication process to have a pre-shared key or, in the best case, a digital certificate (if a public-key encryption algorithm is used for authentication). However, if an EAP method allowing encryption keys exchange is deployed, it is possible to use a different encryption key for each user and each session and even more than one key in the same session, by periodically re-authenticating the supplicant. The deployment of IEEE 802.1x within IEEE 802.11 implies the implementation of the authenticator protocol entity and of an AAA client into the WLAN access point, the possibility to have per-user WEP keys, and the access control and filtering function in the AP. The mobile terminal must implement the supplicant protocol entity and be able to authenticate the authenticator (authentication server) if mutual authentication is being used.

4.4.7.1 802.11I

802.11i task group is the official attempt of the IEEE 802.11 group to fill the gaps in the 802.11 security framework. Work in 802.11i is currently in progress, and so far two new algorithms have been proposed for enhancing WEP encryption, the Temporal Key Integrity Protocol (TKIP) and the Wireless Robust Authenticated Protocol (WRAP) [9].

The TKIP is a new protocol that tries to fix the known problems with WEP. TKIP uses the same ciphering kernel as WEP (RC4) but adds a number of functions:

28-bit encryption key.

48-bit Initialization Vector.

New Message Integrity Code (MIC).

IV sequencing rules.

Per-packet key mixing algorithm that provides a RC4 seed for each packet.

Active countermeasures.

The purpose of TKIP is to provide a fix for WEP for existing 802.11b products. It is believed that essentially all existing 802.11b products can be software-upgraded with TKIP. The TKIP MIC was designed with the constraint that it must run on existing 802.11 hardware. It does not offer very strong protection but was considered the best that could be achieved with the majority of legacy hardware. It is based on an algorithm called Michael that is a 64-bit MIC with 20-bit design strength.

The IV sequence is implemented as a monotonically incrementing counter that is unique for each key. This makes sure that each packet is encrypted with a unique (key, IV) pair, i.e. that an IV is not reused for the same key. The receiver shall also use the sequence counter to detect replay attacks. Since frames may arrive out of order due to traffic-class priority values, a replay window (16 packets) has to be used. A number of “weak” RC4 keys have been identified for which knowledge of a few number of RC4 seed bits makes it possible to determine the initial RC4 output bits to a non-negligible probability. This makes it easier to crypt-analyze data encrypted under these keys. The per-packet mixing function is designed to defeat weak-key attacks. In WEP, the IV and the key are concatenated and then used as seed to RC4. In TKIP, the cryptographic per-packet mixing function combines the key and the IV into a seed for RC4.

Because the TKIP MIC is relatively weak, TKIP uses countermeasures to compensate for this. If the receiver detects a MIC failure, the current encryption and integrity protection keys shall not be used again. To allow a follow-up by a system administrator the event shall be logged. The rate of MIC failure must also be kept below one per minute, which means that new keys shall not be generated if the last key update due to a MIC failure occurred less than a minute ago. In order to minimize the risk of false alarms, the MIC shall be verified after the CRC, IV and other checks have been performed. Through these enhancements, TKIP tries to address all known vulnerabilities of WEP. Nevertheless, TKIP is an interim solution to support 802.11i on legacy hardware. It is not considered as secure as WRAP but very much better than WEP.


IST Project N° 506775 02/12/2005

WRAP on the other hand, uses the Advanced Encryption Standard (AES) and Offset Codebook (OCB), and its operation is based on the Rijndael cipher. It is much stronger than WEP, uses different encryption (per-user) keys for received and transmitted data, and allows an efficient parallel implementation, in both software and hardware. Furthermore, WRAP encapsulation technique provides also integrity protection of the transmitted data.

More specifically, the WRAP privacy consists of three parts:

1. The key derivation procedure. Once an association is established and a temporal key for the association is configured with the use of 802.1X, the 802.11 MAC uses the key derivation algorithm to derive a cryptographic key from the (Re)association Request and Response. This will produce the key used to protect the association data. Note that the above procedure requires 802.1X authentication and key management.

2. The encapsulation procedure. Once the key has been derived and its associated state initialized, the 802.11 MAC uses the WRAP encapsulation algorithm with the key and the state to protect all unicast MSDUs it sends to an associated station.

3. The de-capsulation procedure. Similarly, once the key has been derived and associated state initialized, the 802.11 MAC uses the WRAP de-capsulation algorithm with the receive key and state to decapsulate all unicast MSDUs received from an associated station. Once the key is established, the MAC shall discard any MSDUs received over the association that are unprotected by the encapsulation algorithm.

IEEE 802.1X may also assign a broadcast/multicast key. The implementation uses this key as configured, without derivation. The MAC utilizes the broadcast/multicast key to protect all broadcast/multicast MSDUs it sends, and discards any broadcast/multicast MSDUs received that are not protected by this key. As a final comment, please note that AES requires hardware support meaning that the majority of legacy 802.11b products will not be able to run WRAP.

4.4.8 RFID

4.4.8.1 GENERAL

Radio Frequency Identification (RFID) systems have become popular for automated identification and supply chain applications. An RFID system basically consists of transponders (tags), readers (scanners) and application systems. The tags communicate via radio signals with an RFID–Reader, which is a central component of an RFID System. The reader usually sends the collected tag data to a background application system for further processing.

As with any new promising technology, RFID is going through hype where huge expectations are created followed by just as huge disappointments. The technology fans see a sea of opportunities while others fear that the technology will affect their privacy. But what is actually all this hype about?

RFID is in its most simple form just a bar code that can be read from the distance, and some of the most obvious advantages of this technology are:

Objects don’t need to be passed individually through a laser scanner.

Many objects can be read at the same time from the same reader.

RFID tags can hold more information than bar codes and therefore users or companies can benefit from richer information.

Base on these advantages, the applications that the technology has are almost endless, like locating and tracking an individual product in real time through production, supply chain and warehouse, contactless payments, positioning, personalization and identification just to name a few. Along with all the opportunities come questions like: are people going to monitor each item I’m wearing when I enter a store? Can anyone


IST Project N° 506775 02/12/2005

read the contents of my wallet from the distance? Am I’m going to be monitored and located everywhere I go?

And the answer is no, the technology is not there either for the advantages or the concerns, but it can in very specific cases already provide a clear benefit for users and companies.

RFID systems will play an important role in the future, not only in marking and identifying objects but also in Body Area Networks (BAN), where tags can be equipped with sensors and actors and become part of a Personal Area Network (PAN) or so-called Wearable Computing. Since the tags are also used for personal identification and access control, new challenges for identity management arise. Privacy-enhancing identity management systems could provide a higher level of transparency and control for the user. Another interesting development is the Near Field Communication (NFC) protocol, which allows a simplified exchange between electronic devices based on the RFID technique in the 13,56 MHz band (please see chapter 4.4.8).

There is a large variety of different RFID systems: they may use low, high or ultra high frequencies, the transponder may emit only a fixed identifier or possess significant memory and processing capabilities. Transponders may incorporate no security features at all or realize effective security protocols similar to smartcards. Most transponders are passively powered by the radio field emitted by the reader but there are also active tags with a separate power supply.

RFID (Radio Frequency Identification) is a means of storing, and retrieving data through electromagnetic transmission to an RF compatible integrated circuit. This RFID tag or integrated circuit is usually a single solid-state memory chip.

A micro controller or PC, a reader or interrogator and a transponder or tags are the most basic components of an RFID system.

Figure 10 basic components of an RFID system.

4.4.8.1.1.1 RFID READERS

Readers or interrogators are used to identify objects by communicating with the tags using a wireless RF link. An interrogator is then used to “scan” the tag. The interrogator (controlled by some type of host computer) transmits an RF signal out to the RFID tag(s). In order for these tags to be read by the interrogator they must be presented in a defined RF area of saturation, known as an RF portal, or RF field of view. This RF signal first activates the RFID tag(s), and then interrogates each tag based on criteria received back to the interrogator from the first RF transmission.


IST Project N° 506775 02/12/2005

4.4.8.1.1.2 RFID TAGS

RFID tags or transponders are basically a source chip with an antenna. When these tags are within the field of an RFID reader or interrogator they react by sending the information stored in their memory. This information could be an Electronic Product Code (EPC) number that gives the interrogator a unique identification number for that tag, meaning that the interrogator will not only know what type of object is in the field, but it will no specifically which unique object is in the field. There are two types of RFID tags, which mainly differ in tags that have a battery and tags that don’t have a battery.


IST Project N° 506775 02/12/2005

4.4.8.1.1.2.1 Active RFID tags

Active tags have a source of power, usually in the form of a battery. The advantages of active tags are many, but the most obvious one is the ability to increase the range of read-ability through the use of an extra source of power.

Active tags can also be used to store status information like temperature, pressure, light, etc. This information can provide valuable information about the tagged objects since companies will be able to know not only where is the object at every step of the supply chain, but also how is the object handled through out time.

The disadvantage of these types of tags is the price, which makes them affordable only when the value of the data received is bigger than the investment required in order get such data.

4.4.8.1.1.2.2 Passive RFID tags

Passive tags are tags without any source of power. These types of tags use the principle called inductive coupling to transfer the energy from one circuit (such as a conductive antenna and associated circuitry) to another by means of mutual inductance between the two circuits. It basically uses the energy provided by signals sent by the reader to send a signal back with the information stored on the tag.

These tags are much cheaper than active tags and are commonly used in pallets to increase visibility in the supply chain. Although the price of these tags is considerably lower, it hasn’t yet reach the point where every single product can be tagged, but with increase adoption and economies of scale the prices of tags are expected to reach the critical price to be able to be used at item level.

4.4.8.1.1.3 RFID SOFTWARE

The last basic component in any RFID system is the software that controls the interrogators in order to synchronize when and where tags are read, filter the received data (since tags and readers communicate more than one time when they are within each others field) and gives the data meaning for business processes.

4.4.8.2 RFID IN THE FUTURE/ EPC GENERATION 2

For most of 2004 there has been a lot of focus towards the second-generation UHF standard of EPCGlobal, but there are only few people who really understand how this new generation differs from the first-generation EPC standards (Class 0 and Class1).

The biggest different between these two standards is that there is now a single global protocol instead of two (Class 0 and Class 1) that EPC previously had. The implications of a unified protocol will be that readers will be able to read tags regardless of where they are manufactured.

Another important aspect of the UHF Gen 2 protocol is that it uses the available radio spectrum more efficiently providing a better performance in Europe more than any other UHF protocol.

Finally and probably the most important addition to the new standard is that a Gen 2 reader will now be able to read active tags with sensors, which moves RFID from a pure supply chain management approach to a more general asset managing approach which includes a wider range of markets.

4.4.8.2.1 THE FACTS ABOUT PRODUCT LEVEL TAGGING

Item level is a term that usually refers to fairly small items in high volume.

Item level tagging offers far more benefits than case and pallet tagging. They include crime reduction, error prevention and brand enhancement as well as cost, service and so on. It is only with item level tagging that the consumer will clearly see benefits.

Others with their own priorities are proceeding very rapidly to trial and roll out item level tagging with excellent paybacks, usually employing the well proven 13.56 MHz frequency where the environment and production quality are less of a problem.


IST Project N° 506775 02/12/2005

4.4.8.3 RFID SECURITY

4.4.8.3.1 THREATS

The radio communications between RFID transponders and readers rises, as basically all wireless technologies, a number of security issues. Fundamental information security objectives, such as confidentiality, integrity, availability, authentication, authorization, non-repudiation and anonymity are often not achieved unless special security mechanisms are integrated into the system [17].

ConfidentialityThe communication between reader and tag is unprotected in most cases (with the exception of some high-end ISO 14443 systems). Eavesdroppers may thus listen in if they are in immediate vicinity. The forward channel from the reader to the tag has a longer range and is more at risk than the backward channel [15]. Furthermore, the tag’s memory can be read if access control is not implemented.

IntegrityWith the exception of high-end ISO 14443 systems which use message authentication codes (MACs), the integrity of transmitted information cannot be assured. Checksums (CRCs) are often employed on the communication interface but protect only against random failures. Furthermore, the writable tag memory can be manipulated if access control is not implemented.

AvailabilityFrequency jamming can easily disturb any RFID system. But, denial-of-service attacks are also feasible on higher communication layers. The so-called “RFID Blocker” exploits tag singulation (anti-collision) mechanisms to interrupt the communication of a reader with all or with specific tags.

AuthenticityThe authenticity of a tag is at risk since the unique identifier (UID) of a tag can be spoofed or manipulated. The tags are in general not tamper resistant.

AnonymityThe unique identifier can be used to trace a person or an object carrying a tag in time and space. The traced person may not even notice this. The collected information can be merged and linked in order to generate a person’s profile. A similar problem occurs in supply-chain applications where undesired product scans are possible. The automated reading of tags permits the counting of objects (e.g. banknotes with attached tags), which may be undesired.

4.4.8.3.2 SECURITY MECHANISMS AND PROPOSALS

Effective security mechanisms can provide protection against the described threats. But it should be taken into account that the primary purpose of the RFID technology is the realization of cheap and automated identification. Thus, standard security mechanisms can hardly be implemented because of their relative complexity compared with the constrained tag computing resources. AES, SHA-1 and efficient public-key protocols are too elaborate for low-cost tags. In the following, we describe implemented and proposed RFID security mechanisms.

Access Control and AuthenticationSome tags implement access control mechanisms for their read/write memory. Access to the UID is mostly unrestricted, and the strength of memory access control procedures varies a lot (e.g., nothing, clear text password, challenge-response protocol). Current RFID tags do not protect the Unique Identifier, which raises the above-mentioned privacy concerns. Some tags (in particular ISO 14443) enforce authentication mechanisms before granting read or write access to specific memory blocks. Here, either a simple password authentication or a unilateral or bilateral challenge-response authentication (e.g. ISO 9798-2)


IST Project N° 506775 02/12/2005

with symmetric keys is realized in practice. The authorization may be granular and depends on the key, which is used by the supplicant (i.e., the reader). For the forthcoming part 4 of the ISO 15693 standard a challenge-response authentication protocol with DES or 3DES is proposed. High-end transponders, which comply with ISO 14443-4, can also employ application level authentication like contact smart cards.

As a general conclusion with regards to authentication passive RIFID can serve as an identifier, but not as an authentication function.

Tag authenticationThere are also proposals for protocols, which authenticate the tag to the reader and protect against tag counterfeiting. Reference [18] proposes and analyzes several lightweight tag authentication protocols. Reference [19] proposes the Simple Authentication and Security Layer (SASL) protocol with AES encryption and analyses the hardware requirements.

Encryption and Message AuthenticationSome high-end RFID systems (ISO 14443) are able to encrypt and authenticate the data traffic with proprietary protocols. Since data exchange apart from identifiers does not play a major role for RFID systems, secure messaging is often not regarded as a key issue. Encryption of memory blocks may be realized on the application layer, which is transparent for the RFID tag. The Unique Identifier (UID) is usually read-only and many RFID transponders (e.g., ISO 15693 or 18000-3 tags) permit a permanent write lock of memory blocks. This can ensure data integrity but, of course, not message authentication.

4.4.8.4 RFID PRIVACY CONCERNS

Users are increasingly more concerned about the privacy of information, and when it comes to RFID cards or phones that hold sensitive information such as bank accounts or credit card numbers, they are afraid that a thief will be able to read the card with a mobile RFID interrogator and steal all the data stored in the card.

Such fears could be the biggest barrier for adoption of RFID based payments, and this might be due to all the negative media that has been surrounding some of the early adoptions of RFID for supply chain management like Gillette who had to cancel their RFID pilot due to a very aggressive movement towards the protection of privacy.

But the truth is that RFID payment devices offer a higher level of security than traditional payment cards. The ISO 14443, which is the standard adopted by credit card issuers (MasterCard, Visa and American Express) allows the account information on the card to be encrypted. Giving each company the possibility to use a different encryption method and keys.

Unlike RFID for supply chain management, this standard is specified for very short-range communication (in the range of 10-cm.) making it difficult to read from long distances. Even if someone is able to read the data with a specialized long-range interrogator, the attacker will still have to crack the encryption algorithms to be able to make some sense of the data acquired. The concept behind using such a such range is to guarantee that the card is read only when the user wants it to be read, just as it is today with contact or magnetic stripe cards.

When the cardholder waves the card by an RFID payment terminal, it turns the encrypted number into a digital signature, which is passed through the payment network and then decrypted to authorize the transaction. To further protect the account information, the digital signature changes each time a card is read. So even if a thief were to somehow access the digital signature, it could not be used to make another transaction.

The main challenge is therefore for card associations, banks and merchants to send a clear message to consumers that contactless payment systems are actually more secure than today’s cards if they want consumers to comfortably adopt the technology.


IST Project N° 506775 02/12/2005

4.4.9 RFID from the mobile phone through NFC The purpose of this chapter is to give a general overview of the NFC RFID technology and the role it will play when included in mobile phones.

4.4.9.1 MERGING RFID AND GSM SERVICES THROUGH SIM

One of the main purposes of including the RFID technology into the SIM card was to be able to offer an alternative for the contactless card infrastructure being installed in different parts of the world. (With the first beneficiary being contactless ticketing)

Including RFID into the mobile phone gives contactless cards the advantage of being able to be installed, updated and cancelled over the air through the services offered by GSM.

Figure 11 Merging of RFID and GSM services.

One of the biggest challenges of RFID in general is that it doesn’t work that well when it is attached to metal or glass because the radio field gets distorted. Therefore putting an RFID transponder in the heart of the mobile phone (the SIM card) is not an easy task, because the SIM card is usually placed under the battery and is surrounded by many different materials that disturb the RFID radio field.

Some proprietary solutions have been offered, but ePerSpace strongly advice to implement and follow up the NFC technology.

4.4.9.2 NEAR FIELD COMMUNICATION (NFC)

Near Field Communication is a short-range wireless technology optimized for communications between various devices without any user configuration. The goal of the NFC technology is to make to objects communicate in a simple and secure way just by putting them close to each other. NFC can also be used


IST Project N° 506775 02/12/2005

to start other communication technologies like Bluetooth and WiFi by exchanging the configuration and session data.

On April 2004 the NFC forum was establish with three founding members: Nokia, Philips and Sony with the vision of bringing the physical world and the electronic world closer together. This was not a new vision, but was rather the Auto-ID labs “Internet of Things” vision, which was brought to the consumer market. By placing tags and readers into objects, users would be able to interact with them by touching them with other NFC devices (e.g. mobile phone).

Since April until September 2005 another 44 members have joined the forum from a wide variety of industries. There are four level of membership, but the founding members remain in the same industries with the addition of VISA and Master Card who together dominate the payment market.

Without having insight from why these partners have joined the forum, one could probably guess their motivation by grouping them in to following segments:

Mobile phone providers: Nokia, Motorola, Samsung Electronics, Philips and Microsoft.

Semiconductors manufacturers: Philips, NEC, Renasas and Texas Instruments

Payment: MasterCard International and VISA

4.4.9.3 NFC APPLICATIONS

In order to emphasise the idea of close proximity, Philips (http://www.semiconductors.philips.com/markets/identification/products/nfc/index.html) has divided the NFC applications in the four following areas:

Touch and GoApplications such as access control or transport/event ticketing, where the user only needs to bring the device storing the ticket or access code close to the reader. Also, for simple data capture applications, such as picking up an Internet URL from a smart label on a poster.

Touch and ConfirmApplications such as mobile payment where the user has to confirm the interaction by entering a password or just accepting the transaction.

Touch and ConnectLinking two NFC-enabled devices to enable peer-to-peer transfer of data such as downloading music, exchanging images or synchronizing address books.

Touch and ExploreNFC devices may offer more than one possible function. The consumer will be able to explore a device's capabilities to find out which functionalities and services are offered.

4.4.9.4 THE ROLE OF THE SIM CARD FOR THE NFC TECHNOLOGY

With the introduction of the NFC technology in to the mobile phones, the SIM card takes a more important role not just for Telecom Operators, but also for payment, ticketing and SIM card providers.

When NFC functions as a contactless card, it requires a place to store critical information such as ticket numbers, credit card accounts or ID information. This storage place could be basically anywhere in the mobile phone (RAM), but since the SIM card has storage capacity and already offers a high level of security, it seemed to be an common agreement between all the companies involved in the NFC forum to use the SIM card for storage of critical and sensitive information.

The only problem is that communication between the NFC chip and the SIM card does not exist today and has therefore to be standardized. The communication between the SIM card and the NFC chip requires a high-speed transaction time in order to offer a real alternative for today’s ticketing and payment system.


http://www.semiconductors.philips.com/markets/identification/products/nfc/index.html

IST Project N° 506775 02/12/2005

Users would never accept a new ticketing solution that is not easier or faster than the already available solutions offered by contactless plastic cards.

Baseband

ISO/IEC 7816

NFC Reader SIM

This connection has to be standardized

Figure 12 standardisation to be done on communication NFC and SIM.

NFC service discovery is the concept of interacting with (tagged) objects in the real world through the use of a NFC enabled devices. The example most commonly used is that of a movie poster with an RFID tagged attached to it: when the user touches the poster with the NFC mobile phone, it can automatically download information about the movie, ring-tones, logos or even purchase tickets. The main idea is to provide easy access to information related to the tagged object.

4.4.9.5 NFC TECHNICAL OVERVIEW / ISO 14443

The ISO 14443 is the international standard for 13.56 MHz identification cards. This standard was initially designed for payment and ID cards and it was later modified to include contactless cards. This standard is most commonly used for payment and ticketing systems due to the higher security and faster communication that it provides. There are two types of ISO 14443 readers, A and B. They basically differ in speed, signal modulation, coding format and anti-collision method.

NFC is compatible with the broadly established infrastructure based on ISO 14443 A (Philips MIFARE technology), ISO 14443 B, as well as Sony’s FeliCa card used for electronic ticketing in public transport and for payment applications.

NFC devices can operate in a reader mode that allows communication with a wide variety of contactless smart cards or RF transponders (tags). NFC devices can also work in a card emulation mode, which enables NFC device to act as a smart card towards smart card readers, such as public transport and point of sale terminals.

4.4.9.6 CONCLUSION

One of the main technological advantages of a NFC is that its chip can act as reader, but it can also act as a card, and is backward compatible with the contactless card standards. Therefore it makes a mobile phone an ideal device for making payments since with a mobile phone you can control the interaction with the card, (no one can read your card if you don’t want them to), the ePerSpace operator can through mobile operator update or cancel the card remotely and is a device that users are already carrying.

The quick growth of the NFC forum plus the relevance of the players involved gives credibility to this emerging technology. Most of the actors of which ePerSpace has had contact with indicate that they are serious about their efforts towards the NFC technology and that we can expect devices to be launched with full support of their companies starting from 2006.


IST Project N° 506775 02/12/2005

4.5 Communication security in WANThe aim of this chapter is to document the available security technologies for the communication infrastructure between service providers, service and management platform and residential gateway. The supporting communication protocol is SOAP over HTTP. The network layer is IP.

Proxies and gateways (software or, preferably, security appliances) generally used to secure the access to service platforms and to secure zones may be also considered as part of the communication infrastructure security.

Additionally, we should keep in mind two other communication area:

1) Home network and associated devices that are connected through short range wireless techniques (WiFi, Bluetooth…).

2) Mobile phones and related devices that are connected through to a cellular network.

Security of wireless devices depends basically on the strength of authentication and key distribution. This aspect is further covered in annex chapter 9.1.

4.5.1 Technical assumptions


IST Project N° 506775 02/12/2005

Figure 13 ePerSpace architecture and security


Attribute Provider

GeolocationContact book…

Service and Management

Platform

Residential Gateway

Home network and residential

devices

Mobile phones

Content Provider

Application Provider

Cellular network for mobiles

IST Project N° 506775 02/12/2005

This diagram roughly depicts the ePerSpace technical architecture.

The communication between service providers, service and management platform and residential gateway is based on SOAP over HTTP. Firewalls and proxies can be deployed to secure access to the content provider platforms and to the service management platform.

Home gateway and residential devices are connected most likely through wireless communications (WiFi or Bluetooth).

Mobile phones are used to access (through the cellular network) the services of the service and management platform and to connect (through the cellular network) or directly (wireless) to the home gateway and to the home appliances.

4.5.2 Security over HTTP-based communications

4.5.2.1 THE E-PER-SPACE CONTEXT

SOAP over HTTP is the basic technology that supports the communications between Content and Services Providers, Service Management Platform and Home Gateway. Therefore, security on this leg of the communication results from: 1) the security provided by the communication stack (upper layers protocols + transport protocols); 2) the security provided by the gateways or the service platform themselves.

4.5.2.2 TRANSPORT AND MESSAGE LEVEL SECURITY PROTOCOLS

TRANSPORT

SSL (Secure Socket Layer) /TLS (Transport Layer Security) is the most widely used secure protocol for transport layer. It provides confidentiality of communication through encryption, and, at a minimum, strong Server Authentication using a Server certificate. Once the encrypted SSL tunnel is established, client authentication is generally performed through username/password mechanism.

SSL can provide strong mutual authentication using a client certificate. This option requires previous distribution of a certificate to the client, which implies that this option is possible only when clients are previously enrolled in a pre-requisite identification phase, separately from the secure protocol.

MESSAGE

OASIS Web Services security v1.0 (WS-Security 2004) describes the syntax of extensible security elements conveying tokens for provision of data integrity, data origin authentication, digital signature and confidentiality (encipherment).

OASIS stands for "Organization for the Advancement of Structured Information Standards". It is a consortium that aims at driving the development, convergence and adoption of e-business standards.

WS-Security is protocol-agnostic (it may be bound to other transport protocols than HTTP) and mechanism-independent: the crypto aspects are based on XMLDsig and XMLEncryption, the KeyInfo elements being used to convey the algorithm identifiers so as various algorithms (DSA, RSA…) could be supported without change at the WS-Security layer (this does not mean that the pre-requisite key distribution and management infrastructure would be unchanged).

WS-Security is composed of the following specifications: SOAP Message Security v1.0

Security Token Profiles


IST Project N° 506775 02/12/2005

The standard profiles issued by OASIS are:

Username token

X.509 token

Kerberos token

SAML token

SAML tokens are used to convey security assertions about the identification and authentication of remote entities. It is the reason why SAML is intensively used to support Liberty-compliant SSO.

SOAP Message Security

Insertion of tokens cannot ensure sound security if the tokens can be modified or removed between emitter and receiver of the SOAP message, since SOAP is designed so as intermediate actors can modify elements, remove elements or add new elements in a message, or even add new intermediate actors.

To ensure that such modification is not possible for malicious purposes, an additional SOAP security layer is needed. This additional layer can also provide message encryption.

SOAP message security consists of:

-Integrity protection: message body, message header or any combination of both can be integrity-protected using digital signature (XML Dsig).

-Confidentiality protection: message body, message header or any combination of both can be confidentiality-protected using encryption (XML Encryption).

WS-Security is embedded at message level as depicted in Figure 14 wsse token in a SOAP request; the use case is a request (conveyed in the body of a SOAP message) from a Web Service consumer to a Web Service provider. The wsse (WS-Security) token may contain the credentials of the requestor, or a signed authentication assertion provided by a trusted third party.

Figure 14 wsse token in a SOAP request

The wsse tokens may be unsigned (e.g. username tokens) or signed (e.g. signed assertions, certificates). If they are not signed, it is necessary to protect them from malicious modification or eavesdropping by means or additional security measures, typically SSL.


IST Project N° 506775 02/12/2005

4.5.2.3 SECURITY PROVIDED BY PROXIES AND GATEWAYS

IP or XML-level firewalls and proxies can be used in front of a service platform or to control the access to a sensitive area of the network.

Network firewalls can be used to filter the IP traffic, based on checking the consistency of IP addressing.

XML firewalls and proxies provide the following security facilities:

Secure the transport layer;

Mask internal resources using NAT and URL rewriting;

Implement XML filtering: detect and discard abnormal messages that can be harmful for parsers (e.g. huge namespace…), validate conformance to XML schemas.

Handle SOAP-level security tokens using cryptographic mechanisms and time-stamping;

Implement access control rules;

System and event logging, communications tracing (this can be used for billing purposes, and for archiving evidence in case of further disputes).

Different products are available either software or hardware. The available tests indicate that (as expected) the hardware-based XML proxies (appliances such as XS40 from Datapower or Forum Sentry from Forum Systems) are far more effective in terms of load performance and bit rate, due essentially to the hardware crypto accelerator.

4.10 Personal profile securityThis section will outline security related to the personal profile. I should be noted that more details will be published in ePerSpace report D5.4, scheduled for end of 2005.

4.5.3 Access control from end user point of viewPrivacy and security of a user’s personal information is very important in the ePerSpace approach; any identity-related services or applications – and personalisation services are key samples of this class of services – need to be compliant with the applicable privacy laws and regulations, and therefore need to put in place the security mechanisms that ensure that privacy requirements and regulations are satisfied.

The user personal profile will contain highly sensitive information and it must be ensured that access to such information is granted only to parties that have such right. Further different levels of privacy may apply to different information elements, accordingly different privacy policies must be applied and ensure that such policies are applied.

User requirements with regard to access to the personal profile may be divided into two main categories:

User access to profile;

Access by other parties.

Requirements in the first category are to ensure that security mechanisms are as far as possible transparent to the user, and that access to the information is granted following the policies set by the user; requirements in the second category are to ensure that access by unauthorized entity is prevented and that the correct privacy policies are applied to authorised entities.

The first category of requirements is covered by SSO. When entering the ePerSpace system the identity of the user is checked and access is granted to all the subscribed ePerSpace services, including the personalisation services and access to the user profile. It is expected that the user will have full access rights, however it must be possible, if the user so wishes, that additional security is applied for accessing the more sensitive data. Additional control may also be required by the user for any application that requires/implies modification of the personal profile data.


IST Project N° 506775 02/12/2005

4.5.4 Access control mechanisms for accessing parts of personal profile

To allow personalization of services, service providers, content service providers, and other parties will access the user’s personal profile managed by the Personalization Engine, in order to obtain user’s interests, context information, identity information, etc. The location of the User Profile is never known by the calling parties, they don’t care to know anything but how to request personalization information to the SPOE via the GSeM.

In order to control the access to the different information in the profile the ePerSpace user will assign specific access rights to each SP (at the moment of a service subscription) following a Role Base access model; in other words the user will select a role for a SP; this information (mapping between roles and service providers) is stored in the GSeM Database.

Each SP that wants to access/update the profile will contact the GSeM which will forward the request to the SPOE. Before forwarding the request, the GSeM will assign a role to the calling service (since a mapping for roles/services is stored in the GSeM global Database); this role will later determine the operations the SP can perform towards the profile.

The SPOE will contact the correspondent Personalization Engine, passing the service’s role and the userId as parameters. The Personalization engine will query/update the UserProfile, first checking (internally) the access rights for the calling role and returning appropriate results. For instance, a query to get the whole of the UserProfile will return only those parts of the profile that the calling role has access to. In the case of updates, if the calling role doesn’t have the right to perform an update in the profile, the update will not occur.


IST Project N° 506775 02/12/2005

CSP: GSeM: SPOE: PersonalisationEngine:

getProfileInformation(UserId, XQuery, SPId)

XMLProfileInformation

AuthenticateSP(SPId)

mapRoleToSP(SPId)

roleName

getProfileInformation(UserId, XQuery, roleName)


findRightPersonalizationEngine(UserId)

PersonalizationEnginegetProfileInformation(UserId, XQuery, roleName)


validateAccessRights(UserId, roleName)

PermissionsperformQuery(userId, roleName)


Figure 15. Access to personal profile elements

The management (access, update) of the personal profile is provided by an API exposed in the Personalization Engine and overwritten in the SPOE, following a façade pattern, since the profile information of a User might be in one of several Personalization Engines.

2 basic APIs or set of methods to manage the User Profile have been defined: a GenericAPI and a HelperAPI which are deployed as Web Services in the personalization engine. Therefore a web-service based security over the network should be implemented. This APIs centralize the access to the profile, regardless of the way in which it will be distributed.

The GenericAPI aims to provide access to the UserProfile, through methods to retrieve the whole document and parts of it by specifying an XQuery, and update methods by specifying an XUpdate xml document (in the form of a String) which will contain the changes to be made to the XML based User profile.

The HelperAPI aims to provide access to specific parts of the UserProfile that can be requested by services in a regular basis to satisfy the requirements of some of the scenarios, e.g. getting the user interests, getting the IdentityProfile of the user (or basic information of the User), getting a PhotoIndex (Collection of the User’s photo storage) without the need to specify

4.10.1 Data protection Data in the User Profile is protected by:

Secure network communications and;

Appropriate and effective access control of the data held in the profile.


IST Project N° 506775 02/12/2005

The purpose is to ensure the user’s data is protected during transfer and that only the entities with appropriate rights will access certain user profile information.

Secure network communications between components accessing profile information are essential to ensure the integrity and confidentiality of the user’s profile data, which include very sensitive information such as Identity details of the user, Interests, etc. Within the ePerspace platform these nodes include the Personalization Engine, the SPOE, the GSeM and third parties such as CSP as depicted in figure 15 shows the network traffic of sensitive user’s profile data along the different components of the ePerspace platform in each direction, i.e: during requests of personalization information or updates to the profile done by SP or the user himself. To support the confidentiality of the messaging between the different components SSL is used in order to encrypt the data which travels along the network. This mechanism can provide sufficient security for a range of uses of web services today

As a first security point, network firewalls are used in front of the Personalization Engine and SPOE to filter the IP traffic, allowing requests only from the right component; Personalization Engines are accessed by the SPOE and any call to the SPOE should be coming from the GSeM on behalf of any other third party.

Access to users’ profile information is provided as web services exposed in 1 or more Personalization Engine with the SPOE acting as a single façade for other entities also using web services to expose its functionality, allowing interoperability between the components.

The supporting communication protocol for web services is SOAP (normally over HTTP) which makes it possible to incorporate transport protocol security mechanisms like SSL, in order to avoid messages from travelling as plain text across the network. Indeed, to provide a level of web services security SOAP communications over SSL are used to exchange information between components. This ensures the privacy of the SOAP messages (which will contain XML extracts of user profile information) by decrypting and encrypting them as they are received and sent, respectively. This encryption assures that only authorized parties are able to understand the data being passed, even when others may know of its existence.

Other security mechanisms (on the message level) such as XML Encryption can be used on top of SSL to provide other features, such as encrypting just a piece of the user’s profile information being sent within the SOAP message (XML extract), ie: a particularly sensitive piece of the user’s data. WS-security, which aims to standardize security mechanisms at the message level (also trying to trying to address some of the limitations of only using transport level mechanisms like SSL) include other specifications such as digital signatures, tokens, and so forth.

Also, SOAP messages (request and responses) are logged in both the SPOE and the Personalization engine, including details as caller identity; time of request and the data exchanged and can be revised for quality purposes.

Regarding Access Control, each part of the profile will define the access right of each role. This can be overwritten by a subsection of it; allowing an inheritance model. For instance, the permission to read “News” for the “non-trusted” party can be defined to “no”, overwriting the permission given for the general section “Interests”, assigned to “yes”. This is to allow a bit more flexibility in the way each provider accesses the information in each section of the profile.


Personalisation Engine

SPOE

GSeM/GSeP CS/ Third Party P

Figure 16. Traffic of profile data.

IST Project N° 506775 02/12/2005

When the user profile is newly created, only the “owner” role will have permission to perform every operation towards the profile (“read”, “write” and “update”) and these permissions will be stored in the AccessControl node under the root element.

Figure 17 access controls within profile


IST Project N° 506775 02/12/2005

5 Authentication implementations in ePerSpace

This chapter documents the implementation work of authentication in HAN and elsewhere. This can be considered as a building step towards an implementation of SSO within HAN and elsewhere. It should be noted that this is a “snapshoot” of the current implementation status (November 2005), and that some further implementation details will be documented in the upcoming release of D3.3 and D5.2.

5.1 Global Authentication & Authorization Services utilizing the GseM

The EPS environment has a service management platform to handle customers, providers and operators (Global Service Manager - GSeM) and to support service delivery (Global Service Provisioner - GSeP).

The GSeM, provides user interfaces (or portals) for customers to subscribe and invoke services, for providers to register and offer their services and for operators to manage customers, providers, residential gateways, services, etc. GSeM is implemented using J2EE and Web Services as a built as a multi-layer architecture with separate presentation, business and data layers.

GSeM handles data of customers, residential gateways, services and providers in an ORACLE database. GSeM also manages services profiles, which describe particular services and used together with user profiles in personalisation. More information can be found in D6.2 and D6.3.

The GSeM functions as a central access point for customers & users, service providers, services and system operators. This functionality makes the GSeM an ideal repository for the storage of credentials such as IDs, usernames and passwords. The information in regards to security subjects such as users for example, is stored in the GSeM-DB in the form of tables and records. For each user, service provider and a system operator there is an associated ID, username and a password. The username and password fields are created by the user, whereas the ID field is generated automatically when a new entry is created. For example, when a customer adds a new user, a new record is created in the GSeM DB with the required fields. Since the ePerSpace platform supports multiple authentication methods (such as the Form-based, RFID, SIM-based and Fingerprint) it is required to be able to integrate all these methods in a uniform way in order to support a global authentication into ePerSpace. The Figure 18 - Secure Context inthe GseM presents the architecture for the secure context in ePerSpace. The GSeM Business Logic Layer (BLL) contains a remote method, which is accessible as a Web service for authenticating a security subject.

As the Figure 18 denotes, this method is used by the RFID, SIM and Fingerprint authentication methods using the terminal proxy. The terminal proxy is in charge of sending the user’s credential (i.e. username and password) over the network into the authentication handling code at the Business Logic Layer. The handling code queries the GSeM-DB for a corresponding ID for the username & password provided. The user is proven to be authenticated if a corresponding ID is found. The ID is then returned back to the handling code which stores the ID in a session context and redirects the user to her personalized area in the portal. If a corresponding ID is not found, the GSeM-DB returns a null value, and as a result the handling code raises an exception that a no corresponding user is found. In order to support username & password authentication method, a login form is available under the GSeM presentation layer. Once a user submits the form, the request is submitted to the same handling code which handles the other authentication methods. Once an ID is returned from the GSeM, it is possible to query the role of the particular subject which performed the authentication.

In a role-based solution such as a GSeM access to resources is controlled by a role specification. The GSeM defines the following roles: USER, CUSTOMER, OPERATOR and a SERVICE PROVIDER For example, when a customer is logged into the portal certain features will be made visible on the screen which otherwise would be hidden (such in the case of the user). Using the Role-based approach it is convenient to perform decision-making and control the visible parts of the UI based on the role. In various scenarios it is required to access the user profile via the personalization manager. In order for a user to


IST Project N° 506775 02/12/2005

manage the user profile, the ID from the GSeM is sent along with the request to the personalization manager where mapping is performed in order to allocate the required profile. The service profile schemas defines a different roles from the roles defined by the GSeM in order to support who is granted to access to which segment of the profile. For example, a trusted Service provider can view parts of the profile, which he may view or alter. On the other hand a non-trusted service provider will be denied an access to that particular part. In order to support the confidentiality of the messaging between the different components SSL is used in order to encrypt the data that travels along the network.

Figure 18 - Secure Context in the GseM

5.2 Local Authentication (RG Based)Local authentication in the ePerSpace architecture is considered a key issue due to the fact that services created in the project focus primarily towards the residential user being at home and having an advanced infrastructure that will allow the deployment of a wide variety of services in this environment. Local services are thus considered together with services that are offered by third parties through the Internet (Service providers). Therefore in the home arena, there is a need of including security for the user when he tries to access the ePerSpace services.

The approach taken by the project is based on the infrastructure that is applied and that has been defined in Workpackage 2 [D2.1]. It permits the deployment of networked infrastructures at home easily by installing new Bundles on a Residential Gateway that handles and centralizes the communication between the HAN and the WAN. Therefore one of the most important responsibilities of the RG is the implementation of security mechanisms to secure the communications within the home and to the outside. Local Authentication will be thus managed by Middleware on the RG and by authentication means that are


IST Project N° 506775 02/12/2005

to be deployed in the home using the HANs to communicate to the RG (normally readers will be used that will be connected to the RG).

Moreover it is important to pinpoint that Local authentication will be harmonized with the global architecture and principles of the architecture referenced above. All players in the architecture will identify the user in ePerSpace in the same way. Therefore the UserID will be the same at the local level and on the Management system for example. The Middleware developed will insure the secure handling of the above user identity. Moreover, users at home, when authenticated at the local level, will be able to login into the GseM seamlessly.

In the following sections, the Middleware architecture and functionalities will be described for the local authentication together with a description of the physical means that will be supported within the HAN.

5.2.1 Local Authentication Scenarios (RG Based) The authentication scenarios that will be supported for the trial 2 of ePerSpace are summarized below:

The user accesses his home platform physically (e.g. using an electronic key at the door) and only some personalization features of the environment are to be performed. For this he uses the electronic means described below. He is not connected in the HAN through a terminal and is not interacting with the local portals resident on the RG.

The user wants to access the local services of the Home Platform through a terminal. He then can choose to authenticate automatically, through one of the electronic identity means or manually (User name and Password), or for further strength a combination of these.

The user wants to connect to the GseM directly via his Laptop and can choose between a manual authentication means or a semi-automatic one by letting his mobile and Laptop do the job for him. The Authentication means stored on the mobile phone’s SIM is passed via Bluetooth to the PC and from there accesses the GseM on the Web by providing automatically the needed parameters.

5.2.2 Local Authentication Requirements The Home Platform that was already integrated in the first trial of ePerSpace at T0+12, incorporated the use of an RFID tag to identify the user. The latter is operating as an electronic key in order to open the door and start some personalization actions in the home: ambient creation by switching on or off appliances attached to the home automation networks, send messages to family members for example, etc.

Now, in the second phase of the trials in ePerSpace, there is a need of providing local authentication means to the user that is accessing the local services or wants to log into the Management system. So as a starting point, the local authentication solution will have to accommodate and incorporate the principles applied to the user identification up to now as far as possible and define the needed modification or enhancements of the available middleware.

First, a description of the latter infrastructure applied for the first trial is presented and the possible migration of the latter architecture to encompass local authentication functionality in the second trial is defined.

The identification means used in the trial1 (RFID) were integrated to the Home Platform just as another home appliance or device (Figure 19). The RFID tag needs a reader that communicates with the associated RG to convey the user Identification information.


IST Project N° 506775 02/12/2005

Figure 19 identification means in HAN for trial 1.

The middleware blocks that are used within the RG OSGI Middleware to support the identification means in Trial 1 are listed together with the OSGI framework blocks that are relevant in order to tackle the personalization and notification services upon the identification of a given user:

1) The Driver: It provides the communication commands that are needed to operate the Tag reader and get the information from the tTag.

2) Access Management: This is the bundle that gets user tag information from the Driver and checks if the Tag is a valid one. This block needs a configuration process that provides the necessary means to link a physical tag information to a given ePerSpace user.

3) Personalization: This is responsible for initiating all personalization actions in the home. For trial 1 the Home automation operations are performed and, furthermore, also the Personalization block can trigger notification mechanisms such as sending an SMS to another user (for example a parent that wants to get an SMS whenever one of his children comes home).

4) User Admin: This is an OSGI standard component where the information of the users can be stored and be processed by other bundles.

5) Configuration Admin: This is also a standard component of the Framework where infrastructure information can be stored in such a way that the other software bundles can use the information to perform services.

6) Device Manager: This is the Bundle that builds up the ePerSpace device community. It performs three basic operations: Device Addressing, Device Discovery and Device Description. The Device manager functionality is currently being designed, and will be documented in D8.5. Also, it is important to stress the fact that it registers all device services in the OSGI registry in such a way that other bundles can use them.


IST Project N° 506775 02/12/2005

OSGi framework

OSGi Registry

Configuration Admin

RFIDreader

DRIVER

Access Management

Personalization

RS232

Doorlock

LON, EIB, etc...

Lights Other devices

DEVICE MANAGER

NOTIFICATION

User Admin

RESIDENTIAL GATEWAY

Figure 20 RG outline

The solution described above only tackles the physical access control of an ePerSpace user and provides the middleware blocks ability to perform personalization actions in the home platform.

An analysis had to be done of how the above architecture could be enhanced in order to implement authentication within the Home Platform of ePerSpace for Trial2.

The Access Management block will evolve to a Local Authentication Manager. This will again be in charge of registering the users that are allowed to access the Home Platform.

Further authentication means will be incorporated: Another RFID that is compliant with the NFC (Near Field Communication) standard, Smartcard authentication via a PC, Doorkeeper authentication and Mobile Phone-PC authentication. The latter are explained in detail in the following sections. To be able to handle them, drivers will be incorporated in the Middleware platform that will interface the mentioned means to the authentication manager.

A Terminal Manager will be needed that will take the responsibility of handling the HTTP requests and accesses from any terminal on the Home Platform. The Terminal Manager is explained in detail in D8.5. As soon as a user wants to access the Local services through a terminal, the Terminal Manager will then ask the Authentication manager to authenticate the user through one of the authentication means listed above.

In order to handle authentication in a consistent way throughout all elements of the global ePerSpace architecture, a local authentication bundle is provided in order to register the ePerSpace user information (User ID, User Name and User Password) on the User Admin OSGI service to access the ePerSpace “world”. This bundle is described in detail in deliverable D6.3.

In the figure below (Figure 21) a revised architecture is presented. The blocks that are incorporated in order to implement the local authentication are highlighted with dotted lines, In this way a clear evolution of the Middleware can be observed from the trial 1 down to the trial 2 Middleware architectures.


IST Project N° 506775 02/12/2005

OSGi framework

OSGi Registry

Configuration Admin

RFIDreader

RFID-NFC/Smartcard

/PC

ICODE DriverNFC/PC Drivers

Local Authentication Manager

Personalization

RS232 Ethernet

Doorlock

LON, EIB, etc...

Lights Other devices

Doorkeeper

Doorkeeper Driver

Device Manager

Notification

GSeM

User Admin

Local Authentication Bundle

Ethernet

TerminalManager

SIMCARD-PCDriver

Mobile+PC

Ethernet

RESIDENTIAL GATEWAY

Figure 21 revised architecture for RG with authentication.

5.2.3 Local Authentication Manager High Level SpecificationFrom the above section all related developments that will be needed to implement the local authentication in ePerSpace were identified. Now (following a layered model) the Local Authentication Manager is placed in such a way that clarifies its relation to all layers in the Middleware platform designed in ePerSpace (Figure 22).

DEVICE MANAGER

Discovery bundles:uPnP,ad- hoc, ETC

TERMINAL MANAGER

LOCAL SERVICES IMPLEMENTATION (Control Points & Java)

Authentication Manager

SERVICES UI

MANAGEMENT BUNDLES ( Authentication, Communications, Soap, ect.)

Access

Addressing

Control

Presentation

Management

Devices & NetworksBundles

Figure 22 layered model of local authentication

The Authentication Manager will be in close cooperation with the readers drivers presented in the section above. The block will process the tags for authentication inherent information. Furthermore, it will check if the tags and user information are valid and are declared through the configuration process that is described later on. The API to connect to the readers will be the same for all reader drivers. In this way new authentication means can be easily integrated in the system.

The following Authentication means will be supported:


IST Project N° 506775 02/12/2005

Doorkeeper,

Icode and NFC RFIDs

Smartcard linked to a PC

Mobile Phone SIMCARD linked via Bluetooth to a PC

Manual Authentication

Following some policy enforcement the Terminal Manager or ePerSpace services platform should be able to ask the manager to proceed with an authentication check, but in first implementation (as a minimum pre-requisite), the Authentication manager will be able to respond to a request of authentication with the ePerSpace userID.

Now, an important process that needs to be implemented is the one that relates the authentication means and the user data on the user administration service of the OSGI framework. This process will be considered as the configuration process for the Authentication Manager that will have to be implemented by the installer or an advanced user. The process is as follows (please refer to the attached diagram below that somehow simulates the user interface):

The configuration page will present a list of users of the Home platform. It will be possible to select one user and present his identity and the authentication means configured and if active. If the operator wants to activate one, he chooses one of the possibilities. The Authentication manager will meanwhile wait for a reader and related driver to send a tag identification. The latter will be assigned to the user being configured. The Authentication manager will have to implement a method to get the list of ePerSpace users from the OSGi User Admin bundle. In this way the users that are authorized to interact with the Home platform are defined. Typically, this will be an installation procedure, but the same functions will have to be available to the home platform user in an advanced configuration mode to handle changes.

AUTHENTICATIONMANAGERCONFIGURATION

LIST OF USERS

AUTHENTICATIONMANAGER

USER’s INFORMATION

Name: PeterAuth Means:

RFID 0x00FAA01 CardNFC not configured

Search

SelectUser

AssignCardToUser( userID, means )

Peter inserts or placestoken near reader

CONFIGURATIONADMINOSGi

USER ADMINOSGi

assign token to userID

userID, name

userID, nameadditional info

0x00BFF02

OKRESULT

Peter’s NFC code is 0x00BFF02

Back

Figure 23 authentication means and the user data on the user administration service of the OSGI framework


IST Project N° 506775 02/12/2005

5.2.4 Authentication Means Descriptions

5.2.4.1 RFID ICODE

The I-CODE protocol is a development in the RFID field (please see chapter 4.4.8 for more details on RFID). The I-CODE tags are designed to provide a low cost and high performance solution that can be used in any identification field. The following are features of I-CODE devices. • Passive Tags. They get their operating energy from the electromagnetic field generated by the reader

device.• Long range system. It is possible to operate at up to 1 meter.• Medium operating frequency. 13.56MHz• Read/Write tags. Up to 106 write operations.• 512 bits memory capacity. Higher capacities in the future.• Anti-collision protocol. It is possible to read a theoretical maximum of 32K tags in the same RF field.• Low cost tags.• For retail or distribution applications, the device includes some special functions: EAS (Electronic

Article Surveillance), a anti-theft bit that can be detected and give an alarm in the reader device, and QUIET, to put a tag in «sleep» state, for instance, after the goods on which it is fixed is sold. Both bits can be activated and de-activated many times.

Below the basic elements that configure an I-Code system are explained:

READER/ENCODER

A reader is the device that, by means of one or more antennas, establishes the radio link with the tags that are in its reading field. It also decodes the data received from the tags. The data comes from the embedded memory in the tags in some cases the reader device can also write data to it

There are different type of reader/encoders, depending on the application where they are to be used. The RIDEC5000 is a short range and low cost I-CODE reader/encoder used in the ePerSpace project.

ANTENNA

The antenna is the transducer that generates the electromagnetic field needed to supply the power to the transponders in order to generate the flow of information between the reader and the tag.

TAGS

The tag is an element including an electronic device and an antenna, both mounted on a base material. It can be compared with Smartcard (comprising processor, ROM and RAM,) equipped with an antenna. The antenna is both used for powering (induction of the coiled antenna) as well as conveying the information bits. In our case, the RFID is denoted as “passive”, and can only operate at small ranges (in contrast to battery powered “active” RFIDs. Passive tags will after initiation always return the same signal, and is therefore vulnerable to cloning.

5.2.4.1.1 PROTOCOL

The Protocol is an ASCII serial protocol. It uses 8 bits, no parity and one stop bit without handshake at 9600 Baud. A CRC byte is transmitted if a RS485 interface is used.The continuous read command is used to configure the RIDEC5000 reader/encoder for continuous reading of the tags near the reader antenna. The command ask the reader for the block number (hexadecimal Number). In the absence of a Tag, no information is received. If a hexadecimal number is read, ranging from 0x20 to 0x3F, then a Tag is in the vicinity and the reader will wait for the information field to be transmitted.All Icode RFID cards used in the system should be first registered in order to associate the card serial number with a given user (in the case of ePerSpace). The drivers of the reader used will obtain the serial number that is afterwards associated to a user.


IST Project N° 506775 02/12/2005

The 64 bits serial number is unique and is stored in blocks 0 and 1 of the embedded memory. Below a memory map can be seen (Figure 24).

Figure 24 Icode RFID memory map

The authentication process using this technology will be as follows on step by step basis:

- The RFID reader detects the smart card,

- The drivers of the reader used will obtain the serial number. The RFID Icode Bundle Driver send the serial number to the Authentication Manager,

- The Authentication Manager checks the serial number against its configuration information, If the serial number is known then the authentication is positive and is ready to send the information of the user to any bundle that is waiting for the user information.

- The Authentication Manager notifies that user has entered the home to the personalization Bundle.

- If configured, Automation actions will take place in the Home Platform.

5.2.4.2 RFID NFC

An NFC mobile phone has the possibility to act as an RFID reader and as an RFID tag as shown in the figure below. This proposal focuses on the possibilities of using the mobile phone as an RFID card (tag) and has therefore many similarities with the proposal for RFID authentication explained above.


IST Project N° 506775 02/12/2005

Figure 25 NFC/RFID

Some of the biggest benefits of using an NFC mobile phone for such a solution are that it usually can be combined with already established RFID infrastructure, but has the added advantage that the cards can be updated remotely via the GSM infrastructure. Using SMS messages to write and read on an NFC mobile phone could prove useful when a user wishes to share his/her access for a short period of time, for example: if a family member was going to meet me at home, but I haven’t arrived because I am stock in traffic, I could just send an SMS message to the NFC mobile phone and access will be granted for just that phone in the next couple of hours.

The authentication process is identical to the one already listed in the previous section.

5.2.4.3 BIOMETRIC AUTHENTICATION IN THE DOORKEEPER

The Doorkeeper is a service composed of several elements enabling the connection of visitors with members of a household, wherever they might be located. The service uses a terminal at the front door connected to the residential LAN with call buttons and a digital camera, this terminal is allowing visitors to initiate a call whether locally if the person to be contacted is inside the house or remotely to GSM phone for example if the person to be contacted is away. Moreover, the Doorkeeper is integrating a biometric fingerprint reader to authenticate residents and/or visitors with the aim of opening the door if the person is recognized.

The authentication chosen for the doorkeeper is the fingerprint checking. This method has been chosen because it provides a strong authentication which is needed when we consider the critical function controlled: opening a house door. Two different means of fingerprint authentication are included: one is considering a fingerprint reader included in the Doorkeeper terminal at the front door, the second enables to use a PDA with a fingerprint reader embedded to authenticate the user.

Scenario for biometric authentication with a PDA: Note that prior to this scenario the user should have registered his fingerprint on his PDA. A small application has been developed enabling this functionality.

Note also that to ensure data integrity in the process the wireless communications between the PDA in the LAN must be secured with a WPA or WEP key.

Here are the different steps of the authentication :

The Doorkeeper (bundle Driver PDA) detects the PDA via Wifi

The PDA asks the user to put his finger on the PDA fingerprint reader

The PDA checks the fingerprint and notifies to the Doorkeeper that the user has been authenticated

The Doorkeeper notifies the Authentication Manager that the user has been authenticated


IST Project N° 506775 02/12/2005

Scenario for biometric authentication with a fingerprint reader at the door The operation is similar for the reader on the door with the difference that the Doorkeeper terminal sends the result of the authentication:

Here are the different steps of the authentication:

The user is asked to put his fingerprint on the reader at the door front

The Doorkeeper checks the fingerprint

The Doorkeeper notifies the Authentication Manager that the user has been authenticated

The Doorkeeper, as all the local authentication means, will be linked to the Authentication manager in the same way as the RFID readers: A bundle will be driving the Doorkeeper and as soon as a user is authenticated via the Doorkeeper it will send a userID to the Authentication manager that will have to check if the user is recognized as part of the internal “database”.

The Doorkeeper will also implement a “OSGi lock” interface so as to be treated as a doorlock. When the Authentication Manager receives an authentication token from the Doorkeeper, it will first verify the validity of the token (is the user authorized to enter ?) and warns the Doorkeeper that it should open the door.

5.2.4.4 MANUAL (USERNAME PASSWORD)

The Manual Authentication will be also available. This will be implemented through the GUI of the Terminal Manager. When a user via a terminal is accessing the local services, the Terminal Manager will redirect the user to the authentication HTTP pages resident on the RG. Here the user may choose to provide manually the username and the password. The scenario is below represented (Figure 26):

Residential Gateway

HomePlatform

STB BundlesHAN

Authentication Page

Welcome to ePerSpace

ACCESSPORTAL

LISTRFID1RFID2

User/passwd

Figure 26 manual authentication in HAN

5.2.4.5 SMARTCARD-PC

Thanks to the greater possibilities of the Smartcard cards with respect to other types of authentication means, mainly due to their processing capacity, the security mechanisms are more advanced and can rely on PKI infrastructures. That is why it was decided to include this authentication mechanism in the Home platform. In this case the smartcard reader will be linked to a PC. This is done so in order not to overload the Residential Gateway with extra-processing needs.


IST Project N° 506775 02/12/2005

A PC Middleware will be responsible for the authentication process using advanced challenge and certificate mechanisms and as soon as the smartcard is recognised as a valid one, the PC Middleware will contact an ad-hoc driver that will signal the Authentication bundle in the same way as it is done by the other RFID readers or the Doorkeeper drivers.

Residential Gateway

HomePlatform

STB BundlesHAN

Smart cardReader

Figure 27 Smartcard-PC authentication in HAN

The proposed mechanism is based on a public key infrastructure.

The driver in charge of the Smartcard based authentication, to be integrated within the access control architecture in the ePerSpace environment, will consist of two software modules (one on the PC and one bundle on the RG as stated above). This structure will allow having the Smartcard reader connected to any PC at home.

One of the modules, the one that will run on the PC, is in charge of the communication with the reader/card. This communication is based on a PKCS#11 implementation. This standard specifies an API, called Cryptoki, to devices, which hold cryptographic information and perform cryptographic functions. Cryptoki follows a simple object-based approach, addressing the goals of technology independence (any kind of device) and resource sharing (multiple applications accessing multiple devices), presenting to applications a common, logical view of the device called a cryptographic token. It allows working with a greater level of abstraction not having to worry about the communication driver to the cardlet at APDU level, as standard functions can be used.

The other module will be deployed in the residential gateway as an OSGi bundle, and will be the one in charge of implementing the "challenge" function for the user authentication, in agreement with the described protocol. When a correct authentication takes place, it will send the Tag number of the person who was authenticated to the Authentication Manager.

The fact of dividing the driver in two separate modules does not harm the security, since the first module is only an interface between the challenge and the Smartcard. As soon as the user has presented a digital certificate(a valid certificate signed by a certification authority, that associates the user with a public-key) and has demonstrated to be in possession of the private-key corresponding to that certificate (he makes use of this key, stored in the card, to generate a random number for the implementation of the challenge). This private-key is kept in the Smartcard, and can only be used by the person who knows the PIN.

The process that will take place between the smartcard and the software module on the PC can be summarised by the following list of actions:


IST Project N° 506775 02/12/2005

Action 0: Inserted card. Action 1: Show on the PC the user interface asking for a PIN. Action 2: Request the PIN Action 3: Verify the PIN. Action 4: Obtain the certificate stored in the card. Action 5: The certificate is sent to the PC Software client. Action 6: Invoke a card session. Action 7: Verify the validity of the certificate. Action 8: Generate a random number in order to implement the challenge. Action 9: Encode the challenge with the public key of the obtained certificate. Action 10: The ciphered challenge is sent to the Smartcard. Action 11: Decipher the challenge with the private key. Action 12: Verify that the challenge is the correct one. Action 13: Check certificate Action 14: Sent to the Authentication Manager the Smartcard identifier. Action 15: Extract the card.

Once the verification is done, using the proposed protocol, the user can be authenticated by the Home Platform via the Terminal Manager to access the local services and the personalization actions can be performed.

5.2.5 Local Authentication with SIM cardThis part of the document describes an authentication service that is allowing a local authentication using a SIM card of a mobile phone for storing securely the authentication data. This section mainly focuses on the integration of this authentication means to the Authentication Manager.

The proposed mechanism is based on the access to the SIM card located in a mobile phone. This service allows to store in a SIM card of a mobile phone the login/password associated to the ePerSpace portal and to locally authenticate a user via the Authentication Manager.

The mechanism in charge of the SIM card authentication, to be integrated within the access control architecture in the ePerSpace environment, will consist of two software modules (one on the Mobile Phone and one bundle in the RG). The first module in the mobile phone is in charge of accessing to the data that are stored in the SIM card. The mobile phone will be linked to the RG via a Bluetooth connection.

The other module will be deployed in the residential gateway as an OSGi bundle. This bundle will serve a an driver for the authentication means and will be the one in charge of implementing function for the user authentication, in agreement with the described protocol. When a correct authentication takes place, it will send the login/password of the person who was authenticated to the Authentication Manager.

The process that will take place between the mobile phone, the Authentication manager and the SIM card authentication driver is described below. This sequence takes place after the user has chosen the SIM Card authentication:


IST Project N° 506775 02/12/2005

Figure 28 local authentication with SIM card

Step 1: The authentication manager asked the user the mobile he will use for his authentication Step 2: The user selects of a mobile


OSGI Framework

Authentication Manager

SIM Card Authentication Driver

Residential GatewayChoose Mobile:Mobile XMobile Y

1

2

3SIMPass cardlet

PIN code: ****

4

5

6

IST Project N° 506775 02/12/2005

Step 3: The driver checks if the mobile is present Step 4: The driver requests the PIN code to the user. Step 5: The driver presents the PIN code given by the user to the SIMPass cardlet . Step 6: the driver obtains from the SIMPass cardlet via the mobile phone Step 7: the driver sends back to the Authentication Manager the login/password

Once the verification is done, using the proposed protocol, the user can be authenticated by the Home Platform via the Terminal Manager to access the local services and the personalization actions can be performed.

5.3 Elsewhere Authentication

5.3.1 Functional descriptionThis part of the document describes an authentication service that is allowing authentication towards the GSeM Web portal using a SIM card as for the authentication data storage mean. This service allows to store in a SIM card some authentication data for example a login/password and then uses this data to connect automatically to a Web portal for example the GSeM portal. We can also manage the portfolio of authentication data so as to delete or change any data stored in the SIM card.

The use case is the following:

Step 1: connexion to GSeM portal

Step 2: write PIN code of the phone to authorize the transfer of authentication data

Step3: Authentication data are automatically downloaded to the fill-in the authentication form

Web browser

Navigateur WEB

SIMPASS Plugin

Interface PC-SIM

Web Portal GSeM

Mobile Phone SIMPass

Cardlet

SIM Card

TCP/IP

Figure 29 SIM Authentication elsewhere

5.3.2 Main modules descriptionPlug-in SIMPASSThis piece of software enables the analysis of Web pages that are read by the Web browser so as to detect the authentication form and then start the authentication process of the user allowing automatic fill-in of the authentication form.

PC-SIM InterfaceThis interface allows the plugin to access to the SIMPass cardlet located in the SIM card via a mobile phone.

SIMPASS Cardlet


IST Project N° 506775 02/12/2005

This application enables the secured storage of the authentication data and their management.

5.3.3 Sequence diagram

1. Access to GSeM portal

2. Send authentication form

3. Request Code PIN

4. PIN Code validation

5. Access to authentication data

6. Authentication data sent

PC

7. automatic Fill-in and authentication

GSeM Web Portal

Figure 30 Sequence diagram of SIM based authentication

Automatic authentication 1 Http connexion to the GSeM Web portal2 Authentication form proposed 3 PIN code of SIM card is requested4 Code PIN is presented to the SIM Card5 Access to the SIMPass cardlet located in the SIM card to request the authentication

data6 Automomatically filled-in of the authentication form on the WEB page7 Authentication to the GSeM


IST Project N° 506775 02/12/2005

5.3.4 Manual AuthenticationThe same authentication method (HTTP-Auth) will be used in both HAN and elsewhere scenarios. The GSeM will declaratively assign http-auth headers requirements so both the terminal manager, and devices outside the home can be authenticated in the same manner. The form based authentication details can be found in 4.1.2.1, and local implementation details in 5.2.4.4.

5.4 Evaluation of ImplementationsMost findings points to the fact that the end user is the weakest link in the trust chain. In ePerSpace the evaluation is focused on end user authentication. In order to have end user acceptance a certain level of user friendliness must be balanced with classical security mechanisms.

The user acceptance and the appropriateness of the different user authentication methods depend mostly on two parameters: authentication frequency and usability. The following sections tries to classify some of the most common user authentication methods according to their frequency of use and usability, to establish the basis for choosing the best method depending on the purpose. Also the need for authentication must be based on the ‘strength’ needed seen from service side. An outline of service levels is presented. Taking this as a basis, local authentication methods proposed in ePerSpace will be evaluated.

5.4.1 IntroductionUsers need to trust devices to keep confidentiality and to be enabled to access to certain services only if they are authorized to do so. Nevertheless, it is difficult to provide physical security to the mobile devices usually used for authentication (smart cards, proximity cards, mobile phones, etc).

Thus, providing security in the access to the services depends on authentication. Thanks to authentication mechanisms, the system will be able of discerning between a legitimate user and an illegitimate one. In ePerSpace, the Authentication Manager will be in charge of verifying the identity of the users (checking the user identity against the list of authorized users registered in the GseM).

The problem of user authentication is different for the mobile and the fixed domains. Mobile devices are unique, are usually used from the elsewhere, in public places, sessions use to be short, and user interface is normally more simple, to fit the mobile device capabilities. Authentication tasks in the mobile environment are then more intrusive, less intuitive, and more frequent than in the home domain.

The design of authentication mechanisms for mobile devices frequently lacks of the most basic usability criteria, ending up in the use of shorter passwords, or even disabling the use of password in the mobile phone because typing a passwords in the mobile for a short access to one service may take too long.

To give an answer to the constrains imposed by mobile devices, two criteria are employed for evaluating some authentication methods: granularity and transparency.

5.4.2 Authentication CriteriaBefore evaluating the authentication methods according to its granularity and transparency, it is necessary to define them.

Granularity is defined as the amount of time between a request and its governing authentication event. This is, the time separating an authentication event and the action of the user that depends on it. Taking into account this criteria, granularity zero means that authentication occurs after each request of the user.

Transparency is the amount of participation required for the user in the process of authentication. Transparency may be considered as a measure of usability. A system that requires the user to perform frequent or complex actions is not transparent, and a fully transparent system requires no external actions.

Both criteria are essential, but giving them two at the same time is often difficult. Moreover, apart from a high granularity and high transparency, usability must be kept also high, making the life of the user easier in order not to disappoint him even before the use of the target service.


IST Project N° 506775 02/12/2005

5.4.2.1 GRANULARITY

The importance of granularity resides in the fact that during the granularity time, something could happen that invalidates the authentication while the system is not aware of it. For instance, someone could assume the identity of an authorized user without authenticating. The user identity may change within the granularity time and the system wouldn’t detect the requests made by the unauthorized user.

Most of current systems cannot detect the change of user because identification is only requested at the beginning of a session. Then, the system assumes that user requests come always from the authenticated user. Commonly the systems do not provide any assurance about a user ending a current session within a time period, having unbounded granularity (this is called ‘delegation’). Other systems use timeout on sessions, requiring authentication every certain period of time. Nevertheless, these systems have coarse granularity.

Systems that prevent this kind of attacks are considered to have a fine granularity. ISO 7498-2 differs between these aspects concerning ConnLess & ConnOriented networks.

For CO networks the normal way is to authenticate initially only, for CL each attempt (ie. Packet) must be authenticated (mechanism: data Origin authentication e.g. with MAC or signatures on each packet)

For login systems various methods applies, e.g. Session time-out (eg Kerberos requires tickets to be renewed after x hours). Granularity, however, does not resist “man-in-the-middle” attacks, where an intruder steals the authentication parameters to use them for own purposes.

5.4.2.2 TRANSPARENCY

Transparency is very important in user authentication for two reasons: for usability constraints and because even when using secure algorithms for authentication, the interaction of the user with the system is usually not that secure. E.g. the transparency do not add technical security as such, but makes life easier for the end user and will as such prevent the end-user to shortcut security mechanisms.

Transparency is even more important when dealing with mobile devices for authentication. Mobile devices are used normally in frequent and short sessions. It the authentication procedures needed before each section is complicated or consumes a long time, the user will be annoyed. Even if the authentication mechanism is simple but is required too often, the user’s tolerance threshold can be exceeded.

Transparency is a subjective parameter and depends on what the users are now used to in current systems.

Several commercial solutions use a key ring or a card to authenticate the user before using the service. However, these solutions use to emulate the same mechanism of a normal key: they are inserted and removed quickly (of just passed near the reader in the case of the proximity cards). Inserting a key, for instance, and remembering to remove it from the device once the service has been used does not conform to the established usage model of a key. Insertion and removal is more transparent than letting the item attached for continued operation.

Figure 31 shows a classification of current authentication methods. Only a few systems provide both fine grain authentication and, at the same time, high level of transparency.


IST Project N° 506775 02/12/2005

Figure 31 Authentication Method Taxonomy

5.4.3 User Authentication criteriaTypical authentication mechanisms ask the user to provide a secret or a piece of unique information in addition to his basic ID-claim. This is for processing the verification task (= authentication)

Different authentication mechanisms are available depending on how this secret is created and stored. Usually, authentication procedures combine something the user knows (password), with something he has (card, token) or something he is (biometrics).

One measure alone is denoted “weak” combinations of 2 or 3 are denoted “strong” by ISO. Unfortunately, there are few systems that provide both fine grain authentication and transparency.

In the following sections, the main authentication methods used in ePerSpace are evaluated.

5.4.3.1 PASSWORDS

The password is the simplest form of user authentication (denoted “weak”). It was the original security mechanism for login into UNIX and time-sharing systems. At the moment when the WS(no PC in the UNIX world) is connected, the user supplies a password together with his user name that is compared against a database for correctness. Methods of increasing pass-word security have been proposed as the complexity of the attacks increases.. Most new procedures rely on preventing bad pass-phrase choices and increasing the resilience of the algorithm to brute force attack. But overall this method is still considered “weak”.

Once the user has provided a valid password, the system assumes that the same person provides commands. At any time the user can revoke the authentication by several methods, such as providing an explicit command to log out of the device. Logging in again requires the password.

When users are given complex secrets that they can’t remember, they tend to write them down. Such a mechanism does not take into account that users have limited memories and prefer to create their own mnemonic-based secrets. Additionally, pass-phrases can be sniffed from networks, keystroke detectors, or users are watched while typing them. I.e., they are vulnerable to heaps of attacks.


IST Project N° 506775 02/12/2005

5.4.3.2 TOKENS

Tokens are introduced to implement strong authentication by utilizing two-factors. The chance for fraud is diminished by simple statistical consideration, provided that the two factors are independent: If each factor has a chance of 1/1000 to be “broken”, the combination of the two will have 1/1 million to be broken.

To address the vulnerabilities of passwords some users carry tokens—small devices that provide authentication information for the user. Tokens have several advantages over pass-phrase-based authentication. First, while a password can be copied a token is more difficult to replicate. The security of these devices depends on the difficulty in replicating the token. If the token itself is stolen it may be easy to copy.. Second, the secret password is stored on the token and then the user does not to need remember it. This permits secrets that are long and difficult to guess. Third, the user will notice when the token has been lost and can revoke any access granted that token.

There are different types of tokens, swiped, such as magnetic strip cards, others require the user to read a value from the token and type it into their device, such as One-time-password generators like SecureID tokens. This value acts as the user’s password. This password is valid for a finite period of time or once, known as a one-time password.

5.4.3.3 SMART CARD AND SIM/NFC

The best technologies for tokens are smart-cards (including SIM) with embedded functions to carry out cryptographic challenge-response protocols, insensitive to replays attacks.

Note: a stolen smart card with a 4 digit PIN is secured if stolen. The card will block itself after 3 unsuccessful attempts. If the PIN is 4 digits (0000 – 9999) the chance of guessing is about 3/10000. A blocked card requires an 8 digit PUK (Pin Unblocking Code) that can also be configured to tolerate a number of failures before a complete self-destruction of keys etc is carried out. Thanks to the mobile phone, most users today are familiar with PIN and PUK (see 4.1.3.2).

Passive RFID (see 5.2.4.1) is cheap and easy to implement; the security is low, however, as the return signal is easily wiretapped and apt to be cloned in an unauthorized manner (passive tags will after initiation always return the same signal). Strictly speaking, RFID alone is truly an Identification means. AUTHENTICATION is defined as the process of verifying claimed identities. RFID alone has no such authentication ability; it is merely a claimer of identity.

The introduction of RFID/NFC (please see chapter 4.4.9) through mobile phone allows the usage of an active RFID, e.g. the possibility to change return signal through mobile phone (SMS). This work is not finalised, but should be considered for further improvement of implementations.

5.4.3.4 BIOMETRICS

Tokens can be lost or stolen, whereas biometric systems are not vulnerable to the same attack. Such systems measure either physical or behavioral traits. Physical traits are immutable characteristics about a person’s body while behavioral traits are extracted from user activity patterns. Physical biometrics are chosen for the impossibility of finding identical biometric features in two different people. The biometrical patterns are difficult to falsify—fabricating false fingerprints is not as easy as copying a pass-phrase. But attacks have been reported, e.g. the use of plastic laminate to fake a detected fingerprint. Other advantage over pass-phrase-based or token-based authentication is that the users cannot forget their biometrics or pass their traits to another person. Other biometric methods include behavioral authentication such as voice-prints, signatures and keystroke dynamics. The problem with Biometric authentication is an inexact process, as the biometrical item may change with time. Also, e.g. fingertips may be temporarily hurt, eyes may suffer from cataracts, Due to biometric variations, the digital reading will never exactly match the reference measurement. The system is adjusted to accept something that is “close enough” because the reading will never exactly match the reference measurement. Two criteria are defining for tuning the biometric system: the false negative reading, where a legitimate user is denied access and a false positive reading, where an illegitimate user is given access. A biometric system must tend to give more false negatives than false positives. For instance result in false-negative rate for fingerprints system can be as high as 44%, depending the subject. For face recognition,


IST Project N° 506775 02/12/2005

the false-negative rate can be between 10% and 40%, depending the factors as the amount of time between training and the recognition system used. Quality equipment with lower fail rate is also known to have a high cost. False denial of access encourages users to disable or work around biometric protection. A possible exception is iris recognition, which can have a low false-negative rate. The cost, however, is tremendous. The immutable nature of biometrics is as much of a disadvantage as an advantage. If a user’s biometric data is exposed to an attacker it is not easily revoked. It is unlikely that the retina and fingers of users can be changed after attacks. But they can be cut off: a report from Malaysia informs a business man lost his thumb because culprits had to use it to start (and steal) his expensive car with biometric lock.Additionally, many users find such systems unacceptable for psychological reasons. That is user’s fear of biometric data being misused by administrators, and fear of the scanning device itself. In response to users’ fears, researchers have found that people are more willing to use behavioral authentication. Biometrics also concerns legal matters, as it may conflict with privacy regulations.

5.4.4 Level of securityWhen providing access to services, we propose a security, which matches the security requirements of the specific services. Two major classes appear, local services such “switch on light”, e.g. inside the house, and access to global services (through global service platform), e.g. services “outside of the house” including remote access to local ‘in-house’ services. Within the house many of the services don’t require authentication. If authentication is used, it will act as a key to personalised services. Global services are typically linked to some payment authorisation. We suggest to subdivide here into two levels, one for the ordinary use, e.g. ordering of video on demand, and the other for the security critical access to bank or VPN to work.

Thus, we end up with in total 4 levels of security, as shown in Table 7.

Sec.level

Type of service Additional remarks

0 “switch on lights” (switches) No authentication needed, required.

1 Local Web access via a Terminal to local services (Home Automation, content services, services configuration, etc.)

Authentication used for personalised services.

2 Entrance into home, Internet Access outside the ePerSpace “world”

Authentication with external entity, considering only one authentication, e.g. encrypted key through NFC or biometrics

3 VPN to work, bank access Strong authentication based on two measures

Table 7 Levels of security for ePerSpace service access

Level 0 and 1 are typical usage scenarios within the house, while level 2 and 3 cover global services. We suggest leaving level 2 and 3 authentication to an entity outside of the house, e.g. the global service management. This will lower the security requirements for the in-house service platform, and make it less likely that a non-friendly attack to the home will succeed in getting security relevant information.

When comparing with the security requirements stated by the Liberty Alliance (see chapter 4.3.2.1), we identify that our level 2 represents ‘weak’ authentication, while level 3 satisfies the need for ‘strong’ authentication.

5.4.5 Standards1. Common Criteria has defined items covering several levels of authentication. It is a large task to

carry out a CC evaluation. But it is recommended to at consider the PP profile options. Also one should have some thoughts in mind about which assurance level to estimate (EAL 1 – 7)


IST Project N° 506775 02/12/2005

2. NIST is currently working on a four-level authentication model. The target is to standardise levels in order to comprehend systems like federated bridges (single sign-on systems for multiple domains) where the various target may have different authentication policies. The two highest levels address two-facto authentication (encompassing one-time-passwords, PKI, and HW-protection of keys like smart cards. It is notified that NIST assesses banking systems only to the two lower levels (passwords and PIN-only)

3. ETSI has under work in TISPAN an attempt to establish guidelines for security evaluation e.g. CC. This concerns more general methods than mechanisms as such, so it is doubtful that it will be of any value to ePerSpace.

5.4.5.1 NIST

The National Institute of Standards and Technology - NIST (USA) works on enhancing the overall security of federal information technology systems [Sept 2004, 800-63, http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63v6_3_3.pdf]

NIST has completed the draft NIST Special Publication 800-63, Recommendation for Electronic Authentication. The purpose of this recommendation is to provide technical guidance to agencies in the implementation of electronic authentication to allow an individual person to remotely authenticate his or her identity to a Federal IT system. This technical guidance supplements OMB guidance, E-Authentication Guidance for Federal Agencies that defines four levels of authentication in terms of the likely consequences of an authentication error. Special Publication 800-63 states specific technical requirements for each of the four levels of assurance in the following areas: identity proofing and registration, tokens, remote authentication mechanisms and assertion mechanisms.

The guidelines present technical requirements for identity proofing, tokens, remote authentication and assertion mechanisms at each level of assurance. The levels indicate increasingly serious risks of authentication errors or misuse of electronic credentials. Making an online reservation for a national park campsite, for example, carries less risk than online filing of financial information.

4 levels (certification and accreditation) are defined:

1. Level requires no identity proofing and allows a wide range of authentication technologies and tokens, including a simple personal ID number. There is no requirement for Federal Information Processing Standard-approved cryptography.

2. Level requires some identity proofing and at least a password as a token. FIPS-approved cryptography is required to thwart eavesdropping or hacker attacks.

3. Level requires a high level of identity proofing and FIPS-approved cryptography to protect the authentication token as well prevent eavesdropping or attacks. Tokens can be either software or hardware.

4. Level provides the highest practical remote network authentication assurance. It is similar to Level 3 but requires hardware tokens with cryptographic modules validated at FIPS 140-2 Level 2 or higher. “By requiring a physical token, which cannot readily be copied and must be unlocked with a password or biometric, this level ensures good, two-factor remote authentication”.

NIST SP 800-63 analyses authentication assurance levels according to the token being used during authentication. Table 8 summarises which token types are permitted at each assurance level.

Type Level 1 Level 2 Level 3 Level 4

PIN

Password

Soft Crypto, One Time Passwords (OTP)

Hard crypto token

Table 8. Token types at different Authentication Assurance Levels according to NIST


http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63v6_3_3.pdf

IST Project N° 506775 02/12/2005

5.4.6 Evaluation conclusionPass-phrases, swiped tokens, and biometrics are examples of transparent, yet coarse grained, authentication systems. These are shown in the upper-left quadrant of the classification of Figure 31Authentication Method Taxonomy, found at page 86.

In user authentication the compromise between usability and security prevents mobile devices from constantly authenticating users, even though security through authentication policy demands it. Users want a system that provides adequate security for their devices without further burdening them.

However, the greatest problem with passwords, swiped tokens, and biometrics is that users forget to log out. Failure to log out results in unbounded granularity—anyone who finds the authenticated device assumes the rights of the legitimate user. Several means applies to counter this, screen lock is well known.We have identified two essential properties of an authentication system. First, it must be transparent to the user. Second, the granularity of authentication must be smaller than the time needed to attack the system. Taking into account this criteria, we could considered four principles: First, users must be able themselves to make the authentication on the device. Second, the mechanisms to secure sensitive data on a mobile device or fixed domains must be as fast as someone can attack it. Third, the system must impose no additional usability burdens. Finally, users must give explicit consent to actions performed on their behalf. In ePerSpace the authentication system must fulfill these principles.

It is further recommended to carry out some risk assessment for local and global services, such as access to home (Doorkeeper) to define a minimum level of security, and align with the proposed levels. For the home area this is implied by the value of the assets inside. I.e., in order to automatically open a front door on a house the means must be comparable with a physical lock (else the insurance company may have strong objections to cover legacy issues in case of burglary). Also the establishment of end user initial identity in order to get access to ePerSpace “identity” must be secured.

The use of RFID as a one-factor authentication is a valid first step, but it should be noted that RFID alone is truly an Identification means, and that added security depending on security policy can be implemented by using RFID as a bootstrap in combination with other authentication challenge. The security could be improved by implementing active RFID through further work on RFID/NFC with communication through SIM/mobile phone.


IST Project N° 506775 02/12/2005

6 Open items for future ePerSpace work

In this chapter we will consider how ePerSpace should continue their work regarding, NFC and SIM, and how the service security could enabled through Liberty Alliance. Note that these considerations are based on the time of ePerSpace at this deliverable completion (Nov 2005), not at the end of project with final implementations and trials.

In general terms a more comprehensive security solution should be provided for the ePerSpace platform at service level integrating currently available processes and technologies. This will include further integration of SIM-based authentication by FT/Telenor, login name and password authentication using http by Mycom, biometric authentication (Doorkeeper) by FT, and two different approaches of RFID by Telenor and Telefonica.

NFC and SIMePerSpace advice to further implement and follow up the RFID NFC technology. Including RFID into the mobile phone (SIM) will give contactless cards the advantage of being able to be installed, updated and cancelled over the air through the services offered by GSM. As mentioned in 4.4.9.4, the communication between the NFC chip and the SIM card does not exist today and has therefore to be standardized. The communication between the SIM card and the NFC chip requires a high-speed transaction time in order to offer a real alternative for today’s ticketing and payment systems.

This is a place where ePerSpace could work by prototyping how this could be done or by specifying the ePerSpace needs for the NFC – SIM communication. Any advances in this field could be played back in to the NFC standardization. In the ePerSpace authentication context this might open for distribution of access keys in elsewhere scenario. We can expect devices to be launched with full support of their companies starting from 2006.

User side security considerationsAlthough further work on Liberty Alliance wil solve some challenges, some considerations should be given to User side security :

Authentication, ePerSpace should consider the following authentication needs in the future work

o All users should be able to authenticate both at home and elsewhere, also opening for “roaming” access in every home, e.g. enabling the open access network in every home. The Elsewhere authentication needs further studied in ePerSpace.

o An anonymous authentication should be considered. By this it we mean that a user should be able to use some services without giving sensitive information, still allowing the service provider the ability to charge the user.

Authorization, when it comes to authorization ePerSpace must continue to work on the ability to let ePerSpace users share authorization to services with other ePerSpace users.

Federation of identity and SSO through Liberty AllianceLooking at the total ePerSpace architecture with its distributed architecture (SP, CSP, GseM/LSeM, and personalization components) is should be noted that this is a good example where the means to satisfy user and server side considerations through SSO is extremely challenging. The de-facto standard seems to be Liberty Alliance, which aims to provide an open single sign-on standard that includes decentralized authentication and authorization for multiple service providers.

The advantage of Liberty being that the ID is not kept centrally, but managed between different providers and that only “federation keys” are sent to the requesting entity, while the identifier is hidden from third parties (opaque).


IST Project N° 506775 02/12/2005

The Service Management Platform is implemented in its first version. It is recommended to use the summary of service level requirements found in chapter 4.3.4.4 as a further “checklist” for functional requirements for an enhanced service management platform that can enable cross-boundary single sign-on and equally important global single logout, dynamic user provisioning and identity attribute sharing.Also Liberty SSO is designed to be independent of authentication mechanisms. However, when a certain security level is required, a SCP, when it delegates authentication of accessing entities, should be confident that the used authentication method matches the requirements for his security level. Depending on how service security policies are applied, the ePerSpace service providers (or SCP) should be able to request stronger authentication.

Currently the ‘level of strength’ to be requested by services are not standardised. We have shown that ISO (7498-2) consider one measure alone is as ‘weak’, and a combination of 2 or 3 are denoted ‘strong’. The measure being something the user knows (password), with something he has (card, token) or something he is (biometrics). Also NIST aims to standardise levels in order to comprehend systems like federated bridges (single sign-on systems for multiple domains) where the various target may have different authentication policies. ePerSpace has made a first outline on 4 levels on security for service access (please see chapter ). It should be further investigated how ePerSpace service management platform could make use of this.

Liberty protocol syntax includes an "Authentication Context" parameter, which indicates the type of used authentication method (e.g. Password, Password, Protected Transport, SmartCard, Mobile, etc…). For further work it should be investigated how this could be implemented though Access management/Terminal manager, and if this information could be included in Personal profile and Service Profile.

We have in chapter 4.3.4.3 shown how the Liberty Alliance framework can be applied to our architecture These considerations should be further documented in the update of the global ePerSpace architecture to be finalized by end of project ( D2.3: Proposition of functional architectures for next phases).

Implementations - AuthenticationIn this document, a proposal has been made on a component handling multiple authentication methods (such as the Form-based, RFID, SIM-based and Fingerprint) integrated at local level in order to support a global authentication. We still need to validate the plug and play quality of our development, e.g. to validate how easy it will be to update the Home Platform with a new authentication means. We will need to consider two aspects:

The provisioning of the database: how to link a user with his UserID and his Smartcard, his phone or his fingerprint.

The actual authentication.

One option could be to delegate the authentication to an entity in the network that would match for example a fingerprint with a UserID. This would allow transferring functionalities of a weak security point such as the residential gateway to the network, and also be in line with the proposed levels of security.

It is further recommended to carry out some risk assessment for selected services following results from business model results, and to align this with the proposed levels. E.g. in the ePerSpace context we expect that the proposed local authentication means are used, but for some services a reauthentication might needed according to stronger authentication demanded by services.


IST Project N° 506775 02/12/2005

7 Conclusion

This deliverable provides a security framework for ePerSpace. This security task has been performed interworking with the personalization and profile tasks within WP5. With regard to the overall ePerSpace architecture, this deliverable outlines the security requirements, as well as proposing a global-local authentication solution.

Threat analysis and global Security requirementsBased on 5 scenario analysis, the global security requirements are identified and classified in critical and medium:

Critical:9) Data Integrity (provide a means to detect any modification of the exchanged data) .

10) Authentication of individuals and data origin authentication (ascertain the identity of the originator of any request to any resource).

11) Access control (provide a means to check the right of a request originator to perform the requested action on the requested resource).

12) End to end authentication or forwarding authentication assertions .

13) Data confidentiality .

14) Provide logs of actual requests for business and legal requirements (Non-repudiation)

Medium:15) Filtering .

16) Digital Rights Management

The global security requirements also dictate the global security policies. Furthermore an evaluation against ISO17799 main sections is performed. The ISO17799 security standard applies to all aspects of the ePerSpace framework relating to security, so all ePerSpace services should be compliant with this extensive European security standard.

ePerSpace security - Single-Sign-on through federation of identitiesIn order to create adaptive and multilevel security, some key building architecture blocks must be in place, e.g. Single Sign On (SSO) and support through authentication by different means. The main candidate is the de facto standard Liberty Alliance Identity Federation Framework (ID-FF), with main focus on the provision of ID distribution, through the distribution of a “federated key”, originated from an ID provider (IDP) and distributed to an ID requestor. The current version SAML 2.0 is ratified as OASIS standard in March 2005 (the parallel development between Liberty ID-FF and SSTC is resolved through submitting ID-FF 1.2 as input to SAML 2.0.).

Although ePerSpace have not implemented any Liberty Alliance solution, we have shown that the service platform architecture can aligned with the Liberty Alliance framework. Also Liberty SSO is designed to be independent of authentication mechanisms. ePerSpace on the other hand focus on the authentication mechanisms summing up to a complementary solution.

Special consideration should be on the basic assumption for identity federation is the pre-requisite existence of a user account at each involved service, and that the federation of identities is a voluntary process based on the explicit consent of the user.


IST Project N° 506775 02/12/2005

ePerSpace security – communication security in WAN1) The communication between service providers, service and management platform and residential

gateway is based on SOAP over HTTP. Firewalls and proxies can be deployed to secure access to the content provider platforms and to the service management platform.

2) Home gateway and residential devices are connected through wireless communications (WiFi or Bluetooth), and mobile phones are used to access (through the cellular network) the services of the service and management platform and to connect (through the cellular network) or directly (wireless) to the home gateway and to the home appliances. For this wireless security ePerSpace must rely on the security mechanism in WiFi or Bluetooth, GSM/GPRS, UMTS and RFID.

ePerSpace security – Personal Profile SecurityThe ePerSpace user will assign specific access rights to each SP (at the moment of a service subscription) following a Role Base access model; in other words the user will select a role for a SP; this information (mapping between roles and service providers) is stored in the GSeM.

Each SP that wants to access/update the profile will contact the GSeM, which will forward the request to the SPOE. The SPOE will contact the correspondent Personalization Engine, passing the service’s role and the userId as parameters. The Personalization engine will query/update the UserProfile, first checking (internally) the access rights for the calling role and returning appropriate results. The management (access, update) of the personal profile is provided by an API exposed in the Personalization Engine and overwritten in the SPOE, following a façade pattern, since the profile information of a User might be in one of several Personalization Engines.

2 basic APIs or set of methods to manage the User Profile have been defined: a GenericAPI and a HelperAPI which are deployed as Web Services in the personalization engine. As these exposed as web services, a web-service based security over the network will be implemented through transport level security SSL, possibly with XML Encryption on top of SSL, and WS-security for message level.

Authentication implementations:

Through the service management platform (Global Service Manager - GSeM) multiple authentication methods (such as the Form-based, RFID, SIM-based and Fingerprint) are integrated in order to support a global authentication. The GSeM contains a remote method (accessible as a Web service) for authenticating a security subject. This method is used by the RFID, SIM and Fingerprint authentication methods through local components in HAN.

The proposal design include local authentication components needed to provide authentication to the user that is accessing the local services, or wants to log into the Management system: The Terminal Manager (developed within WP8) will ask the Local Authentication Manager to authenticate the user through one of the authentication methods. The Local Authentication Manager will be in charge of registering the users that are allowed to access the Home Platform. To be able to handle the local authentication methods, drivers are incorporated in the Middleware platform. The block process the tags for authentication inherent information, check if the tags and user information are valid and are declared through the configuration process. The API to connect to the readers is the same for all reader drivers. In this way new authentication means can be easily integrated in the system. The Terminal Manager or ePerSpace services should be able to ask the Local Authentication Manager to proceed with an authentication check. The following Authentication means is supported: Doorkeeper (Biometric), Icode and NFC RFIDs, Smartcard linked to a PC and Mobile Phone SIMCARD linked via Bluetooth to a PC. All these can be used in combination of Form-based (username / password).

For elsewhere authentication a service that is allowing authentication towards the GSeM Web portal using a SIM card as for the authentication data storage mean will be implemented. This service allows to store in a SIM card some authentication data for example a login/password and then uses this data to connect automatically to a Web portal, for example the GSeM portal. We can also manage the portfolio of authentication data so as to delete or change any data stored in the SIM card. Also the manual authentication method (HTTP-Auth) will be used in both HAN and elsewhere scenarios. The GSeM will declaratively assign http-auth headers requirements so both the terminal manager, and devices outside the home can be authenticated in the same manner.


IST Project N° 506775 02/12/2005

The use of RFID NFC is very interesting in terms of authentication. Trough NFC its chip can act as reader as well as a card, and is backward compatible with the contactless card standards. Including RFID into the mobile phone (SIM) gives contactless cards the advantage of being able to be installed, updated and cancelled over the air through the services offered by GSM

ePerSpace security – Authentication evaluationThe conclusion from evaluation of authentication is two essential properties of an authentication system. First, it must be transparent to the user. Second, the granularity of authentication must be smaller than the time needed to attack the system. From this, we deduce four principles: users must be able themselves to make the authentication on the device, the mechanisms to secure sensitive data on a mobile device or fixed domains must be as fast as someone can attack it, the system must impose no additional usability burdens, and users must give explicit consent to actions performed on their behalf.

The outcome of these implementations will be documented through WP3 for service trials results, and final version of D5.2 for security architecture impact.


IST Project N° 506775 02/12/2005

8 References

[1] ANSI/IEEE Std. 802.11, “Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications”, Edition 1999.

[2] IEEE Std. 802.11b, “Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Higher-speed Physical Layer Extension in the 2.4 GHz Band”, 1999.

[3] IEEE Std. 802.11a, “Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: High Speed Physical Layer in the 5GHz Band”, 1999.

[4] S. Fluhrer, I. Mantin, A. Shamir, “Weaknesses in the Key Scheduling Algorithm of RC4”, Eighth Annual Workshop on Selected Areas in Cryptography, Toronto, August 16-21 2001.

[5] N. Borisov, I. Goldberg, D. Wagner, “Intercepting Mobile Communications: The Insecurity of 802.11”, Seventh Annual International Conference on Mobile Computing and Networking, July 16-17 2001, © ACM.

[6] A. Stubblefield, J. Ioannidis, A.D. Rubin, “Using the Fluhrer, Mantin and Shamir Attack to break WEP”,© AT&T Labs, 2001.

[7] IEEE Std. 802.1x, “Standard for Port based Network Access Control”, 2000.

[8] C. Rigney, S. Willens, A. Rubens, W. Simpson, “Remote Authentication Dial In User Service (RADIUS)”, IETF RFC 2865, June 2000.

[9] IEEE Std 802.11i, Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications, July 2004.

[10] GSM 03.60, “GPRS, Service Description, Stage 2”, 1998.

[11] C. Xenakis and L. Merakos, “Security in third Generation Mobile Networks”, Computer Communications, Vol. 27, No. 7, May 2004, pp. 638-650.

[12] 3GPP TS 33.102 (v3.12.0 ) “3G Security, Security Architecture”, release ‘99, June 2002.

[13] Bluetooth, The Bluetooth Specifications, www.bluetooth.com

[14] B., Schneier, Applied Cryptography, 2nd Ed., John Wiley & Sons Inc., 1996, 758p.

[15] S. Weis, S. Sarma, R. Rivest, D. Engels, “Security and Privacy Aspects of Low-Cost Radio Frequency Identification Systems”, Security in Pervasive Computing, Lecture Notes in Computer Science, Volume 2802, p. 201-212, Berlin 2003.

[16] E. Sarma, S. Weis, D. Engels, “RFID Systems and Security and Privacy Implications”, Workshop on Cryptographic Hardware and Embedded Systems, Lecture Notes in Computer Science, Volume 1965, p. 302-317, 2000.

[17] H. Knospe, H. Pohl, “RFID Security”, Information Security Technical Report”, Vol.9, No.4, pp.39-50, 2004.

[18] I. Vajda, L. Buttyan, “Lightweight Authentication Protocols for Low-Cost RFID Tags”, Second Workshop on Security in Ubiquitous Computing (Ubicomp), Seattle 2003.

[19] M. Feldhofer, “A Proposal for Authentication Protocol in a Security Layer for RFID Smart Tags”, The 12th IEEE Mediterranean Electrotechnical Conference (MELECON), Dubrovnik 2004.


http://www.bluetooth.com/

IST Project N° 506775 02/12/2005

9 Annex

9.1 Wireless securityThis section provides an overview of the security solutions and mechanisms that are employed in the wireless technologies considered in the framework of ePerSpace project. Authentication is just briefly dealt with in this chapter, since this is detailed in 4.4.

9.1.1 GPRS

9.1.1.1 GENERAL

GPRS is a service that provides packet radio access for GSM/GPRS users, and constitutes a migration step toward third-generation (3G) communication systems, but is also in use in parallel with 3-G systems.. The main benefit of GPRS is that it reserves radio resources only when there is data to be sent, thus, enabling the efficient provision of a variety of new and unique services to the mobile subscribers. From a high level, GPRS can be thought of as an overlay network onto a second-generation (2G) GSM/GPRS network, enabling packet data transport at rates from 9.6 to 171 kbps (in practical terms up to approximately 30 kbps) . This networks support IP transport through Telco wireless GSM/GPRS network node GGSN.

9.1.1.2 GPRS SECURITY

As the GPRS is built on the GSM infrastructure, it uses the same security functions used in GSM, although, slightly modified to adapt to the packet-oriented traffic nature and the GPRS network components. These functions aim at two goals: a) to protect the network against unauthorized access, and b) to protect the privacy of the user. Security implementations are based on the secrecy of encryption algorithms. The security features provided by GPRS and refer to the GPRS access network consist of the following components [10]:

Use of Subscriber Identity Module (SIM)

Subscriber identity confidentiality.

Subscriber identity authentication.

User data and signaling confidentiality between the Mobile Station (MS) and the Service GPRS Support Node (SGSN).

9.1.1.2.1 SUBSCRIBER IDENTITY CONFIDENTIALITY

The MS includes the mobile equipment and the SIM. Initially, the subscriber is registered in the home network, which assigns the MS a unique and permanent identifier, the International Mobile Subscriber Identity (IMSI), and a unique 128-bit secret key, Ki. The SIM card stores the IMSI, the Personal Identity Number (PIN), the Ki, as well as the parameters of security functions.

The subscriber identity confidentiality deals with the privacy of the IMSI of the mobile users, as well as with their location. The utilization of the Temporary Logical Link Identity (TLLI) accomplishes this security feature, by keeping the relationship between the TLLI and the IMSI known only to the MS and the SGSN. Moreover, this feature necessitates the confidentiality of the subscriber identity (IMSI), when it is transferred in signaling messages, together with specific measures to preclude the possibility to derive it indirectly from listening to specific information, such as addresses, at the radio path.

The TLLI is used to identify a mobile subscriber on the vulnerable radio path. It is a local identity and must be accompanied by the routing area identity (RAI) to avoid ambiguities. When a TLLI is received with an


IST Project N° 506775 02/12/2005

RAI that does not correspond to the current SGSN, the IMSI of the MS must be requested from the SGSN in charge of the indicated routing area, if its address is known; otherwise, the IMSI is requested from the MS.

The allocation of a new TLLI corresponds implicitly for the MS to the de-allocation of the previous one. When a new TLLI is allocated to an MS, it is transmitted to the MS in a ciphered mode. The MS must store its current TLLI in a non-volatile memory, together with the RAI, so that these data are not lost when the MS is switched off. In the fixed part of the network, the cancellation of the record for an MS in a SGSN implies the de-allocation of the corresponding TLLI. To cope with some malfunctioning, e.g., arising from a software failure, the fixed part of the network can require the identification of the MS in clear. This procedure is a breach in the provision of service, and should be used only when necessary.

9.1.1.2.2 SUBSCRIBER IDENTITY AUTHENTICATION

A mobile user must prove its identity to access the network. Authentication is used to protect against fraudulent use and to ensure correct billing. GPRS uses the authentication procedure already defined in GSM with the distinction that it is executed by the SGSN. The authentication procedure is always initiated and controlled by the network, and it is performed by a challenge/response mechanism, as shown in Figure32.

Figure 32: GPRS authentication scheme

The SN first issues a random number R to the MS, which is a non-predictable outcome of a random number generator. The MS encrypts R by using the A3 hash algorithm, which is implemented in the SIM, and the unique key, Ki, that is assigned to the MS, and, then, sends the signed response (SRES) back to the network.

SRES = A3(Ki, R)

Based on the response, the operator checks if the MS has the correct Ki, by performing the same SRES using the algorithm A3 and the Ki. Once a correct match occurs, the subscriber is recognized as an authorized user; otherwise, the SN rejects the subscriber access to the system. The R and Ki also pass through the A8 hash algorithm, in the MS and the network, to derive the encryption key Kc.

Kc = A8(Ki, R)

Comment to A3, A5, A8 and GEA algorithms: these are being implemented in different versions depending on operator/country (they can be individual for each operator since only triplets are sent when roaming). Some countries will actually not allow the strongest cryptography ( not applicable to most European countries).According to GSM standards the terminal shall be able to display the cryptographic strength offered by the operator (e.g. A3/5), but few vendors have implemented this.


IST Project N° 506775 02/12/2005

9.1.1.2.3 DATA AND SIGNALING PROTECTION

User data and signaling confidentiality is based on the GPRS ciphering algorithm (GPRS-A5), which is similar to the A5. The MS device (not the SIM-card) performs the GPRS-A5 using the key Kc, since it is a strong algorithm that requires a relatively high processing capacity. The GPRS ciphering function has been extended up to the SGSN, and it is carried out at the Logical Link Layer (LLC) supporting signaling and user data encryption over the Um, Abis, and Gb interfaces.

GPRS-A5 is a symmetric stream cipher algorithm, which is selected from the set of algorithms supported by the MS. The MS advertise its algorithm set to the network during authentication. The inputs of the ciphering environment (see Figure 33) are the Key (Kc), the frame dependent input (INPUT), and transfer direction parameter (DIRECTION). The output of the algorithm is the output string (OUTPUT).

Kc is a 64 bit-key generated during the GPRS authentication and key management procedure, and it is never transmitted over the radio interface. The ciphering key is unique for the MS, when point-to-point traffic is used, or it may be common for several MSs, when the SGSN sends the same data to several MSs in point-to-multipoint transmission.

The direction bit (DIRECTION) specifies whether the output string is used for upstream or downstream communication. The input (INPUT) parameter (32 bits) is used as an additional input, so that each LLC frame is ciphered with a different output string. This parameter is calculated from the LLC frame number, a frame counter, and a value supplied by the SGSN called the IOV (input offset value). The IOV is negotiated during the LLC layer and layer 3 parameter negotiation.

The output of the ciphering algorithm ranges from 5 to 1600 bytes. In the sender entity, the OUTPUT string is bit-wise XORed with the LLC payload (PLAIN TEXT), and the result is sent over the radio interface. In the receiving entity, the OUTPUT string is bit-wise XORed with CIPHERED TEXT, and the original PLAIN TEXT is obtained.

Figure 33: Basic GPRS ciphering environment

9.1.2 UMTS

9.1.2.1 GENERAL

UMTS is a realization of 3G networks, which intend to establish a single integrated system that supports a wide spectrum of operating environments. Users have seamless access to a wide range of new telecommunication services, such as high data rate transmission for high-speed Internet/Intranet applications, independently of their location. Thus, mobile networks are a natural extension of the wired Internet computing world, enabling access for mobile users to multimedia services that already exist for non-mobile users and fixed networking.

UMTS has been standardized in several releases, starting from Release 1999 (R99), and moving forward to Release 4 (Rel-4), Release 5 (Rel-5), Release 6 (Rel-6), supporting compatibility with the evolved GSM/GPRS network. The fundamental difference between GSM/GPRS and UMTS R99 is that the latter supports higher bit rates (up to 2Mbps). This is achieved through a new WCDMA (Wideband Code Division Multiple Access) radio interface for the land based communications system, named UMTS Terrestrial Radio Access Network (UTRAN).


IST Project N° 506775 02/12/2005

3G-security is built on the security principles of 2G systems, with improvements and enhancements in certain points in order to provide advanced security services. The elementary security features employed in 2G, such as subscriber authentication, radio interface encryption, subscriber identity confidentiality, are retained and enhanced where needed. The main objective of 3G security is to ensure that all information generated by or relating to a user, as well as the resources and services provided by the serving network (SN) and the home environment, are adequately protected against misuse or misappropriation. The level of protection will be better than that provided in the contemporary fixed and mobile networks. The security features shall be adequately standardized to ensure worldwide availability, interoperability, and roaming between different SNs. Furthermore, 3G security features and mechanisms can be extended and enhanced as required by new threats and services [11].

3G-security architecture comprises five major security classes [12]:

Network access security

Network domain security

User domain security

Application domain security

Visibility and configurability of security

From these classes in the present report we will focus on the network access security.

9.1.2.2 NETWORK ACCESS SECURITY

Network access security is a key component in the 3G-security architecture. This class deals with the set of security mechanisms that provide users with secure access to 3G services, as well as protect against attacks on the radio interface. Such mechanisms include: i) user identity confidentiality, ii) authentication and key agreement iii) data confidentiality and iv) integrity protection of signaling messages. Network access security takes place independently in each service domain.

9.1.2.2.1 USER IDENTITY CONFIDENTIALITY

User identity confidentiality allows the identification of a user on the radio access link by means of a Temporary Mobile Subscriber Identity (TMSI). This implies that confidentiality of the user identity is protected almost always against passive eavesdroppers. Initial registration is an exceptional case where a temporary identity cannot be used, since the network does not yet know the permanent identity of the user.

The allocated temporary identity is transferred to the user, once the encryption is turned on. A TMSI in the circuit-switched (CS) domain, or a P-TMSI in packet-switched (PS) domain has a local significance only in the location area or the routing area, in which the user is registered. The association between the permanent and temporary user identities is stored in the VLR or the SGSN. If the mobile user arrives into a new area, then, the association between the permanent and the temporary identity can be fetched from the old location or routing area. If the address of the old area is not known or the connection cannot be established, then, the permanent identity must be requested from the mobile user.

To avoid user traceability, which may lead to the compromise of user identity confidentiality as well as to user location tracking, the user should not be identified for a long period by means of the same temporary identity. Additionally, any signaling or user data that might reveal the user's identity are ciphered on the radio access link.

9.1.2.2.2 AUTHENTICATION AND KEY AGREEMENT

Authentication and key agreement mechanism achieves mutual authentication between the mobile user and the SN showing knowledge of a secret key K, as well derives ciphering and integrity keys. The authentication method is composed of a challenge/response protocol (see Figure 34), and was chosen in such a way as to achieve maximum compatibility with the GSM/GPRS security architecture facilitating the migration from GSM/GPRS to UMTS. Furthermore, the User Service Identity Module (USIM) and the HE


IST Project N° 506775 02/12/2005

keep track of counters SQNMS and SQNHE, respectively, to support the network authentication. The sequence number SQNHE is an individual counter for each user, while the SQNMS denotes the highest sequence number that the USIM has accepted.

Figure 34: 3G authentication and key agreement

Upon receipt of a request from the VLR/SGSN, the HE authentication center (HE/AuC) forwards an ordered array of authentication vectors (AV) to the VLR/SGSN. Each AV, which is used in the authentication and key agreement procedure between the VLR/SGSN and the USIM, consists of a random number RAND, an expected response XRES, a cipher key CK, an integrity key IK, and an authentication token AUTN.

Figure 35 shows an AV generation by the HE/AuC. The HE/AuC starts with generating a fresh sequence number SQN, which proves to the user that the generated AV has not been used before, and an unpredictable challenge RAND. Then, using the secret key K it computes:

The Message Authentication Code MAC = f1k (SQN ||1 RAND || AMF), where f1 is a message authentication function, and the Authentication and key Management Field (AMF) is used to fine tune the performance or bring a mew authentication key stored in the USIM into use.

The expected response XRES = f2k (RAND) where f2 is a (possibly truncated) message authentication function.

The Cipher Key CK = f3k (RAND),

the Integrity Key IK = f4k (RAND),

and the Anonymity Key AK = f5k (RAND) where f3, f4 and f5 are key generating functions.

Finally, the HE/AuC assembles the authentication token AUTN = SQN Å2 AK || AMF || MAC

It has to be noted that the authentication and key generation functions f1, f2, f3, f4 and f5, and the consequent AV computation follow the one-way property. This means that if the output is known there exist no efficient algorithm to deduce any input that would produce the output. Although the f1-f5 functions are based on the same basic algorithm, they differ from each other in a fundamental way in order to be impossible to deduce any information about the output of one function from the output of the others. Since they are used in the AuC and in the USIM, which are controlled by the home operator, the selection of the algorithms (f1-f5) is in principal operator specific. However, an example algorithm set has been proposed called MILENAGE.

1 || String concatenation 2 Å Exclusive or


IST Project N° 506775 02/12/2005

When the VLR/SGSN initiates an authentication and key agreement procedure, it selects the next AV from the ordered array, and forwards the parameters RAND and AUTN to the user. The USIM using also the secret key K computes the AK,

AK = f5k (RAND),

and retrieves the SQN, since the AUTN contains the (SQN Å AK) value.

SQN = (SQN Å AK) Å AK.

Figure 35: Generation of authentication vectors in 3G

Then, it computes XMAC = f1k (SQN || RAND || AMF), and checks whether the received AUTN and the retrieved SQN values were indeed generated in AuC. If so, the USIM computes the RES = f2k (RAND), and triggers the mobile station (MS) to send back a user authentication response. Afterwards, the USIM computes the CK,

CK = f3k (RAND),

and the IK,

IK = f4k (RAND).

The VLR/SGSN compares the received RES with the XRES field of the AV. If they match, it considers that the authentication and key agreement exchange has been successfully completed. Finally, the USIM and the VLR/SGSN transfer the established encryption and integrity protection keys (CK and IK) to the mobile equipment and the RNC that perform ciphering and integrity functions.

9.1.2.2.3 DATA CONFIDENTIALITY

Once the user and the network have authenticated each other, they may begin secure communication. As described above, a cipher key is shared between the core network and the terminal after a successful authentication event. User and signaling data sent over the radio interface are subject to ciphering using the function f8. The encryption/decryption process takes place in the MS and the RNC on the network side. The f8 is a symmetric synchronous stream cipher algorithm that is used to encrypt frames of variable length. The main input to the f8 is a 128-bit secret cipher key CK. Additional inputs, which are used to ensure that two frames are encrypted using different keystreams, are a 32-bit value COUNT, a 5-bit value BEARER and an 1-bit value DIRECTION (Figure 36). The output is a sequence of bits (the ‘keystream’) of the same length as the frame. The frame is encrypted by XORing the data with the keystream. For UMTS R99, f8 is based on the Kasumi algorithm.


IST Project N° 506775 02/12/2005

Figure 36: Ciphering over the radio access link in UMTS.

9.1.2.2.4 INTEGRITY PROTECTION OF SIGNALING MESSAGES

The radio interface in 3G-mobile systems has also been designed to support integrity protection on the signaling channels. This enables the receiving entity to be able to verify that the signaling data has not been modified in an unauthorized way, since it was sent. Furthermore, it ensures that the origin of the received signaling data is indeed the one claimed. The integrity protection mechanism is not applied for the user plane due to performance reasons.

The function f9 is used to authenticate the integrity and the origin of signaling data between the MS and the RNC in UMTS. It computes a 32-bit Message Authentication Code (MAC) (Figure 37), which is appended to the frame, and is checked by the receiver. The main inputs to the algorithm are an 128-bit secret integrity key IK, and the variable-length frame content MESSAGE. Additional inputs, which are used to ensure that MACs for two frames with identical content are different, are a 32-bit value COUNT, a 32-bit value FRESH, and an 1-bit value DIRECTION. In the UMTS R99, the f9 is based on the Kasumi algorithm.

Figure 37: Derivation of MAC on a signaling message in UMTS.

9.1.2.3 EAP AKA

This section specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using the UMTS Authentication and Key Agreement (AKA) mechanism. Compared to the GSM mechanism, UMTS AKA provides substantially longer key lengths and mutual authentication. The introduction of AKA inside EAP allows several new applications. These include the following: The use of the third generation mobile network authentication infrastructure in the context of wireless

LANs. The use of the AKA also as a secure PPP authentication method in devices that already contain an

USIM. Relying on AKA and the existing infrastructure in a seamless way with any other technology that can

use EAP.

EAP AKA works in the following manner:


IST Project N° 506775 02/12/2005

1. The USIM and the home environment have agreed on a secret key beforehand.2. The actual authentication process starts by having the home environment produce an

authentication vector, based on the secret key and a sequence number. The authentication vector contains a random part RAND, an authenticator part AUTN used for authenticating the network to the USIM, an expected result part XRES, a session key for integrity check IK, and a session key for encryption CK.

3. The RAND and the AUTN are delivered to the USIM.4. The USIM verifies the AUTN, again based on the secret key and the sequence number. If this

process is successful (the AUTN is valid and the sequence number used to generate AUTN is within the correct range), the USIM produces an authentication result, RES and sends this to the home environment.

5. The home environment verifies the correct result from the USIM. If the result is correct, IK and CK can be used to protect further communications between the USIM and the home environment.

Figure 38 shows the basic successful full authentication exchange in EAP-AKA, when optional result indications are not used. The authenticator typically communicates with an EAP server that is located on a backend authentication server using an AAA protocol. The authenticator shown in the figure is often simply relaying EAP messages to and from the EAP server, but these back end AAA communications are not shown. At the minimum, EAP-AKA uses two roundtrips to authorize the user and generate session keys. As in other EAP schemes, an identity request/response message pair is usually exchanged first. On full authentication, the peer's identity response includes either the user's International Mobile Subscriber Identity (IMSI), or a temporary identity (pseudonym) if identity privacy is in effect. The initial identity request is not required, and may be bypassed in cases where the network can presume the identity, such as when using leased lines, dedicated dial-ups.

Figure 38 : EAP-AKA full authentication procedure

After obtaining the subscriber identity, the EAP server obtains an authentication vector (RAND, AUTN, RES, CK, IK) for use in authenticating the subscriber. From the vector, the EAP server derives the keying material. The vector may be obtained by contacting an Authentication Centre (AuC) on the UMTS network;


IST Project N° 506775 02/12/2005

per UMTS specifications, several vectors may be obtained at a time. Vectors may be stored in the EAP server for use at a later time, but they may not be reused.

Next, the EAP server starts the actual AKA protocol by sending an EAP-Request/AKA-Challenge message. EAP-AKA packets encapsulate parameters in attributes, encoded in a Type, Length, and Value format. The EAP-Request/AKA-Challenge message contains a RAND random number (AT_RAND) and a network authentication token (AT_AUTN), and a message authentication code AT_MAC. The EAP-Request/AKA-Challenge message may optionally contain encrypted data, which is used for identity privacy and fast re-authentication support. The AT_MAC attribute contains a message authentication code covering the EAP packet. The encrypted data is not shown in the figures of this section.

The peer runs the AKA algorithm (typically using a USIM) and verifies the AUTN. If this is successful, the peer is talking to a legitimate EAP server and proceeds to send the EAP-Response/AKA-Challenge. This message contains a result parameter that allows the EAP server in turn to authenticate the peer, and the AT_MAC attribute to integrity protect the EAP message.

The EAP server verifies that the RES and the MAC in the EAP-Response/AKA-Challenge packet are correct. Because protected success indications are not used in this example, the EAP server sends the EAP-Success packet, indicating that the authentication was successful. The EAP server may also include derived keying material in the message it sends to the authenticator. The peer has derived the same keying material, so the authenticator does not forward the keying material to the peer along with EAP-Success.

The cryptographic security of the EAP/AKA-protocol is basically the same as that of the AKA protocol. In particular, the network-to-user authentication is provided by the use of a signed challenge and a sequence number mechanism for replay protection. The AuC computes a MAC over the challenge RAND and the sequence number. This MAC and the sequence number are verified by the USIM. The important aspect to note here is that the computation of the MAC is based on the long-term secret K which is stored only in the USIM and in the Authentication Centre AuC, both of which are particularly well protected. The network thus proves possession of the long-term secret K to the user.

Similarly to EAP-SIM, Figure 39 demonstrates the complete picture of 802.1X authentication procedure using the EAP-AKA method.


IST Project N° 506775 02/12/2005

Figure 39: 802.1X authentication using EAP-AKA

9.2 AAA architectureThe previous chapter proved that current 802.11 standard's implementation of WEP doesn't meet the security requirements of most large—and many small to midsized—corporations that are vulnerable to attackers, who can grab companies' data out of the air. Recognizing the inherent security weaknesses of the 802.11 standard, the IEEE defined the 802.1x standard, which promises to provide stronger and more flexible security than 802.11's authentication and encryption mechanisms. This section explains AAA technology, which is essential to understand 802.1X and the next chapters will explain 802.1X and its components.

Complete AAA means moving beyond basic user authentication to policy-based authentication, authorization and accounting (AAA) for users’ access to network and application services. The AAA architecture, simply put, is an attempt to map out a design of how the AAA pieces fit together. AAA


IST Project N° 506775 02/12/2005

implementations can be as simple or as complex as they need to be, mainly because of the efforts of the Internet Research Task Force (IRTF) AAA Architecture Working Group to make a model as application-neutral as possible. In other words, the AAA model is designed to work in environments with varied user requirements and equally varied network design. There are some key attributes of the model that make this possible.

First, the AAA model depends on the client/server interaction, in which a client system requests the services or resources of a server system. In simple implementations, these roles generally stick—the server never acts as the client and vice versa. Client/server environments allow for a good load-balancing design, in which high availability and response time are critical. Servers can be distributed and decentralized among the network. Contrast this with the opposite network model, a peer-to-peer (P2P) net-work. With P2P networks, all systems display characteristics of both client and server systems, which can introduce such demons as processing days and unavailability.

A proxying capability is a slight variation of this. An AAA server can be configured to authorize a request or pass it along to another AAA server, which will then make the appropriate provisions or pass it along again. In essence, a proxy chain is created, in which AAA servers make requests of both clients and other AAA servers. We said ”slight variation” earlier because when a server proxies another server, the originator displays the characteristics of a client. Thus, a trust relationship has to be created for each client/server hop until the request reaches equipment that provisions the needed resources.

Proxying is a very useful feature of the AAA model and a boon to enterprise and distributed network implementations, in which some AAA equipment can be configured to always proxy requests to machines in other locations. An example of proxying at its best is with an ISP reseller agreement. Often a major networking company will make a significant investment in network infrastructure and place points of presence in multiple locations. Armed with this distributed network, the company then resells to smaller ISPs that wish to expand their coverage and take advantage of a better network. The reseller has to provide some form of access control over the tangible resources in each location, but the smaller ISP doesn't wish to share personal information about its users with the reseller. In this case, a proxying AAA machine is placed at each of the reseller's points of presence, and those machines then communicate with the appropriate NAS* equipment at the smaller ISP.

Clients requesting services and resources from an AAA server (and in this case, clients can include AAA proxies) can communicate with each other by using either a hop-to-hop or an end-to-end transaction. The distinction is where the trust relationship lies in the transaction chain. Consider the following circumstances to get a better picture.

In a hop-to-hop transaction, a client makes an initial request to an AAA device. At this point, there is a trust relationship between the client and the frontline AAA server. That machine determines that the request needs to be forwarded to another server in a different location, so it acts as a proxy and contacts another AAA server. Now the trust relationship is with the two AAA servers, with the frontline machine acting as the client and the second AAA machine acting as the server. It's important to note that the trust relationship is not inherently transitive, meaning that the initial client and the second AAA machine do not have a trust relationship. Figure 40 shows how the trusts are sequential and independent of each other.


IST Project N° 506775 02/12/2005

Figure 40: Independent trust relationships in a hop-to-hop transaction

Differing from the hop-to-hop model is the end-to-end transaction method. The key difference is, again, where the trust relationship lies—in this model, it's between the initial, requesting client and the AAA server that finally authorizes the request. In an end-to-end model, the proxy chain is still very much functional as the model doesn't necessarily mean the transaction is end-to-end: it's the trust relationship that is. Because it is poor design to pass sensitive information in proxy requests, some other mean of authenticating a request and validating data integrity is needed when the initial request jumps through the hops in the proxy chain. Most commonly, digital certificates and other PKI certifications are used in these situations. RFCs 2903 and 2905 describe the requirements of implementing end-to-end security, which is shown in Figure41.

Figure 41: Client/Server trust relationship in the end-to-end model.


IST Project N° 506775 02/12/2005

9.3 EAP Authentication Types802.1X does not define any required EAP methods, but it will transport the wide-range of authentication methods that the industry has developed including: MD5, TLS, TTLS, LEAP, PEAP, SIM, FAST and AKA--with more types on the way. Each of these EAP methods has its own advantages and disadvantages for certain environments.

9.3.1.1 EAP-FAST

Extensible Authentication Protocol-Flexible Authentication via Secure Tunneling (EAP-FAST) is a new, publicly accessible IEEE 802.1X EAP type developed by Cisco Systems. It is available as an IETF Internet draft.

Like other tunneled EAP methods, EAP-FAST supports customers who cannot enforce a strong password policy and wish to deploy an 802.1X EAP type that does not require digital certificates, supports a variety of user and password database types, supports password expiration and change, and is flexible, easy to deploy, and easy to manage. FAST provides Cisco customers using LEAP who cannot enforce a strong password policy an upgrade path for protection from dictionary attacks.

Like the other tunneled EAP methods, TTLS and PEAP, EAP-FAST provides protection from a variety of network attacks, including man-in-the-middle, authentication forging, weak IV attack (AirSnort), packet forgery (replay attack), and dictionary attacks.

FAST can be considered by organizations using primarily Cisco networking gear. It is expected that EAP-FAST will appear on Cisco equipment first and then a completed public standard would be made available at a later date allowing third parties the ability to implement it. Within that context, it is used in 802.1X environments for authentication. | Hampshire 03801 | United States of America

9.3.1.2 EAP-MD5.

This is the EAP equivalent to CHAP where a one-way hash algorithm is used in combination with a shared secret and a challenge to verify that the supplicant knows the shared secret. MD5 is considered a base-level authentication method and not generally appropriate where strong security is required for the protection of high value network assets. This is true for a number of reasons.

As with any method that uses a random challenge combined with a password and hash algorithm, it is open to a dictionary attack. If the attacker can obtain the challenge and the hashed response, they can then run a program off-line with the same algorithm as the supplicant, plugging in words from a dictionary until their hashed response matches the supplicant.s. They then know the supplicants password and can steal its identity to gain access to the corporate network. This process is made much easier in wireless LANs where the challenge and response are passed through the air. This is why it is

so important for users to choose passwords that are not based on dictionary words. In addition, EAP-MD5 offers only client-side authentication (i.e., the client is authenticated to the network). Other EAP methods offer mutual authentication where the client is authenticated to the network and the network is authenticated to the client.

Mutual authentication is an important, perhaps, critical feature. With just client-side authentication, EAP-MD5 can allow a client to be fooled into talking to a rogue AP -- one impersonating a valid AP, deployed by a malicious person. This produces vulnerability to man-in-the-middle attacks, which threaten the secrecy of the user.s authentication credentials and all of the data passed to and from the end user. Furthermore, without dynamic data privacy encryption (allowed by mutual authentication EAP methods) it could allow an attacker to hijack a supplicant.s session without ever doing a dictionary attack. The attacker poses as a valid AP; the client attaches to the rogue AP; the rogue AP poses as the valid supplicant to the network passing all the supplicant.s responses as its own. When the network indicates a successful authentication the rogue AP takes control of the connection and sends a ’disassociate’ to the valid supplicant. Since there was no keying material (dynamic session keys) created by the authentication method that only the supplicant and network could know, there was no opportunity to change the WEP key (data privacy encryption key), which would have prevented this attack.


IST Project N° 506775 02/12/2005

9.3.1.3 EAP-TLS.

Transport Layer Security (TLS) offers a very secure authentication process that replaces simple passwords with client- and server-side certificates through the use of Public Key Infrastructure (PKI). EAP-TLS authentication is based on X.509 certificates. certificate is a record of information about an entity (e.g., a person, corporation, etc.) that is verified by an asymmetric mathematical algorithm. Mutual authentication is supported, as are dynamic session keys. TLS is a good choice where strong authentication/security is required and a PKI program is already supported. However, the use of a PKI, where every client has his/her own certificate, is expensive when compared to password-based systems. The expense comes from the required software tools as well as the training and education to make the system effective. EAP TYPE

9.3.1.4 EAP-TTLS.

Tunneled Transport Layer Security (TTLS) is an extension to TLS and was developed to overcome the need created by TLS for client-side certificates (server-side certificates are required with TTLS). As one of the two currently available tunneling authentication methods (PEAP being the other), TTLS is a two-step authentication method. In the first step, an asymmetrical algorithm based on server keys are used to verify the server.s identity and to set up a symmetric encryption tunnel. The second

step involves verifying the client.s identity by using a second authentication method through the symmetric encryption tunnel for the actual authentication negotiation. The second authentication method used within the tunnel may by an EAP type (often MD5) or a legacy method such as PAP, CHAP, MS CHAP, or MS CHAP V2.

The symmetric encryption tunnel of TTLS is used only for protecting the client authentication method.

Once verified, the encryption tunnel is collapsed and it is up to the wireless devices to create a WEP encryption tunnel for the on-going data privacy. This approach offers strong security during authentication while accommodating existing end-user working methods (userid/password), thus avoiding the need for retraining.

9.3.1.5 EAP-PEAP.

Protected Extensible Authentication Protocol (PEAP) is similar to TTLS. PEAP and TTLS are the only currently available tunneling EAP methods. As with TTLS, a symmetric encryption tunnel is established using a server certificate over which the client authentication process is securely conducted. PEAP supports EAP methods through the tunnel, but unlike TTLS, legacy methods are not supported for the client authentication negotiation step. There is an EAP-MS CHAP V2 implementation, but this is incompatible with older RADIUS servers that do not provide EAP support.

9.3.1.6 EAP-LEAP.

Light Extensible Authentication Protocol (LEAP) was developed by Cisco for use on WLANs that use Cisco 802.11 wireless devices. It features mutual authentication, secure session key derivation and dynamic per user, per session WEP keys. However, LEAP is vulnerable to dictionary attacks. LEAP is a proprietary EAP method because of its requirement that it use a Cisco AP. The 802.1X standard is quite clear that the NAS (AP/bridge) does not look at the EAP packets that pass through it, but LEAP was implemented by Cisco prior the ratification of the 802.1X standard. The NAS.s job, according to the standard, is to act as an EAP proxy between the supplicant and authentication server (RADIUS). It does not look at the EAP, rather it repackages it between EAPOL and RADIUS.

This allows new EAP methods to be created and implemented without any modifications to the NAS devices. LEAP is an exception to this standard and is, therefore, Cisco proprietary. Although, like TTLS and PEAP, it provides for mutual authentication and session keys, LEAP.s use of unencrypted challenges and responses does leave it open to potential off-line dictionary attacks (see previous discussion of EAPMD5). TTLS and PEAP do not have this vulnerability because they pass the challenges and responses through their symmetric encryption tunnel. Still when LEAP is combined with a rigorous user


IST Project N° 506775 02/12/2005

password policy, it can offer strong authentication security without the use of certificates. However, PEAP may ultimately eclipse LEAP as Ciscos strategic EAP method.

White Paper

9.3.1.7 EAP-SIM

Subscriber Identity Module is the current standard authentication method used by many cellular equipment providers. This is a smartcard-like authentication method. Smartcards are credit card-size cards with microprocessors and other electronics that can store small programs (e.g., encryption programs) and information about the history of a device, its use, and its owner. In the cellular world these cards have been even further downsized. Clients use these small cards containing their credentials to authenticate to the network. EAP-SIM would enable a user to utilize the existing GSM/GPRS roaming infrastructure for authentication. EAP-SIM provides identity privacy with a method called pseudonyms. The standard does provide mutual authentication, although there is some concern that the keys used for authenticating the server are derived keys and this makes them more vulnerable to spoofing than permanent keys. The standard also provides for key derivation.

9.3.1.8 EAP-AKA.

Authentication and Key Agreement is a new standard being developed by some cellular service providers. This is not yet a standard, but like SIM, the draft is on a relatively mature version. EAP-AKA is similar to EAP-SIM except that it utilizes the USIM (User Service Identity Module) device and the AKA authentication algorithms contained in that device rather than SIM cards and GSM/GPRS authentication algorithms. The USIM device is also smartcard-like. The USIM is defined in the Universal Mobile Telecommunications System (UMTS). While EAP-AKA is similar to EAP-SIM, it is generally acknowledged that EAP-AKA is more secure than EAP-SIM due to its use of permanent keys for mutual authentication. It uses identity privacy with pseudonyms very similar to the EAP-SIM approach. EAP-SIM and EAP-AKA will be discussed later with more details

9.3.1.9 SUMMARY

The preceding inventory of EAP types should leave the reader with the notion that there are a wide variety of EAP methods available today, each with tradeoffs including ease of deployment and level of security provided, among others. We have explained that TTLS and PEAP tunneled authentication methods represent major advancements in WLAN authentication. However, it is important to acknowledge that an utterly unbreakable security system covering every eventuality will likely remain an elusive target. Indeed, recent research has indicated that an environment that includes client systems supporting weak, non-tunneled authentication methods may still be vulnerable to certain kinds of man-in-the-middle attacks even if the infrastructure has implemented the stronger tunnel-based methods. Figure 42 summarizes all the methods with their pros and cons.

Figure 42: EAP methods with their pros and cons


IST Project N° 506775 02/12/2005

9.4 Bluetooth security In every Bluetooth device, there are four entities used for maintaining the security at the link level. The Bluetooth device address (BD_ADDR), which is a 48-bit address that is unique for each Bluetooth device and defined by the Institute of Electrical and Electronics Engineers (IEEE). Private authentication key, which is a 128-bit random number used for authentication purposes. Private encryption key, 8-128 bits in length that is used for encryption. And a random number (RAND), which is a frequently changing 128-bit random or pseudo-random number that is made by the Bluetooth device itself.

In Bluetooth Generic Access Profile, the Bluetooth security is divided into three modes:

Security Mode 1: non-secure

Security Mode 2: service level enforced security

Security Mode 3: link level enforced security

The difference between Security Mode 2 and Security Mode 3 is that in Security Mode 3 the Bluetooth device initiates security procedures before the channel is established.

There are also different security levels for devices and services. For devices, there are 2 levels, "trusted device" and "untrusted device". The trusted device obviously has unrestricted access to all services. For services, 3 security levels are defined: services that require authorization and authentication, services that require authentication only and services that are open to all devices.

9.4.1 Key Management All security transactions between two or more parties are handled by the link key. The link key is a 128-bit random number. It is used in the authentication process and as a parameter when deriving the encryption key. The lifetime of a link key depends on whether it is a semi-permanent or a temporary key. A semi-permanent key can be used after the current session is over to authenticate Bluetooth units that share it. A temporary key lasts only until the current session is terminated and it cannot be reused. Temporary keys are commonly used in point-to-multipoint connections, where the same information is transmitted to several recipients.

There are several different types of keys defined in Bluetooth. Link keys can be combination keys, unit keys, master keys or initialization keys, depending on the type of application. In addition to link keys, there is the encryption key.

The unit key is generated in a single device when it is installed. The combination key is derived from information from two devices and it is generated for each new pair of Bluetooth devices. The master key is a temporary key, which replaces the current link key. It can be used when the master unit wants to transmit information to more than one recipient. The initialization key is used as link key during the initialization process when there are not yet any unit or combination keys. It is used only during the installation.

The length of the Personal Identification Number (PIN) code used in Bluetooth devices can vary between 1 and 16 octets. The regular 4-digit code is sufficient for some applications, but higher security applications may need longer codes. The PIN code of the device can be fixed, so that it needs to be entered only to the device wishing to connect. Another possibility is that the PIN code must be entered to the both devices during the initialization.


IST Project N° 506775 02/12/2005

Figure 43: Key generating algorithm E22 for master and initialization keys

The initialization key is needed when two devices with no prior engagements need to communicate. During the initialization process, the PIN code is entered to both devices. The initialization key itself is generated by the E22 algorithm, which uses the PIN code, the Bluetooth Device Address of the claimant device and a 128-bit random number generated by the verifier device as inputs. The resulting 128-bit initialization key is used for key exchange during the generation of a link key. After the key exchange the initialization key is discarded.

Figure 44: Key generating algorithm E21 for unit and combination keys

The unit key is generated with the key generating algorithm E21 when the Bluetooth device is in operation for the first time. After it has been created, it will be stored in the non-volatile memory of the device and is rarely changed. Another device can use the other device's unit key as a link key between these devices. During the initialization process, the application decides which party should provide its unit key as the link key. If one of the devices is of restricted memory capabilities (i.e. cannot remember any extra keys), its link key is to be used.

The combination key is generated during the initialization process if the devices have decided to use one. It is generated by both devices at the same time. First, both of the units generate a random number. With the key generating algorithm E21, both devices generate a key, combining the random number and their Bluetooth device addresses. After that, the devices exchange securely their random numbers and calculate the combination key to be used between them.

The master key is the only temporary key of the link keys described above. It is generated by the master device by using the key generating algorithm E22 with two 128-bit random numbers. As all the link keys are 128 bits in length, the output of the E22 algorithm is 128 bits, too. The reason for using the key generating algorithm in the first place is just to make sure the resulting random number is random enough. A third random number is then transmitted to the slave and with the key generating algorithm and the current link key an overlay is computed by both the master and the slave. The new link key (the master key) is then sent to the slave, bitwise XORed with the overlay. With this, the slave can calculate the master key. This procedure must be performed with each slave the master wants to use the master key with.


IST Project N° 506775 02/12/2005

The encryption key is generated from the current link key, a 96-bit Ciphering Offset Number (COF) and a 128-bit random number. The COF is based on the Authenticated Ciphering Offset (ACO), which is generated during the authentication process. When the Link Manager (LM) activates the encryption, the encryption key is generated. It is automatically changed every time the Bluetooth device enters the encryption mode.

Figure 45: Key generating algorithm E3 for the encryption key

9.4.2 EncryptionThe Bluetooth encryption system encrypts the payloads of the packets. This is done with a stream cipher E0, which is re-synchronized for every payload. The E0 stream cipher consists of the payload key generator, the key stream generator and the encryption/decryption part.

Figure 46: Description of the encryption process

The payload key generator combines the input bits in an appropriate order and shifts them to the four Linear Feedback Shift Registers (LSFR) of the key stream generator. The key stream bits are generated by a method derived from the summation stream cipher generator by Massey and Rueppel [14].

Depending on whether a device uses a semi-permanent link key or a master key, there are several encryption modes available. If a unit key or a combination key is used, broadcast traffic is not encrypted. Individually addressed traffic can be either encrypted or not. If a master key is used, there are three possible modes. In encryption mode 1, nothing is encrypted. In encryption mode 2, broadcast traffic is not encrypted, but the individually addressed traffic is encrypted with the master key. And in encryption mode 3, all traffic is encrypted with the master key.

As the encryption key size varies from 8 bits to 128 bits, the size of the encryption key used between two devices must be negotiated. In each device, there is a parameter defining the maximum allowed key length. In the key size negotiation, the master sends its suggestion for the encryption key size to the slave.


IST Project N° 506775 02/12/2005

The slave can either accept and acknowledge it, or send another suggestion. This is continued, until a consensus is reached or one of the devices aborts the negotiation. The abortion of the negotiation is done by the used application. In every application, there is defined a minimum acceptable key size, and if the requirement is not met by either of the participants, the application aborts the negotiation and the encryption cannot be used. This is necessary to avoid the situation where a malicious device forces the encryption to be low in order to do some harm.

The encryption algorithm uses four LFSRs of lengths 25, 31, 33 and 39, with the total length of 128. The initial 128-bit value of the four LFSRs is derived from the key stream generator itself using the encryption key, a 128-bit random number, the Bluetooth device address of the device and the 26-bit value of the master clock. The feedback polynomials used by the LFSRs are all primitive, with the Hamming weight of 5. The polynomials used are (25, 20, 12, 8, 0), (31, 24, 16, 12, 0), (33, 28, 24, 4, 0) and (39, 36, 28, 4, 0). Information on the fundamentals of LFSRs is found in [14].

9.4.3 Authentication The Bluetooth authentication scheme uses a challenge-response strategy, where a 2-move protocol is used to check whether the other party knows the secret key. The protocol uses symmetric keys, so a successful authentication is based on the fact that both participants share the same key. As a side product, the Authenticated Ciphering Offset (ACO) is computed and stored in both devices and is used for cipher key generation later on.

Figure 47: Description of the authentication process

First, the verifier sends the claimant a random number to be authenticated. Then, both participants use the authentication function E1 with the random number, the claimants Bluetooth Device Address and the current link key to get a response. The claimant sends the response to the verifier, who then makes sure the responses match.

The used application indicates who is to be authenticated. So the verifier may not necessarily be the master. Some of the applications require only one way authentication, so that only one party is authenticated. This it not always the case, as there could be a mutual authentication, where both parties are authenticated in turn.

If the authentication fails, there is a period of time that must pass until a new attempt at authentication can be made. The period of time doubles for each subsequent failed attempt from the same address, until the maximum waiting time is reached. The waiting time decreases exponentially to a minimum when no failed authentication attempts are made during a time period.


eperspace wp 8 requirementswiki.unik.no/media/m2005homeinfoaccess/eps_del53_final_r... · web...

Documents