Symmetric Key Infrastructure

1. Symmetric Key Infrastructure Karel Masarik, Daniel Cvrcek Faculty of Information Technology Brno University of Technology xmasar01@stud.fit.vutbr.cz, cvrcek@fit.vutbr.cz

2. Current State • there is no TTP / CA generally trusted • large amount of CAs • standards for name structure - uniqueness • complicated mutual certificate verification • is it possible to transfer trust? • see Farrell’s presentation from yesterday (XML) • commercial pressure to use certificates as often as possible – everywhere • certificate structure becomes complicated

3. Certificate Verification • signature verification • certificate validity verification • certificate attributes verification • cross-check with list of revoked certificates • all the steps several times • verification of root-certificate hash

4. PKI - Summary • there is a TTP + simple key management - when broken, one can not even verify a signature • signature verification + in-site (original idea) - access to actual CRL -> on-line access to TTP • unique identification + each CA (certificate service provider) takes care of it - is the recipient able to perform the same (never seen an ID card) • non-repudiation • the biggest advantage of … not PKI but asymmetric crypto

5. The Facts • asymmetric cryptography • simple key-agreement • non-repudiation • when a shared key exists, all the subsequent communication the same as with the symmetric key management • X.509-based PKI fails • very serious problem is to keep actual information about public keys • the assumptions leading to X.509 definition

6. Communication Schemes • 1:n – server with clients how big problem is to have a shared symmetric key with the server and use for generation of short-term public key certificates • m:n, m=n, network (equivalent nodes) • server – the one running its own key management • a) intranet – one server • b) e-business –small number of servers • c) e-mail - peers • >1 server => mutual trust

7. Eliminating PKI Problems • Tiny PKI • Local Key Infrastructure • entry point – X.509 certificate (link to PKI) • our own local shared keys • symmetric or asymmetric • validity of local keys is short / one-time key • we do not need CRL • revocation is automatic or on peer-to-peer basis

8. SDSI names attributes authentication key Local Scheme CA X. 509 certificates CA CA PKI client client client client Lokální KI server client Example AK – certificate and shared secret hash AK is the index into databases of shared keys

9. Properties • minimal dependance on PKI (enrollment) • complete certificate verification done only once • certificate make link • name – public key • exploring PKI’s unique identification of users • CRL is replaced with other mechanisms • short-time keys, one-time tickets, direct revocation • in n:a communication model client complexity grows • categories signer – verifier disappear

10. Symmetric Key Infrastructure • 2000 - Christianson, Crispo, Malcolm Proc. of Security Protocols • basis for a project solved as M.Sc. thesis • forward secrecy • Ki=H(Si-1|1) and Si=H(Si-1|0) • Si – shared secret • Ki – symmetric key valid for just one message • Si and Ki are updated with each message exchange

11. A T B Non-Repudiation • we want to transfer messages secured with symmetric crypto • exploiting mutually mistrusting parties for non-repudiation • EAT(M), EAB(M) – ETB(M), EAB(M) A, T, B – mutuallymistrusting S – e.g. firewalls

12. Trusted Third Party • it is needed • shared keys with all users or other TTPs • key distribution or translation center – very powerful • use of DH key agreement protocol • DH does not ensure authentication • we do trust TTP to ensure authentication • TTP does not posses enough information to follows client communication sessions

13. Authentication Protocol • just an example of how to do it (Denning-Sacco variant of Needham-Schroeder protocol) • Alice, Bob, and TTP • a common generator g and modulus N • A  B: gXa mod N • B  A: gXb mod N • A  T: IDA, IDB, H2(gXaXb) • T  A: {IDA, KAB, H2(gXaXb), {IDA, KAB, H2(gXaXb)}KBT}KAT • A  B: {IDA, KAB, H2(gXaXb)}KBT • B  A: {H(gXaXb)}KAB

14. Messages MKsm1, MKsr mirrors MKm3r, MKsr MKm1m2, MKsr MKm2m3, MKsr

15. Messages MKsm1, MKsr mirrors MKm3r <> MKsr MKm1m2, MKsr MKm2m3, MKsr

16. What We Can Do • create new relations between “anonymous” entities • decrease importance of TTP into authentication and control (arbiter) functions • offer mechanisms for ensuring non-repudiation in the case of any dispute • detect unauthorized changes of messages and detect their originator • compromise of TTP does not break the whole scheme – users can still work

17. What is the cost • each principal needs a hardware security module (smart card at least) • PKI expects the same from you • each principal generates and keeps logs • it is for all principals and all messages they send/receive/transmit • there must be a TTP for principal enrolment and dispute solving • PKI needs a TTP with much more power

18. Conclusions • PKI is not universal and problem-free • key management should be designed with taking care of environment • we do not need X.509v3, v4 in most applications • less options • requirements must be made mandatory