You are on page 1of 23

System & Network Security

Dr. Ashok Kumar Das


Center for Security, Theory and Algorithmic Research International Institute of Information Technology, Hyderabad E-mail: ashok.das@iiit.ac.in URL: http://www.iiit.ac.in/people/faculty/ashokkdas Personal Home Page: http://sites.google.com/site/iitkgpakdas/

Dr. Ashok Kumar Das (IIIT-H)

System & Network Security

1 / 23

Security at the Application Layer

Dr. Ashok Kumar Das (IIIT-H)

System & Network Security

2 / 23

Authentication Applications: X.509 AUTHENTICATION SERVICE

Dr. Ashok Kumar Das (IIIT-H)

System & Network Security

3 / 23

Characteristics of X.509
ITU-T (International Telecommunication UnionTelecommunication Standardization Sector) recommendation X.509 is part of the X.500 series of recommendations that dene a directory service. The directory is a server or a distributed set of servers that maintains a database of information about users. X.509 is an important standard because the certicate structure and authentication protocols dened in X.509 are used in a variety contexts, such as X.509 certicate format is used in
S/MIME (Secure Multipurpose Internet Mail Extension) for providing E-mail security. IPSec (IP security) for providing the Network Layer security. SSL/TLS (Secure Socket Layer/ Transport Layer Security) for providing security at the Transport Layer. SET (Secure Electronic Transaction) for providing Application Layer Security (for examples, Credit card/Debit card transactions).
Dr. Ashok Kumar Das (IIIT-H) System & Network Security 4 / 23

Characteristics of X.509 (Continued...)

X.509 is based on the use of public-key cryptography and digital signatures. The heart of X.509 scheme is the public-key certicate associated with each user. Each certicate contains the public-key of a user and is signed with the private key of a trusted certication authority (CA). The user certicates are assumed to be created by some trusted certication authority (CA) and placed in the directory by the CA or by the user.

Dr. Ashok Kumar Das (IIIT-H)

System & Network Security

5 / 23

General Format of a X.509 Certicate

Table: X.509 Certicate Formats

Version (1/2/3) (V) Certicate serial number (SN) Signature algorithm identier (AI) Issuer name (CA) Period of validity (TA ) Subject (user) name (A) Subjects public-key info (Ap ) Issuer unique identier (V2 and V3 only) Subject (user) unique identier (V2 and V3 only) Extensions (V3 only) Signature on the above elds (all versions)

Dr. Ashok Kumar Das (IIIT-H)

System & Network Security

6 / 23

General Format of a X.509 Certicate (Continued...)


Version: Differentiates among successive versions of the certicate format: the default version is V1. If the issuer unique identier or subject unique identier are present, then it is V2. If one or more extensions are present, the version must be V3. Serial Number: An integer value, unique within issuing CA. Signature algorithm identier: The algorithm used to sign the certicate, together with associated parameters. Issuer Name: X.500 name of the CA that created and signed this certicate. Period of Validity: Consists of two dates: the rst and last on which the certicate is valid. Subject Name: The name of the user to whom this certicate refers. That is, this certicate certies the public key of the subject who holds the corresponding private key.
Dr. Ashok Kumar Das (IIIT-H) System & Network Security 7 / 23

General Format of a X.509 Certicate (Continued...)


Subject Name: The name of the user to whom this certicate refers. That is, this certicate certies the public key of the subject who holds the corresponding private key. Issuer Unique Identier: An optional bit string eld used to identify uniquely the issuing CA in the event the X.500 name has been reused for different entities. Subject Unique Identier: An optional bit string eld used to identify uniquely the subject in the event the X.500 name has been reused for different entities. Extensions: A set of one or more extension elds. Extensions are added in V3. Signature: Covers all of the other elds of the certicate; it contains the hash code (H) of the other elds, encrypted with CAs private key. This eld includes the signature algorithm identier.
Dr. Ashok Kumar Das (IIIT-H) System & Network Security 8 / 23

General Format of a X.509 Certicate (Continued...)

The standard uses the following notation to dene a certicate (for V1): CA << A >>= CA{V , SN , AI , CA, TA , A, Ap } CA << A >> = the certicate of user A issued by the certication authority CA. sgnData = signature of the information I = {V , SN , AI , CA, TA , A, Ap }. sgnData = EKRca [H (V ||SN ||AI ||CA||TA ||A||Ap )]. KRca : private key of CA; KUca : public key of CA. Thus, CA << A >>= {V , SN , AI , CA, TA , A, Ap , sgnData} = {V , SN , AI , CA, TA , A, Ap , EKRca [H (V ||SN ||AI ||CA||TA ||A||Ap )]}.

Dr. Ashok Kumar Das (IIIT-H)

System & Network Security

9 / 23

Certicate Revocation

Sometimes it may be desirable to revoke a certicate before it expires due to the following reasons:
The users private key (KR) is assumed to be compromised. The user is no longer certied by this CA. The CAs certicate is assumed to be compromised.

Dr. Ashok Kumar Das (IIIT-H)

System & Network Security

10 / 23

Certicate Revocation (Continued...)

Table: Certicate Revocation List (CRL)

Revoked Certicate Revoked Certicate

Signature Algorithm Identier (AI) Issuer Name (CA) This update date Next update date User certicate Serial # Revocation date . . . User certicate Serial # Revocation date Signature on the above elds

Dr. Ashok Kumar Das (IIIT-H)

System & Network Security

11 / 23

Certicate Authentication
U

U<<V>>

V Certificates of X generated by by other CAs Useful for traversing down a hierarchy of CAs

V<<X>>

Figure: Forward certicates example

Dr. Ashok Kumar Das (IIIT-H)

System & Network Security

12 / 23

Certicate Authentication (Continued...)


Z

Y<<Z>>

X<<Y>>

Y Certificates generated by X are certificates of other CAs Useful for traversing up a hierarchy of CAs

Figure: Reverse certicates example


Dr. Ashok Kumar Das (IIIT-H) System & Network Security 13 / 23

Certicate Authentication (Continued...)

Problem: Suppose that user A has a digital certicate from certication authority X1 and user B has obtained a certicate from CA X2 . We would like to present a hypothetical scenario where user A veries the certicate of user B .
Case I: If A does not know securely the public-key of X2 , the B s certicate issued by X2 is useless to A, because the certicate needs to be decrypted using KUX2 , the public-key of X2 . A can read the certicate, but can not verify the signature.

Dr. Ashok Kumar Das (IIIT-H)

System & Network Security

14 / 23

Certicate Authentication (Continued...)


Case II: If two CAs have securely exchanged their own public keys, then the following procedure will enable A to obtain B s public key:
Step 1. A obtains the certicate of X2 signed by X1 from the directory. Because A securely knows the X1 s public key, A can obtain X2 s public-key from its certicate and verify it by means of X1 s signature on the signature. Step 2. A then goes back to the directory and obtains the certicate of B signed by X2 . Because A knows now a trusted copy of X2 s public-key, A can verify the signature and securely obtain B s public-key. Hence, A veries the certicate of B .

Note: Here, A has used a chain of certicates to obtain B s public key. In the notation of X.509, this chain is expressed as: X1 << X2 >> X2 << B >>. In a similar fashion, B can also obtain As public-key with the reverse chain: X2 << X1 >> X1 << A >>.
Dr. Ashok Kumar Das (IIIT-H) System & Network Security 15 / 23

Certicate Authentication (Continued...)

Generalization of this scheme


The above scheme need not to be limited to a chain of two certicates. An arbitrarily long path of CAs can be followed to produce a chain. A chain with N elements could be expressed as: X1 << X2 >> X2 << X3 >> . . . XN << B >> A can use the chain to verify the certicate of B issued by CA, XN .

Dr. Ashok Kumar Das (IIIT-H)

System & Network Security

16 / 23

Certicate Authentication (Continued...)


U

U<<V>> V<<U>>

V<<W>> W<<V>>

V<<Y>> Y<<V>>

W<<X>> X<<W>> X<<Z>>

Z X

Y<<Z>> Z<<Y>> Z<<X>>

X<<C>>

X<<A>>

Z<<B>>

Figure: X.509 Hierarchy: A Hypothetical Example


Dr. Ashok Kumar Das (IIIT-H) System & Network Security 17 / 23

Authentication Procedures
One-way Authentication
It involves a single transfer of information from one user (A) to another (B ), and establishes the following. 1. The identity of A and that the message was generated by A. 2. That message was intended for B . 3. The integrity and originality (it has not been sent multiple times) of the message. A B : tA , rA , IDB , sgnData, EKUb (Kab ) tA : timestamp prevents delayed delivery of messages, rA : random nonce used to detect replay attacks. B stores the nonce until it expires and reject any new messages with the same nonce, IDB : identity of B , sgnData = EKRa [tA ||rA ||IDB ], signature on data containing tA , rA , and IDB . Kab : secret symmetric session key between A and B .
Dr. Ashok Kumar Das (IIIT-H) System & Network Security 18 / 23

Authentication Procedures (Continued...)


One-way Authentication (Continued...)
t A r A A ID Compare Compare

Compare

E {t , r , ID } A A B KR a

, ID } { t , r A A B

(K ab ) KU b

KU a

D KR

Store K

ab

Figure: Verication of signature by B


Dr. Ashok Kumar Das (IIIT-H) System & Network Security 19 / 23

Authentication Procedures (Continued...)

Two-way Authentication
It involves transfer of two messages between one user (A) to another (B ), and establishes the following:
1. The identity of A and that the message was generated by A. 2. That message was intended for B . 3. The integrity and originality (it has not been sent multiple times) of the message. 4. The identity of B and that the reply message was generated by B. 5. That the message was intended for A. 6. The integrity and originality of the replay.

Dr. Ashok Kumar Das (IIIT-H)

System & Network Security

20 / 23

Authentication Procedures (Continued...)

Two-way Authentication (Continued...)


A B : tA , rA , IDB , sgnData1 , EKUb [Kab ] B A : tB , rB , IDA , sgnData2 , EKUa [Kba ] Kab = Kba sgnData1 = EKRa [tA ||rA ||IDB ] sgnData2 = EKRb [tB ||rB ||IDA ||rA ]

Dr. Ashok Kumar Das (IIIT-H)

System & Network Security

21 / 23

Authentication Procedures (Continued...)


Three-way Authentication (X.509 Strong Authentication Procedure)
Involves exchanges of three messages between A and B Final message from A to B is included, which a signed copy of the nonce rB . A B : tA , rA , IDB , sgnData1 , EKUb [Kab ] B A : tB , rB , IDA , rA , sgnData2 , EKUa [Kba ] A B : EKRa (rB ) Kab = Kba sgnData1 = EKRa [tA ||rA ||IDB ] sgnData2 = EKRb [tB ||rB ||IDA ||rA ] This approach is needed when synchronized clocks are not available.
Dr. Ashok Kumar Das (IIIT-H) System & Network Security 22 / 23

Thank You

Dr. Ashok Kumar Das (IIIT-H)

System & Network Security

23 / 23

You might also like