Solution Architecture for Access Control
System in Military Environment
Ankur Kulshrestha
Department of Computer Science & Engineering
Solution Architecture for Access Control
System in Military Environment
A Thesis Submitted
In Partial Fulfillment of the Requirements For the Degree of
Master of Technology
by
Ankur Kulshrestha
to the
Department of Computer Science & Engineering
Indian Institute of Technology Kanpur
Abstract
With the advent of new technology, latent threat scenarios and new emerg-ing facets of intrusion and sabotage, a need has risen to modify and modernize the military Access Control mechanisms. Smart cards provide convenient and secure mechanisms for personal identification. In this work we have designed a smart card based Access Control System for physical as well as logical access to resources in a military environment.
As a part of this work, the necessary network topologies, roles of control-ling authorities and implementation strategies have been discussed. The software architecture design for the overall solution caters to a modular composition, where off-the-shelf components might be adapted for system’s usage with no loss of function-ality or efficiency. Non-functional attributes like security, usability, speed, reliability, disaster recovery and maintainability etc, have been considered along with functional attributes to provide a robust and ready-to-deploy architectural solution.
The Card Management System uses SCOSTA-PKI as the Smart Card Op-erating System and the system has been designed to effectively utilize the security, access control and cryptographic primitives supported by the card OS. The system design includes Key Management, Role management and Card Lifecycle Management as sub-systems.
The system design also delves into operational processes and provides an overview of the system’s deployment view.
Acknowledgment
I would like to express my gratitude for Dr. Rajat Moona, my thesis supervisor, teacher and mentor. Without his invaluable guidance and infallible patience, this project would never have taken off. I am grateful to him for his enduring efforts in educating me and giving proper direction to my efforts. His deep insight into the subject of System security and SCOSTA has been a source of inspiration to me.
This tribute shall not be complete without a special mention of Dr Manindra Agrawal and Dr Piyush P Kurur. They provided me valuable guidance where I felt stuck for lack of specialist knowledge or experience.
I would like to thank Lt Cdr Vinod Vasudevan for unending support and col-laborative work. This overall project remains a team effort even though the directions of our efforts were slightly at variance. He has been an ideal devil’s advocate, an ef-fective feedback provider and a matchless partner in this endeavor. It is owing to his efforts that we have a secure as well as practicable architecture in place for practical implementation in the Navy.
I thank the entire Computer Science department for providing an environment which is conducive to learning and encouraging for all students. It is only after this course that I can fully appreciate why CSE department at IIT Kanpur is considered one of the best in the nation.
I would also like to extend thanks to my Y7 batchmates and Mr. Satyam Sharma, who made my stay enjoyable and comfortable. They made a great contribu-tion to this project by active participacontribu-tion in endless debates about various aspects of security protocols and other features concerning this project. This in-design peer-review helped shape a lot of crucial aspects of this project.
Finally I would like to thank my family members for motivating me towards doing quality work and enduring with the rigorous academic schedule. A special word
Contents
1 Introduction 1
1.1 Motivation . . . 2
1.2 Overview of existing system . . . 3
1.2.1 Card Issuing Process . . . 4
1.2.2 Special Pass Issuing Process . . . 4
1.2.3 Card Checking at Gates . . . 5
1.2.4 Administrative Control infrastructure. . . 5
1.3 Shortcomings of the Present System . . . 5
1.4 Related Work . . . 7
1.5 Thesis Objective . . . 8
1.6 Thesis Organization . . . 8
2 Background 10 2.1 Overview of Smart Cards . . . 10
2.2 Types of Smart Cards . . . 11
2.2.1 Chip Type . . . 12
2.2.2 Data Transmission mechanism . . . 14
2.2.3 Selection of Card Specifications for Current Project . . . 15
2.3 Smart Card Operating System . . . 15
2.4 Biometrics . . . 16
2.5 Advantages of Smart Card based system vis-`a-vis existing system . . 16
2.5.1 Enhanced Physical Security . . . 16
2.5.2 Digital Security . . . 17
3 Proposed Solution 18 3.1 Network topology . . . 18
3.1.1 Server Topology . . . 19
3.1.2 End Nodes . . . 19
3.2 Functions of End Nodes . . . 21
3.2.1 ID Cells . . . 21 3.2.2 Administrative Locations . . . 21 3.2.3 Gates . . . 22 3.2.4 Information Kiosks . . . 22 3.3 Software Architecture . . . 23 3.3.1 Secure Sign-On . . . 23
3.3.2 Infrastructure Management Layer . . . 23
3.3.3 Security Management Layer . . . 25
3.3.4 Database Management Layer . . . 25
3.3.5 Backup Management Layer . . . 25
3.3.6 Reporting Services . . . 25
3.3.7 Content Management System . . . 25
3.3.8 Identity Management System . . . 26
3.3.9 Public Key Infrastructure (PKI) system . . . 26
3.3.10 PKI ESCROW . . . 26
3.3.11 Scheduling system . . . 27
3.3.12 Update Management . . . 27
3.3.13 Query Generation . . . 27
3.3.14 Mail / Messaging Server . . . 27
3.3.15 Data Collection . . . 28
3.3.16 Biometric System . . . 28
3.3.17 Card Management System . . . 28
3.3.18 Identity and Authentication Layer . . . 28
3.3.19 User Interface . . . 29
3.3.20 Administrative Application . . . 29
3.3.21 Offline Devices . . . 29
4 Card Management System 30 4.1 Entities in Card Management System . . . 30
4.1.3 Level 1 CA . . . 31 4.1.4 Level 2 CAs . . . 32 4.1.5 Level 5 Users . . . 33 4.1.6 Unit Owners . . . 33 4.1.7 Zone Owners . . . 34 4.1.8 Level 4 Users . . . 34 4.1.9 Level 3 Users . . . 34 4.1.10 Level 2 Users . . . 35 4.1.11 Level 1 Users . . . 37 4.1.12 Level 0 Users . . . 37 4.2 User Keys . . . 38
4.3 Key Management Plan . . . 39
4.3.1 Procedure for nominating the initial Root CA . . . 40
4.3.2 Procedure for creating Level 1 CAs . . . 41
4.3.3 Procedure for creating Level 2 CAs . . . 42
4.3.4 Procedure for creating Cards for Level 5 users (Core ID Cell) 43 4.3.5 Procedure for creating Cards for Level 5 users (Normal ID Cell) 44 4.3.6 Procedure for creating an end user card (Defense Personnel) . 45 4.3.7 Procedure for creating a Civilian’s card . . . 46
4.3.8 Procedure for creating a Dependent’s card . . . 46
4.3.9 Procedure for creating Casual Visitor’s card . . . 47
4.3.10 Procedure for initializing operations for critical hardware . . . 48
4.3.11 Procedure for creating a Unit Owner’s card . . . 48
4.3.12 A brief on Security Zones and Entry Permission Codes (EP Codes) . . . 49
4.3.13 Procedure for creating a Zone owner . . . 51
4.3.14 Procedure for creating a Level 3 user . . . 52
4.3.15 Procedure for creating a Level 2 user . . . 54
4.3.16 Procedure for creating a Level 1 user . . . 54
4.3.17 Procedure for assigning Unit Key to users . . . 56
4.3.18 Procedure for assigning EP Code updates to users . . . 57
4.4 Role Management . . . 57
4.4.1 All the role management activities can be covered under two headings. . . 58
4.4.2 Case 1 . . . 58
4.4.3 Case 2 . . . 59
4.4.4 Case 3 . . . 59
4.5 Card Lifecycle Management . . . 59
4.5.1 Card Re-validations . . . 60
4.5.2 Additional Issues . . . 62
4.5.3 Replacement of Lost / Damaged Cards . . . 62
4.5.4 Card Destruction Procedure . . . 63
5 Operational Processes 64 5.1 User Base Creation . . . 64
5.2 Card checking at Gates . . . 65
5.2.1 User Certificate Verification and Authentication . . . 65
5.2.2 EP Code Verification . . . 66
5.2.3 Biometric Authentication . . . 67
5.3 Change own Password . . . 68
5.4 Incoming Procedure . . . 68
5.5 Outgoing Procedure . . . 68
5.6 Email exchange . . . 69
5.6.1 Email Properties . . . 69
5.7 Reporting a Lost Card . . . 70
6 Conclusion and Future Scope 71 6.1 Future Scope . . . 73
List of Figures
2.1 Smart Card(Image courtesy www.tiresias.org) . . . 11
2.2 Smart Card Categorization . . . 12
2.3 Typical Layout of a microprocessor card with crypto co-processor . . 13
3.1 Server Locations’ Topology . . . 19
3.2 End Nodes Network Layout . . . 20
3.3 Proposed Software Architecture . . . 24
4.1 Card creation hierarchy . . . 32
Chapter 1
Introduction
“Security” is a term that has been associated with the Armed forces and its signifi-cance has evolved over refinements around technology, practices or implementations. The advances in technology have brought in multi-dimensional approaches to intru-sion as well as security. Adoption of these technologies and rapid upgradations are the only solution for achieving the minimum necessary standards for satisfactory levels of security. Military facilities and establishments call for highest level of security of myriad kinds of which access control is a pivotal aspect. It is for this reason that military installations and armed forces of various nations are laying more and more emphasis on physical Access Control to sensitive locations by laying stringent guide-lines [8, 11, 7]. Smart card based access control is viewed as the leading technology and the way to go in this direction. This technology is being increasingly deployed across the world in Military, Corporate, Industrial, Banking, Research and Develop-ment EstablishDevelop-ments etc. Electronic Security offered by Smart Card is more robust
cerns of tampering, duplication etc. Undoubtedly the Smart Card based technology provides comparatively more secure and reliable form of identification.
1.1
Motivation
Access Control at military installations is a basic requirement since not everyone can be allowed to enter secure zones. The authenticity and need of the person desirous of entering a secure zone is evaluated by various means and only then the person is allowed entry. In smaller units and field posts, there is an added advantage of personal history in the sense that the sentry at gate knows each and every member of the unit and thus allows people entry based on personal knowledge. In larger establishments, this is achieved by issuing authorized personnel with passes or Identity Cards. Thus I-Cards are the primary means of achieving Physical Access Control in Indian Navy. This system has been in place for a long time now and is well-established. It has been functioning very well till now. However with commonly available technology today that was in use to produce physical and visual features on the I-cards, the system is posed with a threat of fake I-Cards which would be hard to detect. The threat from enemy countries with similar capabilities has become even more prominent than what it was earlier.
The smart card based access control systems have a distinct advantage over paper based I-cards. Such technologies are in place in the Indian Navy on trial basis where smart cards are used to exercise Access Control at local levels. The security-intensive superiority of smart card based systems was openly acknowledged by the armed forces when the Canteen services all over the country were shifted to a smart
card based system [13]. In this thesis, we vision and propose a full-fledged Smart Card based Access Control system for the Indian Armed Forces in general and for Indian Navy in particular.
1.2
Overview of existing system
The present Access Control System of the Indian Navy is largely dependent on paper based I-Cards. These I-Cards are printed at a Government Press and are distributed to local I-Card Issuing Authorities. As and when a person enters active service, he is issued an I-Card and a replacement is issued to the person upon promotion or when the old card is worn out or damaged.
There are certain high security zones where a military person is also not allowed to enter without special authorization. This procedure is usually implemented in one of the two ways. In a large infrastructure, special passes are issued to authorized personnel by the designated authorities. In a small infrastructure, the security staff is notified with a list of authorized personnel.
From security perspective there are issues in both these procedures. The spe-cial pass cannot be revoked once issued and a person can claim to lose his pass and get issued a new one, while the lost pass can be used by a malicious person to enter the secure zone. In the case of normal military ID cards, there is no mechanism to find out if a card issued by a remote authority is still valid or not. Similarly the list of authorized personnel can be altered or changed in between shifts of sentries. Since
attacks. With the advent of newer and more robust technologies like Smart Cards, there exists a possibility of reducing the probability of such attacks to a minimum if not zero. This thesis is an attempt to cover this well-recognized gap.
In this section we shall try to portray various aspects of the existing access control system in practice within the Indian Navy. The entire system can be sub-categorized in following processes.
1.2.1
Card Issuing Process
Every Naval Officer and Sailor is issued an I-Card when he enters the active service. This I-Card is deemed valid as long as its owner feels it is serviceable. If the I-card owner gets promoted or if the Card is damaged due to physical wear and tear, the I-Card owner must request for a new I-I-Card. The punishment in case the card gets lost can be pretty harsh at times. Thus the responsibility of maintenance of the I-Card has been completely delegated to individuals.
1.2.2
Special Pass Issuing Process
If an individual is required to gain access to a restricted high security zone, then appropriate request is made by the individual. Based on this request, the individual is issued a new security pass by the local authority. These passes are usually temporary in nature and have short term validity. As and when the individual’s need for accessing the high security zone ends, his pass is withdrawn and destroyed. At any point in time, it is possible that a user might be using multiple different security passes for gaining entry in different security zones.
1.2.3
Card Checking at Gates
The card is checked at gates by sentries. The sentries are supposed to check for three basic tenets for any individual requesting entry into their establishment.
• Whether the I-Card has been issued by a valid Naval authority. To achieve this, the sentries are made aware of all the different types of cards that might turn up for their scrutiny.
• Whether the card-holder is indeed the person to whom the card was issued. This is done by comparing the photograph on the I-Card with the card-holder.
• Whether the card holder is authorized to enter this specific gate or not. The Sentry may check this against a pre-declared list given to him by the authorities.
1.2.4
Administrative Control infrastructure.
As might be obvious, there are a lot of complicated background processes that support these basic processes of I-Card Issuing and checking. Often this becomes a time-consuming and laborious task.
1.3
Shortcomings of the Present System
Since the entire system is based on various types of paper based I-Cards, all the shortcomings relevant to paper based security are relevant to this system.
• The printed security features on the I-Card have not evolved with time as have on the currency notes. Thus the new age security printing techniques like micro-text, UV printing, watermark, security relief etc. are not used. Even though I-Cards are not very easy to imitate, they can be copied physically, given enough resources and time.
• The photograph of the card-holder is stuck on the card with glue for identifi-cation. Even though the address of card issuer and his seal are partially over-lapping on the photograph, for a reasonably determined and mildly resourceful attacker, replacing the photograph can be easily achieved.
• The user’s signature is placed on the card for his identification if the need arises. However, the very presence of the signature on the card makes them plain for anyone to see and it should not be too difficult for an attacker to forge or copy the signature.
• The official seal placed on the card can be easily copied as it contains no secret design per se, or at least none that is obvious.
• Issuing Authority signature is present on both side of the card to ensure ac-countability and reducing probability of forgery. However, it is a known fact that the Card Issuing authorities are Naval officers in transferable jobs. Since the Cards are being issued at a number of locations, it is not possible for sen-tries to be aware of signatures of all possible Issuing Authorities. Additionally, since the permanent cards do not have an expiry date, the temporal existence of Issuing Authorities makes the number of them to be very large, almost being impractical to keep track of
it is dependent on a human being giving entry. The sentry at high traffic gates has to look at about 1500 to 2000 I-Cards in an hour making the system prone to human errors.
1.4
Related Work
There have been a number of reported works in the related area. A number of world governments have shifted to Smart Card based citizen ID cards or are in the process of research and development towards the same goal. Malasia, Brunei, Hong Kong, Macau, China, Thailand, South Korea, Australia, Belgium, Sweden, Finland, Estonia, France, Italy, Oman, UAE, Saudi Arabia, Bahrain, Yemen, Morocco, Israel and South Africa are some of the countries that have implemented or are planning to implement a citizen ID card based on smart card technology[2]. However, since most of these cards are directly under government control, not much information is available about individual projects.
In the field of Military ID Cards, the Common Access Card (CAC) of the US military is prime [1]. CAC is being used for physical as well as logical access control in the US military and is based on a microprocessor smart card with 32KB storage. Netherlands has issued smart card based ID cards to its military personnel [3].
In India, the e-passport project [5]is underway for issuing smart chip embedded passports to citizens. Also the prestegious national ID project also employes the smart card technology as well as SCOSTA Operating System standards and the pilot project
1.5
Thesis Objective
As a part of this thesis, we developed the software architecture for implementation of an Access Control System based on Smart Card technology. The architecture is mod-ular and it can be implemented using commercially off-the-shelf available products, thus giving the user freedom for his choice of components. The solution architec-ture has successfully mapped existing processes to the new paradigm with no loss of functionality and an appreciable enhancement in the non-functional attributes.
We have also designed the detailed Card Management System component for the overall Access Control System. Since SCOSTA-PKI is a new technology, this is the first time such a system has been designed. The security architecture, key management plan, card lifecycle management processes and operational processes have been defined while maintaining full backward compatibility with the existing system and incurring no additional manpower liabilities to the user.
1.6
Thesis Organization
The rest of the thesis is organized as follows. In chapter 2 we discuss the background of the proposed system and discuss the various technologies that are proposed to be included in our system. In chapter 3, we outline the overall design features of the proposed system including the network topologies relevant to various locations, various operational entities that shall constitute the system along with their hardware requirements and the detailed software architecture for the system. In chapter 4 we shall discuss the particulars of Card Management Component, clearly defining
the roles of involved entities, the intricacies of the Key Management Plan and the issues pertaining to Card Lifecycle Management. The details regarding operational processes with respect to the aforementioned Card Management System and one-to-one mapping of existing system processes to the new Smart Card based system are discussed in chapter 5. We discuss in chapter 6 shall discuss the future scope for expansion of this system and conclude our work.
Chapter 2
Background
The Smart card based identification technologies have grown significantly in the recent past. Smart Card based Access Control systems are a norm today in fields like military, governance, banking, finance and corporate security.
2.1
Overview of Smart Cards
A smart card is a credit card sized [17], security device that offers multiple functions for secure information storage and information processing. A smart card contains a secure VLSI chip embedded in the plastic card [29](Figure 2.1).
Figure 2.1: Smart Card(Image courtesy www.tiresias.org)
2.2
Types of Smart Cards
Smart Cards may be categorized on the basis of the chip technology employed in their manufacturing or based on the communication media supported by the Smart Card device (Figure 2.2).
Figure 2.2: Smart Card Categorization
The two categorization criteria as depicted in Figure 2.2 are orthogonal and a choice for each criterion must be made in order to finalize the smart card technology for implementation. A brief description of these technologies is given here.
2.2.1
Chip Type
This criterion decides the type of chip that goes in the Smart Card. This defines the type of operations the card shall be capable of carrying out.
• Memory Chip. The memory chip cards can be used for storing user data on the card’s EEPROM. This information can be accessed by the user application however the card is not capable of carrying out any processing. Memory Access can be controlled by write-protection or delete-protection based security logic. Such cards are inexpensive but severely limited in application and provide less scalability and flexibility [16].
• Microprocessor Card. The microprocessor based smart cards, as the name sug-gests, have a microprocessor chip embedded in the smart card, which is sup-ported by functional blocks ROM, RAM, EEPROM and I/O Port (figure 2.2.1). The ROM contains the card’s Operating system, which is hard-masked during chip manufacturing phase and thus cannot be changed during the card’s oper-ational lifetime [13]. The EEPROM is the card’s non-volatile memory. Data structures and program code can be written to and read from the EEPROM through an interface to the card’s Operating System. The RAM is the proces-sor’s working memory and is volatile in nature. The I/O interface provides for the communication between the card and the reader. The crypto-coprocessor is a separate module which supports cryptographic algorithms like AES, DES and RSA. Supported algorithms may vary from module to module [13].
2.2.2
Data Transmission mechanism
The communication interface between the smart card and the card reader can be one of the following two types [13].
• Contact Interface. Contact smart cards have to be inserted in a slot in the reader for communication to take place. The smart card has contact pads through which it makes physical contact with the reader’s interface and a physical com-munication circuit is established [17]. This interface has the advantage of not being susceptible to eavesdropping, however over time the card contacts wear out due to physical insertions in the reader slot and thus the life expectancy of the card comes down.
• Contact-less interface. Contactless interface smart cards communicate with the reader over Radio Frequency waves. The card must be in the proximity of the reader for communication to take place [20, 21]. As opposed to contact interface, the contact-less interface is more convenient to use as the card need only be brought in the proximity of the reader. However this interface has got additional security implications as the communication between card and reader is susceptible to eavesdropping as well as denial of service attacks through RF jamming [4]. RF communication speeds are typically better than contact interface communication speed, thus giving faster responses [28].
• Hybrid interface cards. Hybrid interface cards support both contact as well as contactless communication interfaces in the same card. This dual interface availability provides maximum flexibility in card usage, but with additional cost liability [28]. In a hybrid card there may be a single microprocessor chip or two
separate and independent microprocessor chips.
2.2.3
Selection of Card Specifications for Current Project
It can be seen from above comparative analysis that the microprocessor based smart cards provide better security, flexibility and scalability in operation. Similarly the hy-brid interface based data transmission mechanism in smart cards provides maximum flexibility in protocol design and operational usage. Thus, for implementation of this project, Microprocessor Smart cards with single chip and hybrid interface have been favoured.
2.3
Smart Card Operating System
We selected SCOSTA as an operating system for smart card which is the designated national standard [26]. SCOSTA-PKI is an extended version of SCOSTA-CL which supports Public Key based cryptography[12]. SCOSTA-PKI provides a number of cryptographic primitives like RSA[30], digital signature computation[32], user-defined access permissions for data stored on the smart card[12], user-defined access permis-sions for critical command execution[12], on-card certificate chain verification[12] and Secure Messaging between card and reader[26]. Due to these superior security im-plementations and multiple application support, SCOSTA-PKI is considered most suitable for this security intensive Smart Card implementation in a military environ-ment.
2.4
Biometrics
The above mentioned technologies are necessary but not sufficient means of an accu-rate personal identification. The electronic device reading the SCOSTA-PKI based card can only assess that the card has been issued by a genuine authorized person to another genuine authorized user. The backend system can further find out that the card has not been reported lost and all the certificates held on the card are still valid and have not been revoked. Some extent of personal identification can be achieved by provision of PIN or password which can be compared with the reference PIN and password stored on the Card. However, these could have been overheard or coerced from a genuine user by a malicious third party. We also use biometric mechanisms for identification of an individual with the reference templates stored on the card[7].
2.5
Advantages of Smart Card based system
vis-`
a-vis existing system
A number of distinct advantages are evident in this proposed Smart Card based Access Control System as compared to the existing system based on paper I-Cards.
2.5.1
Enhanced Physical Security
The security features embedded in the inner layers of plastic of the smart card shall define how difficult is it to duplicate the card by an adversary. The security features can generally be classified in three categories. Overt features are the features visible
to the naked eye such as Hologram, Kinegram and Optically Variable Ink printing[29]. Covert features are not visible to the naked eye but are verified using an additional device. Examples of these include UV or IR printed text, Taggants and Microtext[29]. Tamper-evident features are not visible generally but they distort the card’s visual form if the card is tampered with. It is pertinent to mention that most of the security features which are hard to break or copy are usually patented and proprietary.
2.5.2
Digital Security
The existing paper based system is completely dependent on sentry’s judgement in the process of card scrutiny for providing physical access control and hence is sus-ceptible to human errors. A Smart Card based system, on the other hand, provides digital security features like PKI based certificate verification, real-time biometric authentication, almost instant revocation of certificates for lost cards etc and thus is considerably more reliable, secure and user-friendly than the existing system.
Chapter 3
Proposed Solution
The new Smart card based system shall be required to support all existing Access Control processes as well as a number of other applications including some which may arise in future. Thus the overall setup of the new system has been designed to be as future proof as possible with existing set of knowledge parameters.
3.1
Network topology
Since the system is expected to cover all naval locations spread over the country, the system design must cater to a distributed and decentralised operation. Almost all naval locations are already on the naval intranet which is implemented using internal means. Since it is a dedicated naval communication network, it is imperative that the new system would be deployed on the same network. The operational nature of this network demands that proper data segregation is maintained. The network is never exposed to Internet and all communication over the network is expected to be
encrypted.
3.1.1
Server Topology
The network shall be under a decentralized control which shall be exercised from up to five locations. These locations shall be housing the server machines, under physical control of the designated Network Administrators. Since the number of locations are small, a fully connected topology is considered viable for connecting these servers. The network management layer shall also support multi-hop communication to cater for link failures. This topology shall have an added advantage of implementing an efficient backup management as well as an effective disaster recovery plan management.
Location 1
Location 3 Location 2
Location 4 Location 5
Figure 3.1: Server Locations’ Topology
may be unreliable, and definitely not connected all the time. Hence the end nodes shall be configured to work in a disconnected mode with no loss of operability and efficiency. These nodes shall be connected in a star topology as any single node’s intermittent connection with the server must have no detrimental effect on any other node’s operation and a mesh topology is considered unnecessary and wasteful as the networked operations are planned to be kept to a minimum. Also the nodes that are considered critical for the system’s security and operational needs shall be maintained continuously available and the infrastructure management layer of the software shall cater to their special conditions. The end nodes are of various types to cater for different functionalities. Server Router ID Cell Secure Location Hand-held Device Printer Printer Information Kiosk Entry to Secure Building Admin Location Dial Up Dial Up Modem ID Cell Admin Location Admin Location Information Kiosk Wall-mounted Device
3.2
Functions of End Nodes
The end nodes and their functionalities are broadly covered in following categories.
3.2.1
ID Cells
ID Cells are the offices where I-Cards for all individuals shall be made. The data for various individuals is collected by ID cell and verified for corrections through their units. The ID Cells shall be responsible for following operations.
• Personalization of I-cards for verified users. This process includes printing per-sonal information on the front of the cards as well as storing electronic perper-sonal data on the cards.
• Commissioning the cards. The cards are then enabled to be used as valid I-Cards. The process of commissioning requires several operations as discussed later.
• Updating the database with details of users whose I-Cards are created.
3.2.2
Administrative Locations
The administrative locations are the designated location in every unit from where various users register requests for updates. These requests may be any of the following.
• Updating server with the logs of incoming and outgoing personnel.
• Any enhancement in user privileges with respect to the system.
• Request by an individual for change of personal information such as phone number on card and in database.
• Receive updates and alerts from the server.
3.2.3
Gates
The gates for entry / exit to a unit or a security zone shall have specialized hardware for exercising Physical Access Control. The gates shall be further sub-divided based on the traffic they get because the number of lanes at any gate shall be decided by the kind of traffic it expects. The nature (vehicular or pedestrians) and amount of traffic at any particular gate is a matter of speculation and any decision can only be taken with experience. The gates shall be having wall-mounted readers as well as hand-held devices for Access Control. These devices will include contact and contactless smart card reader, fingerprint scanner and software to process the card.
3.2.4
Information Kiosks
Information kiosks shall be networked PCs placed in public areas within secure lo-cations like Dockyards to cater for connectivity needs of ships and submarines. The hardware at an information kiosk shall also include a networked PC, a Smart Card Reader and a Fingerprint Reader to be able to authenticate the genuine I-Card and provide services accordingly.
3.3
Software Architecture
The software architecture [Fig 3.6] include the following components.
3.3.1
Secure Sign-On
The access to every local system as well as to every networked resource of this system shall be through a secure sign-on system which shall use the smart card for user identification.
3.3.2
Infrastructure Management Layer
The system deploys several critical devices such as automated door controls and access control for buildings or server components. All such systems must be monitored for failures and appropriate alerts must be generated. The Infrastructure Management Layer provides this functionality.
3.3.3
Security Management Layer
This layer gives support to security protocols which are not directly related to the card’s PKI based encryption and security.
3.3.4
Database Management Layer
This layer performs the policy management of data to and from data base. This layer shall house all databases such as logs of entry and exit, pending requests etc.
3.3.5
Backup Management Layer
As the name suggests, this layer shall be responsible for implementing backup policies and performing scheduled or requested backups.
3.3.6
Reporting Services
This sub-system shall be responsible for report generation and disbursement. Report queries can come to this system through infrastructure management system, database system or user defined report parameters.
3.3.8
Identity Management System
The Identity Management System shall be the repository of all identities on the system for normal users, authorities and hardware devices. The system shall also keep track of certificates that are about to expire or that are already beyond their validity period and generate appropriate alerts.
3.3.9
Public Key Infrastructure (PKI) system
The PKI system shall be responsible for creation, storage and dissemination of public domain certificates.
3.3.10
PKI ESCROW
PKI escrow is a futuristic mechanism that shall be used for disaster recovery of encrypted data in case of loss of cards etc. Almost all data in the system shall be stored in an encrypted form such that only the private key of an authorized in-dividual can decrypt this data. Since this private key is on the Smart Card of each individual, there is no way that it can be recovered in case the card is lost or damaged. In such an eventuality, all the data that was encrypted for the benefit of this lost key is rendered unreadable. The escrow system shall provide a mechanism for recovery of such data.
3.3.11
Scheduling system
A number of activities on the system shall be scheduled through this subsystemsuch as backups, updates etc.
3.3.12
Update Management
Updates such as those for CRL, newer certificates etc. are generated by the server at regular intervals. The update management system shall verify the updates for authenticity and carry out those updates.
3.3.13
Query Generation
Users are authorized to query the database for information pertaining to their personal data or data pertaining to their role. The query generation system shall be the interface between such users and database.
3.3.14
Mail / Messaging Server
Mail server will ensure the mail delivery to users and maintain the confidentiality through cryptographic techniques.
3.3.15
Data Collection
This sub-system shall cater to the system’s requirement of collecting user data for card-creation in a secure manner. The user data shall be collected from various units which shall be offline. The sub-system must cater for secure transfer of data either over network from a remote location or through removable media.
3.3.16
Biometric System
This component takes care of storage, retrieval, authentication and recovery needs for biometric information of users.
3.3.17
Card Management System
The Card Management System is responsible for the management of all functions involving the Smart Cards such as authentication for physical and logical access to system resources, digital signing of document for data integrity and non-repudiation needs, secure mails and messaging etc. The processes governing Card Management including card lifecycle management, card creation and usage protocols, PKI support for cards etc. shall be covered under this component.
3.3.18
Identity and Authentication Layer
This is the user authentication layer for the applications. This layer shall be imple-mented separately for different applications running on a number of different devices,
and might interact with the Secure Sign-on layer for verifying user credentials.
3.3.19
User Interface
User interface layer shall define the graphical interface available to various users de-pending on their roles and credentials.
3.3.20
Administrative Application
This application is the user interface available to users at administrative locations.
3.3.21
Offline Devices
A number of devices mainly the hand-held devices and wall-mounted devices at gates shall work in offline mode and hence, the application running on them shall have a number of above mentioned components integrated in it.
Chapter 4
Card Management System
The Card Management System evolves around entities and their roles, key manage-ment, role management and card lifecycle management.
4.1
Entities in Card Management System
There are several entities with their specific functions for card management.
4.1.1
Naval Root CA
The Root CA is at the apex of the Certifying Authority chain of the Naval PKI system. He is responsible for delegating certifying authority to other entities. Root CA card shall have a special layout and hence this card will not be used for any other purpose. Since the role of Root CA is extremely security intensive and crucial,
insofar that if the root CA card is compromised, then the entire PKI system shall be impacted. Due to this reason, it has been decided that this authority will be split among three people in such a way that any two of them shall be able to exercise this authority jointly but none individually.
4.1.2
ID Cells
The entire hierarchy of cards below Root CA shall be handled at ID Cells. There are several ID Cells out of which some are designated as Core ID Cells. I-Cards of all naval personnel as well as personnel of other armed forces associated with the Navy shall be made at these Core ID Cells. The other ID Cells shall be responsible for creation of all other type of cards like those for Civilians, dependents, casual visitors etc. Every ID Cell be administered by a Level 1 or Level 2 CA.
4.1.3
Level 1 CA
Level 1 Certifying Authorities are under the root CA in the certifying authority chain. The smart card based I-Card for naval personnel shall be made at core ID Cells, administered by a Level 1 CA. Level 1 CA card shall be a special card and it shall not be used for any other purpose. Level 1 CA authority is transferable as far as the person holding the authority is concerned, but this authority shall always be vested in the person who is designated as the owner of the Core ID Cell. Level 1 CAs shall sign certificates for some Level 5 users designated for creating cards for defense personnel.
4.1.4
Level 2 CAs
Besides core ID Cells there are several ID Cells which are responsible for creating cards for non-naval personnel. The owners of these ID Cells shall be designated as Level 2 CAs under Level 1 CAs. Similar to Level 1 CA authority, Level 2 CA authority is transferable as far as the person holding the authority is concerned, but this authority shall always be vested in the person who is designated as the owner of the Core ID Cell. Level 2 CAs shall be responsible for creating Level 5 users, who shall in turn be responsible for creating cards for other categories of personnel. It may be bought out that at Core ID Cells, the role of Level 2 CA shall be carried out by the same person who is the Level 1 CA, since Core ID Cell shall also be making cards for some personnel of other categories. Thus the Core ID Cell owner shall also certify himself as a normal ID Cell owner and use this role for creation of normal Level 5 users who shall in turn be responsible for creating cards for other category personnel at the Core ID Cells. Fig 4.1 illustrates this categorization.
Level 1 CA (Core ID Cell Administrators) Cards of other users (End User) Level 5 User (Card Making Authority) Level 2 User (All ID Cell Administrators) Defence Personnel Cards (End User) Level 5 User (Card Making Authority) Root CA
4.1.5
Level 5 Users
These are the roles assigned to employees of all ID Cells including Core ID Cells. Their responsibility is to create I-cards for all personnel of all other categories except defense personnel. Thus the employees of Core ID Cells shall have a dual role to play. When they create defense users they shall be exercising their authority as Special Level 5 users and when they create the card for a civilian, they shall be using their authority as a normal Level 5 user. The employees of Core ID Cells shall be deemed special as their hierarchy does not include Level 2 CAs. These users shall be authorized to create ID Cards for Defense personnel.
4.1.6
Unit Owners
The entire naval setup is sub-divided into a number of pre-defined Units. A Unit is an organizational entity and is the administrative unit for the naval setup. Usually, the units are commanded by a senior Naval Officer who is designated as the Commanding Officer of the Unit. With respect to the PKI setup, the unit shall have a designated Unit owner. This authority shall be exercised by the Commanding Officer of the unit and when the CO gets transferred out, he shall hand over the authority to the new CO. Unit Owner shall be given a special card, which shall be used only for exercising this authority and not be used for any other purpose.
4.1.7
Zone Owners
Any unit may have zero or multiple security zones under it. A security zone can be thought of as the unit of security which is going to be implemented using this system. The users having clearance for entering one security zone are not allowed entering another security zone unless they have specific permission from an authorized user to do so. For example ships and submarines etc. have no security zone under them as they are self-contained units. On the other hand there are operational units which have multiple security zones under them and it is important that zonal integrity is maintained i.e. personnel have access only to one zone but not the other zones belonging to the same unit. For the purpose of this thesis, a maximum of 256 zones have been envisaged. It may also be said that a unit is an organizational entity, while a security zone is a geographical one.
4.1.8
Level 4 Users
These users can create a new application on every naval smart Card, regardless of unit or user level. These users will be very few and will be empowered when a new application is to be distributed. As of now, this is an area for future scope of expansion but no immediate relevance.
4.1.9
Level 3 Users
The Level 3 Users shall be nominated by Unit owners for their units. If any unit has multiple Security Zones and the Unit Owner so desires, he can also nominate Zone
based Level 3 Users in addition to Unit based Level 3 users. While the possibility exists, in practice it almost never happens that different security zones under the same unit are assigned different Level 3 Users. Level 3 authority shall be exercised through a certificate issued by the Unit Owner or the Zone Owner on the personal I-Card of the nominated personnel. Usually the Commanding Officer / Regulating Officer / Security Officer of the establishment in addition to a standby officer shall be assigned this level of authority. The roles and responsibilities of Level 3 users are chiefly that of Regulating Officers and Commanding Officers for establishments in the present setup. For example training bases, operational bases, Dockyards, etc. There can always be multiple Level 3 users appointed in large establishments. A number of user defined alerts can be generated by the system based on the policies defined by a Level 3 user for his unit. For example the RO of a Dockyard might be interested to know how many civilians are working in the yard at night. Moreover, higher level units might also issue alerts or messages, which have to be responded to by the Level 3 users in a unit. These users are empowered to do the following.
• They can appoint Level 2 users in their unit.
• Level 3 users can update hotlist database.
• They can analyze entry/exit data of own unit except concerning officers.
• Can generate returns / reports for submission to higher formations.
be assisting the security zone’s Level 3 users in administrative tasks. Following tasks are envisaged for these users.
1. Helping another user of the same unit (any level) recover his forgotten PIN / Password.
2. Level 2 users can manually enter CRL alert, in case a network based CRL database update fails for a node.
3. Appointment of Level 1 users and relegation of Level 1 users to Level 0 users on an as required basis.
4. As a part of Incoming/Outgoing routine for personnel, Level 2 users can enable or disable EP code for a Level 0, 1 or 2 users. This is relevant for high security zones.
The powers and responsibilities of Level 2 users with respect to the Smart Cards of Level 0 users of their establishment are defined at (a) and (b) above and these are relevant in every independent unit. The roles at (c) and (d) are relevant only for units which have an independent entry/exit point with Level 1 users as sentries. In other words, these are not relevant for Level 2 users whose unit does not have an EP Code, for example the entry to all the ships is controlled through entry to the Dockyard itself, so Level 2 users of the ships will not be able to exercise powers mentioned at (c) and (d) above
4.1.11
Level 1 Users
Level 1 users are the sentries who are entrusted with checking the I-cards of personnel seeking physical access to a secure zone. These are users who can verify the authen-ticity of a Level 0 user’s I-card against Password and Biometrics provided by the card holder as well. This level rights are given to personnel deployed at guard rooms, duty offices, restricted facilities etc. Level 1 users are also entrusted with changing the security level for their area of responsibility. Two security levels are defined as “Nor-mal” and “High”. In normal security level, a routine check of an I-Card involves just user authentication based on a challenge-response or any other similar mechanism. It implies that only the veracity of the card is checked and the authentication given us information that the card was issued by a genuine naval authority. In “High” level security, the biometrics of every Level 0 user is also checked against the biometric details stored on his card. This gives us the system a higher level of certainty in the sense that now the system is checking whether the I-Card is genuine or not as well as checking whether the person carrying the I-Card is indeed the person to whom the I-Card was issued. The Level 1 user at any gate can set the security level based on inputs from his superiors or on his own discretion. Level 1 users shall also be responsible for implementing urgent CRL alerts to the system in an offline mode.
4.1.12
Level 0 Users
A Level 0 user is the end user of the access control system. This level is not indicative of the user’s rank. This user can change PIN / Password stored on his own card only.
4.2
User Keys
Barring a few special cards, the cards for all end users and individual card holders shall have the following keys.
• Authentication key. This key shall be unique to every user and shall be used to authenticate a user for granting him physical or logical access to any resource. The same public key shall be used for assigning different certificates to the user where he might be required to authenticate himself to another card. For example a Level 2 user might be required to authenticate himself to a Level 0 user’s card before he can read the personal details of the user from his card. In this case the Level 2 user shall be given a Level 2 user certificate based on his authentication public key. The same public key is also used for the user’s personal authentication certificate using which he is expected to authenticate at gates while entering or exiting a secure zone.
• Confidentiality Key. This key shall be unique to every user and shall be used for decryption of any incoming messages that are encrypted. Similar to authen-tication key, the same public key shall be used for assigning different certificates to the user where he might be required to receive encrypted messages.
• Digital Signature Key. This key shall be used to sign all outgoing messages from the user and for signing the certificates of users below the card-holder in certificate chain. The same public key shall be used for assigning different certificates to the user where he might be required to digitally sign documents. For example a user is required to sign his personal outgoing emails. He shall do so using his personal digital signing certificate. The same user might also be
assigned the role of a Level 3 user of a unit and he might be required to sign the certificates of Level 2 users of his unit. He shall carry out this role using his digital signing certificate which is assigned to him (by a superior authority) using the same digital signature public key.
4.3
Key Management Plan
In this section, the Certificate management procedures and user creation processes for the above mentioned entities shall be discussed. A pictorial representation of the entire Key management hierarchy has been shown in Figure 4.1. The blocks shown in same color represent that the respective keys are stored on the same cards wherever relevant, even if they represent different hierarchical levels in the Key Management Plan. It also implies that the keys on the same cards are role based and may be exer-cised by the same person in different organizational capacities. Detailed explanation on Card Issuing procedures for all members of this hierarchy is 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 4.2: Key Management Hierarchy
4.3.1
Procedure for nominating the initial Root CA
A new Root CA authority can be created for the system at the centralized control server location. As mentioned above, the Root CA authority is split in three users as nominated by the navy in such a manner that any two users of the three can exercise the operation as Root CA. These cards are to be properly secured by the card holders
since their loss has got very far-reaching consequences towards the security of the entire system. Root CA certificate is self-signed. Following steps shall be involved in creation of these cards.
• A new RCA key pair is generated by the system.
• The RCA private key is split into 3 parts using a pre-defined algorithm. Each part is stored on a separate RCA card. A Symmetric Key is shared between these three cards and authentication with this symmetric key shall be required for reading part private key from the RCA cards.
• The RCA public key is self-signed to generate Root CA certificate. This certifi-cate is disseminated to all the end nodes for reference.
• Personal details of all three users are stored on their respective cards. Users select and store their password / PIN on their card.
4.3.2
Procedure for creating Level 1 CAs
Level 1 CAs are special card holders at five Core ID Locations (Mumbai, Delhi, Vizag, Chilka and Ezhimala). The designated Core ID Cell owners shall be given this authority. The Level 1 CA cards shall be special and shall not be used for personal authentication of the card-holders. Their Certificates shall be signed by Root CA. This additional level in hierarchy has been added to ensure that Root CA is not required to update or issue a large number of cards and to ensure that non-authorized ID Cells are not able to make I-Cards for armed forces personnel. These cards are
• Any two of the three nominated Root CAs shall insert their cards in the system and the system shall authenticate Root CA key.
• The system shall generate the key pairs and certificate for Level 1 CA, which shall be signed by Root CA. The certificate shall be stored on the Level 1 CA’s card and shall be disseminated to identity management system and to end nodes as and when necessary.
• Personal details of user are stored on their respective cards. Users select and store their password / PIN on their card.
4.3.3
Procedure for creating Level 2 CAs
Level 2 CAs are ID Cell owners at all ID Cells including Core ID Cells. At Core ID Cells, the same card holding the Level 1 CA keys shall be used for storing the Level 2 CA keys as well since the owner is same person. At other ID Cells a special card shall be used and this card shall not be used for personal authentication of the card-holders. The Certificates for Level 2 CAs shall be signed by Level 1 CA. This level in hierarchy has been added to cater to the transferrable nature of Level 3 CAs. Following steps shall be involved in creation of these cards.
• Level 1 CA shall authenticate himself to the system.
• The system shall generate the key pairs and certificate for Level 2 CA, which shall be signed by Level 1 CA. The certificate shall be stored on the Level 2 CA’s card and shall be disseminated to identity management system and to nodes as and when necessary.
• Biometric data and personal details of Level 2 CA are stored on his card. Level 2 CA select and store his password / PIN on the card.
4.3.4
Procedure for creating Cards for Level 5 users (Core
ID Cell)
Levels 5 users are the employees of Core ID Cells and are Card Issuing authorities (CIAs) for defense personnel. Every Core ID Cell shall have approximately four to five Level 5 (Special) users. As is implied by the nomenclature, a Level 5 (special) user is just like a normal end user who has been assigned a special role. Thus his card shall also be used as his personal I-Card and his role based certificates shall define his role as a Level 5 User. Level 5 User’s certificate shall be signed by a Level 1 CA, who is his Core ID Cell Owner. Once the role (Level 5 user special) has been defined on the cards of these users, their personal certificates (for defining his role as an end user of User Level 0) shall be signed by another Level 5 user (special) if the card holder is a defense personnel or by a normal Level 5 user if he is a civilian. Following steps shall be involved in creation of these cards.
• Level 1 CA shall authenticate himself to the system.
• The system shall generate the key pairs and certificate for Level 5 user, which shall be signed by Level 1 CA. The certificate shall be stored on the Level 5 user’s card and shall be disseminated to identity management system and to nodes as and when necessary.
This is done to ensure that the card goes on working as a normal card (with no extra privilege) once this Level 5 user is transferred out of the ID Cell.
• Card is personalized by the user. The user stores his biometric information as well as selected PIN/Password on the card.
4.3.5
Procedure for creating Cards for Level 5 users (Normal
ID Cell)
Levels 5 users are the employees of all ID Cells and are Card Issuing authorities (CIAs) for civilians of different categories. Every ID Cell shall have approximately four to five Level 5 users. Just like special Level 5 users, the card of a Level 5 user (Normal) shall also be used as his personal I-Card. Level 5 User’s certificate shall be signed by a Level 2 CA, who is his ID Cell Owner. Level 3 CAs of Core ID Cell shall have two role based certificates, one signed directly by Level 1 CA and another signed by Level 2 CA of Core ID Cell. The former shall be used to sign certificates for defense personnel as Special Level 5 user, while the latter shall be used to signing the certificates for other categories of personnel as normal Level 5 user. The steps in making the card for a normal Level 5 user is exactly the same as those for making the card for a Special Level 5 user except that in this case the certificates are signed by Level 2 CAs.
4.3.6
Procedure for creating an end user card (Defense
Per-sonnel)
All Naval personnel as well as personnel of other armed forces, currently deployed with the Indian Navy, shall be issued a card as an end user. This shall be the user’s personal I-Card and shall be his personal responsibility. The certificates for these cards shall be signed by Special Level 5 users of the Core ID Cell. The following steps shall be followed for creation of an end user card.
• User data Collection. User’s personal data shall be collected from his unit and sent to the concerned ID Cell. The ID Cell shall compile this data and send to the individual’s unit for verification of data correctness. Post-verification, this data shall be signed by the unit owner and when received at ID Cell, shall be deemed proper and be used to create a card for the user.
• Card Generation. The user’s card shall be printed according to the verified personal data and the card shall be encoded according to the relevant data layout. The private / public keys for the user shall be generated by the ID Cell and stored on the card. His certificates are signed by the Special Level 5 user of the Core ID Cell.
• Card distribution. Post generation, the card shall be sent to the individual’s unit for distribution to the end user. The card before sending out shall be locked with a key. The key shall be transmitted to the recipient’s unit through any alternative means of communication. At the recipient’s unit, the card shall be
• Card Commissioning. During the card commissioning process, the user shall store his biometric information in the card along with his chosen Password / PIN. The biometric information shall be signed by two Level 5 users of that particular ID Cell. Passwords and PINs shall be stored as hashes. After the commissioning process, the card is ready for use.
4.3.7
Procedure for creating a Civilian’s card
All civilian employees of the Navy shall be issued with this card. A civilian’s card shall be different in physical appearance from an armed forces personnel’s card. This too shall be the user’s personal I-Card and shall be his personal responsibility. The certificates for these cards shall be signed by Level 5 users of the respective ID Cell. The procedure for creation of a civilian’s card shall be the similar to that of an end user as explained above.
4.3.8
Procedure for creating a Dependent’s card
A dependent is a person who is a family member of an armed forces personnel. These cards shall also be personal cards. The certificates shall be signed by Level 5 users of the ID Cells. Their cards shall be created following the procedure as below
• Personal details of the person desiring entry shall be submitted at the ID Cell by the armed forces personnel who dependent is being issued the card.
• The ID Cell shall encode his personal details on the smart card. The individual’s personal details shall also be printed on the card.
• The card shall be given to the individual in person and at the time of collection of the card, the user shall store his biometric details as well as his chosen password / PIN on the card.
• Only after step (c) shall the keys on the card shall be signed by the Level 5 user of ID Cell, thus making the card usable.
4.3.9
Procedure for creating Casual Visitor’s card
A casual visitor is a person who is allowed to enter a secure zone for a very limited period of time. The card when issued to an individual shall be deemed his respon-sibility. The certificates for these cards shall be signed by Level 5 user. Their cards shall be made at the ID Cell following the procedure as described below.
• Personal details including biometrics of the person desiring entry shall be sub-mitted at the ID Cell in person.
• The ID Cell shall verify that the person is not on the blacklist and shall encode his personal details on the smart card. The validity of the card shall be one day or till some specific time as the case may be. The card shall not be printed with any personal details.
• Upon expiry of card’s validity, the card shall be returned to the ID cell, where-upon the ID Cell shall delete all user information and merge the card with blank cards stock.
4.3.10
Procedure for initializing operations for critical
hard-ware
All hand-held devices, wall mounted readers (SAM module), PCs and server (TPM chip) shall be assigned a unique key-pair for secure identification. Hardware keys shall be deemed valid until revoked. The private key shall be stored on the SAM module / TPM chip on the device and the certificate for these devices shall be signed by a Level 5 user.
4.3.11
Procedure for creating a Unit Owner’s card
Unit Owner’s card is issued to all designated Heads of institutions, Commanding Officers of individual units and additional high functionaries as deemed fit by the user. A Unit Owner’s card is special purpose card and is not to be used for unit owner’s personal use. Since the number of units is known, these cards are made one per unit by the Level 5 users of ID Cells (not core ID Cells) and distributed to Unit Owners after personalization. Their certificates are signed by the Level 5 user. Following procedure shall be followed.
• The Unit’s Commanding Officer or Security Officer requests the local ID Cell for a unit owner’s card along with unit name and specific details.
• Since this process can take place at 50 ID Cells, there is a necessity of synchro-nization. The ID Cell shall forward the request to the identity management system at the server.
system administrator shall also check whether the requesting person is indeed authorized to be a unit owner or not. The server shall also synchronize with other servers to find out if a duplicate request has been made or not.
• After the identity management system is satisfied that the request is genuine and needs to be serviced, it will make a provisional entry in the identity management system in the unit’s name for reference and forward approval to the requesting ID Cell.
• The ID Cell receives the approval.
• Level 5 user of the ID Cell generates the unit owner card, with details of specific unit encoded as well as printed on the card.
• The respective unit owners shall go to the ID Cell and get the cards personal-ized. Once the unit owners have given biometric information and selected their PIN/Password for their card. The card is issued to them.
• ID Cell forwards the newly created unit certificate to the server and identity management system.
4.3.12
A brief on Security Zones and Entry Permission Codes
(EP Codes)
Since there maybe up to 256 security zones and a user may be allowed to enter any permutation or combination of these zones, this information cannot be stored in the form of certificates for paucity of space on the cards. Instead, this information
security zone of a unique unit. Initially when a unit is created, it is assumed that the geographical areas of the unit do not need any special permission to enter, i.e. anyone who has a valid I-Card is allowed to enter all areas of that unit. As and when the unit’s owner feels the need to define a specialized security sensitive zone, he shall send his request for creation of a new security zone to the nearest ID Cell. The new zone shall be created after synchronizing the requirements with all other locations and a new zone owner shall be created by the Level 5 User of the ID Cell. Each security zone shall be assigned a unique bit in the EP Code bit-string when the zone is created. Following are the salient properties of EP Codes.
• The EP Code is a 256 bit long bit-string..
• EP Code bit number 0 is fixed and set to 1 for all cards. This bit represents all non-security intensive areas like hospitals, markets, military residential areas etc.
• EP Code bit number 1 shall be used to signify all zones where a normal card holder can visit presently with his paper based I-Card. This bit shall be set to 1 by default for all Defense personnel and for most civilian employees depending on their nature of job.
• As and when the need arises to allow a user entry to a security zone, an EP Code update shall be written to his card by the L2 User. This shall be the L2 user of the unit if all security zones of the unit have common L2 users and L2 user of the security zone if the unit has separate L2 users for each zone under the unit. The format for EP Code update data structure shall be as depicted in Table 4.1
Data Element Remarks
Update string Format for the string: Unit Name + Zone Number I-Card’s Unique ID Unique ID of the card holder
Timestamp When the update is written to the card Signature Signature on all above fields by L2 user
Certificate Certificate of L2 user who signed EP Code update
Table 4.1: “EP code Update” field contents
• EP Code updates shall be merged with the EP Code bit string of the user by the Level 5 user whenever his card communicates with the ID Cell.
4.3.13
Procedure for creating a Zone owner
The definition and requirements of security zones has been explained above. Following procedure shall be followed for creation of a new security zone.
• The Unit owner requests the local ID Cell for a new security zone.
• Since this process can be initiated by hundreds of units simultaneously, there is a necessity of synchronization. The ID Cell shall verify the claim whether the unit can be given a new security zone or not. This step is necessary because there are units that may never have the need to create a zone under them, for example ships and submarines. The ID Cell shall then forward the request to the identity management system at the server.
• After the identity management system is satisfied that the request is genuine and needs to be serviced, it will assign a provisional Zone ID to the new zone.
shall be resolved either using timestamps on requests or using alphabetical order of the requesting units. After the conflicts are resolved the Zone ID shall be finalized and clearance shall be sent to the concerned ID Cell along with the Zone ID.
• The ID Cell receives the approval and informs the Unit Owner of his Zone number (for examples Zone number 20).
• Unit Owner generates a certificate for Zone owner for the allotted zone num-ber and using his own public key and signs the certificate. This certificate is forwarded to the ID Cell. ID Cell verifies the correctness of the certificate and writes the certificate on the Unit Owner’s card through a Secure Messaging Tunnel. Unit owner allows the write to his card by providing his password. This procedure is necessary because a unit owner is not given write permis-sions to his own card to prevent unit owners from creating local zones without synchronizing with the whole system.
• ID Cell forwards the newly created zone certificate to the server and identity management system.
4.3.14
Procedure for creating a Level 3 user
Level 3 users may be considered the representative of the Unit owner or the Zone owner as the case may be. There may be multiple Level 3 users per unit or zone. Level 3 user role is defined using a
