CryptoNET: Security Management Protocols

CryptoNET: Security Management Protocols ABDUL GHAFOOR ABBASI, SEAD MUFTIC CoS, School of Information and Communication Technology Royal Institute of Technology Borgarfjordsgatan 15, SE-164 40, Kista, SWEDEN {aghafoor, sead}@dsv.su.se Abstract: - In this paper we describe several network security protocols used by various components of CryptoNET architecture. The protocols are based on the concept of generic security objects and on wellestablished security standards and technologies. Distinctive features of our security protocols are: (1) they are complete in terms of their functionality, (2) they are easy to integrate with applications, (3) they transparently handle security credentials and protocol-specific attributes using FIPS 201 (PIV) smart cards, and (4) they are based on generic security objects. These protocols are: remote user authentication protocol, single-sign-on protocol, SAML authorization protocol, and secure sessions protocol. Security protocols use our Security Provider as a collection of cryptographic engines implemented either in software or using FIPS 201 (PIV) smart cards. It also manages protocols attributes using security applets stored in PIV smart card. Key-Words: - FIPS-201 (PIV) smart cards, mutual strong authentication, generic security objects,, secure session, key management, authorization policies. 1 Introduction Protocols are an important component of distributed applications. They define set of rules needed to establish connections, exchange administrative messages, and transfer data between applications components. Distributed applications are essential for enterprises, financial, educational, and other institutions to manage their activities and operations [1]. Most of them have serious concerns about security of their resources and operations. In response to market demands, various existing standalone and distributed applications were either extended with security futures or designed new security protocols and methods for adding security functions and features in those applications (see section 2). However, in most of these applications, security functions and features are applied only to specific resources of individual application. Most of them are using proprietary security techniques and protocols, which are very complicated to extend them with new security features. Our analysis showed that most of them use conventional security protocols and techniques like username passwordbased authentication, they store security credentials in files, they use software-based cryptographic functions, etc. Therefore, weak security protocols and security credentials are the main target of attackers trying to reveal secret keys, security attributes, to launch replay attacks [19], and hijack sessions for unauthorized access to information [2]. To combat against most of identification and authentication attacks and cyber crimes, in 1978 smart card technology was introduced [3]. Smart cards are convenient, easy to use, and provide multifactor authentication as compared to conventional username password-based authentication. They combine physical identity with logical identity to provide better identification and authentication services. In early days, most of smart cards were used only for identity verification and authentication purposes due to limited storage capacity and processing capabilities, but recent advancements and standardization in this field increased the usage of smart cards in standard security mechanisms and protocols [4]. We analyzed some of smart card-based security protocols and applications in section 2 and found that most of them support only security functions for individual application. Some of products support only specific smart cards and require special administrative rights to write application-specific security credentials in them. Furthermore, these protocols are not mutually integrated, so each protocol maintains its own security attributes using proprietary techniques, not accessible to other protocols. Most of existing products are using proprietary solutions so they are very complicated to extend with new security protocols and features. In this paper we describe smart card-based security management protocols which are based on wellestablish security standards and technologies. These ISSN: 1792-6157 15 ISBN: 978-960-474-245-5

protocols are: remote user authentication protocol, single-sign-on protocol, SAML authorization protocol [15], and secure sessions protocol. The design of protocols is based on the concept of generic security objects, so each protocol provides complete and the same set of functions and features in order to extend any application with security. Furthermore, they are mutually integrated, so that resources and actions of one protocol are used by another protocol, when needed. They are activated and executed automatically without any user intervention, because each protocol transparently handles security credentials, smart cards, and attributes. The security management protocols are generic and based on modular approach. Therefore, it is easy to add new protocols or replace the logic of the existing ones, if needed, without modifying applications. The following are the main features of our security protocols: They are all based on generic security objects and modular, so the same protocols provide the same set of security services to all components of the CryptoNET System; They are all fully compliant to wellestablished security standards, like FIPS 201 [5], FIPS 196, SAML, etc.; They use the same Security Provider in order to provide the same set of cryptographic services; and Security protocols are easy to understand, so developers can easily integrate them with their applications. 2 Existing Smart Card-based Applications and Security Protocols Smart card are the most expanding technology used in a wide range of applications, from digital access to physical access, online payments to paying on Point-of-Sale (PoS), mobile phones to personal gadgets, and even to the development of next generation secure applications and services. The key features of smart-cards are: (1) they tightly couple physical identity with logical identity, (2) they protect security credentials, and (3) they provide encryption and decryption services without extracting security credentials from smart cards. Due to these features, smart cards got acceptance by businesses, enterprises, and service providers. Users are looking for new and innovative smart cardsbased secure applications and security protocols [7] for protection of their resources. In 2006 NIST published specification FIPS 201, which addressed security requirements and implementation details of the Personal Identity Verification system for government employees. Based on the FIPS-201 standard, Gemplus introduced SafesITe PIV Client to provide highest level of security to government networks [8]. SafesITe is also compliant with MS-CAPI (Microsoft- Crypto Application Programming Interface) and PKCS-11 (Public Key Cryptography Standards) standards. Based on this library, in 2006 Gemplus launched an identity management system to achieve portability and high level of security for government networks [9]. This system is also compliant with Homeland Security Presidential Directive-12 (HSPD-12) [10]. SafesITe PIV client module installed on user machine securely performs strong authentication, encryption, decryption, and generates smart card-based digital signature for application data. Gemalto in collaboration with IBM, also developed solution for Web-based single sign-on protocol based on smart cards for physical and logical access control. This product supports public key cryptography and is fully compliant with FIPS-201 and European Identification Authentication Signature standards. Another product which is used for smart card-based strong authentication is Gemalto s Strong Authentication and Customer Care Portal [11]. In this solution, Gemalto designed a smart card-based Strong Authentication protocol to perform end-user validation with Gemalto Strong Authentication, while Customer Care Portal performs administrative tasks, like managing Gemalto smart cards devices, authentication policies, roles, user, key and functions. Furthermore, this portal enables end-users to register and manage their passwords and account information. Smart Card Alliance [12] is an organization which provides recommendations to different member s organizations for smart card manufacturing, middleware development, and smart card-based applications. The core objective of Smart Card Alliance is to promote smart card technologies for identification, payment and other user applications to ensure user privacy, data security, and integrity. Another interesting protocol is Protocol for Lightweight Authentication of Identity (PLAID) [13], based on symmetric and asymmetric cryptography in order to protect communication between smart card and terminals. This protocol provides mutual strong authentication protocol and protection of data packets between contact less smart cards and smart card readers, which is a terminal device. Motivated by the current smart card standardization initiatives, development of smart card technologies, ISSN: 1792-6157 16 ISBN: 978-960-474-245-5

and possibilities for their integration with applications, we designed smart card-based security management protocols for CryptoNET [14] architecture. These protocols are based on wellestablished security standards and technologies. We used generic security objects, modular and generalized approach for designing the generic security protocols, which provide the same set of security services to secure applications. They are easy to integrate with applications. Furthermore, they are mutually integrated, so that resources and actions of one protocol are used by another, when needed. In addition, all these protocols use the same smart card. The protocols are: remote user authentication protocol, single-sign-on protocol, SAML authorization protocol, and secure sessions protocol. 3 Overview of The CryptoNET System CryptoNET is an integrated framework, as shown in Fig. 1, which strongly protects IT resources, operations and messages in transit. CryptoNET comprises: Secure Station Manager (equivalent to Windows Explorer), Secure E-Mail Client, Secure Documents System, Secure Browser, Several Application s and global security infrastructure servers. In order to provide extended security services, it uses security protocols for Inf. Security Administrator Client Mail Client Issuing PKI Secure Application Secure Message Policy PKI Secure Station Manager XACML Policy PEP Web Browser Mutual Strong Authentication Top PKI Single Sign on Doc Manager IDMS SA SAML Ticket Security Administrator Fig. 1: Abstract Design of The CryptoNET System and Interaction between Components mutual remote authentication, secure communication, and enforcement of authorization polices. These protocols are described in section 4. Application specific functions of each component are not described in this paper since we considered only functions and features required by various security management protocols. The following are the servers of the CryptoNET system: - Local Certification Authority (LCA) : LCA issues and distributes X.509 certificates to all components. This server is also connected with the Top PKI and with the Policy PKI for trusted hierarchy; - IDentity Management System (IDMS) : It manages identities of different resources and clients, and application servers; - XACML Policy : It is also known as Policy Decision Point (PDP). XACML Policy is responsible for creation of SAML tickets, XACML authorization policies [6] and policy sets, and for making decisions based on the SAMLAuthorizationRequests; and - Strong Authentication : It performs strong authentication with clients and passes SAML tickets to clients, generated by the XACML Policy. - Policy Enforcement Point (PEP): PEP is a proxy component of each Application. It enforces authorization policies and consults with XACML Policy for validating SAML Tickets and evaluating XACML polices. - Secure Application s: These are customized application servers which provide application-specific services to various clients of the CryptoNET system. Examples are: Secure E-Mail, Secure Library etc. Detailed functions and components of the CryptoNET are described in [4]. Design of the CryptoNET is based on modular approach and implemented in a form of plugins. Generic plugins provide features to reuse components with the same set of tested and verified security services by multiple applications. 4 Design and Operations of Security Management Protocols Security Administrator (SA) with administrator s rights registers users in the IDMS. The SA creates a complete profile of each user, which is used to form a Distinguished Name for certificates. SA loads card authentication credentials and security applet into user s FIPS-201 (PIV) smart cards. Security applet ISSN: 1792-6157 17 ISBN: 978-960-474-245-5

is managing identity of the user, basic authentication credentials, like username and password, SAML ticket, symmetric key, secure session attributes, and application specific security credentials. After issuance of a smart card, the user logins into a workstation, using PIN and/or fingerprint. Upon successful login, the user generates RSA key pairs in a smart card in order to create four certificates. These are: PIV Authentication certificate, digital signature, key exchange, and digital signature+nonrepudiation certificates. After that, it generates certificate requests which are sent to the LCA. Upon reception of certificates, it stores them in the smart card. If LCA does not exist in a domain, then it generates three self-signed certificates. The purpose and usage of each certificate is explained in the coming sections. Design of security protocols is based on a modular approach and each module is implemented using the concept of generic security objects. Security protocols are: initial user authentication using FIPS 201 (PIV) smart cards, FIPS 196 based strong authentication protocol, single-sign-on protocol, secure session, and SAML authorization protocol. In our system we used security protocols to establish secure sessions and provide network security services to various components of the CryptoNET. 4.1 Remote User Authentication Protocol In our system remote user authentication is performed using mutual Strong Authentication protocol. It is an extension of the FIPS-196 strong authentication protocol. Its extended security functions are: verification of certificates by the LCA and verification of identities by the IDMS. As mentioned above, Security Protocols use Security Provider for software or smart card-based cryptographic functions. So our mutual Strong Authentication protocol also uses PIV credentials and smart card-based cryptographic functions. In our system, client initiates mutual strong authentication protocol with the SA and sends PIV authentication certificate to the SA instead of the Hello message, as specified in the FIPS 196 standard: Client SA : Cert PIV-a SA receives the certificate and verifies it by sending it to the LCA. In addition, it also verifies the distinguished name of the user using IDMS. Upon successful verification, SA generates random number R s and sends it to the client. Otherwise, if verification fails, it informs the client and stops conversation with the client. Client: R s Client receives R s and signs it using private key corresponding to the PIV authentication certificate. The following are cryptographic functions to generate signature of the R s. h = H (R s ) (5.1) S(R s ) = E (h, private key) (5.2) In these equations, H is a hash function and h is the output of the hash function. E is an encryption function which encrypts h using private key corresponding to the PIV authentication certificate. In the next step, client generates a random number R c and returns it with S(R s ) to the SA. Client : {S(R s ), R c } SA receives the message and verifies client s signature using the following cryptographic functions: h = H (R s ) h`= D (S(R s ), public key) (5.3) In equation (5.3), SA uses public key, extracted from the PIV authentication certificate of the client, for verification of the signed challenge (S(R s )). If h is equal to h`, SA returns digitally signed R c and its digital signature certificate to the client. Cryptographic functions are the same as explained in Equations (5.1) and (5.2). Client: {S(R c), Cert sa} Client receives signed random number and verifies its digital signature, using Equation (5.1) and Equation (5.3), but in this case it uses public key extracted from the digital signature certificate of the SA. In addition, it also verifies digital signature certificate from the LCA and the identity of the SA using IDMS. Client : S(R c), Cert sa Upon successful authentication, SA creates connection with the XACML Policy and sends the identity of the client (distinguished name) requesting SAML ticket. XACML Policy validates client s identity using IDMS and generates SAML ticket. SAML ticket contains ticket-id, identity of the client, timestamp, and IP address of the XACML Policy. XACML Policy also digitally signs SAML ticket (ST) using its own private key corresponding to its digital signature certificate. It sends signed ST to the SA which then sends it back to the client. Client receives ST and stores it in the security applet in a smart card. ISSN: 1792-6157 18 ISBN: 978-960-474-245-5

4.2 Single-Sign-On Protocol When client establishes connection with some Secure Application, the initiates single-sign-on protocol. Upon receiving initiation, client fetches ST from a smart card and digitally signs it using private key corresponding to his/her digital signature certificate. It sends ST to the Policy Enforcement Point (proxy to the application server) along with digital signature certificate: Client PEP::Request(ST s,cert DSc) (5.4) The PEP component also signs ST and concatenates to it multi-party signature ST ss. The PEP component encapsulates ST ss in the SAMLAuthenticationRequest message and sends it to the XACML Policy for validation: PEP XACMLPolicy::SAMLAuthenticationRe questst,st ss,cert DSc) (5.5) XACML Policy verifies both signatures. Successful verification of signatures proves that SAML ticket, received from the PEP, was presented by the owner of the SAML ticket, which provides source authentication. After this, XACML Policy consults SAML-Tickets database, in order to validate ST. If it is OK, XACML Policy sends SAMLAuthenticationResponse message to the PEP component, as shown in (5.6), which contains authentication decision: XACMLPolicy PEP::SAMLAuthenticationRes ponse (Permit/Deny) (5.6) If the decision is Deny, PEP informs the client and terminates the connection without any further correspondence. If it is Permit, PEP component establishes secure session with the client. 4.3 Secure Sessions In our system secure session is established after a single-sign-on protocol is successfully completed. Secure Application requests KeyExchange certificate from a client. The purpose of the KeyExchange certificate is to securely exchange session-key and session-id between a client and Secure Application s. To manage secure sessions attributes at the server, PEP creates an active session object for the specific client in a session s container. Each object in the session container contains the identity of an authenticated client, session key, and session id. Upon reception of certificate request, the client fetches KeyExchange certificate from a smart card and sends it back to Secure Application. Since single-sign-on protocol is capable to authenticate clients in a distributed environment, there is still a possibility that the attacker may launch replay or impersonation attack by presenting valid SAML Ticket. To combat against such type of attacks, Secure Application receives KeyExchange certificate and compares its distinguished name with the identity stored in the session container. In addition, Secure Application also verifies the certificate chain. Upon successful verification, Secure Application generates a session-symmetric-key and session id, which are digitally signed by using private key corresponding to its own digital signature certificate and enveloped using public key corresponding to KeyExchange certificate of the client. It sends session key exchange message to the client, as shown in (5.7). SecureApplication Client::P(SK,SID), KeyExchangeCertas (5.7) Client receives the message and verifies the signature. Upon successful verification, it opens the envelope using private key corresponding to KeyExchange certificate in order to extract sessionsymmetric-key and session id. Client stores both session attributes in a smart card, if it is installed. Otherwise, it stores them in a key-file. Client uses session-symmetric-key and smart card based cryptographic functions to create secure messages in the standard format PKCS#7SignedAndEnvelopedData. The purpose of session-id is to enable the secure application client and secure application server to perform secure asynchronous communication. 4.4 Authorization Protocol Authorization policies in our security system are based on the XACML standard [101]. We adopted Role-Based Access Control model, so an authorized person (for example Security Administrator (SA)), creates a group and defines access level for each group member along with his/her role and permitted actions. SA generates a Policy Token (Policy Set) which includes Target object which is used to identify the role of each group member in a group. Target contains the name of a group member, the name of a resource, and actions permitted to be performed by a group member with the specified resource. In addition, SA can also specify Policy and Rules objects, if required. SA saves newly created policy in an XACML policy file. When an authorized group member requests an access to a specific resource, it fetches SAML ticket ISSN: 1792-6157 19 ISBN: 978-960-474-245-5

from a smart card and sends it to the PEP server, along with the name of the requested resource. The PEP server creates SAMLAuthorizationRequest message and sends it to the XACML Policy. XACML Policy consults policy file and generates SAMLAuthorizationResponse message, which contains authorization decision. SAMLAuthorizationResponse is sent back to the PEP server in order to enforce authorization policy accordingly. 5 Conclusions Security protocols are designed based on generic security objects which provide the same set of security services to various applications. Together with modules of Security Provider, these protocols provide the complete set of security functions and features needed to extend any applications with security. Security protocols are mutually integrated, so that resources and actions of one protocol are used by another protocol, when needed. Security protocols handle security credentials and can be activated and executed automatically without user intervention. It is easy to add new protocols or replace the logic of the existing ones, if needed. References: [1] B. P. Kumar, J. Selvam, V. S. Meenakshi, K. Kanthi, A. L. Suseela, V. L. Kumar, Business decision making, management and information technology, publisher ACM New York, NY, USA. Volume 2007 [2] R. Lowe, Malicious Software Attacks targeting Home Users and Businesses, Australian Computer Emergency Response Team, http://www.auscert.org.au/download.html?f=22 3 visited on December, 2009. [3] M.l Tunstall, Smart Card Security, publisher Springer US, pp. 195-228. December, 2007 [4] Microsoft Corporation, Identity and Access Optimization Strong Authentication using Smart Cards Smart Card Lifecycle Management, http://download.microsoft.com/download/3/f/ B/3FBC5A24-B96A-40B4-AC8F- 43A476E27766/Smart_Card_Lifecycle_Manag ement_datasheet.pdf, visited on January, 2010 [5] C. M. Gutierrez, W. A. Jeffrey, FIPS PUB 201-1: Personal Identity Verification (PIV) of Federal Employees and Contractors, Computer Security Division, Information Technology Laboratory, National Institute of Standards and Technology, Gaithersburg, MD 20899-8900, March 2006. [6] S. Godik, T. Moses, extensible 2 Access Control Markup Language (XACML), Version 1.0, OASIS Standard, February, 2003. [7] S. Srinivasan, Alan S. Secure and Practical Smart Card Applications, Information Systems Control Journal, Volume 5, 2003, [8] Gemplus North America, SafesITe Enterprise Smart. Simple. Secure, http://www.gemplus.com/northamerica/downlo ad/safesite_ent_brochure.pdf, visited on December, 2009 [9] Gemplus Inc., Gemplus Launches Identity Management Solution Compliant with FIPS 201, http://www.securityinfowatch.com/hspd- 12,+FIPS+201,+and+TWIC+Announcements/ gemplus-launches-identity-managementsolution-compliant-with-fips-201 Updated on 02-6-2009 [10] Article, Policies for a Common Identification Standard for Federal Employees and Contractors, Homeland Security Presidential Directive-12 (HSPD 12), http://www.dhs.gov/xabout/laws/gc_12176166 24097.shtm, August 27, 2004 [11] Gemalto Inc., Protiva Enterprise Security Solutions for Tivoli Access Manager, Combined convenience of Enterprise and Web single sign-on with the security of smart card authentication, http://www.gemalto.com/brochures/download/ protiva_enterprise_tivoli.pdf [12] Smart Card Alliance, http://www.smartcardalliance.org/ [13] CentreLink, Protocol for Lightweight Authentication of Identity (PLAID), Logical Smart Card Application Specification, Version 7.1, February, 2009 [14] G. Abbasi, S. Muftic, CryptoNET: Integrated Secure Workstation, published in International Journal of Advanced Science and Technology, pp. 1-10, Vol. 12, November, 2009. [15] OASIS, S. Cantor, J. Kemp, R. Philpott, E. Maler, Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0 OASIS Standard, 15 March 2005, http://docs.oasis-open.org/security/saml/ v2.0/ ISSN: 1792-6157 20 ISBN: 978-960-474-245-5