1. Non-PKI Methods for Public Key Distribution
Authors: Mohammad Peyavian, Allen Roginsky and Nevenko Zunic
Source: Computers & Security, Vol.23, pp , 2004.
Adviser: Min-Shiang Hwang
Speaker: Chun-Ta Li
Date: 2004/10/28

2. Outline Introduction The first proposed scheme
The second proposed scheme
The third proposed scheme
Conclusions
Comments

3. Archived public key distribution without CA
Introduction
Server 1 2 3 3 2 CA
Client 1
The X.509 PKI requires a huge and expensive infrastructure with complex operations.
Archived public key distribution without CA

4. Introduction (cont.) ID: client’s user id -- not a secret value
PKc: initial public component of the client’s public key pair
SKc: initial secret component of the client’s public key pair
PKs: initial public component of the server’s public key pair
SKs: initial secret component of the server’s public key pair
EPK(B): data B encrypted with an asymmetric public key PK.
ESK(B): data B signed by an asymmetric secret key SK.

5. The first proposed scheme
Public key distribution
Client Server
(1) generates (ID, PW)
(2) sends (ID, PW) to client
(3) sends ID, PKc, H(ID, PKc, PW) to server
(4) sends ID, PKs, H(ID, PKs, PW) to server
// PW used only once for authenticating the flows from the client and server

6. The first proposed scheme (cont.)
The first scheme can be added to the top of current SSL implementations (PW-based authentication).
PWc: client generates a password
Client sends PWc to the server (e.g. on-line banking)
Client Server
(1) generates PWc
(2) sends ID, ePKs(PWc), eSKc(H(ID, PWc)) to server

7. The first proposed scheme (cont.)
Public key change if client’s SKc is compromised
Client Server
(1) sends ID, “SKc compromised”, eSKc(H(ID, “SKc compromised”) to server
The client and server do not do any further exchange
Until the client generates and sends a new public key to server
The sending of a new public key is done as “Public key distribution”
// If server public key is compromised, contrariwise

8. The first proposed scheme (cont.)
Regular client public key change (periodically)
Client Server
(1) sends ID, new_PKc, eSKc(H(ID, new_PKc) to server
Both the client and server start using the new client’s public key
They won’t accept any message with the old public key
// If server generates a new public key, contrariwise

9. The second proposed scheme
P: prime modulus for Diffie-Hellman algorithm
Rc: generates random number from the client
Rs: generates random number from the server
D: Diffie-Hellman public key
S: symmetric secret key derived from Diffie-Hellman algorithm
Given that the client and server share an ID and PW
One-sided: Only the client needs to get the server’s public key (PKs).
Two-sided: Both client and sever need to exchange public keys.

10. The second proposed scheme (cont.)
Public key exchange protocol
Client Server
(1) generates P, Rc and computes public key Dc Dc = PWRc mod P
(2) sends ID, Dc, P to server
(3) computes public key Ds Ds = PWRs mod P
(4) computes symmetric secret key S S = DcRs mod P = PWRcRs mod P
(5) sends ID, [PKs], Ds, H(ID, Dc, P, [PKs], Ds, S) to client
(6) computes symmetric secret key S S = DsRc mod P = PWRcRs mod P (7) verifies H(ID, Dc, P, [PKs], Ds, S) using the S value that is derived
(8) sends ID, [PKc], H(ID, PKs, Ds, [PKc], new_PW, S), [eS(new_PW)] to server

11. The second proposed scheme (cont.)
Public key change if client secret key is compromised
Client Server
(1) sends ID, “SKc compromised”, eSKc (H(ID, “SKc compromised”) to server
The client and server do not do any further exchange
Until the client generates and sends a new public key to server
The sending of a new public key is done as “Public key distribution”
// If server public key is compromised, contrariwise

12. The second proposed scheme (cont.)
Regular client public key change (periodically)
Client Server
(1) sends ID, new_PKc, eS (H(ID, new_PKc) to server
Both the client and server start using the new client’s public key
They won’t accept any message with the old public key
// If server generates a new public key, contrariwise

13. The third proposed scheme
Public key exchange protocol
Given that the client and server share an ID and PW
Client Server
(1) sends ID, PKc, H(ID, PKc, PW, Rc) to server
(2) sends ID, PKs, H(ID, PKs, PW, Rs) to server
(3) sends ID, ePKs(Rc) to server
(4) sends ID, ePKc(Rs) to server
// PW used only once for authenticating the flows from the client and server

14. The third proposed scheme (cont.)
The third scheme can be added to the top of current SSL implementations (PW-based authentication).
PWc: client generates a password
Client sends PWc to the server (e.g. on-line banking)
Client Server
(1) generates PWc
(2) sends ID, ePKs(PWc, Rc), eSKc(H(ID, PWc, Rc)) to server

15. Conclusions
The proposed scheme can distribute the public key without CA.
This paper is to present alternative simpler solutions to the X.509 PKI to save storage, bandwidth and to reduce the complexity of the operations.

16. Comments
How to send the PKs and PKc to the client and the server in secure? (The first scheme)
Attacker can masquerade server and client to send the wrong PKs` (pair of SKs`) and wrong PKc` (pair of SKc`)
Attacker will require the PKc
Attacker will require the PWc , because of the client encrypt it by using the wrong PKs`

17. Client Attacker Server
Comments (cont.)
Man-in-the-middle attack (The second scheme)
Public key exchange protocol
Client Attacker Server
(1) generates P, Rc and computes public key Dc Dc = PWRc mod P
(2) sends ID, Dc`, P to server
(3) computes public key Ds Ds = PWRs mod P
Dc` = DcRt = PWRcRt mod P
(4) computes symmetric secret key S` S` = Dc`Rs mod P = PWRcRtRs mod P
Ds` = DsRt = PWRsRt mod P
(5) sends ID, [PKs], Ds`, H(ID, Dc, P, [PKs], Ds`, S`) to client
(6) computes symmetric secret key S S` = Ds`Rc mod P = PWRsRtRc mod P (7) verifies H(ID, Dc, P, [PKs], Ds`, S`) using the S` value that is derived
(8) sends ID, [PKc], H(ID, PKs, Ds, [PKc], new_PW`, S`), [eS`(new_PW`)] to server

18. Comments (cont.)
How to send the PKs and PKc to the client and the server in secure? (The third scheme)
Attacker can masquerade server and client to send the wrong PKs` (pair of SKs`) and wrong PKc` (pair of SKc`)
Attacker will require the PKc
Attacker will require the PWc , because of the client encrypt it by using the wrong PKs`

19. Thanks for your attention

21. Cryptanalysis of the first proposed scheme
Public key distribution
Client Attacker Server
(1) generates (ID, PW)
(2) sends (ID, PW) to client
(3) sends ID, PKc, H(ID, PKc, PW) to server
(3`) sends ID, PKc`, H(ID, PKc`, PW) to server
(4) sends ID, PKs, H(ID, PKs, PW) to server
(4`) sends ID, PKs`, H(ID, PKs`, PW) to server
// PW used only once for authenticating the flows from the client and server

22. Cryptanalysis of the first proposed scheme (cont.)
The first scheme can be added to the top of current SSL implementations (PW-based authentication).
PWc`: attacker generates a password
Attacker sends PWc` to the server
Client Server
without change
(1) generates PWc
(2`) sends ID, ePKs(PWc`), eSKc`(H(ID, PWc`)) to server
(2) sends ID, ePKs(PWc), eSKc(H(ID, PWc)) to server

23. Cryptanalysis of the third proposed scheme
Public key exchange protocol
Given that the client and server share an ID and PW
Client Attacker Server
(1) sends ID, PKc, H(ID, PKc, PW, Rc) to server
(1`) sends ID, PKc`, H(ID, PKc`, PW, Rc`) to server
(2) sends ID, PKs, H(ID, PKs, PW, Rs) to server
(2`) sends ID, PKs`, H(ID, PKs`, PW, Rs`) to server
(3) sends ID, ePKs(Rc) to server
(3`) sends ID, ePKs(Rc`) to server
(4) sends ID, ePKc(Rs) to server
(4`) sends ID, ePKc(Rs`) to server
// PW used only once for authenticating the flows from the client and server

24. Cryptanalysis of the third proposed scheme (cont.)
The third scheme can be added to the top of current SSL implementations (PW-based authentication).
PWc`: attacker generates a password
Attacker sends PWc` to the server
Client Attacker Server
(1) generates PWc
(2) sends ID, ePKs(PWc, Rc), eSKc(H(ID, PWc, Rc)) to server
(2`) sends ID, ePKs(PWc`, Rc`), eSKc`(H(ID, PWc`, Rc`)) to server
without change