460 likes | 654 Views
Topics. Digital Signature (Signed Hashed value) Digital Certificate User Authentication Mechanisms Secure Socket Layer (SSL) GSM Security. Digital Signature. Speed and practice consideration Sign on Hashed value of the message. How can public key been seen.
E N D
Topics • Digital Signature (Signed Hashed value) • Digital Certificate • User Authentication Mechanisms • Secure Socket Layer (SSL) • GSM Security
Digital Signature • Speed and practice consideration • Sign on Hashed value of the message
How can public key been seen • Store a list of trusted public keys in your storage. • Public key signed by a authorized unit. (digital Certificate)
Digital Certificate • Digital version of a paper-based passport • Identifies a person/organization uniquely on the Internet • Binds a user with its public key
Digital Certificate “I officially approve the relation between the holder of this certificate (the user) and this particular public key. Digital Certificate Concept Fig 5.1
Digital Certificate Contents • Main contents are the subject name (user), validity and public key • Signed by a Certification Authority (CA) • Provides guarantees about a user’s identity
Digital Certificate Subject Name: Atul Kahate Public Key: <Atul’s key> Serial Number: 1029101 Other data: Email - akahate@indiatimes.com Valid From: 1 Jan 2001 Valid To: 31 Dec 2004 Issuer Name: VeriSign … Digital Certificate Example Fig 5.2
Passport entry Corresponding digital certificate entry Full name Subject name Passport number Serial number Valid from Same Valid to Same Issued by Issuer name Photograph and signature Public key Similarities between a Passport and a Digital Certificate Fig 5.3
Version Certificate Serial Number Signature Algorithm Identifier Issuer Name Validity (Not Before / Not After) Subject Name Subject Public Key Information Issuer Unique Identifier Subject Unique Identifier Extensions Certification Authority’s Digital Signature Digital Certificate Contents
Field Description Version Identifies a particular version of the X.509 protocol, which is used for this digital certificate. Currently, this field can contain 1, 2 or 3. Certificate Serial Number Contains a unique integer number, which is generated by the CA. Signature Algorithm Identifier Identifies the algorithm used by the CA to sign this certificate. (We shall examine this later). Issuer Name Identifies the Distinguished Name (DN) of the CA that created and signed this certificate. Validity (Not Before/Not After) Contains two date-time values (Not Before and Not After), which specify the timeframe 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 (DN) of the end entity (i.e. the user or the organization) to whom this certificate refers. This field must contain an entry unless an alternative name is defined in Version 3 extensions. Subject Public Key Information Contains the subject’s public key and algorithms related to that key. This field can never be blank. Digital Certificate Contents
CA Hierarchy • There can be multiple level CAs • Useful for delegation of work • Each higher level CA vouches for its subordinate CA
Root CA Second Level CA Second Level CA Second Level CA Third Level CA Third Level CA Third Level CA Third Level CA … … … CA Hierarchy Fig 5.20
Root CA Second Level CA (A3) Second Level CA (A2) Second Level CA (A1) Third Level CA (B11) Third Level CA (B10) Third Level CA (B1) Third Level CA (B2) … Bob … … Alice Same Root CA Fig 5.21
Digital Certificate … Issuer Name: ??? Subject Name: Root … Digital Certificate … Issuer Name: Root Subject Name: A3 … Digital Certificate … Issuer Name: A3 Subject Name: B11 … Digital Certificate … Issuer Name: B11 Subject Name: Bob … How to Verify Root CA? Fig 5.22
Digital Certificate … Issuer Name: Root Subject Name: Root … Self-signed Certificate Fig 5.23
Cross-Certification • In some cases, even root CAs can be different • In such cases, they certify each other • Creates a cross level trust
Root CA of Japan Root CA of the US Cross-certified Second Level CA (P1) Second Level CA (A1) Third Level CA (Q2) Third Level CA (Q1) Third Level CA (B1) Third Level CA (B2) Bob … … Alice Cross-Certification of CAs Fig 5.25
Validity of a Certificate • It is necessary to check the validity of a certificate before it is used • Two chief mechanisms: • Online Checks • Offline Checks
Authentication • Who is who? • Identifies a user or a resource • Establishes trust before communication can take place
Authentication Mechanisms • Passwords • Message digests of passwords • Authentication Tokens • Certificate-based Authentication • Biometrics
Password Authentication Id Password Alice fiddle Amay wang1123 Atul hor{9mn} ID: Alice, password: fiddle Bob Alice • Problems: • Password is clear text • 2. How server Bob store users’ password
Message Digests of Passwords Id Hash(Pass) Alice pp*;; Amay werr[}; Atul fghppo{ ID: Alice, passwd:Hash( fiddle} Bob Alice • Problems: • Replay attacks
I’m Alice R Alice Bob R signed with Alice’s private key Solve the replay attack problem • Create a secure channel when communicating. Secure channel ID: Alice, passwd:Hash( fiddle} Bob Alice • Challenge/response between User and Server
Message Digests of Passwords • Original clear text password is never stored/transmitted • Message digest of password is stored in the database, and the same is used for authentication • Problems: replay attacks
Step 1: Calculate the message digests of the passwords on the server-side. tiger newroad april … G%6$1 Vt^80+1 +{:>9mn Passwords Message digests of passwords Message digest algorithm Step 2: Store the user ids and message digests of the passwords in the user database. Id Password Jyoti G%6$1 Amar Vt^80+1 Atul +{:>9mn Server User creation program User database Message Digests of Passwords Fig 7.7
Authentication Tokens • Token and server are synchronized initially • Token generates fresh passwords periodically • Same passwords are generated at the server
Authentication Token Concept Id = atul passWd = 615019191 Bob Alice Seed Id Seed Alice 1123456 Amar 415901617 Atul 615019191 passWd = 615019191 Seed: 1123456
Certificate-based Authentication • User’s certificate details need to be stored on the server-side • CA distributes the certificates to the users also • Validation between the two takes place at the time of authentication
Certificate Server Certificate Certification Authority (CA) User database Id Public Key Validity… Jyoti1 59010191 June 2003 Amar 415901617 May 2002 Atul 615019191 July 2003 Certificate Certificate To respective users Digital Certificate Storage
Step 1: User’s computer encrypts the random challenge with the user’s private key to produce the digital signature. Server Original random challenge 8102811291012 Private key file Encrypt User’s digital signature 90184112124832 Step 2: User’s computer sends the digital signature to the server as a part of the login request. Server Login request Id = atul Sign = 90184112124832 Certificate-based Authentication
Problem/Issue Emerging solution Smart card readers are not yet a part of a desktop computer, unlike a hard disk drive or a floppy disk drive The new versions of computers and mobile devices are expected to come with smart card readers out of the box. Non-availability of smart card reader driver software Microsoft has made the PC/SC smart card framework an integral part of the Windows 2000 operating system. Most smart card reader manufacturers ship the PC/SC compliant reader drivers, making the process of adding a reader hardware to the computer a plug-and-play operation. Non availability of smart card aware cryptographic services software Smart-card aware software such as Microsoft Crypto API (MS-CAPI) comes free with Internet Explorer. Cost of smart cards and card readers is high This is reducing now. Smart cards are available for about $5, and the card readers for about $20. Smart Card Issues and Solutions
Authentication in Wireless Communication • 802.11i • GSM (Global System for Mobible Communications) • DECT (Digital Eurpean Cordless Telephone)
GSM • Handset with SIM card , HLR(Home Location Register), VLR(Visitor Location Register) • Handset HLR has IMSI (International Mobile Subscriber Identity) and Ki (an Authentication Key) • Three functions are used: A3, A5,A8 : • A3 and A8 are one way function like hash but much simpler, • A5 is the one key encrypted/decrypted function like RC4,
VLR Handset HLR IMSI IMSI IMSI, RAND, Kc, SRES RAND SRES A5Kc(TMSI) ACK SRES=A3(Ki//RAND) Kc=A8(Ki//RAND)
Secure Socket Layer (SSL) • World’s most widely used security mechanism on the Internet • Secures communication between a client and a server • Located between the Application and Transport Layers of TCP/IP protocol suite
Application Layer SSL Layer Transport Layer Internet Layer Data Link Layer Physical Layer Position of SSL in TCP/IP Fig 6.9
X Y Application LA data L5 data SSL SH SH Performed LAdata Performed LA data Transport H4 H4 Performed LA data+SH Performed LA data+SH Internet Performed LA data+SH+H4 Performed LA data+SH+H4 H3 H3 Data Link Performed LA data+SH+H4+H3 Performed LA data+SH+H4+H3 H2 H2 Physical 010101010100010101010010 010101010100010101010010 Transmission medium Data Exchange including SSL Fig 6.10
SSL Sub-Protocols • Handshake Protocol • Record Protocol • Alert Protocol
Type Length Content 1 byte 3 bytes 1 or more bytes SSL Handshake Message Format Fig 6.11
Message Type Parameters Hello request None Client hello Version, Random number, Session id, Cipher suite, Compression method Server hello Version, Random number, Session id, Cipher suite, Compression method Certificate Chain of X.509V3 certificates Server key exchange Parameters, signature Certificate request Type, authorities Server hello done None Certificate verify Signature Client key exchange Parameters, signature Finished Hash value SSL Handshake Messages
Establish security capabilities Server authentication and key exchange Client authentication and key exchange Finish Web Browser Web Server SSL Handshake Process
Web Browser Web Server Step 1: Client hello Step 2: Server hello SSL Handshake – Phase 1
Step 1: Certificate Web Browser Web Server Step 2: Server key exchange Step 3: Certificate request Step 4: Server hello done SSL Handshake – Phase 2
SSL Handshake – Phase 3 Step 1: Certificate Web Browser Web Server Step 2: Client key exchange Step 3: Certificate verify
1. Change cipher specs Web Browser Web Server 2. Finished Step 3: Change cipher specs Step 4: Finished SSL Handshake – Phase 4
Application data Fragmentation Compression Addition of MAC Encryption Append header SSL Record Protocol Performed Action on Application data