Public Key Infrastructure Chester Rebeiro IIT Madras Recollect - - PowerPoint PPT Presentation

▶
public key infrastructure
SMART_READER_LITE
LIVE PREVIEW

Public Key Infrastructure Chester Rebeiro IIT Madras Recollect - - PowerPoint PPT Presentation

Mar 15, 2024 406 likes •978 views

Public Key Infrastructure Chester Rebeiro IIT Madras Recollect Diffie-Hellman Key Exchange Key Establishment : Alice and Bob want to use a block cipher for encryption. How do they agree upon the secret key Alice and Bob agree upon a

slide-1
SLIDE 1

Public Key Infrastructure

Chester Rebeiro IIT Madras

slide-2
SLIDE 2
  • Key Establishment : “Alice and Bob want to use a block cipher for encryption.

How do they agree upon the secret key”

2

Alice and Bob agree upon a prime p and a generator g. This is public information choose a secret a compute A = ga mod p choose a secret b compute B = gb mod p B A Compute K = Ba mod p Compute K = Ab mod p Ab mod p = (ga)b mod p = (gb)a mod p = Ba mod p

Recollect Diffie-Hellman Key Exchange

slide-3
SLIDE 3

Man in the Middle Attack

3

Alice sends his public key Alice decrypts with her private key Bob encrypts with Sally’s public key Man in the middle Intercepts messages Sally sends her public key Sally decrypts with her private key and re-encrypts With Alice’s public key

slide-4
SLIDE 4

Man in the Middle Attack

4

Alice sends his public key Alice decrypts with her private key Sally encrypts with Mallory’s public key Man in the middle Intercepts messages Sally sends her public key Sally decrypts with her private key and re-encrypts With Alice’s public key

Fundamental Problem: Who is Alice? Bob has no way to tell whether the public key he received belongs to Alice or not.

slide-5
SLIDE 5

5

choose a secret a compute A = ga mod p choose a secret b compute B = gb mod p Digitally certificate Public key of Bob (B) Compute K = Ba mod p Compute K = Ab mod p

Certifying Authority

Digitally certificate Public key of Alice (A)

slide-6
SLIDE 6

X.509 Digital Certificates

Contains

  • Serial Number
  • Issuer à the certifying authority details
  • Subject à information about the owner (who own’s the public key for

example Alice)

  • Public Key àAlice’s public key
  • Validity
  • Signature à The signature of the certificate signed by the certifying

authority

6

slide-7
SLIDE 7

7

A more practical Perspective

slide-8
SLIDE 8

8

A more practical Perspective

Verify the subject

Ensure that the person applying for the certificate either owns

  • r represents the identity in the subject field.

2, Verify Identity of Alice

slide-9
SLIDE 9

9

A more practical Perspective

Signing digital certificates

CA generates a digital signature for the certificate using its private key. Once the signature is applied, the certificate cannot be modified. Signatures can be verified by anyone with the CA’s public key.

2, Verify Identity of Alice

  • 3. Digitally Sign
slide-10
SLIDE 10

10

  • 4. Alice’s certificate

Signed by CA

A more practical Perspective

Alice can advertise the certificate on her website

2, Verify Identity of Alice

  • 3. Digitally Sign
slide-11
SLIDE 11

11

choose a secret a compute A = ga mod p choose a secret b compute B = gb mod p Alice’s certificate Signed by CA Compute K = Ba mod p Compute K = Ab mod p

A more practical Perspective

Bob’scertificate Signed by CA Alice’s certificate Bob’s certificate

slide-12
SLIDE 12

Fetching certificates with openssl

12

Hostname : port header Certificate 1 header Certificate 2

  • - BEGIN CERTIFICATE --
  • - END CERTIFICATE --
slide-13
SLIDE 13

Fetching certificates with openssl

13

Hostname : port Cut and paste in a file paypal.pem (PEM: privacy enhanced mail) To view text equivalent of this, use

  • penssl x509 –in paypal.pem –text -noout
slide-14
SLIDE 14

Example of X.509 Certificate (1st Part)

The CA’s identity (Symantec) The owner of the certificate (paypal)

slide-15
SLIDE 15

Example of X.509 Certificate (2nd Part)

Public key CA’s signature

slide-16
SLIDE 16

Who Certifies the CA?

16

There are many CAs in the real world, and they are organized in a hierarchical structure.

slide-17
SLIDE 17

Root CAs and Self-Signed Certificate

  • A root CA’s public key is also stored in an X.509 certificate. It is self-

signed.

  • Self-signed: the entries for the issuer and the subject are identical.
  • How can they be trusted?
  • Public keys of root CAs are pre-installed in the OS, browsers and other software

Same

slide-18
SLIDE 18

Root CAs in Mac OS

18

slide-19
SLIDE 19

Intermediate CAs and Chain of Trust

Paypal’s certificate Intermediate CA’s certificate

A is used to verify B B A Something else is need to verify A (certificate from another intermediate CA or root CA)

slide-20
SLIDE 20

Fetching certificates with openssl

20

Hostname : port header Certificate 1 header Certificate 2

  • - BEGIN CERTIFICATE --
  • - END CERTIFICATE --
slide-21
SLIDE 21

21

slide-22
SLIDE 22

22

slide-23
SLIDE 23

Manually Verifying a Certificate Chain

  • Paypal.pem: Save Paypal’s certificate to a file called
  • Symatec-g3.pem: Save certificate from “Symantec Class 3 EV SSL CA – G3”
  • VeriSign-G5.pem: Save the VeriSign-G5’s certificate from the browser

Root CA’s certificate Chain of certificates

slide-24
SLIDE 24

The Entire Process

24

  • 1. Setup the CA

CA

slide-25
SLIDE 25

25

  • 1. Setup the CA

CA’s self signed certificate CA’s public-private key (password protected)

slide-26
SLIDE 26

26

  • 1. Setup the CA

modelCA’s certificate Self signed

slide-27
SLIDE 27

The Entire Process

27

  • 1. Setup the CA
  • 1. Generate Keys

CA user

slide-28
SLIDE 28

28

  • 1. User Generate

Keys

slide-29
SLIDE 29

29

  • 1. User Generate

Keys n = p x q n Public key (A) Private key (a) p q ap aq q-1

slide-30
SLIDE 30

The Entire Process

30

  • 1. Setup the CA
  • 1. Generate Keys

CA user

  • 2. Generate CSR

(certi signing req)

slide-31
SLIDE 31

31

  • 2. Generate CSR

(certi signing req)

slide-32
SLIDE 32

32

  • 2. Generate CSR

(certi signing req) Signed with the bank’s private key (self signed)

slide-33
SLIDE 33

The Entire Process

33

  • 1. Setup the CA
  • 1. Generate Keys

CA user

  • 2. Generate CSR

(certi signing req)

  • 2. Create Certificate

Send csr file

slide-34
SLIDE 34

34

  • 2. Create Certificate
slide-35
SLIDE 35

The Entire Process

35

  • 1. Setup the CA
  • 1. Generate Keys

CA user

  • 2. Generate CSR

(certi signing req)

  • 2. Create Certificate

Send certificate

  • 3. Deploy

(https server)

slide-36
SLIDE 36

36

  • 3. Deploy
slide-37
SLIDE 37

The Entire Process

37

  • 1. Setup the CA
  • 1. Generate Keys

CA user

  • 2. Generate CSR

(certi signing req)

  • 2. Create Certificate
  • 3. Deploy

(https server) client

slide-38
SLIDE 38

38

client A client fails to connect because it cannot verify the first (root) Certificate (modelCA)

slide-39
SLIDE 39

39

client A client connects if the modelCAs certificate is known

slide-40
SLIDE 40

40

https://localhost:44330

slide-41
SLIDE 41

41

https://cse.iitm.ac.in:44330

slide-42
SLIDE 42

42

Register modeCA in your system (need to select that you trust this CA)

slide-43
SLIDE 43

43

https://cse.iitm.ac.in:44330

slide-44
SLIDE 44

Attacker forwards authentic certificate

44

3, Verify Identity of Alice

  • 4. Digitally Sign

Bank.com

slide-45
SLIDE 45

Attacker changes public key with her own

45

3, Verify Identity of Alice

  • 4. Digitally Sign

Request at CA is going to be fail Because signature does not match public key Bank.com

slide-46
SLIDE 46

Attacker sends her own public key + signature

46

3, Verify Identity of Alice

  • 4. Digitally Sign

Verify should fail Bank.com

slide-47
SLIDE 47

47

Alice’s certificate Signed by CA

Consider this Situation

Bank.com Certificate Signed by CA Bank’ s certificate

  • 1. Attacker modifies public keys
  • 2. Attacker replaces Bob’s certificate with his/her own
slide-48
SLIDE 48

48

Alice’s certificate Signed by CA

Consider this Situation

Bank’s certificate

  • 1. Attacker forwards fake certificate
  • 2. Attacker replaces Bob’s certificate with his/her own

(What is the requirement to have a MIMA?) Bank.com Certificate Signed by CA

slide-49
SLIDE 49

Attacker Sends His/Her Own Certificate

  • Attacker’s certificate is valid.
  • Browser checks if the identity specified in the subject field of the

certificate matches the Alice’s intent.

  • There is a mismatch: attacker.com ≠ example.com
  • Browser terminates handshake protocol: MITM fails
slide-50
SLIDE 50

Emulating an MITM Attack

  • DNS Attack is a typical approach to achieve MITM
  • We emulate an DNS attack by manually changing the /etc/hosts file on the

user’s machine to map example.com to the IP address of the attacker’s machine.

  • On attacker’s machine we host a website for example.com.
  • We use the attacker’s X.509 certificate to set up the server
  • The Common name field of the certificate contains attacker32.com
  • When we visit example.com, we get an error message:
slide-51
SLIDE 51

Attacks Surfaces on PKI

slide-52
SLIDE 52

Attack on CA’s Verification Process

  • CA’s job has two parts:
  • Verify the relationship between certificate applicant and the subject

information inside the certificate

  • Put a digital signature on the certificate
  • Case study: Comodo Breach [March 2011]
  • Popular root CA.
  • The approval process in Southern Europe was compromised.
  • Nine certificates were issued to seven domains and hence the attacker

could provide false attestation.

  • One of the affected domain (a key domain for the Firefox browser):

addons.mozilla.org

slide-53
SLIDE 53

Attack on CA’s Signing Process

  • If the CA’s private key is compromised, attackers can sign a

certificate with any arbitrary data in the subject field.

  • Case Study: the DigiNotar Breach [June-July 2011]
  • A top commercial CA
  • Attacker got DigiNotar’s private key
  • 531 rogue certificates were issued.
  • Traffic intended for Google subdomains was intercepted: MITM attack.
  • How CAs Protect Their Private Key
  • Hardware Security Model (HSM)
slide-54
SLIDE 54

Attacks on Algorithms

  • Digital Certificates depend on two types of algorithms
  • one-way hash function and digital signature
  • Case Study: the Collision-Resistant Property of One-Way Hash
  • At CRYPTO2004, Xiaoyun Wang demonstrated collision attack against MD5.
  • In February 2017, Google Research announced SHAttered attack
  • Attack broke the collision-resistant property of SHA-1
  • Two different PDF files with the same SHA-1 has was created.
  • Countermeasures: use stronger algorithm, e.g. SHA256.
slide-55
SLIDE 55

Attacks on User Confirmation

  • After verifying the certificate from the server, client software is sure that

the certificate is valid and authentic

  • In addition, the software needs to confirm that the server is what the user

intends to interact with.

  • Confirmation involves two pieces of information
  • Information provided or approved by user
  • The common name field inside the server’s certificate
  • Some software does not compare these two pieces of information: security flaw
slide-56
SLIDE 56

Attacks on Confirmation: Case Study

Phishing Attack on Common Name with Unicode

  • Zheng found out several browsers do not display the domain name

correctly if name contains Unicode.

  • xn—80ak6aa92e.com is encoded using Cyrillic characters. But

domain name displayed by browser likes like apple.com

  • Attack:
  • Get a certificate for xn—80ak6aa92e.com
  • Get user to visit xn—80ak6aa92e.com, so the common name is matched
  • User’s browser shows that the website is apple.com. User can be fooled.
  • Had the browser told the user that the actual domain is not the real

apple.com, the user would stop.