The ability to quickly revoke a compromised key is critical to the security of a public-key infrastructure. Regrettably, most certificate revocation schemes suffer from latency, availability, or privacy issues. The problem is exacerbated by the lack of a native delegation mechanism in TLS, which increasingly leads domain owners to engage in dangerous practices such as sharing their private keys with third parties. We investigate the utility of "proxy certificates" to address long-standing revocation and delegation shortcomings in the web PKI. By issuing proxy certificates, entities holding a regular (non-CA) certificate can grant all or a subset of their privileges to other entities. This fine-grained control on delegating privileges requires no further actions from a CA, yet does not require trust on first use (TOFU). The lifetime of a proxy certificate can be made almost arbitrarily short to curb the consequences of a key compromise. We analyze the benefits of this approach in comparison to alternatives, discussing various use cases and technical implications. We also show that combining short-lived proxy certificates with other schemes constitutes an attractive solution to several pressing problems. Overall, we make the case that the benefits obtained from incorporating proxy certificates into the current PKI substantially outweighs the changes required in practice. Such changes are minimal, and would only be required on the browser end, should a domain owner opt to use proxy certificates.
A device that performs private key operations (signatures or decryptions), and whose private key operations are protected by a password, can be immunized against offline dictionary attacks in case of capture by forcing the device to confirm a password guess with a designated remote server in order to perform a private key operation. Recent proposals for achieving this allow untrusted servers and require no server initialization per device. In this paper we extend these proposals to enable dynamic delegation from one server to another; i.e., the device can subsequently use the second server to secure its private key operations. One application is to allow a user who is traveling to a foreign country to temporarily delegate to a server local to that country the ability to confirm password guesses and aid the user's device in performing private key operations, or in the limit, to temporarily delegate this ability to a token in the user's possession. Another application is proactive security for the device's private key, i.e., proactive updates to the device and servers to eliminate any threat of offline password guessing attacks due to previously compromised servers. Today's secure stream protocols, SSH and TLS, were designed for end-to-end security and do not include a role for semi-trusted third parties. As a result, users who wish to delegate some of their authority to third parties (e.g., to run SSH clients in the cloud, or to host websites on CDNs) rely on insecure workarounds such as ssh-agent forwarding and Keyless TLS. We argue that protocol designers should consider the delegation use-case explicitly, and we propose a definition of "secure" delegation: Before a principal agrees to delegate its authority, a system should provide it with secure advance notice of who will do what to whom under that authority. We developed Guardian Agent, a delegation system for the SSH protocol that, unlike ssh-agent forwarding, allows the user to control which delegate machines can run which commands on which servers. We were able to implement Guardian Agent in a way that remains fully compatible with existing SSH servers, by "handing over" a secure connection to the delegate once it has been set up. Additionally, we use this work to suggest a path for secure delegation on the Web. Protecting the customer's SSL private key is the paramount issue to persuade the website owners to migrate their contents onto the cloud infrastructure, besides the advantages of cloud infrastructure in terms of flexibility, efficiency, scalability and elasticity. The emerging Keyless SSL solution retains on-premise custody of customers' SSL private keys on their own servers. However, it suffers from significant performance degradation and limited scalability, caused by the long distance connection to Key Server for each new coming end-user request. The performance improvements using persistent session and key caching onto cloud will degrade the key invulnerability and discourage the website owners because of the cloud's security bugs. In this paper, the challenges of secured key protection and distribution are addressed in philosophy of "Storing the trusted DATA on untrusted platform and transmitting through untrusted channel". To this end, a three-phase hierarchical key management scheme, called STYX1 is proposed to provide the secured key protection together with hardware assisted service acceleration for cloud-based content delivery network (CCDN) applications. The STYX is implemented based on Intel Software Guard Extensions (SGX), Intel QuickAssist Technology (QAT) and SIGMA (SIGn-and-MAc) protocol. STYX can provide the tight key security guarantee by SGX based key distribution with a light overhead, and it can further significantly enhance the system performance with QAT based acceleration. The comprehensive evaluations show that the STYX not only guarantees the absolute security but also outperforms the direct HTTPS server deployed CDN without QAT by up to 5x throughput with significant latency reduction at the same time.