Certificate Management Using Distributed Trusted Third Parties Alexander W. Dent Joint work with Geraint Price

2 Trust in a ubiquitous environment Trust is a difficult commodity to find/trade in a dynamically evolving network, e.g. in a PAN or PDE. Public key cryptography offers attractive features in such a situation, however – at a computational cost, – with the usual authentication problem. PKIs are hard to implement efficiently in dynamically evolving networks.

3 PKIs in dynamic networks Mitchell and Schaffelhofer suggest security criteria for a “personal PKI”. Distributed approaches given by: – Zhou and Haas, – Luo and Lu, – Varadharajan, Shankaran and Hitchens, – Zouridaki, Mark, Gaj and Thomas, Here a CA is elected by a cluster of devices.

4 PKIs in dynamic networks Our solution uses a different form of distributed certification authority. Takes advantage of emerging hardware-based secure execution environment technologies, such as Microsoft’s NGSCB and the Trusted Computing Group’s Trusted Computing Platform. We use an abstract execution environment.

5 Secure Execution Environments It can, and is able to demonstrate that it can, – be initialised securely, – download applications in a secure fashion, – securely execute applications, – demonstrate that an application has been successfully executed. Allows “black boxes” to be installed. Allows any TTP service to be installed… …however, not always efficiently.

6 CA-applets Let’s examine how to use this technique to distribute CA functionality…

7 CA-applets – Initialisation Request for applet Send authentication data Verifies device’s identity using authentication data. Verify authenticity of SEE Initiate a secure download channel Generate a new signature key pair for the device. Download applet with new key pair Download certificate for new key pair

8 CA-applets – Registering a key Request certificate for a public key Send authentication data Download newly generated certificate (Download master certificate) Checks identity and issues certificate to person named on initialisation only. Demonstrate proof of possession

9 CA applets – In use CA applet can also host a directory service. CA applet can also host a revocation service. Problems with the need for always-on devices. Methods to cope with the renewal problem. Limited methods to cope with the effects of a compromise of the CA applet (i.e. the release of an applet’s private signing key).

10 Sub CAs verses CA applets CA applets share a lot of characteristics with a sub CA… … i.e. a smaller CA that has been obtained a certificate from a larger root CA… … especially if the root CA issues a policy when certifying the sub CA that states that the sub CA can only issue certificates to certain individuals or according to a certain policy.

11 Sub CAs verses CA applets The main difference is the level of trust the root CA has to extend to its progeny. For a CA applet, the root CA has to trust the hosts SEE and the authentication data. For a sub CA, the root CA has to trust that the user can properly set up and administrate a secure CA application. In a CA applet, the security decisions rest with the security experts – the root CA.

12 Sub CAs verses CA applets Sub CAs do not require proof of possession, and, in some instances, this may be a flaw.

13 Personal CAs CA applets make excellent personal CAs (according to the criteria laid down by Mitchell and Schaffelhofer). Root CA can either be provided by a company or by a single dedicated device in the user’s PDE. The root CA can be configured by the manufacturer, rather than the user.

14 Other applications Ad hoc networks. Short lived certificates. Distributed registration/certificate data preparation. Lightweight PKI. Supporting web services. Paper to appear in upcoming book on Trusted Computing Platforms.

15 The End All images of Torg copyright Pete Abrams.