Transcript Certificate Management Using Distributed Trusted Third Parties

Certificate Management
Using Distributed Trusted
Third Parties
Alexander W. Dent
[email protected]
Joint work with Geraint Price
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.
2
PKIs in dynamic networks


Mitchell and Schaffelhofer suggest security
criteria for a “personal PKI”.
Distributed approaches given by:
–
–
–
–

Zhou and Haas, 1999.
Luo and Lu, 2000.
Varadharajan, Shankaran and Hitchens, 2004.
Zouridaki, Mark, Gaj and Thomas, 2004.
Here a CA is elected by a cluster of devices.
3
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.
4
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.
5
CA-applets

Let’s examine how to use this technique to
distribute CA functionality…
6
CA-applets – Initialisation
Generate
Verifies device’s
a new signature
identity
using
key pair
authentication
for the device.
data.
Request for applet
Send authentication data
Verify authenticity of SEE
Initiate a secure download channel
Download applet with new key pair
Download certificate for new key pair
7
CA-applets – Registering a key
Checks identity and issues
Request
certificate
certificate
to person
named for a public key
on initialisation only.
Send authentication data
Demonstrate proof of possession
Download newly generated certificate
(Download master certificate)
8
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).
9
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.
10
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.
11
Sub CAs verses CA applets

Sub CAs do not require proof of possession,
and, in some instances, this may be a flaw.
12
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.
13
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.
14
The End
All images of Torg copyright Pete Abrams.
http://www.sluggy.com/
15