1. Vilnius, October 21st, 2002 © eEurope SmartCards Securing a Telework Infrastructure: Smart.IS - Objectives and Deliverables Dr. Lutz Martiny Co-Chairman, e Europe Smart Cards October 21, 2002 Vilnius

2. Vilnius, October 21st, 2002 © eEurope SmartCards 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

3. Vilnius, October 21st, 2002 © eEurope SmartCards The IT (R)Evolution Mainframe Department Computer Personal Computer (Desktop) Personal Computer (Laptop) Palmtop Smartcard 1960s 1990s The Internet IPv6, UMTS Mobile Communication

4. Vilnius, October 21st, 2002 © eEurope SmartCards 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

5. Vilnius, October 21st, 2002 © eEurope SmartCards 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)

6. Vilnius, October 21st, 2002 © eEurope SmartCards Scope of eEurope Smart Cards SECURITY/PPSECURITY/PP TB3 USER/REQSUSER/REQS TB8 GOVERN- MENT TB10 HEALTH TB11 PAYMENTS TB5 PUBLIC TRANSPORT TB9 PUBLIC ID, AUTHENTICATION, ELEC. SIGNATURE MULTI APPLICATION PLATFORM GENERIC CARD READERS CONTACTLESS CARDS TB6TB4 TB7 TB1, TB2, TB12 GLOBAL INTEROPERABILITY FRAMEWORK GIF APPLICATIONS GENERIC FUNCTIONS

7. Vilnius, October 21st, 2002 © eEurope SmartCards Cooperation with NICSS Japan Interoperability Issues Not-on-us smart card community Issuer Content provider User Service provider Access provider SCC Admin. Issuer Content provider User Service provider Access provider SCC Admin On-us smart card community

8. Vilnius, October 21st, 2002 © eEurope SmartCards Secure Interoperability Architecture 4 1 2 3 4 1 2 3 IOP adapter Host smart card community card infrastructure application connectivity PKI 0 0

9. Vilnius, October 21st, 2002 © eEurope SmartCards EESSI : Proposed Classes of Electronic Signatures European directive: on electronic signature OPEN & TECHNOLOGY NEUTRAL TB12 FOCUS Smart IS AM

10. Vilnius, October 21st, 2002 © eEurope SmartCards 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

11. Vilnius, October 21st, 2002 © eEurope SmartCards Security Interaction at different Levels - Human interface - Module level API and data structure - Device driver API - Applications level API

12. Vilnius, October 21st, 2002 © eEurope SmartCards 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

13. Vilnius, October 21st, 2002 © eEurope SmartCards 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.

14. Vilnius, October 21st, 2002 © eEurope SmartCards 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.

15. Vilnius, October 21st, 2002 © eEurope SmartCards Scope of NAME vs. NAME.ES NAMEESNAMEES NAMENAME 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

16. Vilnius, October 21st, 2002 © eEurope SmartCards Document Availability The specifications of NAME and NAME.ES can be found in the following documents NAME-V2.1-3-07-021 NAME-ES_V01-20-06-02 and are available under http://www.smartis.org

17. Vilnius, October 21st, 2002 © eEurope SmartCards SMART.IS management office www.smartis.org David.Ankri@wanadoo.fr e Europe Smart Cards http://eeurope-smartcards.org info@eeurope-smartcards lutz@martiny.org Contacts