Ravi .S. Saxena, tAs Additional Chief Secretary D.O. letter no. GOI ...

Ravi .S. Saxena, tAs

Additional Chief Secretary Block 7, 5th floor, Sardar Patel Bhavan, New Sachivalaya, Gandhinagar-382-010

D.O. letter no. GOI/102010/185228/IT

Dear Date: Z 5 JUL Z0\1

As per the National eGovernance plan (NeGP), Department of Information Technology (DIT), Goi had mandated to evolve I adopt standards for all eGovernance applications. As standards are critical to ensure sharing of information and seamless interoperability of Data across eGovernance applications, an institutional mechanism has been set up under NeGP to evolve/adopt standards for eGovernnace. The standards and guidelines published so far are available on the standards website http ://egovstandards. gov.in

2. It is informed by Government of India that it is mandatory for all Government and private agencies involved in the implementation of eGovernance applications in India to adhare to these standards.

3. In view of the above, you are requested 'to take measures to adopt, implement & comply with the guidelines and standards for eGovernance enclosed herewith for building secure and quality and interoperable eGovernance applications which are technology and vendor neutral. It is also advised that in order for eGovernance projects not have interoperability issues and the solution to be interoperable on various platforms, it would be prudent to ensure that the solutions developed are in conformance with the technology standards.

Looking forward for expeditious actions in this regard from your end.

Thanking You,

To

(Ravi S. Saxena)

• All Secretaries Department, GoG, Sachivalaya, Gandhinagar • All Heads of PSUs and HODs • The Chairman & M anaging Director, Gujarat Informatics Limite d Block No: 1, 8th

Floor Udyog Bhavan, Sector-11, Gandhinagar. ...... with request to take • The Managing Director, INDEXT-B, Block no. 18, 2nd Floor, Udyog Bhavan,

Gandhinagar, • The Managing Director, Gujarat Info Petro Limited (GIPL), IT Tower- II, Infocity,

Near lndroda Circle, Airport Road, Gandhinagar- 382009 • State eMission Team (SeMT), consultants, DST • Select file ...... DST.

Tel. +91-23259999 Fax: +91-23250325 E-mail i: [email protected] Website : www.dst.gujarat.gov.in

.,

Policy on Open Standards for e-Governance ___________________________________________________________________________________

______________________________________________________________________Version 1.0 November 2010 Page 1 of 13

Government of India

Ministry of Communications & Information Technology Department of Information Technology

Policy on Open Standards for e-Governance Effective Date : This Policy is effective from the date of notification Preamble Government of India (GoI) aims to make all Government services accessible to the common man in his locality and ensure efficiency, transparency & reliability of such services at affordable costs; in addition to this, GoI endeavours to provide services to all other stakeholders like public agencies and their employees and business communities. To meet this objective, there is a need to cooperate, collaborate and integrate information across different departments. Government systems characterized by islands of legacy systems using heterogeneous platforms and technologies and spread across diverse geographical locations, in varying state of automation, make this task very challenging.

There is a need to identify Open Standards for the consistent, standardized and reliable implementation of e-Governance solutions which meet laid down objectives of the Policy. While selecting Open Standards due consideration will be given to functional and technical requirements and maturity of the standard.

The “Policy on Open Standards for e-Governance” (here after referred to as “Policy”) provides a set of guidelines for identifying such Open Standards.

1. Objective The Policy provides a framework for the selection of Standards to facilitate interoperability between systems developed by multiple agencies. It provides organizations the flexibility to select different hardware and software for implementing cost-effective e-Governance solutions. It, therefore, promotes technology choice, and avoids vendor lock-in. It aims for reliable long-term accessibility to public documents and information in Indian context.

2. Definitions Refer Annexure – I



3. Applicability The Open Standards for e-governance will be adopted /evolved based on this Policy 3.1 They shall be applicable at interface and data archival level of all

systems used for e-Governance. 3.2 They shall be applicable to all prospective e-Governance systems

including businesses (G2G, G2B, G2E and G2C) from the date they come into effect.

3.3 In case of legacy and existing systems : 3.3.1 It will be the responsibility of the application owner to ensure that interfaces of legacy and existing systems adhere to Open Standards when interacting with other systems.

3.3.2 New versions of the legacy and existing systems shall adhere to the Open Standards.

4. Policy Statement GoI shall adopt Single and Royalty-Free (RF) Open Standard progressively for a “specific purpose with in a domain” (herein after referred to as “Area”), to meet the laid down objectives of the Policy. The Open Standard shall have the following characteristics:

4.1 Mandatory Characteristics

An Identified Standard will qualify as an “Open Standard”, if it meets the following criteria:

4.1.1 Specification document of the Identified Standard shall be available

with or without a nominal fee. 4.1.2 The Patent claims necessary to implement the Identified Standard shall

be made available on a Royalty-Free basis for the life time of the Standard.

4.1.3 Identified Standard shall be adopted and maintained by a not-for-profit organization, wherein all stakeholders can opt to participate in a transparent, collaborative and consensual manner.

4.1.4 Identified Standard shall be recursively open as far as possible. 4.1.5 Identified Standard shall have technology-neutral specification. 4.1.6 Identified Standard shall be capable of localization support, where

applicable, for all Indian official Languages for all applicable domains.



4.2 Desirable Characteristics

In case multiple Standards get qualified as Open Standards then the selection of a Single Open Standard shall be endeavoured by further narrowing down based on maximal desirable characteristics given below.

4.2.1 Open Standard having multiple implementations from different

agencies. 4.2.2 Open Standard widely used in India for which technical expertise and

support exists in India. 4.2.3 Open Standard that has Extensions and / or Subsets meeting

mandatory characteristics of section 4.1.

4.3 Non-availability of Open Standard which meets all Mandatory Characteristics In cases, where a standard for an Area meeting all the mandatory

characteristics of the Policy is not available, an alternate standard may be temporarily adopted (here after referred to as Interim Standard). This Interim standard shall be identified by relaxing the mandatory characteristics in the order given below until the standard becomes eligible. Due consideration will be given to functional and technical requirements and maturity of the standard.

a) First the characteristic 4.1.2 shall be relaxed to consider standards

with Fair, Reasonable and Non Discriminatory terms and conditions (FRAND) or Reasonable and Non Discriminatory terms and conditions (RAND) and with no royalty payment.

b) Second the characteristic 4.1.3 shall be relaxed. c) Next, the characteristic 4.1.2 shall be relaxed completely to allow

Standards with RAND/FRAND terms with royalty payments. d) Subsequently the other characteristics shall be relaxed one by one,

on a case to case basis. 4.4 Non-availability of Standards which meets functional requirements In cases, where no standard is available for an Area meeting the

essential functional requirements, GoI shall adopt the most appropriate option, in the following order of preference, as an Interim Standard. Due



consideration will be given to functional and technical requirements and maturity.

o Specifications as per mature Open source reference

implementation(s), where applicable. o Published proprietary specifications as per mature

implementation(s). o Development of a new standard by the Designated Body.

5. Exceptions for Selecting One or More Additional Open Standard in

an Area GoI shall endeavour to adopt Single and Royalty-Free (RF) Open Standard for an Area. However, in view of the sufficient technical justification and in the wider public interest, additional Open Standard(s) in the same Area may be considered by GoI based on the recommendations of the Designated Body. Such standard shall be compatible and bi-directionally interoperable with the already existing selected Open Standard.

6. Review of the Policy

The Government has the right to revise the Policy as and when required.

7. Point of Contact

All queries or comments related to this Policy shall be directed to JS (e-Governance), DIT ([email protected]) and DG(NIC) ([email protected])

8. Implementation Manual

Manual on the Implementation of Policy on Open Standards for e-Governance” can be referred for implementation of this Policy through guidelines, FAQ and rationale.



Annexure – I

1. Data Archival Data Archival is the long-term storage of data which is less frequently used or no longer in active use; the archived data should be retrievable for subsequent usage/reference whenever it is needed.

2. Designated Body An agency appointed by GOI to (i) consider and recommend the selection of additional Open Standard in an Area (ii) give recommendations if multiple Open Standards are available in an Area with equal score on desirable characteristic and (iii) to review Interim Standards to check if it qualifies for adoption as Open Standards or for replacement with alternate Open Standards in that Area (iii) initiate action for formulation of Interim Standard in a situation where no standards are available to meet functional requirements for an Area.

3. Domain A sub-category under an Information Technology field is Domain; specific purpose with in a “Domain” is known as “Area”. For example, “Document type for Web publishing content” is one Area under the “Presentation” domain.

4. e-Governance A procedural approach in which the Government and its citizens, businesses, and other arms of government are able to transact all their activities or at least majority of activities using Information and Communication Technology tools.

5. Essential Claims All claims in a patent that are necessary for implementation of the Recommendation

6. FRAND/RAND An abbreviation for (Fair) Reasonable And Non-Discriminatory, is a phrase that defines a basic set of minimal terms that a patent holder is obliged to offer (such as granting a license that is world-wide, non-exclusive, perpetual, reasonable, and non-discriminatory, etc.) and leaves all other non-specified terms to negotiations between the patent holder and the implementer seeking a license

7. Functional Requirement A function is described as a set of inputs, the behavior, and outputs in a specific Area. A functional requirement describes the functionality that the system is expected to execute; it may be calculations, technical details, data manipulation, processing, any other specific functionality supposed to be accomplished in the specific Area. For example, “Loss-less compression raster image” is an Area under “Presentation Domain” whose Functional Requirement is an image format with compression but without any loss of quality while doing repeated editing. Whereas “Lossy compression raster image” is another Area under “Presentation Domain”, whose Functional Requirement is an image format with high compression and small size by compromising on quality



8. G2B A set of services exchanged between government and the business community.

9. G2C A set of services exchanged between government and the citizen.

10. G2E A set of services exchanged between government and government

employees. 11. G2G A set of services exchanged between government agencies.

12. Interim Standard A standard temporarily adopted as per the process

defined in any one of the sections “Non-availability of Open Standard which meets all Mandatory Characteristics” and “Non-availability of Standards which meets functional requirements” of the Policy on Open Standards.

The Interim Standards would be reviewed regularly by Designated body to check if any of the Interim Standard (i) qualifies to be adopted as an Open Standard or (ii) Any other Standard has been identified as an Open Standard to replace this Interim standard in the Area.

13. Identified Standard A standard which meets maximal essential functional requirements for an Area of e-Governance systems.

14. Interface A boundary across which two independent systems meet and act on or communicate with each other.

15. Legacy System An old method, technology, computer system, or application program that continues to be used, typically because it still functions for the users' needs, even though newer technology or more efficient methods of performing a task are now available.

16. Maturity A Standard is considered mature if different implementations, proprietary/open, are available widely adopted and have been stable for some time

17. New version of Legacy System The legacy system which has

undergone a major version change due to re-engineering like functional changes, architectural changes, technology changes , change in storage mechanism, design implementation changes.



18. Not-for-profit Not-for-profit organisations include major internationally recognized Standards bodies such as the IETF, ISO, IEC, W3C, OASIS including any agency recognized or designated by the GoI as such for the purpose of Open Standards.

19. Open Standard A standard which meets all mandatory characteristics laid down in the Policy.

20. Royalty A stream of payments for use of a certain type of asset/technology, most typically an Intellectual Property Right (IPR).

21. Royalty-Free (RF) A Royalty Free (RF) Standard is a Standard whose license is not conditioned on any payment of royalties, fees and other monetary considerations on its use in an implementation. The RF License is also subject to the following conditions:

a. It shall be available worldwide on non-exclusive basis for the life time of the standard.

b. It shall extend to all Essential Claims owned or controlled by the participating patent holders ( i.e., those developing the standard).

c. It could be conditioned on a grant of a reciprocal RF license. d. It shall not impose any further conditions or restrictions on the use

of any technology, intellectual property rights, or other restrictions on behaviour of the licensee, but may include reasonable, customary terms like relating to operation or maintenance of the license relationship such as the following: choice of law and dispute resolution.

22. Specifications document A document that consists of a set of concise statements of requirements for a system.

23. Standard A specification, method, process or practice for a system that is both widely used and accepted or is sanctioned by a Standards Organization.

24. System A group of interacting, interrelated, or interdependent elements forming a complex whole. Information System is a combination of people, hardware, software, communication devices, network and data resources that processes (can be storing, retrieving, transforming information) data and information for a specific purpose.

Manual on the Implementation of Policy on Open Standards for e-Governance ____________________________________________________________________________________


Manual on the Implementation of Policy on Open Standards for e-Governance Effective Date : The Manual is effective from the date of its notification 1. Purpose

This manual on the “Procedure for Implementation of Policy on Open Standards for e-Governance” (hereinafter referred to as “Manual”) is intended to provide details on the following topics of “Policy on Open Standards for e-Governance”(hereinafter referred to as “Policy” ).

• Policy Implementation Mechanism • Guidelines for Selecting Open Standards as per the Policy • Rationale and Framework for the Policy

This manual should be read along with the Policy 2. Definitions

Refer to Annexure – I

3. FAQs Refer to Annexure – II

4. Policy Implementation Mechanism 4.1 Government of India (GoI) shall identify and prioritize the domains to be

considered for standardization from time to time based on the request from the stakeholders including industry.

4.2 The Principles of the Policy, for identifying a Standard for a “specific

purpose with in a domain” (hereinafter referred to as “Area”) will be applied as given below:

4.2.1. First, the Expert committee will check the Identified Standard

against the Mandatory Characteristics (Policy, Section 4.1) 4.2.2. In case step 4.2.1 does not result in identification of Single

Standard, then the Standard which meets the maximal Desirable Characteristics (Policy, Section 4.2) shall be preferred.

4.2.3. In case step 4.2.2 results in multiple Open Standards (with equal number of Desirable Characteristics), then these Standards shall be referred to Designated Body for further



evaluation. This body shall evaluate these competing Standards based on the functional and technical requirements and maturity of the standards to select a Single Open Standard.

4.2.4. If multiple competing Standards are still available, then the Apex Body on e-Governance Standards shall take the final decision to arrive at a single Open Standard.

4.3 In case of non-availability of an Open Standard for an Area, the Expert Committee for that Area shall appropriately apply Sections 4.3 and Section 4.4 of the Policy, and recommend suitable Interim Standard to be adopted for that Area. The Interim Standards would be reviewed regularly by Designated body to check if any of the Interim Standards (i) qualifies to be adopted as an Open Standard or (ii) Any other Standard has been identified as an Open Standard to replace this Interim standard in that Area.

4.4 Exceptions for selecting one or more additional Open Standard in an

Area shall be applied by the Designated Body as per Section 5 of the Policy document.

4.5 GoI shall publish updated list of selected Open Standards along with

recommendations, if any, for progressive adoption of the selected Open Standards by the stakeholders including industry.

4.6 GoI would establish suitable mechanism which would inter alia undertake activities like monitoring, testing, compliance and comparison of technical merits of competing Standards, developing Open extensions and enhancements as needed for e-Governance and other related activities.

4.7 All future Request for Proposals (RFPs) of e-Governance projects shall

include the guidelines for ensuring compliance to Open Standards as per this Policy.

5. Rationale and Framework for the Policy

(Refer Annexure – III) 6. Review of the Manual

The Government has the right to review the Manual as and when required.

7. Point of Contact All queries or comments related to this Manual should be directed to JS (e-Governance), DIT ([email protected]) and DG(NIC) ([email protected])



Annexure – I Definitions

A-I-1) Apex Body: A competent authority for Approval of Standards.

A-I-2) Expert Committee: A committee setup by GoI under the institutional

mechanism of the Standards to formulate Standards in an identified priority area by following laid down procedure in accordance with Policy on Open Standards for e-Governance and recommending that standard for ratification

A-I-3) Extensions: Additional new-specifications added to the existing

standardized-specifications in order to extend the capabilities of the existing functionalities.

A-I-4) Interoperable: The ability to exchange and use information among

multiple systems. A-I-5) Open Source: Open Source programs are software programs whose

licenses permit users the freedom to run the program for any purpose, to study and modify the program, and to freely redistribute copies of the original or modified program

A-I-6) Patent: A patent is a set of exclusive rights given by a Government of a

country to a patent applicant in which the patent holder is granted the right to prevent others from making, using, selling, offering to sell or importing the invention for a specific period of time. Patents are usually granted for inventions that are considered to be non-trivial, new and novel. Patent grants are territorial in nature in that patents applied for and granted in one country are not automatically recognized in another country.

A-I-7) Vendor lock-in or just lock-in, is the situation in which customers are

dependent on a single manufacturer or supplier for some product (i.e., a good or service), or products, and cannot move to another vendor without substantial costs and/or inconvenience. This dependency is typically a result of Standards that are controlled by the vendor (i.e., manufacturer or supplier). It can grant the vendor some extent of monopoly power and can thus be much more profitable than would be the absence of such dependency. The term is commonly used in the computer industry to refer to the situation that can occur due to a lack of compatibility between different hardware, operating systems or file Standards. Such incompatibility can be intentional or unintentional.



Annexure -II Frequently asked Questions (FAQs)

A-II-1) Who is the audience for the Policy on Open Standards?

The DIT Designated Body / agencies responsible for standardization / adoption of Standards must apply this Policy to check the openness of each standard identified for the respective domain. All projects under e-Governance (G2C, G2E, G2G, G2B) shall adhere to this Policy. However other projects (B2B and B2C) are also encouraged to adhere to this Policy.

A-II-2) Whether the legacy system shall be modified to give Open

interface for inter-operating with other systems?

Yes. The legacy system should be able to interoperate interface level with other systems. The other systems should not be modified to give non-open-standard-interface for inter-operating with legacy systems.

A-II-3) Will any standard, with patent and free from IPR related encumbrance, be considered as Open Standard?

Yes. The standard with patents can be considered as Open standard if

adheres to mandatory characteristics of the Policy. A-II-4) How long the Open Standard should be supported by Solution

Provider? The Open Standard should be supported until the end-user interest

ceases rather than when implementer/Solution Provider business interest declines.

A-II-5) Should the future version of the selected Open Standard have

backward compatibility? While upgrading to a new version of the selected Open Standard for an

Area, the new version should ensure backward compatibility to the maximum extent for interoperability. The new version should be considered for adoption if it is superior to the earlier version.

An Open Standard is considered to be superior to another Open

Standard in the same Area, if it is having better proven characteristics like technical and functional efficiency, stability, quality, maturity, proliferation and performance.

A-II-6) Explain the term “Technology Neutral Specifications”.



Technology neutral specifications are platform independent, where platform can be Operating System/Hardware/Data transmission devices, etc.

A-II-7) How can a single Open standard improve the technology choices? Here “Choice” implies freedom to select the appropriate implementation

of the single selected Open Standard from the available multiple implementations of the standard.

A-II-8) If extensions are made to a standard without publishing it, how

does this affect the main/primary standard? Open Standard from a not-for-profit organization allows creation of

Open Extensions and/or Open Subsets. If some stakeholders create extensions / subsets without publishing, then these extensions / subsets shall not be recommended for use in e-Governance applications by Designated Body. However, the main/primary standard can still be considered without these extensions / subsets.

A-II-9) What is meant by the phrase “Identified Standard should be

recursively Open”? The mandatory characteristics are applicable recursively to the

normative references of the Identified Standard i.e. standards which are essential for the implementation of the Standard of a particular version of the Standard.

A-II-10) Explain the term “Adopted” with reference to the Standard. Not all Standards are developed by the Standards Body. A Standard

could be adopted by bringing together related industries and communities of users, government, vendors, industry and other Standards body. The Standards body articulates requirements, evaluates the existing Standards, identifies the gaps, reorganizes overlaps, fills gaps, publishes guidelines and promotes interoperability.



Annexure – III

Rationale and Framework for the Policy

A-III-1 Technical Standards are used to establish uniform engineering or

technical criteria, methods, processes and practices. To ensure interoperability of e-Governance solutions developed by multiple agencies for various Government departments, it is essential that these solutions conform to established Technical Standards.

A-III-2 For many domains, there are multiple competing Technical Standards

that have evolved for various reasons. These Standards also often get reviewed, revised and updated. For any e-Governance application to simultaneously support multiple Technical Standards is a very complex task. A naive approach would require a quadratic number of en-converters/de-converters- one for every pair of available Standards.

A-III-3 Each of these would also require frequent modification and

maintenance whenever there are any updates/modifications in any of the Standards. Supporting any new Standard would also require considerable development effort and substantial man power. All this will lead to unstable and unreliable systems, defeating the purpose of standardization for e-Governance.

A-III-4 The naive approach is neither desirable, nor necessary. The usual way

out is for each application to be based on a single Standard to which other choices can be bi-directionally converted and/or interfaced. A judicious choice of this single Standard is very critical. Ideally it should be a well established, unencumbered, Open Standard, adopted and maintained in a collaborative and transparent manner by all stake holders. This will ensure maximum choice and a level playing field for all technical innovations which only need to ensure complete conformance with the single selected Open Standard.

A-III-5 This Policy has been designed to meet these objectives. This Policy

recognizes that for some Areas, there may not be any Standard which meet all the mandatory characteristics of Openness. Here, the GoI shall use the procedure outlined in Policy for this purpose.

A-III-6 This Policy also recognizes that in some rare cases, for pressing national needs, , GoI may require the use of additional Standards for certain domains. GoI shall use the procedure outlined in Policy for this purpose.

eGov.BIDS:01 Version: 1.0

November, 2010

Face Image Data Standard for

e-Governance Applications in India

Government of India Department of Information Technology

Ministry of Communications and Information Technology New Delhi – 110 003

i

Contents 1. Introduction ................................................................................................................................ 1

1.1 Scope .................................................................................................................................... 1 1.2 Objective/Purpose ................................................................................................................ 2 1.3 Applicability ........................................................................................................................... 2 1.4 Description ............................................................................................................................ 2

2. Target Audience.......................................................................................................................... 3 3. Type of Standard Document ..................................................................................................... 3 4. Definitions and Acronyms ......................................................................................................... 3 5. Face Image Specifications ........................................................................................................ 4

5.1 Face Image Capturing Device Characteristics ..................................................................... 4 5.1.1 Source Type ................................................................................................................... 4 5.1.2 Pixel Aspect Ratio of the capturing device .................................................................... 4

5.2 Face Image Specifications ................................................................................................... 5 5.2.1 Face Image Type ........................................................................................................... 5 5.2.2 Color Space ................................................................................................................... 5 5.2.3 Inter-eye Distance .......................................................................................................... 5 5.2.4 Pose Angle ..................................................................................................................... 5 5.2.5 Shoulders ....................................................................................................................... 5

5.3 Scene Requirements ............................................................................................................ 5 5.3.1 Expression ..................................................................................................................... 5 5.3.2 Background of Face Image ........................................................................................... 5 5.3.3 Subject and Scene Lighting ........................................................................................... 5 5.3.4 Shadows over the Face ................................................................................................. 6 5.3.5 Shadows in Eye-Socket ................................................................................................. 6 5.3.6 Hot Spots ....................................................................................................................... 6 5.3.8 Eye Glasses ................................................................................................................... 6

5.4 Photograph Size Specifications for Scanning ...................................................................... 6 5.4.1 Width .............................................................................................................................. 6 5.4.2 Height ............................................................................................................................. 6 5.4.3 Aspect Ratio ................................................................................................................... 6 5.4.4 Head Width .................................................................................................................... 6 5.4.5 Head Height ................................................................................................................... 6

5.5 Face image Capture, Storage and Transmission Formats .................................................. 7 5.5.1 Image Capturing Format for Enrolment ......................................................................... 7 5.5.2 Image Capturing Format for Verification ....................................................................... 7 5.5.3 Image Storage/Archival Format ..................................................................................... 7

5.5.3.1 Storage / Archival Format for Normal Memory Devices ....................................... 7 5.5.3.2 Storage Format for Restricted Memory Devices .................................................... 7

5.5.4 Transmission Format for Verification ............................................................................ 7 5.5.4.1 Normal Bandwidth .................................................................................................. 7 5.5.4.2 Restricted Bandwidth .............................................................................................. 8

5.5.5 Transmission Format for Storage / Archival .................................................................. 8 5.5.5.1 For Normal Memory Devices .................................................................................. 8 5.5.5.2 For Restricted Memory Devices ............................................................................. 8

5.6 Face Image Record Format Specifications .......................................................................... 8 5.6.1 CBEFF Header .............................................................................................................. 8 5.6.2 Facial Record Header .................................................................................................... 8 5.6.3 Facial Record Data ........................................................................................................ 9

ii

5.6.3.1 Facial Information ................................................................................................... 9 5.6.3.2 Feature Points ........................................................................................................ 9 5.6.3.3 Image Information ................................................................................................... 9 5.6.3.3.2 Image Data Type ................................................................................................. 9

5.6.4 CBEFF Signature ........................................................................................................... 9 6. Best Practices ........................................................................................................................... 10

6.1 Best Practices for Implementation of Standard Specifications .......................................... 10 6.2 Quality Check List ............................................................................................................... 13 6.3 Face Image Record Format Values .................................................................................. 14

6.3.1 Facial Record Header .................................................................................................. 14 6.3.2 Facial Record Data ...................................................................................................... 14 6.3.3 Facial Information block ............................................................................................... 15 6.3.4 Image Information ........................................................................................................ 16

6.4 Operational Instructions for Image Acquisition .................................................................. 17 6.4.1 Process of Enrolment .................................................................................................. 17

6.4.1.1 Process at Client end ........................................................................................... 17 6.4.1.2 Process at Server end .......................................................................................... 17

6.4.2 Process for Human Visual Inspection and Verification ............................................... 17 7. Annexure ................................................................................................................................... 18

Annexure-I Definitions and Acronyms ..................................................................................... 18 8. References ................................................................................................................................ 21 9. List of Contributors .................................................................................................................. 22

Face Image Data Standard _________ eGov.BIDS:01

Version 1.0 November 2010 Page 1 of 22

1. Introduction The Indian Government proposes to use biometric data for identification and verification of individuals in e-Governance applications. The biometric data includes fingerprint image, minutiae, face image and iris data. This standard deals with usage of face image data for human visual inspection and verification. With the objective of interoperability among various e-Governance applications, the face image data standard for Indian e-Governance Applications will adopt ISO /IEC 19794-5:2005(E). While the ISO standard is broad to cover all possible applications of computer based face recognition and human visual inspection, this standard is more restrictive, as it is limited to human visual inspection. However, this standard does consider the future use of the stored face images for computer based facial recognition. The ISO standard specifications are tailored to meet specific needs of civilian e-Governance applications by specifying certain prescriptive values and best practices suitable in Indian context.

1.1 Scope This standard includes capture and storage specifications of face images for human visual inspection and verification of the individuals in Indian E-Governance applications. A possible future use of these images for computer based face recognition is kept in view during the capture and storage. It specifies a format to store face image data within a biometric data record compliant to the Common Biometric Exchange Formats Framework (CBEFF), given in ISO 19785-1. It also includes best practices recommended for implementation of the specifications in different categories of e-Governance applications. The Indian e-Governance applications will have both biometric identification and verification phases, to ensure there is no duplication of identity and to verify the identity of a person for access to the services of the application. The face image would be mainly used for verification of identity of an individual along with other biometric data like fingerprints/iris image data. In case of missing fingerprints/iris data of an individual, it would be used as primary data for identification/verification. Manual Facial recognition is not sufficient currently for de-duplication. . Computer based face recognition has reasonable accuracy under controlled conditions only. Hence for de-duplication purposes, other biometrics like finger print/iris image are also recommended which are beyond scope of this document. In view of the above, the scope of this standard includes:

a. Characteristics of Face Image capturing device

b. Specifications of Digital Face Image & Face Photograph Specifications intended only for human visual inspection and verification

c. Scene requirements of the face images, keeping in view a future possibility of computer

based face recognition



d. Face Record Format for storing, archiving, and transmitting the information of face

image within a CBEFF header data structure for the purpose of interoperability and usage in future for computer based face recognition.

This standard is sufficiently broad to cover the requirements of all e-Governance applications. The applications may judiciously select the specifications relevant to their needs.

1.2 Objective/Purpose The purpose of this standard is to provide the capture and storage specifications of face images to ensure capture of good quality image and interoperability in Indian e-Governance applications. The specifications are mandated where necessary or recommended as best practices, where possible. The intended applications are:

a. Human visual inspection of facial images with sufficient resolution to allow a human (manual) examiner to ascertain small features such as moles and scars that might be used to verify a person’s identity.

b. Human (manual) verification of identity by comparison of a person’s face against

his/her stored facial image.

1.3 Applicability These biometric Standards would be applicable to all e-Governance applications in India as per the Government’s Policy on Open Standards.

1.4 Description Photograph of the face is commonly used in various types of identification cards and there is wide public acceptance for this biometric identifier. Photograph stored in digital form/electronic representation of portrait i.e. face image, can be used either for display for human visual inspection or for computer based face recognition. As per ISO/IEC 19794-5 Face Image Data standard, there are mainly two types of face images as follows: Basic face image: It specifies face image record format including header and image data. It is a fundamental requirement of face image acquisition. Frontal Image: It is a basic face image that adheres to additional requirements appropriate for frontal face recognition and/or human examination. There are two types of Frontal Face Images - Full Frontal & Token Frontal as described below:



Full Frontal Type: It specifies frontal image with sufficient resolution for human examination as well as reliable computer based recognition. This image includes the full head width, all hair in most cases, as well as neck and shoulders. This image type is suitable for permanent storage of the face information, and it is applicable to portraits for passport, driver license, and other ID cards.

Token Frontal: A face image type that specifies frontal images with a specific geometric size and eye positioning based on the width and height of the image. This image type is suitable for minimizing the storage requirements for computer face recognition tasks such as verification while still offering vendor independence and human verification capabilities. A face needs to be well lighted using controlled light sources, and in frontal pose for visual examination or automated recognition. There are many other technical challenges also associated with robust face recognition, which can be addressed by following standard specifications and recommended best practices. This version of the Face Image Standard describes standard specifications and recommended best practices focused around Frontal Image, which inherits basic image requirements also.

2. Target Audience All e-Governance projects rolled out by Central and State Governments or any other organization using face images or face photographs. Photographers, who capture facial images for e-Governance applications. All Integrators/Biometric Service providers.

3. Type of Standard Document Type: Standard Specifications & Best Practices Enforcement Category: Standard Specifications – Mandatory Best Practices: Recommended

4. Definitions and Acronyms Refer Annexure I



5. Face Image Specifications In the present version of the Standard, the face images are intended only for human (manual) verification in Indian e-Governance applications. These images are mandated to be frontal face images with standard specifications in compliance with International standard ISO 19794-5: 2005(E). Latest technical amendments/enhancements issued by ISO over this standard are being examined, for future versions of this standard. In order to be interoperable among different vendors, it is required that these images be stored in a format compliant to the international standard ISO 19794-5, within the overall Common Biometric Exchange Formats Framework (CBEFF) as per ISO 19785-1. The standard specifications are divided into five components as follows:

a. Face Image capturing Device Characteristics

b. Face Image and Photograph Specifications

c. Scene requirements

d. Face image Capture, Storage and Transmission Specifications

e. Face Image Record Format Specifications.

5.1 Face Image Capturing Device Characteristics

5.1.1 Source Type a. Static face image from a Digital still image camera or Web camera (0x02) which

supports image capturing in a format as specified in section 5.5 and having specifications to meet the image quality requirements.

Refer section 6.1.1(a) for best practices for certain device specifications.

b. Digitized photograph from a flatbed Scanner (0x03) of 118 dpcm (300 dpi) resolution that supports image capturing in a format as specified in section 5.5

Note: Scanner specifications require much more detailing like scanner type, quality requirements, speed etc. In view of the fact that presently many Governance applications may require to use scanner, the present version includes minimum required specifications for scanner. Detailed specifications are being worked out which would be released soon through a corrigendum.

Refer section 6.1.1(b) for best practices. Refer section 5.7.6 of ISO 19794-5:2005 (E) for the source type codes.

5.1.2 Pixel Aspect Ratio of the capturing device Pixel aspect ratio should be 1:1



5.2 Face Image Specifications

5.2.1 Face Image Type The Full Frontal Image should be captured as per the specifications laid down in this Standard. Refer section 8.3 of ISO 19794-5 for more detailing about photographic requirements of full frontal face image type Refer section 6.1.5 for recommended best practices for full frontal image specifications for travel documents

5.2.2 Color Space 24 bit RGB (i.e. Code ox01) Refer section 5.7.5 and Table 12 of ISO/19794-5.

5.2.3 Inter-eye Distance The Inter-eye distance should be a minimum 120 pixels for a head width of 240 pixels. Refer section A.3.1 of ISO 19794-5. Refer section 6.1 for recommended best practices.

5.2.4 Pose Angle Rotation of the head shall be less than ±5 degrees from frontal in every direction (i.e. roll, pitch and yaw).

5.2.5 Shoulders Both the shoulders should be visible.

5.3 Scene Requirements

5.3.1 Expression Expression of the face should be neutral (non-smiling) with both eyes open normally (i.e. code 0x01). This information has to be stored in the facial image header because it would help in automatic face recognition in the future.

5.3.2 Background of Face Image White background is recommended, provided there is sufficient distinction between the face/hair area and the background. In situations where distinction is not clear, a light gray background, up to 18% gray level is permitted. Only one person should be present in the photograph and no other person or object should be present in the background covered in the face image.

5.3.3 Subject and Scene Lighting Natural lighting should be equally distributed on the face Refer section 7.2.7 of ISO 19794-5:2005(E).



5.3.4 Shadows over the Face The region of the face, from the crown to the base of the chin and from ear-to-ear, shall be clearly visible and free of shadows (Refer section 7.2.8 of ISO 19794-5:2005(E)).

5.3.5 Shadows in Eye-Socket There shall be no dark shadows in the eye-sockets due to the brow. The iris and pupil of the eyes shall be clearly visible (Refer section 7.2.9 of ISO/19794-5).

5.3.6 Hot Spots Care should be taken to avoid hot spots (bright areas of light shining on the face (Refer section 7.2.10 of ISO 19794-5:2005(E)).

5.3.8 Eye Glasses Glasses should be clear and transparent to ensure clear visibility of eye pupils and irises. Note: Quality of face image will be checked based on the above specifications. A complete checklist is provided in the best practices section 6.2. The face image will get qualified for storage at the time of enrolment or manual verification, only if it clears all the checklist features.

5.4 Photograph Size Specifications for Scanning Photograph to be scanned for digitization should adhere to specifications of the face image & scene requirements mentioned above. In addition, it should have the following size specifications:

5.4.1 Width The width of the face photograph should be approximately 35 mm (1.4 inches).

5.4.2 Height The height of the face photograph should be approximately 45 mm (1.75 inches).

5.4.3 Aspect Ratio Width to height ratio should be between 1:1.25 – 1.33

5.4.4 Head Width The head width of the face in the photograph should be approximately 20 mm (0.79 inches). The head width relative to photograph width should be between 50% to 70%.

5.4.5 Head Height The head height (chin to crown portion ) of the face in the photograph should be approximately 25 mm (0.98 inches). Head height relative to photograph height should be between 70% to 80% . Refer section A.3.1 of ISO 19794-5 for these specifications.



5.5 Face image Capture, Storage and Transmission Formats

5.5.1 Image Capturing Format for Enrolment For enrolment, the face image can be captured in lossless format (PNG/ JPEG12000/ DNG/ TIFF/ RAW).

5.5.2 Image Capturing Format for Verification For human manual inspection, usually the verification is done by comparing the face of person with printed photograph on the travel document / identity card. However, at times, there may be a need to capture image of the face for verification. Depending upon the e-Governance application sensitivity requirements, the face image for verification can be captured either in lossless format (PNG/ JPEG2000/ DNG/ TIFF/ RAW) or JPEG20002 with compression ratio up to 1:15.

5.5.3 Image Storage/Archival Format Once the face image gets qualified after quality check, it needs to be retained/stored/transmitted. The data storage/transmission format specifications should adhere to the Policy on Open Standards to ensure interoperability, vendor independence, long-term availability of data and optimal utilization of storage space, without affecting the quality of the image. The storage of the image in normal memory devices like client /server systems or restricted memory devices like smart card would be done in the face record format as described in section 5.6.

5.5.3.1 Storage / Archival Format for Normal Memory Devices PNG format (compression algorithm code 5 as per table 3 of ISO 19794-4: 2005(E) The example of such device is Desk top client / Server. Note: The image should never undergo any lossy compression at any stage from the instant of capture to storage in database.

5.5.3.2 Storage Format for Restricted Memory Devices JPEG2000 with compression ratio up to 1:15 (compression algorithm code 4 as per table 3 of ISO 19794-4: 2005(E) The examples of such devices are Smart card, mobile phones etc.

5.5.4 Transmission Format for Verification

5.5.4.1 Normal Bandwidth PNG 1 The usage of term JPEG 2000 in this document means JPEG2000 part- 1 ( for static/still image) , or JPEG2000 Basic or JPEG2000 Core Coding System, or ISO/IEC-15444-1



5.5.4.2 Restricted Bandwidth JPEG2000 with compression ratio up to 1:15

5.5.5 Transmission Format for Storage / Archival

5.5.5.1 For Normal Memory Devices The face image captured during the enrolment process should be transmitted in lossless format (PNG/ JPEG32000/ DNG/ TIFF/ RAW) from client system to the server for storage / archival in the standardized format for future usage.

5.5.5.2 For Restricted Memory Devices Face image can be transmitted in JPEG2000 format with compression ratio up to 1:15.

5.6 Face Image Record Format Specifications This is a format to store face image data within a biometric data record to cater to interoperability requirements of the face image taken by various image acquisition devices. It also stores specific information related to the face image, which would be useful in future automatic verification of face images. CBEFF (Common Biometric Exchange Formats Framework) described in ISO 19794-5 will be adopted. This format is based on ISO 19785-1. The Face Image Record Format is broadly structured as follows:

a. CBEFF Header

b. Facial Record Header

c. Facial Record Data (Facial Information, Feature points, Image Information, Image Data)

d. CBEFF Signature (This is optional as it is used for encrypting & digitally signing the data wherever required.

The format is described below, and for best practices refer section 6.3

5.6.1 CBEFF Header A Standard Biometric Header (SBH) with values, as prescribed in ISO 19785-1 will be stored.

5.6.2 Facial Record Header It has fixed 14 bytes length containing information about the overall record of face image like format identifier (4 bytes), version no (4 bytes), length of record (4 bytes), number of face images (2 bytes). In format Identifier, the value will be 0x464114300 (‘F’ ‘A’ ‘C’ 0x0), version

3 The usage of term JPEG 2000 in this document means JPEG2000 part- 1 ( for static/still image) , or JPEG2000 Basic or JPEG2000 Core Coding System, or ISO/IEC-15444-1



number for this standard will be 0x30313000 (‘0’ ‘1’ ‘0’ 0x0), length of the record includes Facial Record Header and Facial Record Data. Number of face images for this standard is 1.

5.6.3 Facial Record Data ISO 19794-5:2005(E) specifies that the Facial Record Data contains Facial Information, Feature point(s), Image Information and Image Data as detailed below:

5.6.3.1 Facial Information The Facial Information Block of fixed 20 bytes contains fields of Facial Record Data length, Number of Feature points, and additional fields to specify gender, eye color, hair color, property mask, expression, pose angle, pose angle uncertainty. Specifying values for additional fields would be optional. In such cases, the default values would be taken as “Unspecified (Code 0x0)” The feature points are optional in the ISO 19794-5 standard and hence their storage are not required as per this standard as only manual verification is considered here. Therefore, the value of ‘Number of feature points’ in the Facial Information field would be “0x0” (2 bytes). The values of facial information like gender, eye color, hair color, property mask, expression, pose angle, pose angle uncertainty will have to be entered corresponding to the captured image.

5.6.3.2 Feature Points Since the current version of this standard caters to manual verification only, feature points are not stored.

5.6.3.3 Image Information The value of image information like face image type, image data type, width, height, image color space, source type, device type, will have to be entered corresponding to the captured image. 5.6.3.3.1 Face Image Type This standard will store face images in Full Frontal Image type (0x01).

5.6.3.3.2 Image Data Type The Image Data type represents the compression formats of the stored face image. Refer section 5.5.3 for compression types for storage of image data on different types of devices.

5.6.4 CBEFF Signature This is optional as it is used for encrypting and digitally signing the image data, wherever required. Note: Refer section 6.3 for CBEFF detailed structure and the prescribed values tailored to Indian e-Governance applications requirements.



6. Best Practices The e-governance standards are intended for a variety of e-Governance application with varying degree of sensitivity and volume. The specifications in Section 5 are broad in nature to cater to all types of e-Governance applications requirements. This Section covers recommended best practices suitable for various categories of applications.

6.1 Best Practices for Implementation of Standard Specifications 6.1.1 Device Specifications & Operational Instructions Refer section 5.1.1 for Source Type specifications

a. Source type: Digital camera / Web camera i. It should strictly meet the specifications requirements of

the standard

ii. Since the captured face images are to be archived for automatic face recognition in future, it is recommended that for enrolment, preference should be given to Digital Single Lens Reflex (DSLR) or mid range digital point-and-shoot camera

or High end web camera (without any artifacts and fish-eye effect), where output is similar to a digital camera.

Operational Instructions

i. Preference should be given to the use of tethered digital camera / web camera along with APIs to have direct link with computer for image transfer and on line quality check etc, while capturing the face image

ii. The attributes of the camera should be adjusted to meet the standard specifications. Under no circumstances, zoom option of the camera should be used

iii. The vendor should ensure appropriate lighting conditions to meet the quality requirements

iv. In a typical enrolment setup, the camera will be connected to a computer for online checking of quality of facial image, as per the defined parameters listed in Quality Check list at section 6.2, and for conversion of the image into the desired storage formats.

Refer section 6.4 for more detailed operational instructions for acquisition of face images for enrolment /verification.



b. Source Type: Scanner Before scanning the photograph, one should ensure that the paper photograph to be scanned meets the standard specifications of full frontal image Note: Preference should be given to the use of digital camera / web camera with desirable device specifications for capturing the face images

6.1.2 Face Image Specifications

Refer section 5.2.1 for Face Image Type specifications

The full frontal images are required for human visual inspection as-well-as travel documents like Passport, Driver Licenses, identity cards etc. The digital camera / web camera should be positioned appropriately to ensure that specifications mentioned in Section 5.2 are met.

Refer section 5.2.3 for Inter Eye Distance specifications

Inter eye distance specifications can be ensured by different processes such as:

i. Adjusting the distance between the person and camera

ii. Manual measurement of the distance between the eyes

iii. Automatic eye location and inter eye distance computation

on digital face images.

6.1.3 Scene Requirements Refer section 5.3 for Scene requirements

Vendor to certify the quality of the face image by filling check list given in Section 6.2 Refer ISO 19794-5: 20005(E) Section A.3.2.4 for more details. An illustration of acceptable quality of full frontal face image



6.1.4 Face Image Capture and Storage Requirements Refer section 5.5 for Face image capture and storage requirements

For Enrolment Default face image type for storage is “Full Frontal”. However, in case of resource constraints with respect to storage space, option of storing face image using Token Frontal type can be considered. Refer section 9.2.3 of ISO 19794-4:2005(E) for detailing of token image

6.1.5 Use of Full Frontal image for Travel Documents Refer sections 5.2 & 5.4 for face image & photograph specifications

Width of face Image The width of the face image should be a minimum of 420 pixels. Refer section A.3.1 of ISO 19794-5. Height of face Image The height of the face image should be a minimum of 525 pixels. Refer section A.3.1 of ISO 19794-5 Width to Height ratio of image It should be between 1:1.25 – 1:1.33 Head Width The ratio of head width relative to width of the face image should be between 5:7 and 1:2. Head Height The head height (chin to crown portion) of the full face frontal pose should occupy 70% to 80% of the vertical height of the face image

6.1.6 Use of Full Frontal image / Photograph for Identity Cards Refer section 5.2.2 for photograph specifications

The printed full frontal face images are used in ID cards, passports, driving licenses and other documents. Note: The printing size mentioned in section 6.1.5 is recommended for consideration for standardization, which is beyond the scope of this standard.



6.2 Quality Check List Quality check list, as per the specifications & the best practices in Sections 5 and 6.1 5. S.No. Parameter & Prescriptive values Yes No 01 Visual clarity of the output image (no motion blur, no over or under

exposure, no un- natural color, proper and equally distributed lighting with no shadows over the face, no shadows in eye sockets, no hot spots, no radial distortion and no fish-eye effect)

02 Photo taken within 6-months (for enrolment)

03 Pixel resolution for digital camera or web camera – minimum 118 ppcm(300 ppi ) / Scan resolution for scanner minimum approximately 118 dpcm ( 300dpi )

04 Size (width approximately 35 mm (1.4 inches) & Height 45 mm (1.75 inches) in case of scanned photograph

05 Outline of the shoulders Visible

06 Showing white or light gray (18%) background color

07 Background plain (No other objects in the background)

08 Chin to crown clearly visible

09 Head coverage of the person minimum 80%

10 Neutral expression (mouth closed, eyes open)

11 No reflection on Face

12 Showing both edges (both ears) of the face clearly

13 Showing the skin tones naturally

14 Red eye correction done

15 Inter eye distance minimum 120 pixels

16 Looking directly at the camera

17 Eyes open and clearly visible, and not covered with hair or any other obstacle

18 Clearly visible eyes, in case of wearing spectacles, and no color glasses. (If applicable)

19 Spectacles not heavy and not covering eyes (if applicable)

20. No accessories ( Other than turban due to religious reasons, eye patches due to medical reasons supported by medical certificate, small nose ring)



6.3 Face Image Record Format Values Refer section 5.5 for Face image record format specifications

a. Values in shaded rows are variable in nature and need to be entered on case- to case basis

b. Values in other rows are fixed in nature as per ISO 19794-5:2005(E) specifications and should not be altered.

6.3.1 Facial Record Header (Format and fixed values extracted from ISO 19794-5:2005(E))

Field

Size

Value

Format Identifier Indicates face image data

4 bytes 0x46414300 (‘F’ ‘A’ ‘C’ 0x0)

Version Number

4 bytes 0x30313000 (‘0’’1’’0’0x0)

Length of records (Including length of Facial Record Header and Facial Record Data)

4 bytes 46<Length of Record<=232-1

Number of facial images

2 bytes 1

6.3.2 Facial Record Data Prepared based on Figure 2 of ISO19794-5:2005(E)

Field

Size

Value

Facial Information

20 bytes Details in Table at 6.3.3

Feature Point N.A Not stored as the standard is for manual verification only. (This is an optional block in ISO Standard)

Image Information

12 bytes Details in table 6.3.4

Image Data Variable



6.3.3 Facial Information block

Field

Size

Value

Facial Record data length 4 bytes

Number of feature Points 2 bytes 0x0 (No feature points are stored)

Gender 0x0 – Unspecified 0x01 - Male 0x02 -Female 0x0FF- Transgender (Table 3 of ISO 19794-5)

1 byte Relevant value to be entered (0x0 would be the default value, if not filled by vendor)

Eye Color 0x0 - Unspecified 0x01 - Black 0x02 -Blue 0x03 - Brown 0x04 – Gray 0x05 – Green 0x06 – Multi-Colored 0x07 – Pink 0x08-0x0FE – Reserved 0x0FF- Other (Table 4 of ISO 19794-5)


Hair Color 0x0 - Unspecified 0x01 - Bald 0x02 -Black 0x03 - Blonde 0x04 - Brown 0x05 – Gray 0x06 – White 0x07 – Red 0x08-0x0FE – Reserved 0x0FF- Other (Table 5 of ISO 19794-5)


Property Mask 0-Properties are specified

1 Glasses 2 Moustache 3 Beard 4 Teeth visible 5 Blink (either or both

eyes closed) 6 Mouth open 7 Left eye Patch 8 Right eye Patch

3 bytes Relevant value to be entered



9 Dark Glasses (medical)

10 Feature Distorting Medical condition (which could impact Feature Point detection)

11-23 Reserved for Future definition

(Table 6 of ISO 19794-5) Expression 2 bytes 0x01 (Neutral)

Pose Angle 3 bytes 0x0

Pose Angle Uncertainty 0x0

6.3.4 Image Information Field

Size

Value

Face Image type 1 bytes 0x01

Image Data Type 0x0 uncompressed no bit packing 0x1 – Uncompressed bit packed 0x04 – JPEG 2000 0x02-0xFF – Reserved 0x5 - PNG (Table 3 of ISO 19794-4)

1 bytes 0x05 – PNG for storage in large memory devices /archival 0x04 – JPEG2000 with compression ratio up to 1:15 for storage in low memory devices

Width 2 bytes Approximately 420 (in pixels)

Height 2 bytes Approximately 525 (in pixels)

Image color space 2 byte 0x01 (24 bit RGB )

Source Type 1 byte 0x02 (Digital camera/Web cam ) 0x03 (Scanner)

Device type (vendor specific captured device type ID 0x0 Device type not specified

2 bytes Relevant value to be entered



Quality 2 bytes Null - Reserved for future use

Facial Image Data

- PNG for enrolment and archival, and JPEG2000 with compression ratio up to 1:15 for verification

6.4 Operational Instructions for Image Acquisition In the typical enrolment setup, the camera will be connected to a computer for online checking of quality of facial image, as per the defined parameters listed in Quality check -list at 6.2, and conversion of the image into the desired format.

6.4.1 Process of Enrolment

6.4.1.1 Process at Client end a. Capture facial Image data through a digital camera /web camera connected with a

computer for desired online settings as per standard specifications for acquisition of face image

b. Do quality check of captured image online as per the standard specifications

c. Store Facial Image data as per desired specifications along with CBEFF format details in secured manner on client machine along with demographic data of the enrolee, if available

d. Transmit the image to the server, in its native captured format or lossless compressed format, as per the standard specifications.

6.4.1.2 Process at Server end a. Search the relevant record of the person on the basis of Demographic data. Manually

verify enrolee’s facial image, if already available on the server. In case of mismatch, flag the discrepancy for further enquiry. In case of a match, proceed further

b. Store / Archive the Facial data of the enrolee in the prescribed format, as per standard specifications, on the server database, in case the data was not found to be on the server earlier, or an update is required.

Note: The image stored for enrolment purpose should never undergo lossy compression at any stage from the instant of capture to storage in database at server.

6.4.2 Process for Human Visual Inspection and Verification Either visually compare the face of the person with displayed face image, already stored on server / smart card / displayed in the travel document OR An application may require capturing of face image in the verification stage for transmission/ record keeping /online manual inspection and verification with already stored image on server /smart card at the time of enrollment. In such cases, the face image would be captured as per standard specifications.



7. Annexure

Annexure-I Definitions and Acronyms (Source: Various ISO Standards, ICAO Standards, Wikipedia etc.) Acquisition Process of accepting a biometric sample(s) in accordance with the defined policy, that is deemed suitable for creating a biometric reference or a biometric probe. Note: In addition to capture, acquisition may include segmentation, biometrics feature extraction, quality control and other pre-processing steps. Biometrics [Automated] recognition of [living] persons based on observation of behavioral and biological (anatomical and physiological) characteristics. Biometric System An automated system capable of: 1. Capturing a biometric sample from an end user; 2. Extracting biometric data from that sample; 3. Comparing the biometric data with that contained in one or more reference templates; 4. Deciding how well they match; and 5. Indicating whether or not an identification or verification of identity has been achieved. Biometric Data The data representing a biometric characteristic Note: For the purpose of this document, biometric data refers to Face Image data. Example: Image data, behavioral data Biometric Data Block (BDB) Block of data with a defined format that contains one or more biometric samples or biometric templates Biometric Sample Data obtained from a biometric device, either directly or after processing. Biometric Template Biometric sample or combination of biometric samples that is suitable for storage as a reference for future comparison Capture The process of taking a biometric sample from an end user. Capture Device type ID The capture device type ID shall be a unique identifier for the type of capture device deployed to acquire a biometric sample. The capture device type ID shall be recorded in two bytes. A value



of all zeros indicates that the capture device type ID is unreported. The value “unreported” may not be allowable in some applications. The value field is determined by the vendor, possibly depending on requirements for the respective application Chin The central forward portion of the lower jaw Color image Continuous tone image that has more than one channel, each of which is coded with one or multiple bits Color space The way of representing colours of pixels in an image is colour space. For instance, RGB used in this document. Crown Top of the head, or (if obscured by hair or headwear), where the top of the head/skull would be if it could be seen Enrolment The process of collecting biometrics samples from a person and the subsequent preparation and storage of biometrics reference templates representing that person’s identity. Enrolee A human being, whose image is being captured for Enrolment / Verification Face Image Electronic image-based representation of the portrait of a person. Face Image Type A category of facial images that satisfy specific requirements. Human (manual) examination Process of careful human (manual) comparison of a face image with a person or another face image to ascertain the identity of the respective person by a detailed examination of facial features and structures. Identification The one-to-many process of comparing a submitted face image against all of the face images on database to determine whether it matches any of the templates and, if so, the identity of the person matched. The biometric system using the one-to-many approach is seeking to find an identity amongst a database rather than verify a claimed identity. Matching The process of comparing a biometric sample (face image) against a previously stored template and scoring the level of similarity. One-to-many Synonym of “Identification”.



One-to-one Synonym of “verification”. JPEG 2000 Part-14 Static/still Image compression standard specified as ISO/IEC 15444-1:2004 Feature Point Reference point(s) in a face image as used by face recognition algorithms, commonly referred to as a landmark. Example : Position of the eyes. Photograph A paper photo of a full frontal face which can be used for digitization through a scanner or printed face image to be used for human visual inspection Pixel Picture element; element on a two-dimensional array that comprises an image. Portrait A photograph of a person which includes the full head, with all hair in most cases, as well as neck and top of shoulders. Red-eye The red glow from subject’s eye caused by light from flash reflecting from blood vessels behind the retina. Vendor Digital camera / Web camera /Scanner manufacturer.. Abbreviated Terms API Application Programming Interface BDB Biometric Data Block DPCM Dots per centimeter DPI Dots per inch PPCM Pixels per centimeter PPI Pixels per inch PNG Portable Network Graphics

4 JPEG 2000 part- 1 ( for static/still image) , or JPEG2000 Basic or JPEG2000 Core Coding System mean the same thing



8. References Normative References

[1] ISO 19794-5: 2005(E) Information Technology – Biometric data interchange formats – Part

5 Face image data. [2] ISO/IEC 19785 (all parts), Information technology — Common biometric exchange formats

framework [3] ISO/IEC 19794-1, Information technology — Biometric data interchange formats — Part 1:

Framework

[4] ISO/IEC-15444-1 Information technology – JPEG2000 image coding system : Core coding system Other References [1] Biometric Design Standards for UID applications, Version 1.0, December, 2009 [2]Internal Report from Expert Committee for Mapping Open Standards Principles to

Technology Standard of Interoperability Framework for e-Governance(IFEG) for referred image storage formats like uncompressed lossless( uncompressed , PNG) and JPEG2000 for static image

[3] Government of India’s Policy on Open Standards for e-Governance .



9. List of Contributors Expert Committee Contributors S. No Name & Designation Email Address

1. Professor Manindra Agrawal (Chairman)

Department of computer Science & Engineering Indian Institute of Technology (IIT), Kanpur.

[email protected] 9935062605

2. Mr. S. K. Sinha (Nodal Officer) Scientist F , NIC, New Delhi

[email protected]

3. Dr. Mayank Vatsa Assistant Professor, IIIT Delhi

[email protected]

4. Dr. Richa Singh Assistant Professor, IIIT Delhi

[email protected]

5. Shri G.S. Raghu Raman CMC Limited , Hyderabad

[email protected]

6. Mr. R. Ramesh Scientist E , OTC, NIC, Chennai

[email protected]

Technical Expert on Biometrics S. No Name & Designation Email Address

1. Dr. Krithika Venkataramani

Asst. Professor , IIT Kanpur [email protected]

2 Mr. Rajesh Mashruwala Member, UIDAI

[email protected]

Other Contributors S. No Name & Designation Email Address

1. Mrs. Aruna Chaba

Scientist F & Head, e-Governance Standards Division, NIC, New Delhi

[email protected]

2. Dr. P. Balasubramanian Scientist G & Head OTC, NIC, Chennai

[email protected]

3. Ms. Renu Budhiraja, Director (Egov Division), DIT , New Delhi

[email protected]

4. Ms. Anita Mittal Senior Consultant , DIT, New Delhi

[email protected]

5. Dr. Meenakshi Mahajan Scientist E, NIC, New Delhi

[email protected]

6. Mr. Rajnish Kumar Sharma Junior Research Fellow, NIC, New Delhi

[email protected]

Guidelines for Usage of Digital Signatures in e-Governance

Version 1.0

(December 2010)

Department of Information Technology Ministry of Communications and Information Technology

Government of India

Contents

1. INTRODUCTION _________________________________________________4

2. PURPOSE OF DOCUMENT ________________________________________4

3. TARGET AUDIENCE ______________________________________________4

4. OVERVIEW OF DIGITAL DIGNATURES ______________________________5

5. PUBLIC KEY INFRASTRUCTURE IN INDIA____________________________8

6. PROCUREMENT OF DIGITAL SIGNATURE CERTIFICATES_____________13

7. E-GOVERNANCE APPLICATIONS USING DIGITAL SIGNATURES________16

8. USAGE SCENARIOS FOR A CITIZEN FOR DIGITAL SIGNATURES _______16

9. CASE STUDIES OF SUCCESSFUL DIGITAL SIGNATURE IMPLEMENTATIONS 19

4.1 DIGITAL SIGNATURES................................................................................ 5

4.2 DIGITAL SIGNATURE VERSUS HANDWRITTEN SIGNATURES ............................ 5

4.3 DIFFERENCE BETWEEN ELECTRONIC SIGNATURES AND DIGITAL SIGNATURES.. 6

4.4 OVERVIEW OF HOW DIGITAL SIGNATURES WORK.......................................... 6

4.5 LEGAL VALIDITY OF DIGITAL SIGNATURES ................................................... 7

5.1 DIGITAL SIGNATURE CERTIFICATES .......................................................... 10

5.2 CLASSES OF DIGITAL SIGNATURE CERTIFICATES........................................ 11

5.3 TYPES OF DIGITAL SIGNATURE CERTIFICATES ........................................... 11

5.4 CERTIFICATE REVOCATION ...................................................................... 12

5.5 CERTIFICATE REVOCATION LIST (CRL) ..................................................... 12

5.6 DIGITAL SIGNATURE CERTIFICATE VERIFICATION ....................................... 12

6.1 OVERVIEW OF THE PROCESS ................................................................... 13

6.2 PROCEDURE FOR PROCURING DIGITAL SIGNATURE CERTIFICATES ............... 14

6.3 MEDIA FOR STORAGE OF DIGITAL SIGNATURE CERTIFICATES ...................... 15

6.4 COST .................................................................................................... 15

6.5 TIME TAKEN ........................................................................................... 16

6.6 PRECAUTIONS WHILE USING DIGITAL SIGNATURE CERTIFICATES.................. 16

8.1 CONTEXT AND OVERVIEW........................................................................ 16

8.2 USE CASE SCENARIO FOR APPLICATION FOR A G2C SERVICE...................... 16

8.3 USE CASE SCENARIO FOR VERIFICATION OF PRINTED COPY ........................ 17

3

10. ANNEXURE ____________________________________________________30

11. SOURCES AND REFRENCES _____________________________________39

12. LIST OF CONTRIBUTORS ________________________________________40

9.1 MCA21 APPLICATION ............................................................................. 19

9.2 NEMMADI PROJECT IN KARNATAKA ........................................................... 23

9.3 E-DISTRICT APPLICATION OF ASSAM......................................................... 25

9.4 USAGE OF DIGITAL SIGNATURES IN UP..................................................... 27

10.1 ANNEXURE 1 - FREQUENTLY ASKED QUESTIONS ....................................... 30

10.2 ANNEXURE 2 - DEFINITIONS AND ACRONYMS ........................................... 37

4

1. INTRODUCTION

The vision of National eGovernance Plan (NeGP) of Government of India is to “make all Government services accessible to the common man in his locality, throu gh Common Service Delivery Outlets and ensure efficiency, transparency and reliability of such se rvices at affordable costs to realise the basic nee ds of the common man ”. The key objective of this vision is to provide e-services - G2B and G2C - in a ubiquitous manner.

With the implementation of the National eGovernance Plan (NeGP), more and more Departments/Line Ministries in India are automating their operations and business processes and making their Service delivery online. As a result, electronic documentation is slowly permeating every aspect of the business workflow in the Government Departments. However when a signature authorization is required on a document, a hard copy is printed to get a physical routing of signatures. The reintroduction of paper into the workflow increases the Government costs, requires additional time, and prohibits the Government Departments/Line Ministries from realizing the true benefits of a fully electronic workflow.

Digital Signatures provide a viable solution for creating legally enforceable electronic records, closing the gap in going fully paperless by completely eliminating the need to print documents for signing. Digital signatures enable the replacement of slow and expensive paper-based approval processes with fast, low-cost, and fully digital ones. The purpose of a digital signature is the same as that of a handwritten signature. Instead of using pen and paper, a digital signature uses digital keys (public-key cryptography). Like the pen and paper method, a digital signature attaches the identity of the signer to the document and records a binding commitment to the document. However, unlike a handwritten signature, it is co nsidered impossible to forge a digital signature the way a written signature might be. In addition, the digital signature assures that any changes made to the data that has been signed can not go undetected.

2. PURPOSE OF DOCUMENT

This document provides an overview of Digital Signatures, their procurement, authentication mechanism and acceptability in various Governments offices and Courts of Law. The Guidelines also cover case studies of MCA21 application, Nemmadi project in Karnataka, eDistrict application in Assam and Digital Signature Usage in UP. These case studies illustrate how these eGovernance applications have been able to harness the Digital Signatures to deliver G2C services efficiently and with minimum paper work. The Guidelines also have an extensive Frequently Asked Questions (FAQs) section. These Guidelines will serve as a ready reckoner for the State/ Line Ministry officials, Implementing Agencies and citizens.

3. TARGET AUDIENCE

The target audience of this document are the State/ Line Ministry officials, Implementing Agencies and citizens who would like to understand Digital Signatures and how they can be used in various e-Governance applications.

5

4. OVERVIEW OF DIGITAL DIGNATURES

4.1 Digital Signatures

A digital signature is an electronic signature that can be used to authenticate the identity of the sender of a message or the signer of a document, and to ensure that the original content of the message or document that has been sent is unchanged. Digital signatures are easily transportable, cannot be imitated by someone else, and can be automatically time-stamped. A digital signature can be used with any kind of message, whether it is encrypted or plaintext. Thus Digital Signatures provide the following three features :-

Authentication- Digital signatures are used to authenticate the source of messages. The ownership of a digital signature key is bound to a specific user and thus a valid signature shows that the message was sent by that user.

Integrity - In many scenarios, the sender and receiver of a message need assurance that the message has not been altered during transmission. Digital Signatures provide this feature by using cryptographic message digest functions (discussed in detail in section 4.4).

Non Repudiation – Digital signatures ensure that the sender who has signed the information cannot at a later time deny having signed it.

4.2 Digital Signature Versus Handwritten Signatures

A handwritten signature scanned and digitally attached with a document does not qualify as a Digital Signature. A Digital Signature is a combination of 0 & 1s created using crypto algorithms. An ink signature can be easily replicated from one document to another by copying the image manually or electronically. Digital Signatures cryptographically bind an electronic identity to an electronic document and the digital signature cannot be copied to another document. Further, paper contracts often have the ink signature block on the last page, allowing previous pages to be replaced after the contract has been signed. Digital signatures on the other hand compute the hash or digest of the complete document and a change of even one bit in the previous pages of the document will make the digital signature verification fail. As can be seen in the underlying figure, a Digital Signature is a string of bits appended to a document. The size of a digital signature depends on the Hash function like SHA 1 / SHA2 etc used to create the message digest and the signing key. It is usually a few bytes.

Figure: H andwritten Versus Digital Signatures

6

4.3 Difference between Electronic Signatures and Di gital signatures

An electronic signature means authentication of an electronic record by a subscriber by means of electronic techniques. An Amendment to IT Act in 2008 has introduced the term electronic signatures. The implication of this Amendment is that it has helped to broaden the scope of the IT Act to include new techniques as and when technology becomes available for signing electronic records apart from Digital Signatures.

4.4 Overview of how Digital Signatures work

The Digital Signatures require a key pair (asymmetric key pairs, mathematically related large numbers) called the Public and Private Keys. Just as physical keys are used for locking and unlocking, in cryptography, the equivalent functions are encryption and decryption. The private key is kept confidential with the owner usually on a secure media like crypto smart card or crypto token. The public key is shared with everyone. Information encrypted by a private key can only be decrypted using the corresponding public key.

In order to digitally sign an electronic document, the sender uses his/her Private Key . In order to verify the digital signature, the recipient uses the sender’s Public Key .

Let us understand how the Digital Signatures work based on an example. Assume you are going to send the draft of a contract to your lawyer in another town. You want to give your lawyer the assurance that it was unchanged from what you had sent and that it is really from you.

1. You copy-and-paste the contract into an e-mail note. Get electronic form of a document ( eg : - word or pdf file)

2. Using special software, you obtain a message hash (fixed size bit string) of the contract.

3. You then use your private key to encrypt the hash.

4. The encrypted hash becomes your digital signature of the contract and is appended to the contract.

At the other end, your lawyer receives the message.

1. To make sure the contract is intact and from you, your lawyer generates a hash of the received contract.

2. Your lawyer then uses your public key to decrypt the Digital Signature received with the contract.

3. If the hash generated from the Digital Signature matches the one generated in Step 1, the integrity of the received contract is verified.

7

Figure: How Digital Signatures ensure Authenticity, Integrity and Non- Repudiability of the Contract (Source – Wikipe dia)

Note: Message digest, also known as the hash of a message, is a small piece of data that results by applying a particular mathematical calculation (hashing function) on the message. Two properties of message digests to note: (i) a small alteration in the original message would cause a big change in the message digest; (ii) derivation of the original message is not possible from the message digest. The hash produced from these functions is a fixed length bit string. For example: - The widely used message digest function SHA -1 generates a 160 bit hash whereas the SHA-2 function generates 256 bit hash as output. The usage of MD5 is to be discontinued by the Certifying Authorities as per the Amendment to the Rules of the IT Act published in 2009. (Link on the CCA website - http://cca.gov.in/rw/pages/rules.en.do)

4.5 Legal Validity of Digital Signatures

The Indian Information Technology Act 2000 (http://www.mit.gov.in/content/information-technology-act) came into effect from October 17, 2000. One of the primary objectives of the Information Technology Act of 2000 was to promote the use of Digital Signatures for authentication in e-commerce & e-Governance. Towards facilitating this, the office of Controller of Certifying Authorities (CCA) was set up in 2000. The CCA licenses Certifying Authorities (CAs) to issue Digital Signature Certificates (DSC) under the IT Act 2000. The standards and practices to be followed were defined in the Rules and Regulations under the Act and the Guidelines that are issued by CCA from time to time. The Root Certifying Authority of India (RCAI) was set up by the CCA to serve as the root of trust in the hierarchical Public Key Infrastructure (PKI) model that has been set up in the country. The RCAI with its self-signed Root Certificate issues Public Key Certificates to the licensed CAs and these licensed CAs in turn issue DSCs to end users. Section 5 of the Act gives legal recognition to digital signatures based on asymmetric cryptosystems. The digital signatures are now accepted at par with the handwritten signatures and the electronic documents that have been digitally signed are treated at par with the paper based documents.

8

An Amendment to IT Act in 2008 has introduced the term electronic signatures. The implication of this Amendment is that it has helped to broaden the scope of the IT Act to include other techniques for signing electronic records as and when technology becomes available.

5. PUBLIC KEY INFRASTRUCTURE IN INDIA

PKI is the acronym for Public Key Infrastructure. The technology is called Public Key cryptography because unlike earlier forms of cryptography it works with a pair of keys one of which is made public and the other is kept secret. One of the two keys may be used to encrypt information which can only be decrypted with the other key. The secret key is usually called the private key. Since anyone may obtain the public key, users may initiate secure communications without having to previously share a secret through some other medium with their correspondent. PKI is thus the underlying system needed to issue keys and certificates and to publish the public information. PKI is a combination of software, encryption technologies, and services that enable enterprises to protect the security of their communications and business transactions over networks by attaching so-called “digital signatures” to them. The Office of the Controller of Certifying Authorities (CCA), has been established under the Information Technology (IT) Act 2000 for promoting trust in the electronic environment of India. The current PKI organization structure in India consists of the Controller of Certifying Authority as the apex body and as the Root Certifying Authority of India (RCAI)( as shown in the figure on PKI Heirarchy). The CCA is entrusted with the following responsibilities : -

� Licensing Certifying Authorities (CAs) under section 21 of the IT Act and exercising supervision over their activities.

� Controller of Certifying Authorities as the “Root” Authority certifies the technologies and practices of all the Certifying Authorities licensed to issue Digital Signature Certificates

� Certifying the public keys of the CAs, as Public Key Certificates (PKCs).

� Laying down the standards to be maintained by the CAs.

� Conflict resolution between the CAs

� Addressing the issues related to the licensing process including:

a) Approving the Certification Practice Statement (CPS);

b) Auditing the physical and technical infrastructure of the applicants through a panel of auditors maintained by the CCA.

The RCAI is responsible for issuing Public Key Certificates to Licensed Certifying Authorities (henceforth referred to as Certifying Authorities or CA). The CAs in turn are responsible for issuing Digital Signature Certificates to the end users. In order to facilitate greater flexibility to Certifying Authorities, the CCA has allowed the creation of sub-CAs. As per this model, a Certifying Authority can create a sub-CA to meet its business branding requirement. However the sub-CA will be part of the same legal entity as the CA. The sub-CA model will be based on the following principles:

� The CAs must not have more than one level of sub-CA � A sub-CA certificate issued by the CA is used for issuing end entity certificates � A CA with sub-CA must necessarily issue end entity certificates only through its sub-CA. The only

exception will be for code signing and time stamping certificates, which may directly be issued by the CA.

9

Figure: Overview of PKI Hierarchy in India

A Registration Authority (RA) acts as the verifier for the Certifying Authority before a Digital Signature Certificate is issued to a requestor. The Registration Authorities (RAs) process user requests, confirm their identities, and induct them into the user database.

The PKI structure (outlined in the Figure below) in India is the foundation for secure Internet applications which ensure authentic and private transactions that cannot be repudiated at a later time. Thus the CCA certifies the public keys of CAs using its own private key, which enables users in the cyberspace to verify that a given certificate is issued by a licensed CA. For this purpose it operates as the Root Certifying Authority of India (RCAI). CCA is the Root of the trust chain in India.

Figure: Overview of CCA Implementation of PKI as per the IT Act

10

In order to ensure interoperability between the Digital Signature Certificates issued by different CAs’ in India, the CCA has come out with the “Interoperability Guidelines for Digital Signature Certificates issued under the Information Technology Act ” ( http://cca.gov.in/rw/pages/index.en.do). With these guidelines in place, the Digital Signature Certificate issued by one CA can be used across various e-Governance applications as the Interoperability guidelines have prescribed the formats, field and other aspects that will ensure interoperability. To know more about CCA kindly visit their website http://cca.gov.in/.

5.1 Digital Signature Certificates

Certificates serve as identity of an individual for a certain purpose, e.g. a driver's license identifies someone who can legally drive in a particular country. Likewise, a Digital Signature Certificate (DSC) can be presented electronically to prove your identity or your right to access information or services on the Internet. A Digital Signature Certificate is an electronic document which uses a digital signature to bind together a public key with an identity — information such as the name of a person or an organization, their address, and so forth. The certificate can be used to verify that a public key belongs to the individual. Digital certificates are the digital equivalent (i.e. electronic format) of physical or paper certificates. Examples of physical certificates are driver's licenses, passports or membership cards.

Digital Signature Certificates are endorsed by a trusted authority empowered by law to issue them, known as the Certifying Authority or CA. The CA is responsible for vetting all applications for Digital Signature Certificates, and once satisfied, generates a Digital Certificate by digitally signing the Public key of the individual along with other information using its own Private key.

Figure: Overview of Digital Signature Certificate

11

5.2 Classes of Digital Signature Certificates

Depending upon the requirement of assurance level and usage of DSC the following are the classes of Digital Signature Certificates

Class of DSC Assurance Level Applicability

Class 1 Class 1 certificates shall be issued to individuals/private subscribers. These certificates will confirm that user’s name (or alias) and E-mail address form an unambiguous subject within the Certifying Authorities database.

This level provides a basic level of assurance relevant to environments where there are risks and consequences of data compromise, but they are not considered to be of major significance. This may include access to private information where the likelihood of malicious access is not high. It is assumed at this security level users are not likely to be malicious.

Class 2 These certificates will be issued for both business personnel and private individuals use. These certificates will confirm that the information in the application provided by the subscriber does not conflict with the information in well-recognized consumer databases.

This level is relevant to environments where risks and consequences of data compromise are moderate. This may include transactions having substantial monetary value or risk of fraud, or involving access to private information where the likelihood of malicious access is substantial.

Class 3 These certificate will be issued to individuals as well as organizations. As these are high assurance certificates, primarily intended for e-commerce applications, they shall be issued to individuals only on their personal (physical) appearance before the Certifying Authorities.

This level is relevant to environments where threats to data are high or the consequences of the failure of security services are high. This may include very high value transactions or high levels of fraud risk.

5.3 Types of Digital Signature Certificates

The following table provides an overview of the different types of Digital Signature Certificates.

Type of Certificate Description

Individual Digital Signature Certificates ( Signing Certificates)

Individual Certificates serve to identify a person. It follows that the contents of this type of certificate include the full name and personal particulars of an individual. These certificates can be used for signing electronic documents and emails and implementing enhanced access control mechanisms for sensitive or valuable information.

Server Certificates Server Certificates identify a server (computer). Hence, instead of a name of a person, server certificates contain the host name e.g. "https://nsdg.gov.in/ " or the IP address. Server certificates are used for

12

1 way or 2 way SSL to ensure secure communication of data over the network.

Encryption Certificates Encryption Certificates are used to encrypt the message. The Encryption Certificates use the Public Key of the recipient to encrypt the data so as to ensure data confidentiality during transmission of the message. Separate certificates for signatures and for encryption are available from different CAs.

5.4 Certificate Revocation

Digital Signature Certificates are issued with a planned lifetime, which is defined through a validity start date and an explicit expiration date. A certificate may be issued with a validity of upto two years. Once issued, a Certificate is valid until its expiration date. However, various circumstances may cause a certificate to become invalid prior to the expiration of the validity period. Such circumstances include change of name (for example, change the subject of a certificate due to an employee’s change of name), change of association between subject and CA (for example, when an employee terminates employment with an organization), and compromise or suspected compromise of the corresponding private key. Under such circumstances, the issuing CA needs to revoke the certificate. In case a Digital Signature Certificate is compromised, one should immediately contact the respective CA to initiate revocation. The CA will then put the certificate in the Certificate Revocation List. We need to have necessary processes in place defining the roles and responsibility of various government officials for the usage of Digital Signature and their revocation.

5.5 Certificate Revocation List (CRL)

A CRL is a list identifying revoked certificates, which is signed by a CA and made freely available at a public distribution point. The CRL has a limited validity period, and updated versions of the CRL are published when the previous CRL’s validity period expires. Before relying on a signature the CRL should also be checked to ensure that the corresponding DSC has not been revoked.

5.6 Digital Signature Certificate Verification

Digital Signature Certificates are verified using a Chain of trust. The trust anchor for the Digital Certificate is the Root Certifying Authority (CCA in India). A root certificate is the top-most certificate of the hierarchy, the private key of which is used to "sign" other certificates. All certificates immediately below the root certificate inherit the trustworthiness of the root certificate. Certificates further down the tree also depend on the trustworthiness of the intermediates (often known as "subordinate certification authorities"). The Digital Certificate verification process is a recursive process in which the program verifying the end user certificate verifies the validity of the certificate of the issuing authority until it finds a valid certificate of a trusted party. On successful verification of the trusted party Certificate, the Digital Certificate verification stops. In case a trusted party Certificate is not found by the program, the Digital Certificate verification process ends in failure.

13

Figure: Overview of Root Chain Verification proces s for Digital Certificates The e-Governance applications should also undertake Root chain verification and CRL verification in addition to the Public Key verification while doing the Digital Signature verification.

6. PROCUREMENT OF DIGITAL SIGNATURE CERTIFICATES

6.1 Overview of the Process

The applicant for the Certificate must generate his/her own key pair and send the public key to the CA with some proof of his/her identity. The CA will issue a Digital Signature Certificate containing the public key. The CA will digitally sign the certificate using its private key and then send the certificate to the applicant. The CA will check the applicant's identification before it generates the certificate and signs the request. Different Certifying Authorities may issue certificates with varying levels of identification requirements. One CA may insist on seeing the Identity card while another may want a signed letter authorizing certification from anyone requesting a certificate.

14

Figure: Certificate Request and Issuance process b y a CA (Source NIC-CA)

6.2 Procedure for procuring Digital Signature Certi ficates

The CCA has licensed seven Certifying Authorities in India to issue Digital Signature Certificates to the end users. The National Informatics Centre issues Digital Signature Certificates primarily to the Government/ PSU’s and Statutory bodies. The Institute for Development of Research in Banking Technology (IDRBT) issues Digital Signature Certificates primarily to the banking and financial sector in India. The remaining five CAs - Safescrypt, TCS, MTNL, n(Code) Solutions and eMudhra issue Digital Signature Certificates to all end users across all domains. More than 16 lakh Digital Signature Certificates have been issued by the different CA’s in our country at the time of publication of this document.

6.2.1 Steps for Getting an individual Digital Signa ture Certificate

� DSC Form can be downloaded from website of the CA � For Class 3 certificate , the applicant has to submit the completed forms in person at the RA � On successful processing by the RA, the Username and password are sent to applicant mailbox in

order for him/her to log onto CA website. The cryptographic device is handed over to the user for storing the private key.

� The applicant installs the device drivers for the device (for storing the private key) from CA website. For example:- crypto token, smart card reader

� User generates the key pair and uploads his Certificate Signing Request (CSR) request into his/her account on the CA Website

� CA generates the DSC after verification. The user downloads from his/her account on the CA website.

6.2.2 Steps for getting a Web server Digital Signat ure Certificate

� Fill in the application form for issuance of an SSL certificate and submit the same to your CA along with applicable fee.

� Generate a CSR from the Web Server. Kindly note that the tool used for generating the CSR will generate a keystore and save the private key for the CSR on the key store. The key store will have login-id and password which will be required to import the signed public key later. Note: The details filled for generation of CSR should be the same as filled in the form submitted to the CA.

� CA will provide a method to Upload /Submit the CSR . Upload/Submit the CSR to the CA. � On successful processing of the CSR request the CA will generate the SSL Certificate. The same needs

to be downloaded from the location specified by the CA in an email.

15

� After downloading the SSL Certificate, the Certificate needs to be imported back into the key store using the same tool. Once imported successfully the same is ready for use now.

6.3 Media for Storage of Digital Signature Certific ates

It is recommended to store the private key on secure medium, for example, smart cards/ crypto tokens etc. The crypto token connects to the user computer through the USB interface. For smart cards a compatible smartcard reader needs to be installed on the user computer if not already present. The secure media available for the storing the private key may vary per each Certifying Authority.

6.4 Cost

The cost of the Digital Signature Certificate varies from CA to CA. The Certificates are typically issued with one year to two year validity. These are renewable on expiry of the period of initial issue. Further additional fees for renewal may also be charged. The costs involved in procuring Digital Certificates from NIC- CA are attached as a sample. The costs for the other CAs’ can be found on their respective websites.

NIC- CA Certifcate Fee Structure ( For all classes : Class 1, Class 2 and Class 3) Smart Card

Individual/ Personal Certificate USB Token/iKey

Individual/Personal Certificate

Soft Token SSL Server/Device Cert. (Proc. Charge)

Renewal (Proc. Charges)

Type of Subscriber

Smart Card

Smart Card + Reader

Proc. Charge

Total USB Token

Proc Charge

Total

Government 227/- 489/- - 716 /- 555/- - 555/- PSUs & Autonomous/ Statutory Bodies

227/- 489/- 200/- 916/- 555/- 200/- 755/- 200/- 200/-

Validity Two years ( Conditions apply) Renewal On expiry of certificate, processing charge shall be applicable as above to renew/create the

certificate on the same media. All other formalities shall be same as for a new DSC applicant, including submission of fresh DSC Application form and fees applicable.

Mode of Payment ( Demand Draft/RBI Cheque)

i) DSC form submitted to NICCA RA Office, Delhi/Chandi garh/Hyderabad: DD in favour of "Accounts Officer, NIC Delhi" payable at New Delhi ii) DSC form submitted to NICCA RA Office, Lucknow: DD in favour of "DDO, NIC UP State Centre " payable at Lucknow iii) DSC form submitted to NICCA RA Office, Bangalore: DD in favour of "DDO, NIC Karnataka State Centre " payable at Bangalore iv) DSC form submitted to NICCA RA Office, Chennai: DD in favour of "DDO, NIC Tamilnadu State Centre " payable at Chennai v) DSC form submitted to NICCA RA Office, Bhubaneshw ar: DD in favour of "DDO, NIC Orissa State Centre " payable at Bhubaneshwar vi) DSC form submitted to NICCA RA Office, Guwahati: DD in favour of "DDO, NIC Assam State Centre " payable at Guwahati vii) DSC form submitted to NICCA RA Office, Raipur: DD in favour of "DDO, NIC Chhattisgarh State Centre " payable at Raipur

16

Kindly also cross check from the NIC-CA website (http://nicca.nic.in) for any further updates.

6.5 Time Taken

The time taken by the Certifying Authorities to issue a DSC may vary from three to ten days.

6.6 Precautions while using Digital Signature Certi ficates

Digital Signatures are legally admissible in the Court of Law, as provided under the provisions of IT Act 2000. Therefore users should ensure that the Private keys are not disclosed to anyone. For example:- Users generally give their crypto tokes to their personal secretaries or subordinates to sign the documents on their behalf. Any illegal electronic transaction undertaken using a person’s private key cannot be repudiated by the certificate owner and will be punishable in the Court of Law.

7. e-GOVERNANCE APPLICATIONS USING DIGITAL SIGNATUR ES

The following are some of the eGovernance applications already using the Digital Signatures:- • MCA21 – a Mission Mode project under NeGP which is one of the first few e-Governance projects under

NeGP to successfully implement Digital Signatures in their project. • Income Tax e-filing • IRCTC • DGFT • RBI Applications (SFMS) • NSDG • eProcurement • eOffice • eDistrict applications of UP, Assam etc

8. USAGE SCENARIOS FOR A CITIZEN FOR DIGITAL SIGNAT URES

8.1 Context and Overview

A citizen would like to avail various G2C services available at the Common Service Centres(CSC). The following section details the various use case scenarios for a citizen to avail these G2C services.

Please note for the following Use Case scenarios we assume that the digitally signed document that has to be verified is an Income Certificate.

8.2 Use Case Scenario for application for a G2C ser vice

In order to avail a G2C service the user would have to undertake the following steps : -

1. The citizen will visit the nearest Common Service Centre.

2. The citizen will put in the application request for the Income Certificate online at the CSC. He will also submit all the necessary documentary proofs at the CSC. This request will be forwarded to the backend Departmental application.

3. The Department will process the request and after successful verification, the authorized Government Officer will issue the Income Certificate by digitally signing it. The same will be stored in the repository of the Departmental application.

17

4. The citizen revisits the CSC to check the status of the application request. In case the application request has been completed, the CSC operator will be able to show the citizen the Income Certificate from the application repository. In case the Department wishes, they can provide the citizen with a printed copy of the electronic document to furnish for future use.

8.3 Use Case Scenario for Verification of printed c opy

In order to avail the various services and benefits, the citizen will have to show the printed copy of the Income Certificates to various Departments. In order to verify the printed copy of the Income Certificate, the verifier (Department Officer to whom the citizen furnishes the document for availing a service) has the following three options

1) Via Request ID

1.1 The verifier can go to the Department website and search by the Unique Request ID printed on the Income Certificate.

1.2 The electronic version of the Income Certificate will be displayed on the website to the verifier. 1.3 The verifier can compare fields of the Income Certificate displayed in the website with the hardcopy presented by the citizen and thereby verify the authenticity of the document.

Figure: Verification of Income Certificate by Reque st ID

2) Via 2D Barcode

The Income Certificate can have a 2D barcode in which the digital signature is embedded. In case a 2D barcode is present on the Income Certificate, the verifier has the following two options to verify the printed copy of the Income Certificate

2.1 Online Verification

The verifier will be required to have an Internet Connection and a 2D barcode reader for this option.

1) The citizen will scan the 2D barcode from the printed copy of the Income Certificate

18

2) The output from the scanner will be fed to the verification utility of the Department (can be downloaded from the Department website)

3) The verification utility of the departmental application will verify the digital signature embedded in the barcode with the one stored in the database.

4) In case the signatures match, the verification utility will display the electronic version of the Income Certificate on the Department website.

5) The verifier can verify the contents of the Income Certificate with that of the Income Certificate displayed on the website.

Figure: Online Verification of Income Certificate b y citizen

2.2 Offline Verification

The citizen will be required to have a Computer, a 2D barcode reader, Public Key of the Taluka official who signed the Income Certificate, Root Chain Certificate of the CCA and NIC-CA and the verification utility of the departmental application. No connection to internet will be required.

In case the verifier does not have the above softwares installed on the computer, he can follow the underlying steps to install the softwares, This is a one time activity.

1) The verifier will download the root chain certificates of CCA from the CCA website (http://cca.gov.in/rw/pages/rcai_root_certificate.en.do) and NIC-CA certificate from the NIC-CA website (http://nicca.nic.in/index.jsp).

2) The public key of the taluka official can be downloaded from the NIC-CA website by searching for the name of the Taluka official on the website.

3) The verifier will install the verification utility of the departmental application by downloading it from the respective department website.

19

The verifier will have to undertake the following steps to verify the printed copy of the Income Certificate

1) The verifier will open the verification utility.

2) The verifier will use a barcode reader to scan the 2D barcode from the printed copy of the Income Certificate.

3) The verification utility will verify the digital signature scanned from the document.

4) The verification utility will accordingly display the appropriate message to the verifer.

Figure: Offline Verification of Income Certificate by citizen

9. CASE STUDIES OF SUCCESSFUL DIGITAL SIGNATURE IMP LEMENTATIONS

9.1 MCA21 Application

9.1.1 Context and Overview

The Ministry of Company Affairs has undertaken implementation of MCA21 project-an e-Governance initiative that will provide all the Ministry related services online to the businesses through electronic mode. It is a significant step towards an end-to-end paperless delivery of the Government Services. The use of eForms along with Digital Signatures using Digital Signature Certificates (DSCs or just “certificates”) is critical and integral to achieve this goal.

20

Following are the usage of DSC in MCA21 solution:

a) Signing of eForms and Documents : DSC has been used in eForms to ensure the Signatory authentication and data authentication. The eForms and documents shall be digitally signed during submission of requests by the users (Directors, Professionals). Whenever a request for a service is approved and the workflow is completed, the approving officer of the Ministry of Company Affairs (MCA) digitally sign the eform as a proof of having approved the request for delivery of Service. b) Role Check: The MCA21 application requires that the digital signature on the eforms and other documents is done by authorized person. This was difficult to achieve as the DSC issued in India is on Individual category and does not contain any attribute which defines the role. This also brings in the advantage that same DSC can be used by any individual for multiple roles with multiple applications. The role check in MCA21 is achieved through database check. The Directors and professionals are required to register their DSC with MCA21 portal against their Director Identification Number (DIN) and/or PAN (for professional). Database of professionals has been taken from the professional bodies i.e ICAI, ICSI & ICWA and included within MCA21. The professional users database is updated on regular basis. The DIN database is part of MCA21. Once the DSC is registered a mapping of DSC with DIN and/or PAN is maintained within the MCA21. However, a director or a professional may be linked to multiple companies. Hence, only one DSC is required per individual irrespective of roles he performs and companies with which he is associated. c) Secure Login: MCA Employees, Directors and professionals shall login to the MCA portal using DSC instead of a password. DSC based solution provides a much secure way of login over normal user id / password method. MCA21 system does not permit password based login for its users.

9.1.2 Users of MCA21 For MCA21, five types of users are identified:

1. MCA (government) employees

2. Professionals (Chartered Accountants, Company Secretaries, and others) who interact with MCA & Businesses in the context of the Companies Act.

3. Representatives of Banks & Financial Institutions

4. Authorized Signatories and Directors of Companies

5. Citizens /public user

Each of these users provide specific and different sets of information to the MCA21 applications at the various times – to identify themselves before accessing certain information, performing certain operations, and signing documents they are authorized to sign.

The different category of users as identified above are required to use the digital signatures in discharge of their duties mentioned below:-

i) MCA employees (Government):

Various services required to be delivered by the offices of Registrar of Companies(ROC) under the Ministry of Company Affairs have been re-engineered into e-forms. As such, any client (company/ corporate) seeking to avail of any service would be required to apply for the same in the prescribed e-form. Such e-form would be submitted by the client and processed in the Back Office of each ROC for an appropriate decision thereon. Such decision as a result of processing of the clients’ request in the Back Office would be digitally signed in recognition of the approval/

21

rejection of such request. Thus, the employees of the MCA posted in various ROC offices will be using the DSCs to digitally sign the decision taken by them on various requests. This would constitute one class/ category of users in the MCA21 system.

ii) Professionals:

Professionals are authorised to submit various requests through the prescribed e-forms on behalf of the clients with MCA (companies/ corporates). These professionals, working for their clients under due authorisation, submit various requests/ carry out various statutory compliances on behalf of their clients. As such, they are required to obtain Digital Signature Certificates and use the same for submission of various e-forms on behalf of the companies/ corporate and constitute the second category of users for the purpose of issuance of DSCs.

iii) Directors/ Authorised Signatories:

This class of persons represents the Directors of the companies/ corporates and includes Signatories duly authorised by the companies through Resolutions as permissible under the Company Law. A number of documents required to be filed by the companies in the offices of ROCs, now to be facilitated through e-forms, have to bear the signatures of this class of persons. Hence, they would constitute the third category of the users of DSCs before submission of their filings under the MCA21 system.

iv) Representatives of Banks and Financial Institut ions:

Companies/ corporates avail of term loan/ loan against working capital and various other kinds of loans from Banks and Financial Institutions and create a charge of the Financial Institution or the Bank in the process. The document creating a charge or modification thereof at a subsequent stage, is required to be registered with the Registrar of Companies. This service is also to be provided through e-form. The charge creation document bears the signature of the lender as well as the borrower. The FIs/ Banks, being the lenders in this process, would be required to use DSCs under the MCA21 as a token of creation of such charge and the authorised signatory/ Director on behalf of the borrowing company (covered under third category/ class of DSC users) would append their signatures digitally on the e-form before submission thereof to the ROC for registration of this document. Thus, the Banks/ FIs represent the fourth category/ class of DSC users.

v) Citizens/Public user:

Citizens only perform activity of viewing various documents filed by companies as per the Company Act. These users are not required to use DSC as they only perform view operation.

9.1.3 Class of Digital Signature Certificates

Keeping in view of the trust level required and usage model it was decided that all Class 2 or above DSCs will be permitted in MCA21 application.

1. MCA Employee

22

The application form for the Govt. employees will be followed as notified earlier by Department of Information Technology by Gazette notification dated 23rd April, 2004 (GSR 284(E)). For MCA employee, the Ministry is functioning as Subordinate CA or sub-CA under one of the authorized CA. For this purpose, officer have been assigned the duty of RA and sub-CA for issuance and revocation of the certificate. All MCA employee are issued certificates under the MCA sub-CA and the application only permits certificate under this sub-ca chain to perform duties associated with MCA employees. There are approximately 1000 certificates used under the sub-CA.

2. For Professionals, Directors, Authorised signato ries and other category user

Directors/authorized signatories and professionals have to procure “Individual” category DSC from any one of the licensed CA. The DSC issued by the CA should be in accordance with FORM B prescribed by the Department of Information Technology under the Gazette notification dated 23rd April 2004 (GSR 285(E)). A person performing multiple roles of professional, director and authorized signatory for different companies need to procure only one DSC but they are required to register the DSC for each role performed in MCA21 system. The numbers of certificates used are growing every day and have already crossed 5 lakh mark.

9.1.4 Registration Procedure of DSC for Profess ionals and Directors

Directors/authorized signatories and professionals are required to self register at MCA21 portal. It is mandatory for them to procure DSC before registering. Following steps needs to be performed by the Directors/authorized signatories and professionals for registering the DSC:

� Provides personal details including individual identifier (DIN for Directors/Authorised signatory and PAN for Professionals.

� Provide DSC when directed by the MCA21 portal. � System checks the name in the DSC as entered in personal details. � In case DIN is entered, system validates if DIN is active. System also checks if the name in DIN

matches with the name in Personal details. � System creates user-id-DSC Serial number-DIN/PAN mapping after all validation are successful.

There may be need to update the DSC already registered with MCA21 due to loss or expiry or renewal of DSC.

There shall be two cases: Case A: User has existing registered certificate

i. User logs in with user id – DSC (existing) ii. User selects update DSC option. iii. User attaches new DSC and necessary validations are performed. iv. System shall delete old DSC after successful update, v. System creates user id – DSC (new) mapping.

Case B: User has lost certificate or certificate has expired i. User selects update DSC option at the MCA21 FO portal. ii. User enters user id and attaches new DSC. iii. System checks the name in the DSC matches with name entered as personal details. iv. System shall delete old DSC after successful update. v. System creates user id – DSC (new) mapping.

23

9.1.5 Verification

The digital signature verification process is same for certificates issued to all categories of users. MCA21 application performs the following before a digital signature is accepted by the system. Normally, when an eform is submitted, the MCA21 application performs the following steps:

1. Digital signature verification : The digital signature used in the solution is as defined in IT Rules 2000 as PKCS#7 format. The digital signature is verified using the signer’s public key (available in the certificate) to ensure that the signer has signed the document with his private key only and also the data has not been tampered after it has been signed. The class of certificate is also verified.

2. Role Check: Role check is performed against the role check database created through the registration process as described above.

3. Trust Chain Verification : The signer certificate is verified against the various trust chain under the RCAI. A trust-list of CA certificate is maintained in the MCA21 application. For MCA employees trust till MCA sub-CA is verified.

4. CRL Verification : The signer certificate is validated to ensure that the certificate has not expired/revoked and the certificate is valid. The certificate status is checked using the certificate revocation list (CRL) published by the Certifying Authority. CRLs are downloaded from the CAs website on daily basis and maintained within the MCA21 application for verification of DSCs against the CRL.

All documents received are time stamped and maintained in secure repository for future reference.

9.2 Nemmadi Project in Karnataka

9.2.1 Introduction

Under the Nemmadi project, Government of Karnataka (GoK) has set up, through PPP model, a network of 800 telecenters at village level. It has also set up 177 backoffices at the taluka level. These telecenters would deliver range of G2C and B2C services at the citizen’s doorsteps. The Government of Karnataka’s vision for this project is that IT enabled Government services should be accessible to the common man in his village, through efficient, transparent, reliable and affordable means. The key objectives for this project are

� To create efficient and smart virtual offices of state government in all the villages. � Initially, to provide copies of land records and 38 other citizen centric services of the revenue

department in a convenient and efficient manner through 800 village Telecenters across rural Karnataka.

� To scale up the operations to cover all other G2C services of all the departments. � To enhance the accountability, transparency and responsiveness of the government to citizen’s needs. � To provide government departments and agencies means of efficient and cost effective methods of

service delivery to citizens. � To manage the delivery of services through PPP model. � To enable government departments and agencies to focus on their core functions and responsibilities by

freeing them from the routine operations like issuing of certificates, land records, collection of utility bills of citizens and thereby enhancing the overall productivity of the administrative machinery.

9.2.2 Digital Signatures in Nemmadi Application:

24

The Nemmadi application has been developed by the Karnataka Unit of the National Informatics Centre (NIC).This application serves as the single window system for all government services at the village level. There is no need by the citizen to submit a written application for availing any service. There is a uniform service charge of Rs 15 for every service. The unique feature of this application is that “Signature less” documents are issued after being digitally signed by the appropriate authority.

1. Signatureless RTC

GoK is proceeding towards signature less documents and the Record of Rights, Tenancy and Crop Inspection (RTC) delivered from both the village Telecentre and the Taluka office will not contain any signature. This would therefore considerably reduce the dependency on Village Accountant for signing the RTC document at the village telecentre. This will be achieved by making the Bhoomi application PKI enabled. Each revenue official involved in processing of RTCs will sign any changes to RTC records using his private key. Additionally the entire lot of pre-existing RTCs will also be signed using the private key of the authorized revenue official. This process which is compliant with the IT Act 2000, will enable issue of RTC with a 2D Barcode printed on the RTC and will remove the need for physical signature by the Village accountant on the RTC form. The 2D barcode will have within it the embedded digital signature of the RTC.

2. Signatureless Rural Digital Services (RDS) Cert ificate

Rural Digital Services (RDS) involves delivery of services of Revenue department from the Taluka to the citizen. These services include delivery of various types of Caste and Income Certificates, Registration of Birth and Death, Delivery of Birth and Death Certificates and application for Social Security Schemes like Old Age Pension, Widow Pension etc. In future services of other department like Social Welfare, Women and Child development etc. will also be added to the RDS platform.

The government is proceeding towards signature less documents and the RDS certificate delivered from both the village Telecentre and the Taluka office will not contain any signature. The RDS application being PKI enabled will enable the Telecentre operator to issue the certificate at the village itself, after such certificates have been digitally signed by the competent revenue authority, without needing to go to the Taluka office for collecting the physical copy of the signed certificate.

Besides the 2D bar code, the RDS certificate will be printed on a watermark stationary, a certificate id and a hologram to ensure its authenticity.

9.2.3 Verification of Signatureless Certificates

The RDS Certificates are signatureless documents. The certificate is printed on a uniquely numbered and water marked paper supplied by Government of Karnataka and also carries a uniquely numbered hologram. The signed hash of the certificate contents is printed as machine readable 2D barcode at the bottom of the certificate. Each certificate also carries 2 seal impressions and the signature of the Nemmadi operator in accordance with the provisions of IT Act 2000.

The genuineness of these certificates can be verified conclusively by any person or authority as follows:

1. Verification by Request ID

Connect to Nemmadi website (http://nemmadi.karnataka.gov.in/certificateverification). Key in the unique Request ID printed on the certificate. This method shows the corresponding record on the Nemmadi website. However, the user needs to compare the contents displayed on computer (of the authentic document stored on SDC) with the content on the print out. This procedure does not require a 2D barcode and therefore also does not tell who has digitally signed the contents of the document. It allows one to compare the authentic document on the government website with the contents on the print out.

25

2. Verification by 2D BarCode

Connect to Nemmadi website (http://nemmadi.karnataka.gov.in/certificateverification). Use a barcode reader to read the 2-D bar code printed at the bottom of the certificate. The verification process would show the corresponding record on the Nemmadi website and also inform whether the signature on the certificate is of a valid authority. However the user needs to compare the contents displayed on computer (of the authentic document stored on SDC) with the contents on the certificate hardcopy. This method requires a computer, an internet connection and a 2D bar code reader.

3. Fully Independent Verification

This method does not require an internet connection for certificate verification. It also does not have dependence on the content on the government website. The verifier can verify the certificate by just using the data printed on the certificate. The user needs to download and install a verification utility custom developed for Nemmadi from the Nemmadi website. The user also needs to download the certificates of CCA and NIC and the public key of the authorised taluka and the taluka official onto the computer. Once these items are installed on the computer, the user can scan the 2D barcode on the Certificate and the verification utility will check the validity of the Digital Signature. The verified message guarantees three things: 1. The document was signed by the competent authority 2. The contents as shown on the document have not been tampered. 3. The issuing authority cannot disown the content of the document.

9.3 e-District Application of Assam

9.3.1 Introduction

The Government of Assam introduced digital signatures in its e-Governance framework under the ambit of NeGP in one of the torch bearer projects called the “e-District Pilot Project” implemented in the districts of Goalpara and Sonitpur. The twin pilot projects were formally launched by Dr. Himanta Biswa Sarmah, Hon'ble Information Technology Minister, Govt. of Assam on the 12th of November, 2009 and 12th of January, 2010 in Goalpara and Sonitpur districts respectively. Digitally signed certificates are being issued in these two districts. Looking at the success of the digitally signed certificates, the Hon'ble Chief Minister of Assam, Sri Tarun Gogoi has already announced his intent to bring digital signatures in the Secretariat itself through the Assam Online Portal/SP/SSDG & Secretariat Less Paper Office Project (SLPO). Due to a very strong commitment of the Government of Assam, digital signatures have now been implemented in two districts, and the project is ready to be rolled out in the balance of 25 districts in a similar fashion. Digital signatures are also poised to make entry into the Assam Secretariat by December, 2010. The e-District MMP has been implemented in Sonitpur and Goalpara districts of Assam as part of the ambitious National e-Governance Plan for ensuring transparency, efficiency and streamlining various G2C services under the ambit of the District Administration. The e-District project envisages back end computerization of G2C services (Certificates, Pensions, Revenue Courts, Pensions, RTI etc) at the district level and delivery of these services to the citizens electronically leveraging the ASWAN and Common Service Centres. The entire process of application processing and verification of such services would be done electronically and the approval/rejection of the service request by the designated authorities at the District Administration level would be done online. The output of such a service request in the form of a certificate or order, depending on the service would also be system generated with security features like digital signatures, 2D Bar codes etc. Citizens can now collect the print out of such certificates from the CSCs/Public Facilitation Centres by paying a nominal fee. As part of the e-District Pilot project in Assam, one of the major technological interventions introduced is usage of Digital signatures by various approving authorities. This has brought about a complete change in the way applications are processed and approved. The Case study prepared in this regard, highlights various beneficial aspects of digital signatures, challenges being faced in the implementation and the lessons learnt.

26

9.3.2 Digital Signatures in e-District Assam

District Level Authorities Using Digital Signatures: The Digital signature has been able to penetrate the district level hierarchy from top to bottom. Despite certain issues, the level of acceptance has been found to be high. To sensitize the officers about digital signatures, several mock demonstrations and actual training sessions were organized at all the levels in the district. The following is the hierarchical list of district officials using digital signatures under the e-District pilots:-

9.3.3 Uniqueness of Assam e-District The uniqueness of the Assam e-district project has been the use of Digital signatures and the benefits arising out such a usage to the citizens. The following benefits/ features have been highlighted under the project: 1. The certificate / order issued under the project does not carry any physical signatures at all. 2. Each print out of the certificate is treated as original. 3. The certificate carries at least three ways in which it can be verified by any citizen or authority namely-

1. A unique serial number under the 1-D barcode 2. Scanning the 2-D barcode and getting the link information downloaded to one's mobile handset using a camera & java enabled mobile phone having barcode readers.

3. Visiting the e-District Portal and entering the serial number. 4. Calling up e-District rural call center during office hours at +91-361-2724-555 (This facility is technically ready for launch for the benefit of the citizens)

In case the application is lost or damaged, the citizen can just take another print out from the nearest CSC. So far 7066 number of digitally signed certificates have already been issued in the two districts. An image of an actual digitally signed certificate issued under the e-District project may be seen at the end of this section.

9.3.4 Challenges in Implementation of Digital Sig natures

A. Change Management Issues: As the digital signatures are issued in name rather than the designation, transfer of officials requires frequent deactivation and reissue of digital signatures. The administrative effort to manage such issues creates undue delay due to centralized nature of the issuing authority. As the requirement of digital signature is likely to grow after state wide role out of e-District project, a state level issuing authority is thought to be economically more feasible. Currently, it takes anything from 7 days to a month for a new signature certificate. The State Designated Agency (AMTRON) is likely to become a franchisee of M/S Sify for providing Digital signatures to the officials of the Govt. of Assam in order to keep pace with frequent transfers and to ensure timely delivery of services to the citizens. B. Issues on Acceptance by certain Authorities: It has been observed some of the authorities such as Courts, some Universities, Passport offices etc. are finding it difficult to accept the digitally signed certificates in the printed form. The Govt. of Assam has already taken up this matter with the Govt. of India and the

27

authorities concerned. The resistance is slowly melting. If proper awareness is launched in the public, it would help the cause of easy acceptance of digital signatures.

9.3.5 Lessons Learnt and Road Ahead The following are the lessons learnt and the road ahead suggested for implementation of digital signatures in the e-Governance programmes:-

• The digital signature implementation must be end to end available without any dependecy on

proprietary OS. • The verifications must happen on the local application servers, else the implementation model may

fail in the remote applications in the rural landscape. • The State Government needs to develop its own franchisee model for management of digital

signatures on a day to day basis, else it may impede decision making. • No physical signature should be promoted on print outs of any digitally signed certificates/

documents • Awareness campaign should be launched in national and local media (in local languages)

regarding what is digital signature and how it benefits the citizens.

Figure: Screenshot of a Digitally Signed Residence Certificate

9.4 Usage of Digital Signatures in UP

9.4.1. Introduction In Uttar Pradesh, Digital Signatures are being extensively used in various projects right from delivery of citizen centric services through eDistrict to online application for tendering system. Many of the manual processes have

28

been converted to electronic workflow systems and the DSCs are being effectively used by the Government Officials in digitally signing the documents. These processes have made the service delivery faster and have almost brought an end to the physical movement of files and papers which used to cause delays and hold-ups. This has increased the authenticity of documents and reduced the chances of issuance of bogus and fake certificates. 9.4.2. Successful Implementations of Digital Signat ures Some of the successful implementation of Digital Signatures in Uttar Pradesh include -

S.No Project Use of Digital Signatures No of DSC issued

1. eDistrict – implemented in six pilot districts. More than 18 lakh Digitally Signed Certificates/ Service already delivered to citizens

Digital Signatures are being used for electronically signing the Certificates being issued through eDistrict Centres / CSCs etc The approving authority puts his Digital Signatures at the time of approving the certificate and the related information is printed on the certificate also. This not only ensures that the details of the signing authority is displayed, even the DSC of the signatory can be verified over the Internet.

500 to various Govt.

district functionaries such as DM,

SDM, Tehsildar,

DSO, DSWO etc for

issuance of services

2 Online Counselling for admission to more than 1 lakh seats of Engineering, Medical, Polytechnic & B.Ed. courses.

The Digital Signatures are being used by the Counselling In-charge for document verification, fee submission, registration & for choice locking opted by the candidates which are finally locked by the invigilators using DSC. Class II DSC are being used for these activities In case of any modification in the student record, the same can be carried out only through digital signatures in order to ensure the same is recorded in the database.

1264

B.Ed – 438 UPTU - 433 Medical -433 Polytechnic –

220

3 eProcurement is an online tender processing system for the state government departments. More than 1000 tenders published so far.

The Digital Signatures are being used both by the vendors and government officials for tender submission and processing. The vendors/traders are using it for applying tenders online, while the government officials are using it at time of opening the tenders and during finalizing of the tenders. Class II signatures are being used both for signing and encryption of data.

About 500 to Govt. officials

and Around 3000

to bidders

4 Voters List Preparation – The State Election Commission has issued a GO that the field data along with the photo ID will be digitized and the same will be digitally signed assuring the correctness of data.

The DSC will be used to counter verify the digitised data of voters list and the photo ID. This can be used by other applications such as eDistrict for online verification of citizen details.

Under Process

5 Many other departments are using DSC such as

1. CPWD

1. Class III Signing

29

2. Defence 3. Railways 4. Post

2. Class III Signing & Encryption 3. Class II Signing 4. Class III Signing

30

10. ANNEXURE

10.1 Annexure 1 - Frequently Asked Questions

Q1. What is Cryptography? Q2. How do I get a Digital Signature Certificate? Q3. What is a Certifying Authority (CA)? Q4. Who are the CAs licensed by the CCA? Q5. If CA is out of business then if the subscriber is told to move to another CA then the

subscriber has to get a new digital certificate. What happens to his/her earlier transactions? Does this not create a legal and financial problem?

Q6. Can one authorize someone to use DSC? Q7. Can a person have two digital signatures say one for official use and other one for personal? Q8. In paper world, date and the place where the paper has been signed are recorded and court

proceedings are followed on that basis. What mechanism is being followed for dispute settlements in the case of digital signatures?

Q9. Is there a "Specimen” Digital Signature like a “Specimen” Paper Signature? Q10. If somebody uses others computer, instead of his own computer, then is there any possibility of

threat to the security of the owners/users digital signature? Q11. Is it possible for someone to else to use your digital signature without your knowledge? Q12. When you cancel an earlier communication you can get it back, how does this work in e-

environment? Q13. When can a DSC be revoked? Q14. How do digital certificates work in e-mail correspondence? Q15. How do Digital Certificates work in a web site? Q16. What clause an eGov project should have to ensure that the PKI implementation meets the

requirement of the IT Act 2000? Q17. Can I use the certificate issued by a CA across eGovernance applications? Q18. What are the key sizes in India? Q19. What is the size of digital signatures? Q20. What is the Key Escrow? Q21. What are the documents accepted by NIC – CA for verification? Q22. How do applications use the CRLs? Q23. How long do the CAs’ in India preserve the Public Keys of the end users? Q24. Should e-Governance applications archive the Digital Signature Certificates as well? Q25. Can I have multiple Digital Signatures to a document? Q26. What are the types of applications that should use Digital Signatures? Q27. What are cryptotokens? Q28. What are the different ways of authenticating content of digitally signed documents issued to the

citizen? Q29. How can a digitally signed document be verified after the DSC associated with the Public Key

has expired? Q30. How can Departments ensure that their Government officers authorized to sign the Certificates

do not misuse their Digital Signature Certificates after being transferred from a given place? Q31. How can a citizen be assured that the document has been digitally signed by the appropriate

authorized Government officer?

31

Q1. What is Cryptography? Cryptography is the science of enabling secure communications between a sender and one or more recipients. This is achieved by the sender scrambling a message (with a computer program and a secret key) and leaving the recipient to unscramble the message (with the same computer program and a key, which may or may not be the same as the sender's key). There are two types of cryptography: Secret/Symmetric Key Cryptography and Public Key Cryptography. Secret key (symmetric/conventional) cryptography - is a system based on the sender and receiver of a message knowing and using the same secret key to encrypt and decrypt their messages. One weakness of this system is that the sender and receiver must trust some communications channel to transmit the secret key to prevent from disclosure. This form of cryptography ensures data integrity, data authentication and confidentiality. Public key (asymmetric) cryptography - is a system based on pairs of keys called public key and private key. The public key is published to everyone while the private key is kept secret with the owner. The need for a sender and a receiver to share a secret key and trust some communications channel is eliminated. This concept was introduced in 1976 by Whitfield Diffie and Martin Hellman. The Digital Signatures created using the private key ensure data integrity, data authentication and non-repudiation. However, to ensure confidentiality, encryption of the data has to be done with the recipient’s public key.

Q2. How do I get a Digital Signature Certificate? The Office of Controller of Certifying Authorities (CCA), issues Certificate only to Certifying Authorities. The CAs in turn issue Digital Signature Certificates to the end-users. You can approach any of the CAs for getting the Digital Signature Certificate. For more information about the respective CAs kindly visit their websites (provided below)

Name of CA Website

Safescrypt www.safescrypt.com

National Informatics Centre www.nic.in

Institute for Development and Research in Banking Technology (IDRBT)

www.idrbtca.org.in

TCS CA services www.tcs-ca.tcs.co.in

MTNL CA services www.mtnltrustline.com

(n) Code Solutions www.ncodesolutions.com

eMudhra www.e-Mudhra.com

Q3. What is a Certifying Authority (CA)? A CA is a trusted third party willing to verify the ID of entities and their association with a given key, and later issue certificates attesting to that identity. In the passport analogy, the CA is similar to the Ministry of External Affairs, which verifies your identification, creates a recognized and trusted document which certifies who you are, and issues the document to you.

32

Q4. Who are the CAs licensed by the CCA? a. Safescrypt b. NIC c. IDRBT d. TCS e. MtnlTrustline f. GNFC g. e-MudhraCA

Q5. If CA is out of business then if the subscriber is told to move to another CA then the subscriber has to get a new digital certificate. Wh at happens to his/her earlier transactions? Does this not create a legal and financial problem?

Prior to cessation of operations the CA has to follow procedures as laid down under the IT Act. Such problems should not therefore exist.

Q6. Can one authorize someone to use DSC? Incase a person wants to authorize someone else to sign on his/her behalf, than the person being authorized should use their own PKI credentials to sign the respective documents. Q7. Can a person have two digital signatures say on e for official use and other one for personal use? Yes.

Q8. In paper world, date and the place where the pa per has been signed is recorded and court proceedings are followed on that basis. What mechan ism is being followed for dispute settlements in the case of digital signatures? Under the IT Act, 2000 Digital Signatures are at par with hand written signatures. Therefore, similar court proceedings will be followed.

Q9. Is there a "Specimen Digital Signature" like Pa per Signature? No. The Digital signature changes with content of the message.

Q10. If somebody uses others computer, instead of h is own computer, then is there any possibility of threat to the security of the owners /users digital signature? No, there is no threat to the security of the owner / users digital signature, if the private key lies on the smartcard /crypto token and does not leave the SmartCard/crypto token.

Q11. Is it possible for someone to use your Digital Signature without your knowledge? It depends upon the how the signer has kept his private key. If private key is not stored securely, then it can be misused without the knowledge of the owner. As per the IT Act 2000, the owner of the private key will be held responsible in the Court of Law for any electronic transactions undertaken using his/her PKI credentials(public/private keys).

Q12. When you cancel an earlier communication you c an get it back, how does this work in e-environment?

33

A new message saying that the current message supersedes the earlier one can be sent to the recipient(s). This assumes that all messages are time stamped.

Q13. When can a DSC be revoked? The DSC can be revoked when an officer is transferred, suspended or his/her key is compromised. Q14. How do digital certificates work in e-mail cor respondence? Suppose Sender wants to send a signed data/message to the recipient. He creates a message digest (which serves as a "digital fingerprint") by using a hash function on the message. Sender then encrypts the data/message digest with his own private key. This encrypted message digest is called a Digital Signature and is attached to sender's original message, resulting in a signed data/message. The sender sends his signed data/message to the recipient. When the recipient receives the signed data/message, he detaches sender's digital signature from the data/message and decrypts the signature with the sender's public key, thus revealing the message digest. The data/message part will have to be re-hashed by the recipient to get the message digest. The recipient then compares this result to the message digest he receives from the sender. If they are exactly equal, the recipient can be confident that the message has come from the sender and has not changed since he signed it. If the message digests are not equal, the message may not have come from the sender of the data/message, or was altered by someone, or was accidentally corrupted after it was signed.

Q15. How do Digital Certificates work in a web site ? When a Certificate is installed in a web server, it allows users to check the server's authenticity (server authentication), ensures that the server is operated by an organization with the right to use the name associated with the server's digital certificate. This safeguard's the users from trusting unauthorized sites. A secure web server can control access and check the identity of a client by referring to the client certificate (client authentication), this eliminates the use of password dialogs that restrict access to particular users. The phenomenon that allows the identities of both the server and client to be authenticated through exchange and verification of their digital certificate is called mutual server-client authentication. The technology to ensure mutual server-client authentication is Secure Sockets Layer (SSL) encryption scheme.

Q16. What clause an eGovernance project should have to ensure that the PKI implementation meets the requirement of the IT Act 2000? The eGovernance applications have to be developed in compliance with RFC5280 certificate profile. A number of commercial and open source PKI toolkits are available which can be used to develop a standard validation process. Eg : - Microsoft CNG, Sun Java Toolkit. Please refer to Annexure IV of the Digital Signature Certificate Interoperability Guidelines (http://cca.gov.in/rw/pages/index.en.do) for further details.

Q17. Can I use the certificate issued by a CA acros s eGovernance applications ? Yes.

Q18. What are the key sizes in India?

34

CA Key is 2048 bits and the end user keys are 1024 bits. However from 1 Jan 2011, the end user keys will be 2048 bits as well as per the notification by CCA.

Q19. What is the size of digital signatures? The size of the Digital Signatures varies with the size of the keys used for generation of the message digest or hash. It can be a few bytes.

Q20. What is the Key Escrow? Key escrow (also known as a fair cryptosystem) is an arrangement in which the keys needed to decrypt encrypted data are held in escrow so that, under certain circumstances, an authorized third party may gain access to those keys. These third parties may include businesses, who may want access to employees' private communications, or governments, who may wish to be able to view the contents of encrypted communications.

Q21. What are the documents accepted by NIC – CA fo r verification? Any of the following id’s are accepted by NIC-CA for verification of CSR

• Employee ID

• Passport Number

• Pan Card Number

• Driving License Number

• PF Number

• Bank Account Details

• Ration Card No

Q22. How do applications use the CRLs? The applications download the CRLs from the respective CA sites at a specified frequency. The applications than verify the public keys against this CRL at the time of Digital Signature verification. The CCA is in the process of implementation of the OCVS (Online Certificate Verification Service) . This will ensure online verifications of the CRLs by the applications.

Q23. How long do the CAs’ in India preserve the Pub lic Keys of the end users? As per the IT Act 2000, each CA is stores the Public Key in their repository for a period of 7 years from the date of expiration of the Certificate.

Q24. Should e-Governance applications archive the D igital Signature Certificates as well? In view of the fact that the CAs have a mandate to save the DSCs for a period of 7 years, it may be advisable for the egovernance applications which would need to verify the records for authenticity for periods beyond 7 years.

Q25. Can I have multiple Digital Signatures to a do cument? Yes one can have multiple Digital Signatures to a document. For eg: - in the MCA21 application the forms are signed by different Directors as part of the application workflow.

Q26. What are the types of applications that should use Digital Signatures?

35

The eGovernance applications mainly provide:

1. Information Services

2. Interactive Services (downloading of forms etc)

3. Transaction Services with or without payments like issuance of various Certificates etc

The category 3 services (transaction based) can benefit from the use of digital signatures. In general wherever a eGovernance application requires handwritten signatures during the workflow of a document in the approval process, we should replace them with Digital Signatures.

Q27. What are cryptotokens? They are hardware security tokens used to store cryptographic keys and certificates. Eg :- USB etc

Q28. What are the different ways of authenticating content of digitally signed documents issued to the citizen? There are different ways of verifying the content and the digital signatures of the document. Some of the mechanism are enlisted below:-

1. Via Unique Request ID (manual content verificati on only) - In this process the user can verify the validity of his/her document by logging onto the Department website and providing the unique request number printed on the document. The Department application will display the electronic version of the document stored in the application repository. However in this process since the digital signature on the document is not verified, the contents have to be verified manually by the user by comparing the online document from the website with the hardcopy of the document. This process thus provides content verification only. The verification of the Digital Signature does not take place in this process. 2. Verification by the 2D Barcode – In this process, the barcode printed at the bottom of the document is used for the digital signature verification. The barcode has the Digital Signature embedded in it. The two verification mechanisms enlisted below verify the Digital Signature only. Since the complete content of the document is not being scanned, the content verification has to be done manually. a) Online Verification In this process, a barcode reader is used to scan the 2-D bar code printed at the bottom of the certificate. The verification utility of the Departmental application would verify the digital signature embedded in the document and after successful verification, show the corresponding electronic record on their website. However the user needs to compare the contents of the electronic record and the hardcopy. This method requires a computer, an internet connection and a 2D bar code reader. b) Offline Verification In this process, the user can verify the digital signature embedded in the barcode without connecting to the Department website. Thereby this process is called as “offline” verification. The user needs to download and install the verification utility custom developed by the Department (downloadable from their website). The user also needs to download the root chain certificates of CCA and NIC and the public key of the authorised taluka and the taluka official onto the computer. Once these items are installed on the computer, the user can scan the 2D barcode on the document and the verification utility will check the validity of the digital signature embedded in the document thereby proving the authenticity of the document. However, the content of the hardcopy of the document will have to be manually verified by the comparing with the electronic version available at the Department website as the content of the hardcopy is not being scanned in this process.

Q29. How can a digitally signed document be verifie d after the DSC associated with the Public Key has expired? The digital signature verification process for a document requires the public key, root chains and the CRL. The eGovernance application should therefore have a repository of public key certificates, root chains and the CRL’s of the time the document was digitally signed. The CA’s as of now are mandated to store the Digital Signature

36

Certificates, root chains and the CRLs for a period of 7 years as per the Rules of the IT Act. Therefore the Digital Signature Certificates can be downloaded from the CAs for a period of 7 years. However, if the digital signature on the document needs to be verified after this period, the eGovernance applications will have to have a provision to store the DSCs, root chains and the CRLs in a repository and undertaking the verification of digitally signed document against this repository. However, it may be a cumbersome process to get the CRLs’ from the respective CAs for a specific period ( in the past).

Q30. How can Departments ensure that their Governme nt officers authorized to sign the Certificates do not misuse their Digital Signature Certificates after being transferred from a given place? It is recommended that as part of the handing over of charge of a given officer, the DSC issued to the officer be revoked. Further his user credentials in the respective eGovernance applications should be deactivated so that he can no longer access the application while the Certificate revocation is under process with the CA. Once the DSC is successfully revoked, the officer will be no longer able to sign the documents.

Q31. How can a citizen be assured that the document has been digitally signed by the appropriate authorized Government officer? In order to ensure that the documents are signed by authorized individuals only, the Departments should maintain a repository having a mapping between the DSC and the respective roles assigned to the officers of the Departments. The eGovernance application should check against this repository for the various documents before allowing an officer to digitally sign the document. This mechanism has been implemented in MCA21 application wherein multiple directors sign the eforms for the application. The key challenge with this approach is to be able to maintain an updated repository at all times.

The Government of India is currently looking into the proposal for creation of a central repository of Digital Signature Certificates and CRLs’ in order to ensure that digitally signed documents can be verified at a later date ( greater than 7 years).

37

10.2 Annexure 2 - Definitions and Acronyms

Cryptography

The art of protecting information by transforming it (encrypting it) into an unreadable format, called cipher text. Only those who possess a secret key can decipher (or decrypt) the message into plain text. Cryptography systems can be broadly classified into symmetric-key systems and public-key systems.

Secret key (Symmetric/Conventional) cryptography This is a system based on the sender and receiver of a message knowing and using the same secret key to encrypt and decrypt their messages. One weakness of this system is that the sender and receiver must trust some communications channel to transmit the secret key to prevent from disclosure. This form of cryptography ensures data integrity, data authentication and confidentiality.

Public – Key (Asymmetric Key) Cryptography

This system is based on pairs of keys called public key and private key. The public key is published and known to everyone while the private key is kept secret with the owner. The need for a sender and a receiver to share a secret key and trust some communications channel is eliminated. This concept was introduced in 1976 by Whitfield Diffie and Martin Hellman.

Hash Function

A cryptographic hash function is a deterministic procedure that takes an arbitrary block of data and returns a fixed-size bit string, the (cryptographic) hash value, such that an accidental or intentional change to the data will change the hash value. The data to be encoded is often called the "message", and the hash value is sometimes called the message digest or digest or hash.

Cryptotoken

Cryptotoken is a security token used to store cryptographic keys for digitally signing thedocuments. They are typically small enough to be carried in a pocket or purse or keychain. For example : - USB

Digital Signature Certificates (DSC)

Certificates serve as identity of an individual for a certain purpose, e.g. a driver's license identifies someone who can legally drive in a particular country. Likewise, a Digital Signature Certificate (DSC) can be presented electronically to prove your identity or your right to access information or services on the Internet.

Certificate Revocation List (CRL)

A CRL is a list of certificates (or more specifically, a list of serial numbers for certificates) that have been revoked, and therefore should not be relied upon. A CRL is generated and published periodically, often at a defined interval. The CRL is always issued by the CA which issues the corresponding certificates. All CRLs have a lifetime during which they are valid. During a CRL's validity period, it may be consulted by a PKI-enabled application to verify a certificate prior to use.

38

Public Key Infrastructure (PKI)

PKI is a combination of software, encryption technologies, and services that enable enterprises to protect the security of their communications and business transactions over networks by attaching so-called “digital signatures” to them.

Certifying Authority (CA)

This is an entity that issues Digital Signature Certificate to the end users. The digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others (relying parties) to rely upon signatures or assertions made by the private key that corresponds to the public key that is certified. In this model of trust relationships, a CA is a trusted third party that is trusted by both the subject (owner) of the certificate and the party relying upon the certificate.

Registration Authority (RA)

This is an entity within the CA that acts as the verifier for the Certifying Authority before a Digital Signature Certificate is issued to a requestor. The Registration Authority (RA) processes user requests, confirm their identities, and induct them into the user database.

Root Certifying Authority of India (RCAI)

This entity is created under CCA and is responsible for issuing Public Key Certificates to Licensed Certifying Authorities. This serves as the root of the trust chain in India. The requirements fulfilled by the RCAI include the following:

• The licence issued to the CA is digitally signed by the CCA.

• All public keys corresponding to the signing private keys of a CA are digitally signed by the CCA.

• That these keys are signed by the CCA can be verified by a relying party through the CCA's website or CA's own website.

39

11. SOURCES AND REFRENCES

CCA website: http://cca.gov.in

NIC- CA website: http://nicca.nic.in

Interoperability Guidelines for Digital Signature C ertificates: http://cca.gov.in/rw/pages/index.en.do

IT ACT 2000 http://www.mit.gov.in/content/information-technology-act

Wikipedia http://www.wikipedia.org

Nemmadi http://nemmadi.karnataka.gov.in/

40

12. LIST OF CONTRIBUTORS

CORE GROUP

SNo Name and Designation Email Address 1 Mr. Shankar Aggarwal

JS (eGov), DIT [email protected]

2 Ms. Debjani Nag Deputy Controller, CCA

[email protected]

3 Ms. Renu Budhiraja Senior Director & HOD eGov Standards Division, DIT

[email protected]

4 Ms. Anita Mittal Senior Consultant, NEGD - DIT

[email protected]

5 Ms. Runjhun Chauhan Project Coordinator, NEGD - DIT

[email protected]

OTHER CONTRIBIUTORS

SNO Name and Designation Email address 1 Ms. Kavita Bhatia

Additional Director , DIT [email protected]

2 Ms. Deepa Sengar Director, NEGD - DIT

[email protected]

3 Mr. Bhushan Mohan Principal Consultant, NEGD - DIT

[email protected]

4 Mrs. Aruna Chabha, Consultant, NIC

[email protected]

5 Dr. Meenakshi Mahajan Scientist E, NIC

[email protected]

6 Ms. Anuradha Valsa Raj CA Officer & Technical Director NIC Certifying Authority

[email protected]

7 Mr. Aashish Banati Additional Director, STQC

[email protected]

8 Mr. M.K. Yadav MD, Amtron

[email protected]

9 Mr. S.B. Singh SIO, UP

[email protected]

10 Mr. Tanmoy Prasad IT Advisor, Government of Haryana

[email protected]

11 Mr. P Ramachandran, Scientist D, CCA

[email protected]

41

For any feedback kindly contact Kavita Bhatia Officiating Director and HOD eGovernance Standards Division, Department of Information Technology, Ministry of Communication & Information Technology, Electronics Niketan, 6, C.G.O. Complex New Delhi-110 003 INDIA Tel: +91-11-24364729 Email: [email protected] Website: http://www.mit.gov.in Anita Mittal Senior Consultant, Program Management Unit, Department of Information Technology, Ministry of Communication & Information Technology, Electronics Niketan, 6, C.G.O. Complex New Delhi-110 003 INDIA Tel: +91-11-30481607 Email: [email protected] Website: http://www.mit.gov.in