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

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

2. 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 Agenda

3. Palmtop Mobile Communication Smartcard Personal Computer (Laptop) Personal Computer (Desktop) Department Computer Mainframe The Internet The IT (R)Evolution IPv6, UMTS 1960s 1990s

4. 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 Trends

5. 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) Obstacles

6. S E C U R I T Y / P P USER / REQ S TB9 TB10 TB5 TB11 TB3 TB8 PUBLIC TRANSPORT GOVERN-MENT PAYMENTS HEALTH Scope of eEurope Smart Cards APPLICATIONS GIF GLOBAL INTEROPERABILITY FRAMEWORK GENERIC FUNCTIONS TB1, TB2, TB12 PUBLIC ID,AUTHENTICATION, ELEC. SIGNATURE MULTIAPPLICATION PLATFORM TB7 GENERIC CARD READERS TB4 CONTACTLESS CARDS TB6

7. Interoperability Issues SCCAdmin. Issuer User Not-on-us smart card community Access provider Content provider Cooperation with NICSS Japan Service provider SCCAdmin Issuer User Access provider Content provider Service provider On-us smart card community

8. 4 PKI 1 application card connectivity 0 3 3 2 2 4 IOP adapter PKI 1 application infrastructure connectivity 0 Host smart cardcommunity Secure Interoperability Architecture

9. European directive:on electronic signature OPEN & TECHNOLOGY NEUTRAL TB12 FOCUS Smart IS AM TB12 FOCUS EESSI : Proposed Classes of Electronic Signatures

10. Security Device Name Module Server User User Terminal Authentication of the device Mutual Authentication of the device and the server Authentication of the user Mutual Authentication of the user and the server Different Authentication Requirements

11. Security Interaction at different Levels - Human interface - Module level API and data structure - Device driver API - Applications level API

12. 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 Smart.IS Objectives

13. FunctionalDescription 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. 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

15. Level Services Card + Reader Secure keyboard Public key and certificate Secure display Qualified certificate N A M E E S Authentication of the device N A M E Authentication of the authorized user Integrity of communications Electronic signature Advanced electronic signature Scope of NAME vs. NAME.ES Optional Mandatory

16. 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 Document Availability

17. Contacts SMART.IS management office www.smartis.org David.Ankri@wanadoo.fr eEurope Smart Cards http://eeurope-smartcards.org info@eeurope-smartcards lutz@martiny.org