Securing a Telework Infrastructure: Smart.IS - Objectives and Deliverables

Vilnius, October 21st, 2002 © eEurope SmartCards

Securing a Telework Infrastructure:

Smart.IS - Objectives and Deliverables

Dr. Lutz Martiny

Co-Chairman , eEurope Smart Cards October 21, 2002

Vilnius


Agenda

• Where do we come from• Trends and Obstacles• The World is more than Europe• Authentication Requirements and Security Levels• Smart.IS objectives• Scope and functional Characteristics of NAME• NAME vs NAME.ES


The IT (R)Evolution

Mainframe

Department Computer

Personal Computer(Desktop)

Personal Computer(Laptop)

PalmtopSmartcard

1960s 1990s

The Internet

IPv6, UMTS

Mobile Communication


Trends

• From static to mobile– any time any where

• From weak to strong– Pin / PKI

• From moderate to large volumes– Scalability from Thousands to Millions of users

• From intra-enterprise to inter-enterprise– Supply chain management, community of interest networking

• From person to application– Outside application integration

• From medium to larger threats– Password level attacks to complex sophisticated identity thefts


Obstacles

• Non standardized software architecture generally in use,• Multiple hardware architecture of access devices,• Technical complexity of platforms,• Different application requirements in terms of security (payment,

financial, health, government, exchange of confidential information, etc),

• Different security rules in different schemes (payment, financial, health, government, exchange of confidential information, etc),

• Different administration rules addressing different types of users,• Societal constraints not yet resolved,• more than 80% of authentication services are still simple password

systems.• Legal aspects of technology not well understood by the

professionals (lawyers, legal experts)


Scope of eEurope Smart Cards

SECURITY/PP

TB3

USER / REQ S

TB8

GOVERN-MENT

TB10

HEALTH

TB11

PAYMENTS

TB5

PUBLIC TRANSPORT

TB9

PUBLIC ID, AUTHENTICATION, ELEC. SIGNATURE

MULTI APPLICATION PLATFORM MULTI APPLICATION PLATFORM

GENERIC CARD READERSGENERIC CARD READERS CONTACTLESS CARDS CONTACTLESS CARDS TB6TB4

TB7

TB1, TB2, TB12

GLOBALINTEROPERABILITY

FRAMEWORK

GIFAPPLICATIONS

GENERIC FUNCTIONS


Cooperation with NICSS Japan

Interoperability Issues

Not-on-us smart card community

Issuer

Contentprovider

User

Serviceprovider

Accessprovider

SCCAdmin.

Issuer

Contentprovider

User

Serviceprovider

Accessprovider

SCCAdmin

On-us smart card community


Secure Interoperability Architecture

4

1

23

4

1

2 3IOP adapter

Host smart card community

card

infrastructure appl

icat

ion

appl

icat

ion

connectivity

connectivityP

KI

PK

I

0

0


Classes of signature:

General electronic signature as required in 5.2

Qualified electronic signature - as specified in 5.1 (Annex I, II, III)

Enhanced electronic signature (applicable to both general and qualified electronic signatures)

Level of legal certainty:

Can not be denied legal effect (art 5.2)

Same legal effect as hand-written signature (art 5.1)

Enhancement of technical evidence

Explanation: Any electronic signature that is not a qualified electronic signature.

Minimum technical level required for the signer so that his electronic signature can be considered as legally equivalent with a hand-written signature.

Additional technical requirements for a verifier, such as time-stamping, but also for the signer, to enhance technical security and obtain protection against certain threats.

EESSI : Proposed Classes of Electronic Signatures

European directive:on electronic signature

OPEN &

TECHNOLOGY

NEUTRALTB12 FOCUSTB12 FOCUSSmart IS AM


Different Authentication Requirements

User

Name Module

Security Device

User Terminal

Authentication of the device

Server

Authentication of the user

Mutual Authentication of the user and the server

Mutual Authentication of the device and the server


Security Interaction at different Levels

Name Module

Security Device

User Terminal

Security device drivers

Applications

Security applications

Application level API (i.e. GSS-API)

Driver level API (i.e. PK CS#11, MS CAPI)

Device level API Human

Inter face

Module level API and data structure

- Human interface- Module level API and data structure- Device driver API - Applications level API


Smart.IS Objectives

• The main objective of the Smart. IS -Accompanying Measures is to develop cross-industry, cross sector co-operative studies between users, network operators and manufacturers to define an open, technology independent solution of interoperability and security of smart card based e-Commerce applications


Functional Description of NAME

As its title “Network Authentication Module for internet End users “ implies, NAME is (1) a module for (2) authentication of (3) the Internet end-user (4) over a network.(1) Module, means that NAME is a logical or physical (or a combination) part of a smart card. Even if NAME can be a standalone smart card with only a “NAME” application, it can be hosted inside a multi-application smart card.(2) Authentication is the main function of this module. This means that the module has the functionality to provide a verifier with an identity and the functionality to provide this verifier with a means to authenticate the module.(3) An Internet end-user is an end-user who is using Internet for private or public usage. The private or public usage question is out of the scope of NAME. Since the level of expertise of the end-user is unknown, it should be assumed to be the lowest.(4) Over a network means that the security level of the network is unknown. As the network is not defined, its security level should be assumed to be the lowest.


Scope of NAME

• Different generic needs in e-business have been identified :• To give access to institutional or public information : The aim is just to

facilitate and personalize, but not to control, the access to information. e.g. personalized or profiled public information.

• To give access to specific information : The aim is to control access to the information, and to be sure that only the right person access to the information he is supposed to access. e.g. personal or client specific information.

• To give access to critical/confidential information : the aim is similar to the previous needs, but with a higher level of trust and security. E.g. access to medical information, etc.

• To make simple or low value transactions : The need is to have non-repudiation between two parties that are already in a trust relationship, or on low value transactions. E.g. electronic purchase order between a company and a supplier that have a previously signed contract.

• To make high value transactions, contracts, etc. : the need is to have strong non-repudiation between two parties that aren’t in a trust relationship, or for high value transaction. E.g. : funds transfers, etc.


Scope of NAME vs. NAME.ES

NAME

ES

NAME

Advanced electronic signature

Electronic signature

Integrity of communications

Authentication of the authorized user

Authentication of the device

Qualified certificate

Secure display

Public key and certificate

Secure keyboard

Card + Reader

Level

Services

Optional

Mandatory


Document Availability

The specifications of NAME and NAME.EScan be found in the following documents

• NAME-V2.1-3-07-021 • NAME-ES_V01-20-06-02

and are available underhttp://www.smartis.org


SMART.IS management officewww.smartis.org

[email protected]

eEurope Smart Cardshttp://eeurope-smartcards.org

info@eeurope-smartcards

[email protected]

Contacts

Documents

Securing a Telework Infrastructure: Smart.IS - Objectives and Deliverables