A Scalable and Secure Cryptographic Service

1. A Scalable and Secure Cryptographic Service Shouhuai Xu and Ravi Sandhu University of Texas at San Antonio DBSEC'07

2. Roadmap • Motivation • Cryptographic preliminaries • Model and goals • Building block: a single server scheme • Full-fledged scheme • Related work • conclusion DBSEC'07

3. Motivation • Large-scale (e.g., p2p, grid, and GENI) systems must be adequately protected; otherwise they may be exploited to do more harm than good. • Access control enforces a desired policy, but authentication (often based on cryptographic means) is perhaps the watch-dog. • If cryptography (protocol, functionality, key) is compromised, access control cannot help. • If non-repudiation is important for audit, digital signing is needed for authentication. DBSEC'07

4. Motivation • Digital signing based authentication asks each user to possess a pair of public and private keys (e.g., via identity or attribute certificate). • Modern cryptography is “key-centric” • Rivest-Shamir-Adleman have no “short cut” in breaking RSA • But you can generate Rivest’s digital signatures once you compromised his private key • This has no counterpart in handwriting signatures DBSEC'07

5. Motivation • Keys could be relatively easily compromised [Shamir-Someran FC99], [Harrison-Xu DSN’07]. How should the users protect their private signing key and capability? • Hardware token (e.g., TPM) cannot protect signing functionality when OS or application is compromised • Exploit multiple servers to implement threshold signing key and functionality [Xu-Sandhu RSA-CT’03] • Exploit a single sever to implement a flavor of two-party threshold signing [Boyd’89], [Ganesan NDSS’95], [MacKenzie-Reiter Okland’01] • This paper extends [MR01] in several ways DBSEC'07

6. This Paper • Assume a set of servers provide service (e.g., for economic incentives) • But they do not run threshold cryptography • For better performance • For better availability: a single server suffices DBSEC'07

7. Roadmap • Motivation • Cryptographic preliminaries • Model and goals • Building block: a single server scheme • Full-fledged scheme • Related work • conclusion DBSEC'07

8. Cryptographic Preliminaries • Pseudorandom function fk(): • for secret k the output cannot be distinguished from random strings • Message authentication code (MAC) • secure against adaptive chosen message attack • Public key encryption (Init, Enc, Dec) • Secure against adaptive chosen-ciphertext attack • Signature scheme (Init, Sig, Ver) • secure against adaptive chosen message attack DBSEC'07

9. Roadmap • Motivation • Cryptographic preliminaries • Model and goals • Building block: a single server scheme • Full-fledged scheme • Related work • conclusion DBSEC'07

10. Model • A set of semi-trust servers, each with a pair of keys • A server has two interfaces: one for signing and the other for disabling user’s key instance • A set of users, each with a pair of public and private Keys • Private key is somehow split into two parts, one stored at user side and one at a server side • If multiple servers are selected, multiple splits DBSEC'07

11. Adversary • May compromise a user’s computer • May compromise a server’s key, but not the integrity of server end database (for keeping transaction data) DBSEC'07

12. Goals • Abuse prevention (most are inherited from [MR01]): • compromising server does not compromise signing capability • Compromising user & server still needs to launch offline dictionary attack to compromise user’s key • Compromising user end still needs to launch online dictionary attack to sign messages • Compromising user end + password (or when user program is active) cannot compromise signing capability after key is disabled • Hit-and-run attack could be disabled (new!) DBSEC'07

13. Goals (new) • Compromise detection: once the attacker having compromised user end starts to issue signatures, the attack becomes self-evident (kind of crypto-based IDS) • Immediate revocation: password-based revocation • Compromise confinement: compromising of a server is confined to possibly a proper subset of its customers • Scalability: can serve many users • High availability: a user can issue signatures as long as one of his servers is available DBSEC'07

14. Roadmap • Motivation • Cryptographic preliminaries • Model and goals • Building block: a single server scheme • Full-fledged scheme • Related work • conclusion DBSEC'07

15. Building Block: Basic Idea private key of user, sk, is split into two shares (sk1, sk2), and sk1 is protected using password at user end, state information is used to synchronize the system usage Server (pkserver, skserver; state, sk2) User (pk, sk1; state) DBSEC'07

16. Sent to the server Splitting the key Kept at user end Building Block DBSEC'07

17. Signing Enforce 3-factor authentication (token; password; state information (new)) User prepares for authenticating to the server Two-party signing bookkeeping DBSEC'07

18. Building Block • Key disabling via password authentication (one factor authentication) • Transaction atomicity is important (and addressed later) DBSEC'07

19. Building Block • Proposition. The building-block scheme fulfills the properties of abuse prevention, compromise detection, and immediate revocation. • Compromise detection based on the out-of-synchronization of state information • Immediate revocation via password based authentication DBSEC'07

20. Roadmap • Motivation • Cryptographic preliminaries • Model and goals • Building block: a single server scheme • Full-fledged scheme • Related work • conclusion DBSEC'07

21. Full-fledged Scheme private key of user, sk, is split into multiple two-shares (sk1, sk2)i, and the sk1’s is protected using password at user end. Server (pkserver, skserver; state, sk2)i User (pk, sk1; state)i DBSEC'07

22. Enforce server-compromise containment Splitting the key multiple times Another pwd for disabling key Sent to the servers Kept at user end Full-fledged Scheme DBSEC'07

23. Signing Find a server to get the job done Enforce authenticated atomicity (commit/rollback) DBSEC'07

24. Full-fledged Scheme • Key disabling via password authentication (one factor authentication) • Transaction atomicity is important and fulfilled using authenticated commit/rollback DBSEC'07

25. Full-fledged Scheme • Proposition. Suppose there is no loss of system state information, even if system crashes, then transaction atomicity can be assured. • Proposition. The full-fledged scheme fulfill all the desired properties: abuse prevention, compromise detection, immediate revocation, compromise confinement, scalability, and high availability. DBSEC'07

26. Related Work • TPM can protect key but not functionality • If you have a paper ready to submit, today is deadline for STC’07  • Threshold and proactive cryptography for enterprise/p2p computing • Forward-secure/key-insulated/intrusion-resilient cryptography for skilled/demanding individuals • Cryptography as a service for average people • This work is an extension to [MR01] DBSEC'07

27. Conclusion • A service for better protecting users’ cryptographic credentials, which can be used for authentication in large-scale systems. • Features: • Enforce three-factor authentication • Support immediate revocation of key • Damage due to server compromise is contained to a proper subset of its customers • Scalable and highly available. DBSEC'07

28. Future Work • Implement a system that can be used for GENI security etc. • Integrate the idea of [Xu-Sandhu RSA-CT’03] • Exploit state machine replication for better integrated fault-tolerance and security DBSEC'07

29. Thank you, and questions? DBSEC'07