Smart Card Layout and Authentication Protocol for Access Control System in Military Application

(1)

Smart Card Layout and Authentication

Protocol for Access Control System in

Military Application

Vinod Vasudevan

Department of Computer Science & Engineering

(2)

Smart Card Layout and Authentication

Protocol for Access Control System in

Military Application

A Thesis Submitted

In Partial Fulllment of the Requirements For the Degree of

Master of Technology

by

Vinod Vasudevan

to the

Department of Computer Science & Engineering

Indian Institute of Technology Kanpur

(3)

(4)

Abstract

Smart card technologies are increasingly nding their foothold in the eld of security due to the exibility, relatively low cost, robust security, versatility and variety they provide as compared to other available options such as USB tokens, PCMCIA cards etc. Our attempt is directed towards harnessing this growing technology and implementing it into the Armed forces for Access Control and Management. This work is centrally aimed at designing the architecture framework for such an implementation in the Indian Navy catering to both physical and logical access. The design of such a framework is made challenging by the fact that this implementation is envisaged across a large section of users who are not only distributed geographically but also categorized distinctly in their continuously changing roles of operation. Owing to these on-ground user requirements and the exibility provided by Public Key cryptography, the design of the application was done using asymmetric keys as per SCOSTA-PKI and SCOSTA-CL specications.

SCOSTA-PKI and SCOSTA-CL which are compliant to ISO/IEC 7816 set of In-ternational Standards for smart cards dene specications for carrying out symmetric and asymmetric key operations. The design for our implementation utilizes asymmet-ric key operations such as encryption, decryption, authentication, digital signature and certicate verication based on SCOSTA-PKI standards. Establishment of a key man-agement system including secure key generation, distribution and maintenance form a part of the work along with card layout design and authentication protocols. Attempt was made to stick to the already existing and proven system of security management and administration so that little changes need to be incorporated for the implementation and to motivate the user to accept the new technology.

(5)

Acknowledgment

I would like to express my sincere gratitude to my supervisor Dr. Rajat Moona for his unreserved guidance and inspiration throughout the course of this work. I thank him for the patience he has shown over extended discussions during this period. This work would not have been possible without his support, encouragement and faith bestowed upon me.

A word of thanks to Dr TV Prabhakar, Dr Manindra Agrawal and Dr Piyush Kurur for being gracious enough to lend their valuable time in clearing my queries from time to time. Their encouragement and advice have been crucial to this thesis.

Lt Cdr Ankur Kulshrestha has been a perfect partner and colleague in our joint eort to develop an Access Control solution for the Indian Navy. His unending persistence and dedication was inspirational. His deep insight on the implementation aspects proved critical in shaping my work. He has been a true friend and associate during the course of my stay at IIT Kanpur.

I would also like to express my gratitude to Dheeraj Gedam, Anshul Data, Rahul Kulkarni and Satyam Sharma for their support and help. Discussions with them were revealing and aided as the rst level for understanding SCOSTA and PKI framework. Thanks are also due to each of my batch mates and peers not mentioned here for their continued support.

A special mention of thanks goes to my wife for being a tremendous support and motivation throughout this duration.

(6)

with zeal and enthusiasm for which I am thankful to the sta of Computer Science Engineering department, IIT Kanpur. They have provided me all the support needed for the successful completion of the project.

(7)

List of Figures

2.1 A Typical File Layout . . . 12

3.1 System Layout for Key Management . . . 29

4.1 Card layout of Normal user . . . 39

4.2 Card layout of L1CA/L2CA/Unit Card . . . 43

4.3 Card Layout of ROOT Card . . . 47

4.4 Card layout in Dependent Card . . . 49

(12)

List of Tables

2.1 CRT templates in SCOSTA-CL . . . 14

2.2 Security algorithms in SCOSTA-CL . . . 15

4.1 Contents of Card Holder Information File (Normal user) . . . 40

4.2 Contents of Card Holder Information File (Normal user) . . . 41

4.3 Contents of Crad Holder Information File (Normal user) . . . 41

4.4 Access Rights in Normal user card . . . 42

4.5 Contents of Card Holder Information le1(L1CA/L2CA/Unit Card) . . 44

4.6 Access Rights of L1CA/L2CA/Unit Card . . . 45

4.7 Contents of Card Holder Information File (ROOT Card) . . . 48

4.8 Access Rights in ROOT Card . . . 49

4.9 Contents of Card Holder Inforamtion File 1(Dependent Card) . . . 51

4.10 Access Rights in Dependent Card . . . 52

4.11 Contents of Card Holder Information File (Casual Visitor Card) . . . . 53

4.12 Access Rights in Casual Visitor card . . . 54

5.1 Proposed Application Modules . . . 56

5.2 Certicates on cards . . . 64

(13)

Chapter 1

Introduction

Security, be it physical security or logical security, is a term synonymous to the Armed forces. Continuous eorts are being made in the direction to achieve utmost security and Armed Forces across the globe have channelized tremendous resources towards this goal. This work is a small step in line with these eorts and has been appreciated to be necessary and urgent in the present scheme of security requirement in the Indian Navy. The Indian Navy at present has a system in place for management and implementation of physical and logical access control. However, since this existing setup is predomi-nantly based on human interactions and is prone to errors, smart cards are being looked into as an alternative solution to plug loopholes in the prevailing setup.

Plastic cards have grown from simple memory cards to micro processor based smart cards to super smart cards with their own key pads and display [15]. The rapid progress made in this eld of technology has seen it increasingly being adopted by var-ied establishments such as e-commerce, telecommunications, security applications etc. Smart card technology with their myriad advantages such as security (tamper resis-tance), exibility, reliability, scalability, multi-utility on a single card, maintainability

(14)

and extremely portable storage have ensured them being adopted for a variety of com-mercial and non-comcom-mercial applications. Keeping in line with technology, the Govt. of India has adopted and specied standards for Smart Card technology [1].

Usage of asymmetric key based cryptographic operations [22, 27] has evolved signicantly and they presently are available on smart cards. Asymmetric key cryptog-raphy involves the use of key pair consisting of a private key and a public key both of which can only be used in a one-way operation for a given algorithm. For example, if a 2048-bit RSA public key is used for encoding operation then the corresponding private key can only be used to decode that encrypted data. A key dened for encoding cannot be used for decoding operations. The private key is specic to a user and therefore is used to identify the user based on operation performed by this key. Public key, on the other hand, are in the open domain and available to anybody in the system. This key is used to encrypt data that is meant to be decrypted only by the corresponding private key held by the intended recipient. Public keys are certied by certication authority which is a third party trusted by both sender and recipient. A public key operation is, therefore, performed only after it is extracted from a certicate after verication. Key management thus forms an integral and most important part of any asymmetric key cryptographic solution. But the most elementary criteria for robust implementation of PKI solution is safety and portability of private keys.

Implementation of PKI based access control system on smart cards for the Indian Navy is the most suitable solution considering the hierarchy and varied authorizations to be exercised by a large number of personnel. The Access Control Solution has a dis-tributed approach for key generation, card making and commissioning and maintenance of central database of personnel information collated. The users involved at every stage of these processes will be required to authenticate themselves and perform their part of operation using special keys that authorize them to do so. Every activity on the smart

(15)

card is logged and maintained in a database for audit purposes.

1.1 Motivation

The identity card presently being used in the Indian Navy has no formidable security feature as would be desired. It relies only on visual security features of the card for identication without authentication. The cards can easily be duplicated and used maliciously. There is a need to move ahead and catch up with the developing smart card technology that provides state-of-the-art solutions for access control and identity management. The evolution of higher levels of security on smart cards by incorporat-ing more advanced algorithms for various cryptographic operations is propellincorporat-ing their increased use in the eld of e-commerce, security, research etc. The use of smart card for a single application such as banking, access control, e-cash etc. have been proven beyond any doubt. But for an organization like the Indian Navy there is immense scope to incorporate many such applications on a single card.

As far as the navy is concerned, a number of applications for canteen, medical information, travel details, pay and allowance details etc. of the individual can be developed and managed on the same card at a later date. It is possible to include multiple applications on a single card with dierent levels / requirements of security. For example, in a naval scenario, the same Smart Card based I-Card can be used to gain access to a ship, purchase items from Canteen, avail facilities of a Club membership with automatic billing, access a bank account (in liaison with a bank), reserve a ticket in train (in liaison with Indian Railways) and so on.

Armed forces across the world are graduating to the smart card technology and have already gone ahead to implement a number of applications mentioned above.

(16)

It is, therefore, felt that there is an inherent need for the Indian Navy to catch up with the evolving technology. Indian Institute of Technology, Kanpur has successfully undertaken work on developing SCOSTA-CL and its subsequent implementation in National ID cards, Driving license and Vehicle Registration Cards [30], e-Passports etc. The institute's current endeavor to build Public key Infrastructure on the existing SCOSTA-CL and thus develop SCOSTA-PKI specications for smart card technology was one of the most motivating factors for undertaking this work. Being government machinery, it was prudent to develop this application on approved National standards and with open technology rather than proprietary solutions to ensure availability of hardware from dierent vendors and prospects of future development in a logical and smooth manner. The existence of a mandate to develop all smart card based application for government projects on SCOSTA has further strengthened the cause of undertaking this development on SCOSTA-PKI and SCOSTA-CL.

SCOSTA-PKI and SCOSTA-CL standards are compliant to ISO/IEC 7816 In-ternational Standards for Smart Cards in addition to other standards like ISO 14443 Type A and B [34, 35] for card communication, ITU-T standard X.509 [14] for Public Key Infrastructure (PKI) for single sign-on and Privilege Management Infrastructure (PMI), PC/SC standards for interface to computer terminal and so on.

1.2 Thesis Statement

The goal of this thesis is to design the card layout and authentication protocol for a robust, secure and scalable architecture framework for Smart Cards based Access Control and Management using Public Key Infrastructure for implementation in the Indian Navy. The card layouts and application interfaces are based on SCOSTA-PKI and SCOSTA-CL standards for smart card implementation. The work carried out in

(17)

this thesis towards achieving the above goal may broadly be classied into the following.

• Design of various user card layouts: Designing layouts of various cards from ROOT

CA through intermediate level cards in the issuing mechanism to the end user cards held by every authorized person. Some of the smart cards like ROOT CA and Level 1 CA are specic to an application but the various levels of user cards are general purpose cards for identication and authentication with access rights dened.

• Design of Protocols for Authentication: The protocols for authentication between

a smart card and an interface device for all operations to be performed on the card.

1.3 Related Work

Smart card implementations are typically based on the ISO/IES 7816 set of interna-tional standards [2, 8]. Although these standards are elaborate and address every aspect of smart card implementations, it was considered necessary to specify some of the ner details more elaborately and do away with any ambiguity before any smart card ap-plication was undertaken by the Government of India. This reasoning led to the joint development of SCOSTA specications [1] by IIT Kanpur and National Informatics Center. IIT Kanpur also developed the rst SCOSTA compliant OS in 2001 for smart cards which was used for the National transport application. This OS was, however, limited in its functionality to the requirements of contact smart cards. The SCOSTA compliant OS was subsequently enhanced for compliance to contactless smart cards with support for secure messaging to avoid the possibility of eavesdropping.

(18)

smart card implementation, it does not support asymmetric key based cryptography. Lack of support for PKI implementation restricts its usage in large user base scenarios where each user might be required to perform cryptographic operations. IIT Kanpur therefore started work to redene the SCOSTA-CL specications to incorporate PKI functionalities. Initial work on dening the specications for PKI based OS was carried out in a partial level by Venkat Rao Pedapati and Simil Dutta in 2007 [19]. Although this work was not compliant to the ISO/IEC 7816 standards, their development of modular exponentiation using crypto-processor in hardware was a major contribution to SCOSTA OS development. This work was then carried forward by Aditi Gupta in 2008 [16] to develop SCOSTA-PKI specications in compliance with ISO/IEC 7816 standards. Barring a couple of functionalities, it covered detailed explanation for most of the salient aspects of PKI implementation in SCOSTA. Work undertaken by Dheeraj Gedam [17] is underway at IIT Kanpur to plug these inadequacies and complete the SCOSTA-PKI compliant OS implementation.

Apart from the constant work being undertaken by IIT Kanpur on developing PKI compliant OS based on the SCOSTA specications, a number of leading compa-nies and eminent individuals have also concentrated their eorts in this direction. Work was done by Konstantinos Markantonakis and Keith Mayes to study the signicance of public key secure channel protocols in smart cards that supported multiple applications [20]. Helena Handschuh and Pascal Paillier carried out detailed analysis of the perfor-mance of smart card arithmetic crypto-processors with respect to some of the major public key cryptosystems [29].

(19)

1.4 Case Studies

This section includes a couple of case studies on similar implementation in government agencies across the world. The smart card technology has been used for varied purposes and the acceptance of this evolving eld indicates its potential to grow.

1.4.1 Common Access Card (CAC)

CAC are smart card based identity cards issued by the United States Department of Defense to its personnel [32]. The DoD established a system which included electronic messaging, network identication and authentication (I&A) services, personal identi-cation, electronic commerce functions, and physical access based on these cards. The CAC cards have been issued to serving military personnel, selected reserved personnel, civilian employees, non-DoD government employees and state employees of National Guard and selected contractors. More than 1000 decentralized card issuance facilities have been set up by DoD across 27 countries and 2000 workstations which collectively have issued more than 17 million smart cards at the rate of approximately 10k cards per day [32].

The main motivation for adopting such a technology was to ensure information assurance and thus reduce the possibility of fraud related to identity management. The physical and logical access security was expected to open up the possibility of e-commerce and in the long run reduce paper work and transaction time thus improving the overall eciency of the system and cost reduction. Commercially O-The-Shelf (COTS) products were taken and twisted as per DoD requirements to manage cost constraints.

(20)

ographically distributed and rewall protected military networks without hampering network performance. Establishment of a robust PKI based identication system for such a large user base over the internet is essential and challenging for exchange of sensitive information. Last but not the least, the users have to be educated and trained for migration from old system to the new smart card based system. Easily accessible help desks and eective public relations eorts were thought to be critical for a smooth transition to the new system.

1.4.2 Singapore Smart Card Standard SSID

Singapore has taken a pioneering approach to the implementation of smart cards as its national ID card. With relevance to this objective, it released the National standard for smart card related application termed Singapore Smart Card ID (SSID) or SS 529 standards [33]. This standard is applicable to all government based smart card applications and the associated hardware. It species the data structure layout, security and access conditions for smart cards containing personal information etc.

The Singapore government has already deployed an estimated 40,000 smart card readers in government and private organizations. Two of the most important govern-ment organizations that have already deployed SS 529 SSID compliant cards and readers include the Civil Aviation Authority of Singapore (CAAS) with card holder strength of 70,000 ID cards at Chengi airport and PSA Singapore terminals with strength of 100,000 ID cards for its port employees. The implementation here is limited to iden-tication and physical access control. Another application based on these standards is the Singpass which is an online portal for card holders to interact with government machinery.

(21)

cards and therefore the Singapore government is well placed to bring in a national smart card based IDS card for every activity from access control, personnel monitoring to e-commerce and computer logging.

1.5 Organization of Thesis

The rest of the thesis is organized as follows. In Chapter 2 we build a background by discussing SCOSTA-CL and SCOSTA-PKI operating system standards in brief, which essentially is the base for work undertaken. We outline the existing Security and Access Control set up in the Indian Navy in Chapter 3. We also describe various levels of users, their authority of operation and give an insight into some of the security attributes in place. In Chapter 4, we explain the various cards required to be developed for the implementation of the management of the I-Card and the data layout of these cards. In Chapter 5, we describe the various protocols for authentication and for any operation that is required to be performed on a smart card. In Chapter 6, we draw conclusion of the work undertaken and discuss its scope in the future.

(22)

Chapter 2

Background

PKI is increasingly being associated with Smart Cards considering the identity and data security that this combination provides. PKI based implementations of iden-tity establishment for a system with large user base wherein each user may perform cryptographic operations is becoming increasingly feasible. Smart Cards with their inherent qualities of tamper resistance, fast cryptographic co-processors, support for multiple-applications, in-built memory, fast and reliable card interface techniques etc. has resulted in their greater acceptance.

2.1 PKI Related Operations

PKI implementation requires a key pair used in tandem to carry out cryptographic operation. The key pair includes a private key and a corresponding public key. The private key is strictly private to the allotted user while the public key is in open domain certied by a trusted Certifying Authority (CA). The operations that a PKI system supports include the following.

(23)

• Authentication: Challenge-response method is the backbone for authentication to

verify and conrm the identity of an entity. A private key operation is performed by an entity to prove its identity.

• Condentiality: The sender encrypts plain text using the intended recipient's

public key. This cipher text can only be decrypted by the receiver that uses the corresponding private key.

• Certicate Verication: Certicate is a standard data structure used to bind a

public key to an entity along with some information such as name, period of validity, algorithm etc. Certicate verication is the process of extracting the public key of an entity using the public key of the CA. The public key thus obtained is trusted by the entity to carry out subsequent cryptographic processes.

• Integrity and Non-Repudiation: PKI uses Digital signatures to ensure non-repudiation

and integrity of the signed data. The data is signed using signer's private key after computation of its hash. The signature verication of this data is done using the signer's public key. The hash value recovered using public key is compared with the hash computed on the received data. Upon a match the receiver is assured of the authenticity of the sender and integrity of the sent data.

• Session Key Establishment: Asymmetric key algorithms are computationally very

intensive as compared to symmetric key algorithms. It is therefore a general practice in PKI implementations to use symmetric key for condentiality and integrity purpose for large data. The asymmetric keys are then used to exchange the symmetric keys. The symmetric keys for the purpose are established for a session between the concerned entities and discarded later. The key usage is restricted to the session that created it.

(24)

2.2 SCOSTA-CL and SCOSTA-PKI

The design of entire solution architecture is based on SCOSTA-CL [1] and SCOSTA-PKI [16] specications for smart card operating systems. These specications are compliant to ISO/IEC 7816 set of standards [2, 8]. SCOSTA-PKI is built over SCOSTA-CL specications to cater for asymmetric key cryptography. It species a number of data structures and asymmetric key algorithms that have been incorporated to support PKI in SCOSTA. Some of the salient aspects of these specications are mentioned below.

2.3 SCOSTA-CL

SCOSTA-CL is generic specication based on ISO/IEC 7816 international standards and is dened for Smart Card implementations by Government of India. An OS com-pliant to these specications support symmetric key cryptography in contact and con-tactless cards. Some of the salient aspects dened by SCOSTA-CL are as follows.

2.3.1 Basic Data Structure

DEDICATED FILE MASTER FILE ELEMENTARY FILE ELEMENTARY FILE DEDICATED FILE DEDICATED FILE ELEMENTARY FILE ELEMENTARY FILE

(25)

SCOSTA-CL supports two categories of les referred to as Dedicated Files (DF) and Elementary Files (EF).The les are arranged in a tree organization with Master File (MF) as the root. Master File is a kind of DF which must exist prior to the creation of any le on the card. The Master File will have DFs and EFs as its children in the tree. The DFs can further have child DFs and EFs. The size of each of these le is static as dened at the time of creation. Data is stored in EFs in one of the following formats dened in ISO/IEC 7816-4 standard.

• Transparent EF

• Linear EF with xed records.

• Linear EF with variable size records • Cyclic EFs with xed size records.

Each le is referenced by a 16-bit le identier. The EFs may also have an additional 5-bit short ID. The DFs may also carry a unique name for referring independent of their location in the le system tree. Depending on the format in which data is stored in these les, it may be referenced either by a record number (1 Byte) or by a record ID (1 Byte) in case of records or as a stream of 8-bit data units.

2.3.2 Security Architecture

SCOSTA-CL species access control mechanisms for command and data in compliance to ISO/IEC 7816-4, ISO/IEC 7816-8 and ISO/IEC 7816-9 standards. It supports se-curity specications at global level, le specic level and command specic level. The security denitions for a card are specied using the following mechanisms.

(26)

2.3.2.1 Security Attributes

Security Attributes of a le are specied in the FCP using Access Mode byte and Security Condition bytes as described in ISO/IEC 7816-4. The AM and SC bytes for a le can be specied either in Compact format or in Expanded format. Security attributes of commands can only be specied in expanded format.

2.3.2.2 Security Environment

Security attributes may refer to certain security conditions for access control. These conditions are dened in a data structure known as security environments. In SCOSTA-CL the security environment denitions can be stored in a separate EF or in the FCP of a DF. A security environment, as per SCOSTA-CL, is dened using Control Refer-ence Templates (CRT). These CRTs [Table 2.1] are used to dene the conditions and requirements for various card operations.

CRT Remarks Condentiality

Template (CT) Encryption and Decryption. Cryptographic

Checksum Template (CCT)

Cryptographic Checksum computation and verication of Authentication

template (AT)

INTERNAL, EXTERNAL and MUTUAL AUTHENTICATION Digital Signature

Template (DST)

Digital Signature computation and verication.

Hash Template (HT) Hash computation

(27)

2.3.2.3 Security Algorithms

SCOSTA-CL compliant OS supports various algorithms [Table 2.2] for message digest, condentiality, integrity and authentication.

CRT Template to which applicable

Algorithm

CT 3DES (Enc and Dec)

CCT 3DES based CBC Residue (CC Computation and Verication)

CCT ISO/IEC 9797-1 Algorithm 3 for MAC using 3DES

AT (AUTH) 3DES based challenge response AT (AUTH) ISO/IEC 11770-2 Key Establishment

Mechanism 6 using 3DES HT SHA-1 as dened in FIPS-140

Table 2.2: Security algorithms in SCOSTA-CL

2.3.2.4 Security Mechanisms

SCOSTA-CL compliant OS supports security mechanisms in compliance to ISO/IEC 7816-4. These security mechanisms include PIN/Password for user authentication, en-tity authentication (INTERNAL, EXTERNAL and MUTUAL) using keys, data in-tegrity by cryptographic checksum computation and verication, data encipherment and decipherment mechanisms, Hash computation and Secure Messaging to ensure in-tegrity and condentiality during data exchange.

2.4 SCOSTA-PKI

(28)

SCOSTA-implementation on smart cards. A SCOSTA-PKI compliant OS supports asymmetric key cryptography only if certain data structures are present in the card.

2.4.1 PKI Related Data Structures

As per SCOSTA-PKI asymmetric key cryptography will be supported on the card only if following data structures are present in the card.

• Directory of Application (EF.DIR): EF.DIR is an internal transparent elementary

le under the Master File and is identied by a pre-dened le identier 2F00. It contains a list of applications supported by the card stored in pre-dened tem-plates. These templates indicate the application ID and some other information along with path to the corresponding DF.CIA.

• Cryptographic Information Application (DF.CIA): DF.CIA is a directory le of

all cryptographic information pertaining to an application. These cryptographic information are stored in various elementary les under the DF.CIA.

• CIA Information le (CIA.Info EF): CIA.Info le is a mandatory le in DF.CIA

(File ID 5032) that contains information about the card and its capabilities as specied in ISO/IEC 7816-15 [9]. The mandatory elds within this le indicate version number and card characteristics.

• Object Directory le (EF.OD): EF.OD is a mandatory le under DF.CIA (File

ID 5031) that contains references to other CIO EFs of the application.

• CIO Directory les: These les under the DF.CIA are all optional, transparent

and for internal use by the OS. They store cryptographic information that refers to actual cryptographic objects like keys and passwords which are themselves stored in some other elementary les.

(29)

2.4.2 Password and Key repository

The directory les reference the Password and Keys, for the application, stored in dierent EFs. SCOSTA-PKI denes a format for storing the keys in their respective les whereas PINs and passwords are stored as per SCOSTA-CL specications. There can be upto 31 records in each repository le with each record containing one cryptographic object.

2.4.3 Operations supported in SCOSTA-PKI

SCOSTA-PKI species certain aspects of PKI operations that a compliant OS must support. Some of these operations that require explicit mention are as follows.

2.4.3.1 Authentication

SCOSTA-PKI supports two algorithms for authentication (INTERNAL/EXTERNAL/MUTUAL), one being a digital signature based and other being encrypted challenge response based

algorithm. Either of these algorithms can be implemented on smart cards. Authen-tication (INTERNAL, EXTERNAL and MUTUAL) based on these algorithms may broadly be explained as below.

• Signature based authentication: In this algorithm, a challenge is sent to the entity

to be authenticated for its signature. The authenticating entity upon receiving the signed challenge veries the signature using the signer's public key. It then compares the value obtained from signature verication with the hash computed on the previously generated challenge. If they match then only the entity is

(30)

• Encryption based authentication: In this algorithm, the entity to be

authenti-cated is issued with a challenge encrypted with its public key. This challenge is decrypted by a user holding the corresponding private key and sent back to the authenticating entity. The authenticating entity compares this response with the previously generated challenge. If they match then only the entity is taken as authentic.

2.4.3.2 Session Key establishment

The computationally intensive asymmetric key based cryptography often establishes a symmetric session key to exchange large encrypted data items [22, 27]. SCOSTA-PKI species a mechanism to establish session key using asymmetric key pairs. The session keys are symmetric keys and may be used for condentiality, integrity or authentica-tion mechanism based on TDES symmetric key cryptography. SCOSTA-PKI species establishment of at least two session keys during a session one for condentiality and other for integrity. Multiple session keys may exist provided they are derived for dierent purposes.

2.4.3.3 Authentication with Session Key Establishment

SCOSTA-PKI species algorithm for asymmetric key based mutual authentication along with session key establishment. This process generates at least two session keys-one for condentiality and another for integrity. The session keys generated thus are for symmetric key use. The condentiality key may be used for encryption, decryption and secure messaging. The integrity key may be used for computation and verication of cryptographic checksum and for secure messaging with message integrity.

(31)

2.4.4 Cryptographic Algorithms in SCOSTA-PKI

In addition to algorithms specied by SCOSTA-CL specications, SCOSTA-PKI also supports asymmetric key based algorithms for condentiality, digital signature, authen-tication and session key derivation. All symmetric key based operations in SCOSTA-PKI are carried out as per TDES algorithm specied in SCOSTA-CL and all asymmetric key based operations are carried out by RSA algorithm.

2.4.5 Additional Commands in SCOSTA-PKI

Some commands of SCOSTA-CL have been suitably enhanced to handle the PKI func-tionality. These enhancements were essentially made in the command headers to rep-resent PKI related information.

• ENVELOPE: In SCOSTA-PKI, the ENVELOPE command is supported and is

used for transmitting a command APDU in T=0 protocol for extended Lc eld as dened in ISO/IEC 7816-3 [2] and ISO/IEC 7816-4 [3] standards.

• GET CHALLENGE: A smart card generates a challenge when a GET

CHAL-LENGE command is issued to it. This challenge is either in cipher text or plain text depending on the algorithm specied in the command. Ref: ISO/IEC 7816-4 for INS = `0x84'.

• INTERNAL/EXTERNAL/MUTUAL AUTHENTICATE: These commands carry

out the authentication of entities and can specify the algorithm to be used for authentication. Ref: ISO/IEC 7816-4 for INS = `0x88'

(32)

SET operation can be used to establish symmetric session keys using asymmetric keys. Ref: ISO/IEC 7816-4 [4] for INS = `0x22'

• PSO ENCIPHER: This operation deciphers the data transmitted in the command

data eld and returns the plain text as response. Ref: ISO/IEC 7816-8 [7] for INS = `0x2A'.

• PSO DECIPHER: This operation enciphers the data transmitted in the command

data eld and returns the cipher text as response. Ref: ISO/IEC 7816-8 [7] for INS = `0x2A'.

• PSO COMPUTE DIGITAL SIGNATURE: A digital signature is computed by

using an algorithm that takes the hash of the message as input and computes the digital signature on it. Ref: ISO/IEC 7816-8 [7] for INS = `0x2A'.

• PSO VERIFY CERTIFICATE: Certicate verication is carried out by issuing

this PSO command. A certicate in X.509 format is passed on to the card in data eld of this command to verify the certicate information. Ref: ISO/IEC 7816-8 [7] for INS = `0x2A'.

2.4.6 Additional Support for APDU in SCOSTA-PKI

SCOSTA-PKI species support for extended length formats for Lc and Le in command APDU as elaborated in ISO/IEC 7816-4. This change in format from SCOSTA-CL is required to handle large data in commands of sizes greater than 255 bytes. PKI cryptography involves handling X.509 certicates and RSA keys in RSA algorithms that are usually larger than 255 bytes. The design of this implementation is based on RSA keys of 2048 bit size.

(33)

Chapter 3

System Requirements

The Indian Navy infrastructure is geographically distributed with huge complexity of the system. The I-Card must work across such infrastructure and must provide en-hanced security.

3.1 Overview of Existing Security System

The Indian Navy is a large organisation that comprises of various establishment, units, oces, aoat ships and vessels, platforms, stations, controlled areas including residen-tial areas spread over across the country. We refer to such establishments as units. Identication and verication of personnel requiring access to any of these units is done manually by checking the I-Cards issued to the person. Instead of technology, there is excessive reliance on manual verication methods that are susceptible to errors due to fatigue, loss of concentration and inability to verify persons when approached in large numbers.

(34)

the existing procedure by a Smart Card based system for authentication and Access Control. There is a nagging need felt to plug the loopholes in the internal security system and adopt new technologies for the purpose.

3.2 Distribution of Naval Establishments

The Indian Navy has its operational, training and administrative establishments spread across the country with the main concentration of personnel and infrastructure being in Mumbai, Vishakhapatnam, Kochi, Delhi and Port Blair. Additionally, there are an excess of two hundred units spread across the country which also need to be brought under the realm of a central and standard identication and verication system for access control.

3.3 Personnel Involved in Various I-Card Related

Ac-tivities

There is a well dened hierarchy of operation for smooth and accountable execution of responsibilities in various branches of the service. The maintenance of internal security, including I-Card issuance and management, is the responsibility of personnel in the Provost branch of the Indian Navy. Various personnel involved in the process of I-Card related activities may be classied as below.

• I-Card Making Authority: The senior-most serving ocer of the Provost branch,

referred to as Naval Provost Marshal, is the I-Card issuing authority respon-sible for all I-Cards made in the navy. The signing authority, referred to as Commander-at-Arms, is the person who actually makes all cards and signs each

(35)

of them on behalf of the card issuing authority. There is one such ocer at all card making locations.

• Regulating Authority: The regulating authority consists of personnel who are

in charge of all I-Card related management and security issues. They collect personal information for I-Card and distribute the cards to the card holder. Sub-sequently, they are responsible for ensuring safety of these cards by conducting regular inspection of cards and card holders in their respective units. Every unit has an ocer, referred to as Regulating Ocer, who is in charge of security man-agement of the unit including matters concerning I-Cards of personnel of that unit. The Regulating Ocer is assisted by a hierarchy of personnel to help in his duties which include reporting loss of I-Card, checking I-Cards for damage and misuse, verify the identity of card holder along with the validity of cards at regular intervals etc.

3.4 Existing Procedure for I-Card Making

I-Cards are made only at designated locations under strict control. A person may apply for making a new I-Card if he is a new recruit or if he got promoted or lost/damaged his old I-Card. Dierent users carry dierent I-Cards depending upon whether he is a Naval person, civilian employee, Security personnel, dependent, casual visitor or part of support system in residential areas. The card issuance procedure is more or less similar but the authorities involved may be dierent.

In case of service personnel, printing of I-Cards is done centrally at one place. These cards are paper based I-Cards with visual features like watermark [38] and guil-loche pattern [39]. Strict accountability and control is maintained over the printed

(36)

and Vishakhapatnam as per their requirements.

To make a new I-Card for service personnel, a request is made to the Regulating Ocer of the unit. All details to be reected on the new I-Card along with photograph are furnished in this application which is carefully scrutinized by the head of the appli-cant's department and Regulating Ocer. The Regulating Ocer forwards this request to the relevant card issuing unit which prints the personal details on the blank card and sends it back to the unit for card personalization. The unit upon receiving this card gets the applicant to furnish his signature and nger print on the card. This completed document is sent back to the card issuing unit which is now signed by the card signing authority with his name and designation. A record of the new card is also made in their archive. The card is laminated and sent back to the unit where the regulating Ocer issues it to the applicant after the old or temporary I-card is revoked.

All other I-Cards for Civilian Employees, Dependents and support sta are made and issued by the Regulating Ocer designated for various units. The printing of these cards is done locally and are held with the regulating ocer under his responsibility. Every individual applies for an I-Card with his personal details and photographs which is scrutinized carefully by the regulating sta. The personal details are printed on blank cards and signed by the Regulating Ocer. Control on these cards is maintained by issuing them with limited validity.

Temporary I-Cards for defence personnel may be issued in case they are not in possession of a permanent I-Card. These cards are issued to personnel undergoing training or to those who have lost or damaged their permanent I-Card. The procedure for making a temporary I-Card is similar to making the Civilian employees cards as mentioned above.

(37)

3.5 Access Control Setup

The prevailing system for access control heavily relies on manual methods of identi-cation and veriidenti-cation. Every individual required to gain physical access presents his I-Card to a sentry at the gate for identication. The sentry visually identies this person based on the photograph carried on his I-Card. The procedure remains unchanged even in case of high security conditions. The movement of personnel at entry/exit points to high security areas is manually logged in registers which makes then very cumbersome for reference in future. As far as logical access control is concerned, there is no estab-lished concept of logical access control to the Naval network or any computer. At best these assets are protected by passwords.

3.6 Issues in the Existing System

The existing system as explained above has a number of weaknesses which need to be taken care of for enhanced security. They are enumerated below.

• There is accountability on issuance of I-Cards by the I-Card issuing unit. But

there is no mechanism to check the presence of a malicious card in the system.

• The security attributes on the present cards are all visual and easily replicable.

A duplicate card can be easily made.

• Physical access to a unit is entirely dependent on the manual identication carried

out by sentries. Failures due to human error, fatigue and trac handling during peak hours are an alarming bottleneck.

(38)

• System has no mechanism for authenticating an entity. The holder of the paper

based I-Card with noticeable visual security feature such as photograph is always considered authentic and granted access.

3.7 Proposed Design with Smart Cards

The shift from paper based I-Cards to Smart Cards in line with the prevalent technology is likely to improve the security situation considerably. The entire implementation shall include setting up of hardware and software at all applicable locations as per implementation plan. Every user issued with a smart card will be allowed physical or logical access only after he has been correctly authenticated by the system. Hand-held or wall mounted devices would be used to read and authenticate smart cards at gate for physical access and IFDs at computer terminals for logical access.

Dierent types of smart cards are required to be designed in this solution to cater for key management and dierent users in the hierarchy. In addition to a number of advanced visual security features that various technologies such as hologram, laser dots etc. provide, the smart cards will also incorporate high level security for authentication in electronic form with optional biometric verication. This is achieved in the following manner.

• PKI based implementation for authentication, digital signature and condentiality

for user holding unique set of keys.

• Knowledge based authentication mechanism for individuals by means of PIN/Password. • Optional enhanced security feature for logical access by using biometric

(39)

• Card stores the information of units, access to which is permitted to the

card-holder (Entry Permissions).

• Only certain users with pre dened permissions on card can change card

infor-mation

Each card will carry two public-private key pairs that would be used for all asymmetric key based operations performed by the card. The authority to perform these operations is assigned based on the key usage information stored in certicates held by the card. A detailed key management plan for the PKI implementation has been designed which elaborates on all entities and operations performed by them. Details of the entities involved and their roles are described later.

It is proposed to implement a distributed database with a system to manage all user information and access logs. This data could be made available to authorized users. The central server will refer to this database for data update every time a relevant data is modied or log is obtained. Industrial strength encryption techniques such as RSA, triple DES or AES will be used for storing data.

Based on CRL alerts received from any unit, the central server would dissemi-nate lost card information to all other units through CRL updates and globally shared database.

3.8 Security Mechanisms

The security mechanisms in line with user requirements that can be implemented using these cards have been described in following paragraphs.

(40)

3.8.1 Certicate Revocation List

Lost card information is published by means of Certicate revocation List signed by the ROOT CA. CRL updates could be made for lost/ damaged cards, if private key is considered to be compromised, changes in roles, card revalidation etc. The CRL updates are pushed to the entire network for updation in their respective databases, servers and card checking devices. Usage of any revoked card can then be controlled by the system.

3.8.2 Entry Permissions

All Naval establishments and assets shall be categorized with entry permissions. It is envisaged that all designated controlled areas will be assigned a unique Entry Permission code. The card shall carry an Entry Permission Code which correspond to a list of units to which the user has access permission. The Smart Card application at a unit shall check the card's privileges in the stored EP codes for that particular unit only. It is envisaged that EP codes will be saved as a bit string. A card can have EP codes of multiple units on it. Only authorized user will be allowed to upgrade or downgrade entry permissions.

3.8.3 Security levels

The solution establishes a higher level of authentication during high security conditions. Under normal conditions a challenge response authentication of the card is carried out to grant access. But under high security conditions the card holder is also required to present his nger print as well for matching with the reference nger print information stored on the card.

(41)

3.9 Entities of Smart Card solution

The solution is designed to be as close a replica as possible to the existing system in the Indian Navy for I-Card making and management. The personnel who would form part of the entities in the new system [Fig. 3.1] may be trained to undertake I-Card making and management operations. The various users and their permissions and responsibilities are explained below.

Level 1 CA (Core ID Cell) Civilian Employees Level 5 Users of Core ID Cells Level 2 User (ID Cell) Level 0 User Defence Personnel Level 5 User Level 3 User Root CA Level 2 User

Unit Key & EP Code Update

Level 1User

Dependents Casual Visitors Unit Owner

Zone Owner

Figure 3.1: System Layout for Key Management

3.9.1 ROOT CA

(42)

infras-cards, referred to as ROOT infras-cards, which carry partial ROOT CA key information and the card holder's biometric and personal information. The ROOT cards will have their own shared symmetric key which would be used to authenticate among the ROOT cards. Any two of the three cards will be required to generate the ROOT CA key.

3.9.2 Level 1 CA

Level 1 CA is essentially required in the certicate chain of the PKI infrastructure to reduce load in the ROOT_CA. One Level 1 CA card will be made for each core ID cell with their certicates signed by ROOT CA. These cards will be exclusively used only for signing the Level 5 user cards of the Core ID cell and Level 2 CA cards of all the other ID cells.

3.9.3 Level 2 CA

One Level 2 CA card will be made for each core ID cells where I-cards for all non-naval personnel will be made. These cards will also be used exclusively for signing the Level 5 user cards under that ID cell of which it is the owner.

3.9.4 Level 5 users

A Level 5 user is designated high level user at the ID cell and will have associated permissions to do operations on all smart cards. Their roles are assigned on their personal cards by issuing relevant certicates. A Level 5 user will be authorized to make I-Cards at respective ID cells and to update user information on the I-Cards.

(43)

3.9.5 Unit Owner

These are exclusive cards issued per unit and signed by a Level 5 user of an ID cell. This card will only be used for creation of a new security zone and signing the certicates for those zones. The EP code assigned for the new zone will be signed by a L5 user.

3.9.6 Zone Owners

The Zone owner is a virtual entity within the unit card. A zone owner is represented by a zone certicate signed by the unit. The zone owner is required for ease of implementing a secure and scalable method for entry permissions to dierent zones.

3.9.7 Level 3 users

This is a higher level user assigned with certain role in the PKI infrastructure. The higher level of authority is dened on his personal card by an appropriate certicate he holds. This user can perform various operations on a card such as sign certicates for Level 2 user, update EP codes and user levels below him, change card information and assist change lost password in consonance with the card holder.

3.9.8 Level 2 user

A Level 3 user designates a Level 2 user of his zone/unit by signing a certicate on the Level 2 user's card. A Level 2 will have permission to perform operations such as signing certicates for Level 1 user, update EP codes on all cards that are allowed access to his zone/unit. He is allowed to change certain card information and help any user

(44)

with most powers of Level 3 user because these operations are performed by him on most occasions.

3.9.9 User Level 1

A Level 1 user is a sentry at gate responsible for physically authenticating every card. His card is signed by a Level 2 user so that he is authorized to perform his duties which include initiating the hand-held devices to carry out card checking, setting security levels to high or low in hand held devices of his unit and check biometrics of any user.

3.9.10 Normal users

Every user in possession of a valid personal smart card will use it for all authentication purposes. This card is signed by a Level 5 user at the time of card making. It may have additional certicates signed by appropriate authorities for higher roles assigned to him. Apart from using it for day today physical access and logical access requirements, the card holder is provided with permissions to change own PIN/Password and certain personal details.

3.9.11 User level 4

This user level is reserved for future use when any other application would be incor-porated on the same card. This user would be allowed to create les on this card and implement the application.

(45)

Chapter 4

Smart Card Layout

In this chapter, we describe various cards and their layouts for implementation of Ac-cess control solution designed for the Indian Navy. Based on the proposed solution it is envisaged that there would be ve types of cards each with specic le system architecture. The le parameters on each card are governed either by the role for which that card would be used or by the person for whom it would be used. The normal user card, L1CA, L2CA and Unit cards are designed to support PKI implementation. The ROOT cards, dependent and casual visitor cards support symmetric key algorithms for authentication. Based on card layout architecture, the various cards required to be designed for the access control solution are as follows.

• Normal user card (Level 5, 4, 3, 2, 1, 0 and Civilian employees) • Level 1 CA card / Level 2 CA / Unit

• Dependent card • Casual visitor card

(46)

All these cards may be classied either as personal cards or exclusive cards based on their usage in the overall solution for access control. The authentication and crypto-graphic operations performed may be either asymmetric key or symmetric key depend-ing on the need as described here.

4.1 Assumptions

The le layout and their parameters in each type of card is based on certain assumptions as below

• The personal information on card and parameters of their data elds such as max

length are indicative. They may be accurately dened once the user requirements are nalized.

• The cards may be incorporated with other applications as desired by the user. A

Level 4 user is authorized to make new applications on the card.

4.2 File structure of PKI Cards

The le structure in each card comprises of several les each of which carry specic information on the card. There are some mandatory les that carry information re-quired for internal operation by the card OS and some optional les that carry personal information as required by the access control application.

(47)

4.2.1 Mandatory Internal Files

These are a set of internal les that are considered mandatory for all types of cards envisaged for implementation of access control solution. The les are for internal pur-poses only whose contents are used by the card operating system. The access condition on these les is set so that they are neither readable nor modiable directly. However, some of the le contents may be updated by an application through specic commands such as to enable or disable a Password. Each of these mandatory les will be present in all cards that support asymmetric key cryptography and some of them are specic to the PKI implementation in SCOSTA_PKI compliant OS. The mandatory les are described as below.

1. Application DF: This is a dedicated le under the Master File that represents an application and consists of all les required to support the application on card. The application DFs may be identied by an application ID. In our implemen-tation these les are referred to as L1CA.DF in Level 1 CA cards, L2CA.DF in Level 2 CA cards, Unit.DF in Unit cards and as AC.DF in all cards for personal use.

2. PIN File: There is one record dened in this le to store a Password. This cryptographic object is stored as per SCOSTA-CL specications. The card holder is authorized to change this record upon user authentication using his password. In case of loss of password, the records may be updated by a Level 2 or Level 3 user upon external authentication. This new Password will be single use password allowing the user to update his password with a choice value.

3. Private Key File: This le will have two private keys- Condentiality_Pr.Key and Sign_Pr.Key stored in it. The private keys are stored as per format dened

(48)

dation or as and when deemed necessary. None of these les can however be read by anyone including the card holder.

4. Public Key File: This le stores public keys in a format similar to the private keys. Every card will have two keys- Condentiality_Pu.Key and Sign_Pu.Key stored in this le that correspond to the private keys on the card. In addition to these keys, the ROOT CA public key is also stored as the trusted public key in all PKI supported cards. These keys may be updated by a Level 5 user during card revalidation or as and when deemed necessary.

5. SE File: The security environment denitions to carry out various card operations are stored as records in this le. Every card has its own set of records that dene the conditions for security related operation on that card. The number of records in dierent types of cards may vary.

6. EF.DIR: It contains templates that help in the identication and selection of applications supported by the card. Each of these application templates also indicates a DF.CIA, a directory to store the PKI-related information for the application. If an application template is not present in this le then the card does not support PKI implementation for that application.

7. DF.CIA: The DF.CIA is a directory le for the application that supports PKI implementation and contains cryptographic information objects present in various elementary les.

8. CIA.Info.EF: This le contains information about the card and its capabilities that are stored as per specications mentioned in ISO/IEC 7816-15 [9].

9. EF.OD: The EF.OD contains references to other CIO les of the application which in turn contain information stored as CIOs. These CIOs refer to other elementary

(49)

les that store cryptographic objects such as keys and passwords. Each entry in the EF.OD refers to a particular le containing CIOs.

10. EF.PrKD: This elementary le stores a directory of information objects that refer to the Condentiality_Pr.Key and Sign_Pr.Key present in cards. The CIOs in this le dene Condentiality_Pr.Key for decryption and internal authentication and the Sign_Pr.Key for digital signature computation on a given data item. In case of Dependent and casual visitor cards, this le will not contain reference to Sign_Pr.Key.

11. EF.PuKD: This is an elementary le used to store directory of cryptographic information objects referring to trusted public keys of the Central Certication Authority (CCA). These CIOs are stored with the name of the owner of the public key as specied in the corresponding certicate's subject component.

12. EF.AOD: The EF.AOD stores a directory of CIOs that refer to the Password present in the PIN le. In case of casual visitor cards, this le will not contain reference to any Password since a PIN le does not exist.

4.2.2 Mandatory Application Specic Files

This set of les includes all those application specic les that are necessarily needed to be created as per the design for card layout architecture. They contain information of personal nature. The contents and parameters for these les are similar in all types of cards envisaged for implementation. The personal information contained in these les will remain unchanged except in case of casual visitor cards which are issued temporarily. These les are enumerated as below.

(50)

templates of the card holder. The data may be stored wither in WSQ bitmap [40] or ISO 1000 standard minutiae [41] formats depending upon the biometric solution adopted.

2. Photograph File: A photograph bitmap image of the card holder is stored in this le in appropriate size.

4.2.3 File Structure for Various Cards

The dierence in layout of various cards developed for this solution is governed by the presence/absence of certain les. Every type of card designed for this implementation contains the mandatory internal and mandatory application specic les. However, certain application specic les like Card Holder Information File and Information Security File are created in a card according to the design envisaged for a type of card. The parameters and contents of these les determine the conditions for various operations that can be performed on the card. They are created on a card irrespective of whether the card is exclusive or personal. The layout of various cards is described later.

4.2.3.1 Normal User Card

A normal user card 4.1 comprises of all personal cards issued to service personnel and civilian employees. This will also include the cards held by higher level user such as L5, L4, L3, L2 and L1 users. These cards will contain all the mandatory internal and mandatory application specic les mentioned above. The other les that are present in this card are as explained below.

(51)

DF.CIA 2F 01 MF 3F 00 EF5 30 05 CARD HOLDER INFO. FILE 1 AC.DF 30 00 EF2 30 02 PRIVATE KEY FILE

EF3 30 03 SE FILE

EF4 30 04 PUBLIC KEY FILE

EF.DIR 2F 00 CIA.INFO 50 32 EF.OD 50 31 EF.PrKD 2F 03 EF.PuKD 2F 04 EF.AOD 2F 05 EF1 30 01 PIN/PW FILE EF10 30 0A INFO. SECURITY FILE 1 EF11 30 0B INFO.SECURITY FILE 2 EF6 30 06 CARD HOLDER INFO. FILE 2 EF8 30 08 BIOMETRIC FILE EF7 30 07 CARD HOLDER INFO. FILE 3 EF9 30 09 PHOTOGRAPH FILE EF12 3F 01 SE FILE

Figure 4.1: Card layout of Normal user

1. PIN File: The PIN le is a global le to enable the use of a common Password for any application that might be incorporated at a later stage.

2. SE File (Global): This SE le is created to dened global security parameters. The conditions for updation of records in PIN le are dened in this SE le. This le will contain one record pertaining to updation of the PIN le.

3. SE File: The SE le in a normal user card will contain ve records to dene all possible operations supported by the card type.

4. Card Holder Information File 1: The le consists of card holder's personal infor-mation 4.1 that will generally remain unchanged during the life cycle of the card. This le will also contain information such as card data layout version, EP Codes, validity of card, date of card printing, unique ID number etc. The information in this le, most of which is printed on the card for visual verication, will be readable by all but only a Level 5 user will have permission to update them. The

(52)

Item Name Data Type Option

Flag Remarks DATA LAYOUT

VERSION 4 C Pointer to indicate modication tolatest available version. EP_CODE 32 C 256-bit string

VALIDITY 8 C Card validity. PERSONAL_NO 10(Var) C Personal number LAST_NAME 20(Var) C Last name FIRST_NAME 20(Var) C First name MIDDLE_NAME 20(Var) O Middle name RANK 5(Var) C Rank

UNIT 20 (Var) C Present unit

DOC 8 C Date of Commission COMMISSION

TYPE 3 C Type of commission: PMT/SSC DOB 8 C Date of birth

BLOOD_GROUP 3 C Blood Group: AB+, A+, A-, B+, B-, O+, O- and UNK for unknown NATIONALITY 3 C Nationality code: Stored according

to the ISO3166 standard. Eg: IND,JPN, USA.

GENDER 1 C Gender: M/F

IDPRINT_DATE 8 C Date of I-Card printing Unique_ID 10(Var) C I-Card Number

Table 4.1: Contents of Card Holder Information File (Normal user)

5. Card Holder information File2: This le will contain personal information 4.2 of private nature which will be accessible to level 2 and 3 user after appropriate authentication. The level 2 and 3 users will also be able to update data in this le. The information contained in this le is as shown in Table 4.2 below.

(53)

Flag Remarks

EP_UPDATE 32(Var) C unitname + zone number MARITAL_STATUS 1 C Marital Status

MED_CAT 4 C Medical Category

APPOINTMENT 20 (Var) C Present appt/designation DOJ 8 C Date of joining ship/unit. RAILWAY_STN 25(Var) C Nearest railway station (for

LTC)

LOCAL_GUARDIAN 80(Var) O Local Guardian's name and address

BANKACCNO 10 O Bank account number BANKNAME 3 O Bank name

PAN_NUMBER 25(Var) O Personal account number PARENT_NAME 40(Var) C Parent name

SPOUSE_NAME 40(Var) O Spouse name HOMETOWN 15(Var) C Home town

DEPENDENT_NO. 1 C Number of dependent in the family

POB 25(Var) C Place of birth PMT_ADD 50(Var) C Permanent Address LOCAL_ADD 50(Var) C Local Address ISSUE_AUTH_ID 10(Var) C Issuing authority

identication VALID_TILL 8 C Validity of the card

Table 4.2: Contents of Card Holder Information File (Normal user)

6. Card Holder information File 3: This le contains personal information 4.3 of general nature which will be accessible to the user, level 2 and level 3 users after appropriate user authentication. The card holder will be able to update data in the le. The information contained in this le is as shown in Table 4.3 below.

Item Name Data Type Option Flag Remarks TEL RES 12 bytes O Home phone TEL OFF 12 bytes O Oce phone FAX 12 bytes O Fax

MOBILE 12 bytes O Current Mobile number ICE no. 12 bytes O Emergency Tel. No. EMAIL 20 bytes O email address

(54)

7. Information Security File1: This le stores digital signature of data items stored in the Card Holder Information File 1, Biometric Information File and Photograph File signed by a Level 5 user along with the certicate of signer. This le will also contain certicates issued to the card for the public keys held by it.

8. Information Security File2: This le stores the digital signature on data stored in the Card Holder Information File 2 along with the certicate of the signing Level 2 or Level 3 user. The le will also store other certicates signed by a L2/L3 user.

Access Rights

The access rights for various les on this card are enumerated below in Table 4.4 below.

File File ID READ UPDATE

SE File (Global) 3F 01 Never Never

PIN 30 01 Never (User Auth) OR (EXT Auth L2/3 user)

Private Key 30 02 Never L5 user

SE 30 03 Never Never

Public Key 30 04 Never L5 user CH Information 1 30 05 No Condition L5 user CH Information 2 30 06 L2/3 user L2/3 user CH Information 3 30 07 L2/3 user, card holder Card holder Biometric 30 08 No Condition Never Photograph 30 09 No Condition Never Information Security 1 30 0A L5 user L5 user Information Security 2 30 0B L2/3 user L2/3 user EF.DIR 2F 00 Never Level 5 user CIA.Info 50 32 Never Never EF.OD 50 31 Never Level 5 user EF.PrKD 2F 03 Never Never EF.PuKD 2F 04 Never Never EF.AOD 2F 05 Never Never

(55)

4.2.4 L1CA/L2CA/Unit Card

L1CA cards are made for each of the Core ID cell owners and are used to sign certicates for Level 2 CAs of non-core ID cells and Level 5 users of Core ID cells. The L2CA cards are also exclusive cards held by each of the non-core ID cell owner and are used for signing certicates on L5 user of that ID cell. The unit cards are held by an authorized person in the unit and will be used to sign certicates for zones in that unit and for L3 users for each of these zones. All these cards have the same layout, security environment and security attributes. The personal information elds are also similar.

DF.CIA 2F 01 MF 3F 00 EF5 30 05 CARD HOLDER INFO. FILE AC.DF 30 00 EF2 30 02 PRIVATE KEY FILE

EF3 30 03 SE FILE

EF4 30 04 PUBLIC KEY FILE

EF.DIR 2F 00 CIA.INFO 50 32 EF.OD 50 31 EF.PrKD 2F 03 EF.PuKD 2F 04 EF.AOD 2F 05 EF6 30 06 BIOMETRIC FILE EF7 30 07 PHOTOGRAPH FILE EF1 3001 PIN/PW FILE EF8 30 08 INFO. SECURITY FILE

Figure 4.2: Card layout of L1CA/L2CA/Unit Card

1. PIN File: The PIN le is a local le under L1CA.DF/ L2CA.DF/ Unit.DF ap-plication DFs. The le parameters as well as the record maintained in this le are similar to that in the normal user card. However, in case of loss of Pass-word, the record will be updatable only upon external authentication of a L5 user. Subsequently, the user will update this Password as described earlier. 2. Card Holder information File: The le consists of personal information of the

(56)

Only the card holder will have access rights to this le to read and update data contained in it. The information in this le are tabulated as in Table 4.5 below.

Flag Remarks DATA LAYOUT

VERSION 4 C Pointer to indicatemodication to latest available version. PERSONAL_NO 10(Var) C Personal number LAST_NAME 20(Var) C Last name FIRST_NAME 20(Var) C First name MIDDLE_NAME 20(Var) O Middle name RANK 5(Var) C Rank

UNIT 20 (Var) C Present unit Unique_ID 10(Var) C I-Card number.

Table 4.5: Contents of Card Holder Information le1(L1CA/L2CA/Unit Card)

3. Information Security File: This le stores the digital signature on data stored in the Card Holder Information le, Biometric Information File and Photograph File along with the self signed certicate of the L5 user when the card is rst made. Subsequently when L1CA/ L2CA/ Unit card holder changes, the outgoing card holder signs the new data and appends his certicate.

Access Rights

(57)

Smart Card Layout and Authentication Protocol for Access Control System in Military Application