Public Key Infrastructure (pki)

Public Key Infrastructure (PKI) Public key infrastructure become the central focus of modern security mechanism on the internet . PKI is closely related to the idea of asymmetric key cryptography mainly including message digest, digital signature and encryption services. The requirement to enable all these services is the technology of digital certificate.

PKI Validating digital certificate is both crucial and complex. Special protocols such as CRL,OCSP and SCVP are designed to handle this task. PKIX and PKCS are the two popular standards for digital certificate and PKI. A problem of key exchange and key agreement is solved by using digital certificate.

Digital Certificate Conceptually, we can compare digital certificate to the document such as our passport or driving license, these help us in establishing our identity such as full name, nationality , birth date ,photograph. A Digital certificate is a small computer file. Digital certificate shows association between my public key and me.

Digital Certificate A Digital certificate must contain the user name and user’s public key. Example of digital certificate: Subject name: Serial number : Valid from: Valid to: Issuer name : Public key :

Digital Certificate Every digital certificate has a unique serial number. Two digital certificate issued by same issuer can not have same serial number . Certification Authority: A certification authority is a trusted agency that can issue digital certificate. The authority of acting as a CA has to be with someone who everybody trusts.

Digital Certificate Usually , CA is a reputed organization , such as passport office , financial institution ,software company etc. Two of the world’s most famous CA’s are VeriSign and Entrust. Safescrypt Limited ,a subsidiary of Satyam infoway Limited ,became the first indian CA .

Digital certificate A Standard called as X.509 defines a structure of digital certificate. The International telecommunication union came up with this standard .At that time it was a a part of another standard called X.500. since then, X.509 was revised twice ,the current version of standard is version 3,called as X.509V3. Figure shows structure of X.509 V3.there are different fields which specifies version of standard contains which field.

X.509 Version 1 of of the X.509 standard contained seven basic fields ,version 2 added two more fields and version 3 added one more field. these additional fields are called as extensions. Version: Identifies a particular version of the X.509 protocol, which is used for this digital certificate. This field can contain 1,2,3 etc.

X.509 Certificate serial Number: Contains a unique integer number, which is generated by CA. Signature Algorithm Identifier: Identifies the algorithm used by CA to sign this certificate. Issuer Name: Identifies the distinguished name of the CA that create and signed this certificate .

X.509 Validity: Contains two date time values which specify the time frame within which the certificate should be considered as valid . These values generally specify the date and time up to seconds or milliseconds. Subject Name: Identifies the distinguished name of the end entity to whom this certificate refers. this field must contain an entry unless an alternative name is defined in version 3 extension .

X.509 Subject Public key Information : Contains the subject public key and algorithm related to that key. This field can never be blank. These are fields in version 1 some fields are added, Issuer Unique Identifier: Helps to identify C.A uniquely if two or more CAs have used the same issuer name over time

X.509 Subject Unique Identifier: Helps to identify subject uniquely if two or more subjects have used the same subject name over time. The digital certificate standard certifies that The same issuer name or subject name should never be used more than once in the first place. These are fields added by version 2 & these are optional & helps to distinguish between 2 issuers

X.509 V3 Following are the various fields of X.509 digital certificate version 3 Authority Key Identifier: A CA may have multiple private public key pair. This field defines the which of the key pairs used to sign this certificate. Subject Key Identifier: A subject may have multiple public private key pair. This field defines which of those key pairs are used

X.509 V3 to sign so that corresponding key can be verified. Key Usage: Defines the scope of the operation of the public key of particular certificate,e.g. we can specify whether particular public key can be used for all cryptographic operations or only for encryption or only for the Diffie-Hellman key exchange etc.

X.509 V3 Extended Key Usage: Can be sued in addition

to or in place of key usage field.Specifies which protocols this certificate can interoperate with e.g. these protocols are transport layer security, client authentication, server authentication etc. Private Key usage Period: Allows defining different usage period limit for the private & public key corresponding to this certificate.

X.509 V3 If this field is empty, the validity of private key corresponding to this certificate is same as that of public key. Certificate Policy: Defines policies & optional qualifier information that the CA associates with a given certificate Policy mapping: Used only when the subject of given certificate is also a CA i.e when CA issues a certificate to another CA

X.509 V3 The certifier CA specifies which of its policies the CA being certified must allow Subject Alternative Name: Optional defines 1 or more alternative names for the subject of the given certificate. However if the subject name field in the main format is empty, this field must contain some value.

X.509 V3 Issuer Alternative Name: Optionally defines 1 more alternative names for the issuer of the given certificate. Subject Directory Attributes: Can be used to provide additional information about subject such as subject phone/fax number, Email Id etc. Basic Constraints: Indicate whether the subject in this certificate may act as CA.

X.509 V3 This field also specifies if the subject can,in turn, allow other subject to become CAs For instance, if CA X is issuing the particular certificate to another CA Y,X can not only specify if Y can act as CA & issue certificate to other subjects, but also whether Y can grant the authority of becoming CA to other subjects, in turn

X.509 V3 Name Constraint: Specifies the name space. Policy Constraint: Used only for the CA certificate

Certificate Hierarchy Certification Authority Hierarchy is also called chain of trust, all the CAs are grouped in to multiple hierarchy CA Hierarchy begins with the root CA. Root CA has one or more second level CA’s below. Each second level CA can have one or more third level CA which in turn can have lower level CA’s & so on.This is like a reporting hierarchy in organization,

Certificate Hierarchy Where CEO or managing director is the highest authority. Many senior managers report to CEO & many managers report to senior managers. Many people would report to each manager & so on. This sort of hierarchy release the root CA from to have manage all possible digital certificates. Instead the root CA can deligate this job to second level CA & this

Certificate Hierarchy Delegation can be region wise e.g. one second level CA can be responsible for western region & another for eastern region etc. Each of these second level CAs can appoint third level CAs statewide within that region. each third level could delegate its responsibilities to 4th level CAs city wise & so on

Cross Certification Root CAs are for different for different countries.one country can have multiple countries e.g. Root CAs in US are Verisign,Thawte & the US postal service. In such cases there is no single root CA which can be trusted by concerned parties.To solve this problem an alternative is there for cross certification.This came about because

Cross Certification The single monolithic CA certifying every possible user in the world is quite unlikely instead the concept of the decentralized CAs for different countries, political organization & business is far better. This allows CAs not only worry smallest population of the user but also work independently. Moreover cross certification allows CAs & end users from different public key infrastructure domain to interact.

Cross Certification Cross Certificate are issued by the CAs to create non hierarchical trust path. Figure shows, the root CAs Alice & Bob are different but they have cross certified each other. This means that Alice’s root CA has obtained a certificate for itself Bob’s root CA.Now Alice’s software trusts only her own root CA,it is not a problem since Bob’s root CA is certified by Alice root CA.

Cross Certification The technology of the certificate hierarchy, self signed certificate & cross certification, virtually any other can verify any other user’s digital certificate & based on that,deside to either trust it or reject it.

X.500 Directories The X.500 directory service is a global directory service. Its components cooperate to manage information about objects such as countries, organizations, people, machines, and so on in a worldwide scope. It provides the capability to look up information by name (a whitepages service) and to browse and search for information (a yellow-pages service).

X.500 Directories The information is held in a directory information base (DIB). Entries in the DIB are arranged in a tree structure called the directory information tree (DIT). Each entry is a named object and consists of a set of attributes. Each attribute has a defined attribute type and one or more values. The directory schema defines the mandatory and optional attributes for each class of object (called the object class).

X.500 Directories Each named object may have one or more object classes associated with it. The X.500 namespace is hierarchical. An entry is unambiguously identified by a distinguished name (DN). A distinguished name is the concatenation of selected attributes from each entry, called the relative distinguished name (RDN),

X.500 Directories in the tree along a path leading from the root down to the named entry. Users of the X.500 directory may (subject to access control) interrogate and modify the entries and attributes in the DIB (directory information base).

X.500 Directories The Directory model: X.500 uses a distributed approach to realize a global Directory Service. The idea is that local (communication oriented) information of an Organisation is maintained locally in one or more so-called Directory System Agents (DSAs).

X.500 Directories Note that 'local' is a flexible expression here: it is possible that one DSA keeps information of more than one organisation. The opposite is also possible: Directory data of one large organisation can reside in multiple DSAs, which is still considered local from a service-provision point of view.

X.500 Directories A DSA is essentially a database: • in which the information is stored in a structure according to the X.500 information model .that has the ability, where necessary, to exchange data with other DSAs through use of the Directory System Protocol (DSP) of the X.500 recommendation set.

X.500 Directories . 'organisations' are defined, and below an organisation 'individuals', or additionally, 'organisational units', are defined (see the simplified illustration below where only three countries and no organisational units are presented). The DIT is a representation of the global Directory:

X.500 Directories

X.500 Directories Each DSA holds part of the global Directory and is able to find out, through the hierarchical DIT structure, which DSA holds a certain part of the Directory. This is done by means of 'knowledge references'. Some implementors have chosen to use an alternative approach for the X.500 (1988) version of this concept (since they thought it was not appropriate), which resulted in interoperability problems between DSA implementations by different vendors.

X.500 Directories The information model : The X.500 standard defines the information model used in the Directory Service. All information in the Directory is stored in 'entries', each of which belongs to at least one so-called 'object class'. In the White Pages application of X.500 object classes are defined, such as 'country', 'organisation', 'organisational unit' and 'person'.

X.500 Directories The actual information in an entry is determined by so-called 'attributes' which are contained in that entry. The object classes to which an entry belongs define which types of attributes an entry may use and hence, what information is specific for entries belonging to that object class. The object class 'person' for example, allows attribute types like 'common name',

X.500 Directories 'telephone number', and 'e-mail address' to be used and the object class 'organisation' allows for attribute types like 'organisation name' and 'business category'. Depending on its type, an attribute can take one or more values. At least one attribute value of the entry is used to specify a name for an entry. The entry of a person is usually named after the value of the attribute type 'common

X.500 Directories An example of an entry belonging to the object class 'person' is:

Attribute type

Attribute value

Object Class:

top person

Common Name:

Peter Jurg P. Jurg

Surname:

Jurg

Postal Address: SURFnet bv Postbus 19035 NL-3501 DA Utrecht Telephone Number:

+31 30 305305

Mail:

[email protected]

X.500 Directories The names that occur in the DIT are simply the names of entries. Hence, the entry shown in figure 2.1 occurs in the DIT as the node 'Peter Jurg' below the node of the organisation 'SURFnet'.The name of an entry must be unique at the level in the sub-tree of the DIT to which the entry belongs. So if there are two people called Peter Jurg at SURFnet, they must have a different first value for the attribute type Common Name in their entries.

X.500 Directories Core Services: X.500 • Directory System Agent (DSA). The DSA is the core directory server. A single DSA will typically hold only a part of the data available in the total directory. • Directory User Agent (DUA). A DUA is the client process that accesses information in the directory. This could be a (human) user interface or embedded in another application.

X.500 Directories •

•

Directory Access Protocol (DAP). DAP is the protocol which a DUA uses to access one or more DSAs. Thus it is the protocol which allows the client/server model of the X.500 directory. Directory System Protocol (DSP). DSP is the protocol that DSAs use to talk to each other, and it carries the same operations as DAP, along with some DSA control information.

X.500 Directories • These interactions are governed by a set of procedures for distributed operations, which enable a set of DSAs to provide a coherent service, with the DUA unaware of how the directory data is distributed between DSAs.