1/6/2015HostAP1 P2P Security Case Study: COCA (Cornell Online Certification Authority) Mobile Multimedia Lab, AUEB, 04/04/2003

1/6/2015P2P Security2 of 19 Public Key Cryptography First proposed by Diffie & Hellman (1976) Also known as Asymmetric Cryptography  Assume user A possesses two keys: K e, K d Encryption key K e is made public Decryption key K d is kept secret  Two separate well-known functions exist: E(. ), D(. ) For every message M: D ( K d, E( K e, M ) ) = M To send M to A, users compute and send E( K e, M ) Rivest, Shamir, Adelman (RSA, 1978) proposed specific functions & key generation algorithms

1/6/2015P2P Security3 of 19 Digital Signatures Assume users A, B and message M We want A to send M to B so that: B knows M came from A B knows nobody tampered with M A cannot repudiate M (M is unencrypted while in transit) A could send K d is A’s private key MD5 is an example of a collision-resistant, one-way hash function

1/6/2015P2P Security4 of 19 Public Key Infrastructure (PKI) How do interested parties obtain A’s public key? A can give it to them, along with a certificate that binds his ID to this public key The certificate is signed by a 3 rd party, the Certification Authority (CA) Trust chain (1) If user B trusts the CA (knows the CA’s public key) (2) and the CA trusts A (has issued a certificate to A) then B can trust A (accept A’s public key) Certificate revocation The CA may decide to revoke A’s certificate Before each conversation with A, interested parties should:  Check with the CA for possible revocation  Better yet, obtain the certificate, if any, from the CA directly In either case, the CA needs to be online

1/6/2015P2P Security5 of 19 What is COCA? Cornell Online Certification Authority  Secure *and* Fault-Tolerant online CA  Traditionally, difficult to achieve both  Consists of n peer servers (i.e. the CA is distributed)  Up to t servers can be compromised assuming 3t + 1 <= n (or t < n / 3 ) Compromised? (opposite of Correct)  Server down (‘fail-stop’)  Byzantine failure

1/6/2015P2P Security6 of 19 Additional COCA Assumptions ‘Fair Links’ Completely insecure links, with one assumption: “If a process sends infinitely many messages to a single destination, infinitely many of those are correctly received” i.e. eavesdropping, insertion, corruption, deletion, reordering and replay attacks are allowed Asynchrony No bound on message delivery delay No bound on server execution speed Crypto algorithms used are secure

1/6/2015P2P Security7 of 19 COCA Entities n COCA servers Each has a private/public key pair All server public keys are known to all COCA servers Certificates (stored in COCA) Each with a unique serial number COCA clients Each with a unique cid and private/public key pair. Client may query COCA for another client’s certificate Authorized clients may update COCA certificates COCA service public key Universally known (to clients and servers) COCA service private key Each server knows part of it

1/6/2015P2P Security8 of 19 COCA Operations (1 of 2) QUERY (a Request/Response operation)  R = c query: request type c: requesting client ID seq: a nonce cid: ID of the client whose certificate is requested ( c means request is signed by c )  *WILL* return certificate ζ for cid such that: ζ is valid (created by a previous COCA UPDATE) For any valid ζ’ for cid, σ ( ζ ’) <= σ ( ζ )  Where σ ( ζ ) is the serial number of certificate ζ (assuming up to t compromised servers, always)

1/6/2015P2P Security9 of 19 COCA Operations (2 of 2) UPDATE (a Request/ACK operation)  R =, cred> c update: request type c: requesting client ID seq: a nonce ζ΄: an older certificate for the same cid cid: ID of the client whose certificate is updated key: cid’s new public key  revocation is equivalent to setting this to something random cred: credentials to authorize UPDATE request  *WILL* return ACK after: New certificate ζ for cid is created in COCA such that: σ(ζ’) < σ(ζ)  Idempotent

1/6/2015P2P Security10 of 19 Note on COCA paper Before we proceed… L. Zhou et al, “COCA: A Secure Distributed Online Certification Authority,” ACM TOCS, 20(4), 2002  Assumes familiarity with: D. Malkhi and M. Reiter, “Byzantine Quorum Systems,” Proceedings ACM STOC, 1997 Y. Desmedt and Y. Frankel, “Threshold Cryptosystems,” CRYPTO89, Proceedings LNCS, vol. 435, 1990

1/6/2015P2P Security11 of 19 Byzantine Quorum Systems (BQS) Quorum systems Ensure consistency and availability of replicated data… …despite failure of data repositories (Hidden ‘fail-stop’ assumption: benign failures) BQS assume arbitrary (Byzantine) failures (Byzantine) agreement is not possible with fewer than 3t + 1 processes if t is the maximum number of faulty processes “Reaching agreement in the presence of faults” Byzantine protocols costly and slow! The simplest BQS? Read/write a variable ‘x’ Associate each ‘x’ replica with a timestamp COCA uses a Dissemination BQS that is: “…suited for services that receive and distribute self-verifying information from correct clients that faulty servers can fail to redistribute but cannot undetectably alter”

1/6/2015P2P Security12 of 19 Threshold Cryptosystems Server 1Server 2 Server t + 1 Server t+2 Server n Not Participating Participating in Calculation Partial Share 1 Partial Share 2 Partial Share t + 1 Combiner Final Result Partial Shares Message M (Note that combiner creates the final result without having to see the actual secret) Example of (n, t + 1) threshold cryptography

1/6/2015P2P Security13 of 19 COCA Protocols (1 of 4) Challenges Due to COCA BQS, many “valid” certificates for a cid can exist  Solution: certificate serial numbers & QUERY Clients cannot authenticate COCA server responses  They don’t know their public keys  Solution: delegates (also act as combiners)  Client sends request to t + 1 servers ‘Fair Links’  Solution: retransmissions  Until a signed response is received

1/6/2015P2P Security14 of 19 COCA Protocols (2 of 4) Server Quorum Server Delegate Client t + 1 requests response

1/6/2015P2P Security15 of 19 COCA Protocols (3 of 4) Prove QUERY response ( ζ ) satisfies: (1) ζ is valid (created by a COCA UPDATE) (2) For any valid ζ’ for cid, σ ( ζ’ ) <= σ ( ζ )  Prove (1) ζ satisfies (1) if each certificate is signed by COCA after the UPDATE that created it More than t servers are required to sign a certificate There are not enough compromised servers to sign a certificate. QED

1/6/2015P2P Security16 of 19 COCA Protocols (4 of 4) Prove QUERY response ( ζ ) satisfies: (1) ζ is valid (created by a COCA UPDATE) (2) For any valid ζ’ for cid, σ ( ζ’ ) <= σ ( ζ )  Prove (2) for query QUERY_1 Given BQS Quorum Intersection:  “The intersection of any two quorums contains at least one correct server” If ζ’ was created by UPDATE_1 Some correct server p in QUERY_1 quorum must also be in the UPDATE_1 quorum Let ζ p be p’s response to QUERY_1  Server p always chooses largest serial…  … so σ ( ζ’ ) <= σ ( ζ p )  ζ is the certificate with the largest serial among those from all servers in the QUERY_1 quorum…  … so σ( ζ p ) <= σ( ζ ). QED

1/6/2015P2P Security17 of 19 COCA and DoS attacks DoS (but not DDoS) Countermeasures  Authorization mechanisms  Grouping of requests into classes and RR scheduling  Caching results of expensive crypto operations  ‘Fair Links’, Asynchrony assumptions Consequently: eventuality guarantee, but no real-time guarantees with these two weak assumptions … but real-world usually allows stronger assumptions

1/6/2015P2P Security18 of 19 COCA Proactive Recovery Execute Proactive Recovery protocols periodically:  Reload the code from read-only medium Eliminate Trojan horses  Reconstitute the state of each COCA server  Make obsolete any confidential information an attacker might have obtained

1/6/2015P2P Security19 of 19 Conclusions  Online CAs Vulnerable to network attacks… … but clients’ vulnerability to attacks based on invalidated certificates is reduced  Value of extremely weak assumptions DoS attacks succeed by invalidating assumptions Assumptions are vulnerabilities  The ‘Fault-tolerance vs Security ’ question O(n 2 ) Complexity? Or worse…