X.

509 and its need

To remove the side effects caused by Certification Authority (CA), ITU designed X.509 which is a means to describe certificates in a structured way. Protocol used is ASN.1 ( Abstract Syntax Notation 1).

X.509 certificate format

Brief description of fields :

Version number: defines version of X.509, current version i.e. third one is denoted by 2. Serial number: defines unique number assigned to each certificate Signature algorithm ID: identifies algorithm used to sign certificate Issuer name: identifies CA that issued certificate, normally a hierarchy of strings that

defines a country, a state, organization, department and so on.

Validity period: defines earliest time(not before) and latest time(not after) the certification

is valid
Subject name: defines entity to which public key belongs, it is also a hierarchy of strings Subject public key : defines owners public key, the heart of certificate, also defines

corresponding Public-key algorithm

1

 Issuer unique identifier : (optional field), allows two issuers to have the same issuer field

value, if issuer unique identifiers are different

Subject unique identifier : (optional field) ), allows two different subjects to have the same

subject field value, if subject unique identifiers are different

Extensions : (optional field), allows issuers to add more private information to the

certificate Signature : made of three sections- first section contains all other fields in the certificate - second section contains the digest of first section encrypted with CAs private key - third section contains the algorithm identifier used to create second section

CERTIFICATE RENEWAL Each certificate has a period of validity. If there is no problem with the certificate, CA issues a new certificate before old one expires.

CERTIFICATE REVOCATION-WHEN ITS NEEDED ? In some cases a certificate must be revoked before its expiration, some such cases are : Users private key (corresponding to public key listed in certificate) might have been compromised/leaked CA is no longer willing to certify the user CAs private key, which verifies all certificates, may have been compromised, thus CA needs to revoke all unexpired certificates

HOW REVOCATION DONE ? It is done periodically issuing a certificate revocation list(CRL) List contains all revoked certificates that are not expired on the date CRL is issued When a user wants to use a certificate, he first needs to check directory of corresponding CA for last certificate revocation

CERTIFICATE REVOCATION FORMAT

Signature algorithm ID : identifies algorithm used to sign certificate Issuer name : identifies CA that issued certificate, normally a hierarchy of strings that

defines a country, a state, organization, department and so on. This update date : defines when the list is released Next update date : defines next date when the new list will be released Revoked certificate :each certificate has two parts- serial number and revocation date
Signature : made of three sections-

- first section contains all other fields in the certificate - second section contains the digest of first section encrypted with CAs private key - third section contains the algorithm identifier used to create second section

PKI (Public Key Infrastructure)

In its most basic form, a public-key infrastructure (PKI) consists of a community of principals, a community of verifiers and an authentication authority that is recognized by both. A verifier may also be a principal. The purpose of the infrastructure is to allow a verifier to authenticate attributes (commonly the identity) of a principal when they communicate over an unsecured network. The situation is shown in Figure 1.

Authentication proceeds in the following steps:

1) The principal generates a public-private key pair {KVP, KSP} and stores the private key

(KSP) in local storage with integrity and confidentiality protection. It sends the public key (KVP) to the authority, using a trust mechanism. 2) The principals public key and its identifying information (P) within a namespace sub -tree administered by the authority are signed by the authority, using its private key, KSCA. The resulting data structure, SCA{P, KVP}, is called the principals public-key certificate, and the authority is called a public-key certification authority or CA. The certificate is commonly returned to the principal. 3) The verifier obtains the authoritys public key (KVCA) using a trust mechanism and stores it with integrity protection. 4) In order for the principal to authenticate itself to the verifier, it signs a data structure (D), attaches its certificate, and sends the data structure, the signature, SP{D}, and its certificate

to the verifier over the unsecured network. The verifier can then confirm that the data originated with the principal identified in the certificate.

Large-scale PKI
In order for an authority to communicate with principals and verifiers in a cost effective and reliable way, there must be an existing close relationship between them. Generally, authorities only have a suitable relationship with a limited community. And, commonly, PKIs are required to scale beyond such limits. Therefore, PKIs with more than one authority are required, and the authorities keys must be shared amongst the participants in a secure manner. Trust mechanisms are used for this purpose.

Trust mechanisms
Four trust mechanisms will be considered: Out-of-band mechanisms Certificate trust lists Certificate request messages Cross-certification a) Out-of-band mechanisms: These include following steps1) Publishing a fingerprint of an authority key in a trustworthy location and passing the unprotected key itself over an unsecured communications network, the recipient can then verify the key using the trusted fingerprint 2) Securing a protocol with a key derived from a random string of printable characters (the random string is shared by means of a trustworthy channel) 3) Embedding a key in trusted software (the technique used by browsers and web servers). b) Certificate trust list A certificate trust list is an extension of the first out-of-band technique. But, instead of publishing the fingerprint in a trustworthy location, it is secured by the signature of a trust list manager (TLM). The mechanism operates in this way:

1) The principal generates a public-private key pair and stores the private key in local storage

2)

3) 4) 5)

6)

with integrity and confidentiality protection. It sends the public key to the certification authority, using a trust mechanism. The principals public key and its identifying information within a name space sub-tree administered by the certification authority are signed by the authority and returned to the principal with the CAs public key, using a trust mechanism. The public key of the CA is commonly encoded as a self -signed certificate. The verifier obtains the trust list managers public key using a trust mechanism and stores it with integrity protection. The trust list manager imports the certification authoritys public verification key using a trust mechanism. The trust list manager calculates a fingerprint of the certification authoritys public key and places it in a list with other fingerprints. The resulting list is signed by the trust list manager and pushed to the verifier in the form of a certificate trust list. In order for the principal to authenticate itself to the verifier, it signs a data structure, attaches its certificate and the public key of the certification authority. The verifier can verify the identity of the principal using the data structure, the signature, the certificate, the certificate trust list and the TLMs public key.

c) Certificate request message The certificate request message is used by a registration authority (RA)

The mechanism proceeds as follows:

1) The principal generates a public-private key pair and stores the private key in local storage

with integrity and confidentiality protection. It sends the public key to the registration authority, using a trust mechanism. 2) The principals public key and its identifying information within a name space sub-tree administered by the registration authority are signed by the registration authority and sent to the certification authority. The signed message is called a certificate request message. 3) The certification authority verifies the signature of the registration authority. If it is valid, then it signs the public key and the identifying information of the principal, using its own private key. The resulting certificate is then commonly returned to the principal. 4) The verifier obtains the certification authoritys public key using a trust mechanism and stores it with integrity protection.
7

5) In order for the principal to authenticate itself to the verifier, it signs a data structure and

attaches its certificate. The verifier can confirm the identity using the data structure, the signature, the certificate and the CAs public key. d) Cross-certification

The mechanism works as follows:

1) The principal generates a public-private key pair and stores the private key in local storage

2) 3) 4) 5) 6)

with integrity and confidentiality protection. It sends the public key to CA1, using a trust mechanism. The principals public key and its identifying information within a name space sub-tree administered by CA1 are signed by CA1 and returned to the principal. The verifier obtains CA2s public verification key using a trust mechanism and stores it with integrity protection. CA2 obtains CA1s public verification key using a trust mechanism. It then signs the key in a data structure called a cross-certificate. In order for the principal to authenticate itself to the verifier, it signs a data structure and attaches its certificate. The verifier obtains the cross-certificate from CA2 over an unsecured network. The verifier can verify the identity of the principal using the data structure, the signature, the certificate, the cross-certificate and the public key of CA2.

Evolution of trust mechanisms

All of the mechanisms described above are in routine use today. However, not all interfaces are multi-vendor interoperable, even those that conform with industry standards. Figure 5 shows those mechanisms that are in routine use today, others that are in experimental use and yet others that are primarily theoretical.

Trust models
Practical large-scale PKIs use a combination of trust mechanisms. But, all of them rely on one or more of the out-of-band mechanisms for initialization, including providing the public key of at least one authority to the verifier in a secure way. An authority key passed to a verifier in this way, for the purpose of validating its certificates, is called that verifiers trust point or trust anchor. Well look at two practical large-scale PKI trust models: The hierarchical trust model and The bridge trust model.

Hierarchical trust model

A hierarchical trust model is one in which every key can be the subject of no more than one certificate or certificate request message. (This restriction is not usually applied to CTLs. That is to say, even in a hierarchy a key may be the subject of more than one CTL). We will be discussing two such models : a) Isolated hierarchical trust model b) Multiple hierarchical trust model
a) Isolated hierarchical trust model

The mechanisms used in an isolated hierarchical trust model are shown in Figure 6.

10

The symbol A B means: Bs public key is passed to A so that entities that rely on As public key may also rely on Bs public key; or A issues a certificate (or certificate request message or certificate trust list) for B; or A trusts B. For the purposes of risk containment, trust is usually conditional. That is, A allows its key to be used as the basis of trust in Bs key only for certain specified purposes and by a certain specified community of verifiers. It is common practice for the certificate issuer (A in this example) to dictate the terms of the certificate policy. This is because parties that rely on its public key have expectations concerning the quality or suitability of its certificates, and in order to preserve those expectations, it must impose conditions on its certificate subjects. But, at least in theory, the subject (B in the example) may dictate the policy, or the issuer and subject may negotiate a mutually agreeable policy. b) Multiple hierarchies A hierarchy operating in isolation is a somewhat artificial situation. A more realistic situation is one in which principals are required to operate subordinate to multiple roots, as shown in Figure 7.

11

In the diagram, an end-entity is the combination of a principal and a verifier, and the shading indicates the policy under which the entity operates. Unless the roots coordinate their policies, they will operate different policies and each will require its subordinates to operate in accordance with its policy. So, each subordinate CA operates a different policy, that of its root. Authorities may coordinate their policies by design or under the command of an oversight body, such as a regulatory body. However, it is common for there to be no such coordination of policy between roots. Only the end-entity is required to operate in accordance with the policies of all roots. Subordinate CAs operate only in accordance with the policy of their single superior CA.

12

 Bridge trust model

A subordinate CA can be certified by more than one root. But, the result will not be a hierarchy, because then the subordinate CA would have more than one superior, which is inconsistent with the definition of a hierarchy. Instead, we call the result a bridge model. We will discuss two such models: a) Isolated bridge trust model b) Multiple bridges
a) Isolated bridge trust model

The trust mechanisms used in the bridge model are shown in Figure 8. Bridge model is very similar to the hierarchy, shown in Figure 6. The only difference is that various renaming have been done from root CA to bridge CA, trust list manager to spoke CA and subordinate CA to spoke CA. The specific trust mechanisms used between the entities are also different: this model does not use the certificate trust list mechanism, instead it uses cross-certification.

13

The essential difference, however, between the two models is that spoke CAs can be certified by more than one bridge, whereas, in a hierarchy, subordinate CAs can only be certified by one root. So, in a hierachy, if a principal must be certified subordinate to more than one root, then it must have a separate key pair and there must be a separate subordinate CA for each root, whereas, in the bridge model, a principal can operate downstream of many bridges with a single key pair. b) Multiple bridges Just as in the case of the hierarchy, the isolated bridge model depicts a somewhat artificial situation. Figure 9 shows the more realistic situation of multiple bridged

14

The striking difference between this architecture and the architecture with multiple roots is that there may be only one spoke CA per domain. Whereas, in the hierarchical model, there must be a subordinate CA for each root. However, the single CA must operate in accordance with the policies of each upstream bridge. So, the spoke CAs behaviour must be consistent with the policies of more than one upstream bridge.

PKI in INDIA(and other related topics)

Acts related to PKI :
15

1) Objective of the Indian IT Act 2000

To grant legal recognition to records maintained in electronic form. Till this point only paper based records had legal recognition. To prescribe methods for authenticating electronic records. Paper records were authenticated by handwritten signatures. To define computer system and computer network misuse and make it legally actionable.

2) Authentication Method Prescribed by the Indian IT Act 2000

The Act specifies that authentication must be signed by Digital Signatures based upon Asymmetric Key Cryptography and Hash Functions. The National Root CA uses a 2048 bit RSA key. Other CA and end entities use 1024 bit.

Secure Digital Signature

It should be verifiable that at the time it was affixed the digital signature was unique to the subscriber affixing it capable of identifying such subscriber created in a manner or using a means under the exclusive control of the subscriber and is linked to the electronic record to which it relates in such a manner that if the electronic record was altered the digital signature would be invalidated

Root Certifying Authority of India (RCAI)

16

1. Role of RCAI

The IT Act provides the Controller for Certifying Authorities (CCA) to license and regulate the working of CA. The CCA operates RCAI for certifying the public keys of CAs using it private key The CCA has established the RCAI under section 18(b) of the IT Act to digitally sign the public keys of CAs in the country The requirements fulfilled by the RCAI include the following: -

The license issued to the CA is digitally signed by the CA. All public keys corresponding to the signing private key of a CA are digitally signed by the CCA. Relying parties can verify the CAs public key signed by CCA through the CCAs website. The CCA performs the Root CA functions in accordance with the Certificate Practice Statement of RCAI The RCAI root certificate is the highest level of certification in India. It is used to sign the public keys of the licensed CAs. The RCAI certificate is the self-signed certificate.

2. Licensed CAs

Safescrypt : a Private Certifying Authority http://www.safescrypt.com/

NIC : An organization of Government of India, issuing Certificates to Government organizations for G2G transactions https://nicca.nic.in/

IDRBT : Established by Reserve Bank of India, issuing Certificates to Banking industry for INFINET transactions http://idrbtca.org.in/
17

3i Infotech

TCS : Private Certifying Authority to issue Certificates to Individuals, Company and Government users http://www.tcs-ca.tcs.co.in/

MTNL
-

http://www.mtnltrustline.com

Customs & Central Excise https://www.icert.gov.in/

(n)Code Solutions CA (GNFC)

-

https://www.ncodesolutions.com

Trust Model followed in India :

National Root CA

Licensed CA

Licensed CA

Licensed CA

Subscriber s

18 Subscribers

Subscriber s

The law mandates a hierarchical Trust Model. For a Digital Signature to have legal force it must derive its trust from the National Root CA certificate.

Key Applications for PKI Enabling

a) b) c) -

Government Filing Tax Returns online by taxpayers Citizen ID card Issuing forms and licenses Reservations & ticketing Banking Inter/ Intra bank messaging systems Corporate Internet Banking applications Internet Banking Financial Services/ Broking Online Trading Electronic Contract Notes Healthcare Healthcare Management System (HMS) Electronic Medical Recording (EMR) Electronic Prescriptions

Existing Implementation
a) Government i. Ministry of Commerce and Industry: - Electronic applications and approvals of Special Economic zones and Export Oriented Units - Online Applications for licenses by the EXIM community
19

ii.

Income Tax Department: - Online Tax returns through e-Intermediaries

b) Banking
i. ii.

Securing Inter/Intra bank messaging system (SBMS) PKI enabling Corporate Internet Banking application by banks like ICICI Bank, Punjab National Bank

c) Financial Services & Broking i. Two major depositories in India have their applications PKI enabled - NSDL (National Securities Depositories Limited) - CDSL (Central Depository services (India) Ltd.) ii. Two major Stock Exchanges in India have secured their transactions with PKI - BSE - NSE

India PKI Forum

It is an association of organizations that are interested in promotion of PKI. Primary members are the CCA and all the licensed CA. Any organization with same interest can be associate member. Some broad objectives are : To promote use of PKI and facilitate the penetration electronic transactions in society To interact with other national and International PKI forums To sponsor, conduct or organize training on subjects of interest To disseminate information about electronic transactions

PKI Outlook in India

More than 10,00,000 (1 Million) digital certificates have been issued. There are several important initiatives that can increase the number of digital certificates by an order of magnitude. The important initiatives are : Mandatory electronic filing of Income Tax returns Mandatory electronic filing of Value Added Tax returns Citizen services portals Electronic passport initiative

20

REFERENCES :
1) www.cca.gov.in

2) PKI Trust Models paper by Tim Moses 3) Cryptography and Network Security by Behrouz A. Forouzan and Debdeep Mukhopadhyay (X.509 part)

21