6th Annual PKI R&D Workshop
April 17-19, 2007, NIST, Gaithersburg MD
6th Annual PKI R&D Workshop - Proceedings
The official proceedings are published as a NIST Technical Publication, and
available for download: NISTIR 7427.
This online version of the proceedings reflects the original program, and
includes everything in the official proceedings (papers and summaries) as well
as those presentation materials that have been provided by the presenters.
Workshop Summary
Workshop Summary by Ben Chinowsky of Internet2.
Tuesday, April 17, 2007 - Full Day
8:30 - 9:00
Registration and Continental Breakfast
9:00-9:10 Welcome and Opening Remarks
Program Chair: Kent Seamons, Brigham Young University (Slides: ppt )
9:10 - 10:00 Keynote Talk
Identity Management
Carl Ellison - Microsoft
(Slides: pdf, CardSpace video (AVI), and mobile CardSpace video (AVI) )
10:30-1:00 Session 2 - Identity Systems
Panel Moderator: Eric Norman, University of Wisconsin (Slides: ppt )
Peter Alterman, National Institutes of Health
Mike Ozburn, NetMesh (Slides: ppt )
Mike McIntosh, IBM (Slides: ppt )
Scott Cantor, Ohio State (Slides: ppt )
Carl Ellison, Microsoft
1:00 - 2:00 LUNCH
2:00-3:30 Session 3 - Digital Signatures - Technical paper session
Session Chair: Rich Guida, Johnson & Johnson
•The OASIS Digital Signing Service and its Application to E-Invoicing in Europe
(Presentation slides: pdf )
[Nick Pope, Thales e-Security, UK and Juan Carlos Cruellas - Universitat Politècnica
de Catalunya, Spain]
•The Directory-Enabled PKI Appliance: Digital Signatures Made Simple,
Approach and Real World Experience
(Presentation slides: pdf )
[Uri Resnitzky, Algorithmic Research (ARX)]
•A New Paradigm in PKI Architecture: OTPK Technology
(Presentation slides: ppt )
[Zvi Efroni and Tan Teik Guan, Data Security Systems Solutions Pte Ltd]
4:00-5:30 Session 4 - Panel - Mortgage Industry
Panel Moderator: R. J. Schlecht, Mortgage Bankers Association (Slides: ppt )
Yuriy Dzambasow, A&N Associates (Slides: ppt )
François Leblanc, Silanis Technology (Slides: ppt )
Jim Bacchus, Digital Presence, Inc. (Slides: ppt )
5:30 pm Bus Departs for Gaithersburg Holiday Inn
6:00 pm Social Gathering and Dinner Buffet - Gaithersburg Holiday Inn
Wednesday, April 18, 2007 - Full Day
9:00-10:30 Session 5 - PKI Technologies - Technical paper session
Session Chair: Russ Housley, Vigil Security, LLC
•Universal Certificate Authentication to Key Applications at Argonne National
Laboratory
(Presentation slides: ppt )
[Doug Engert, Rich Raffenetti, David Salbego and John Volmer, Argonne National
Laboratory]
•Temporal Key Release Infrastructure
(Presentation slides: pdf )
[Ricardo Felipe Custodio, Julio da Silva Dias, Fernando Carlos Pereira and Adriana
Elissa Notoya, Universidade Federal de Santa Catarina-UFSC]
•Limited Delegation for Client - Side SSL
(Presentation slides: pdf ppt )
[Nicholas Santos and Sean Smith, Dartmouth College]
11:00-12:00 Session 6 Standards
Session Chair: Carl Ellison, Microsoft
OASIS PKI Steering Committee Update
John Sabo, CA, Inc.
(Slides: pdf)
Kerberos Extensions for PKI
Paul Rabinovich, Exostar
(Slides: ppt)
12:15-1:00 Session 7 PKI-Enabled Applications in US Government Now
Session Chair: Peter Alterman, National Institutes of Health
Jim Schminky, US Treasury (Slides: ppt )
Cindy Cullen, SAFE BioPharma (Slides: ppt )
Peter Alterman for Chris Jewell, DEA (Slides: ppt )
1:00 - 2:00 LUNCH
2:00-3:30 Session 8 - Panel - PKI in Government
Panel Moderator: Peter Alterman, National Institutes of Health
Judy Spencer, General Services Administration (Slides: ppt )
Tim Polk, NIST (Slides: ppt )
Debb Blanchard, Cybertrust (Slides: ppt )
4:00-4:30 Session 9 Invited Talk
The Attribute Ecosystem
Ken Klingenstein, Internet2 (Slides: ppt )
4:40 - 5:30 Session 10: RUMP Session
Session Chair: Sean Smith, Dartmouth College (Slides: ppt )
Using PIV Smart Cards on Linux for Authentication to Windows Active
Directory
(Presentation slides: ppt )
Douglas Engert, Argonne National Lab
Implementing PKINIT
(Presentation slides: pdf )
Olga Kornievskaia, CITI, University of Michigan
Dartmouth PKI Census
(Presentation slides: pdf )
Geetha Wunnava and Scout Sinclair, Dartmouth College
Simple Authentication for the Web Using Personal-Messaging Identifiers
(Presentation slides: ppt )
Kent Seamons, Brigham Young University
RFID Passports and PKI
Simon Godwin, Apptis
5:30 pm Bus Departs for Gaithersburg Holiday Inn
Dinner (on your own)
8:00 pm Birds of a Feather Sessions - Gaithersburg Holiday Inn
See the Workshop Summary for notes on the BOFs.
Thursday April 19, 2007 - Half Day
9:00-10:30 Session 11 - Grid Security - Technical paper session
Session Chair: Frank Siebenlist, Argonne National Laboratory
•A Scalable PKI for a National Grid Service
(Presentation slides: ppt )
[Jens Jensen, David Spence and Matthew Viljoen, Rutherford Appleton Laboratory]
•A Certificate-Free Grid Security Infrastructure Supporting Password-Based User
Authentication
(Presentation slides: ppt )
[Jason Crampton, Hoon Wei Lim, Kenneth G. Paterson and Geraint Price, Royal
Holloway, University of London]
•Enabling the Provisioning and Management of a Federated Grid Trust Fabric
(Presentation slides: ppt )
[Stephen Langella, Ohio State University (OSU); Scott Oster, OSU; Shannon Hastings,
OSU; Frank Siebenlist, Argonne National Laboratory; Tahsin Kurc, OSU and Joel
Saltz, OSU]
11:00 -12:30 Session 12 - Panel Federation Experiences
Panel Moderator: Scott Rea, Dartmouth College (Slides: ppt )
Georgia Marsh, eAuth
Jens Jensen, UK Federation/Shib-Grid (Slides: ppt )
Ken Klingenstein, Internet2 (Slides: ppt )
12:30-12:45 Wrap up
See Also
This workshop is part of the IDtrust Symposium Series
•2008: 7th Symposium on Identity and Trust on the Internet (IDtrust 2008)
•2007: 6th Annual PKI R&D Workshop
•2006: 5th Annual PKI R&D Workshop
•2005: 4th Annual PKI R&D Workshop
•2004: 3rd Annual PKI R&D Workshop
•2003: 2nd Annual PKI Research Workshop
•2002: 1st Annual PKI Research Workshop
6th Annual PKI R&D Workshop Summary
http://middleware.internet2.edu/pki07/proceedings/workshop_summary.html
Ben Chinowsky, Internet2
Note: this summary is organized topically rather than chronologically. See
http://middleware.internet2.edu/pki07/proceedings/ for the workshop program, with links to papers and
presentations.
The workshop looked at three aspects of its main theme of "applications-driven PKI":
I. Identity systems and federations
II. Current or imminent applications
III. Advanced approaches to infrastructure
There were also some additional talks not directly related to the workshop theme.
I. Identity systems and federations
There is a surge of interest in an "identity layer for the Internet", and a change in how identity is conceived
in many quarters. The old joke goes that on the Internet no one knows you're a dog; identity is about giving
you control over who -- if anyone -- gets to know that you're a dog, and if so, what kind of dog you are.
This notion of identity as attributes, instead of identity as identifier, is gaining momentum for both privacy
and security reasons.
In that spirit, Carl Ellison, now working with Identity and Access Architect Kim Cameron at Microsoft,
and speaking on his behalf, keynoted on Identity Management. The Internet was built without much
attention to security; various approaches to addressing this -- like proliferating per-vendor passwords and
Microsoft Passport -- are more and more showing their limitations. Kim Cameron, through extensive
discussions with a variety of parties concerned with solving this problem, has proposed seven Laws of
Identity:
1. User Control and Consent. Technical identity systems must only reveal information identifying a
user with the user's consent.
2. Minimal Disclosure for a Constrained Use. The solution that discloses the least amount of
identifying information and best limits its use is the most stable long-term solution.
3. Justifiable Parties. Digital identity systems must be designed so the disclosure of identifying
information is limited to parties having a necessary and justifiable place in a given identity
relationship.
4. Directed Identity. A universal identity system must support both "omni-directional" identifiers
for use by public entities and "unidirectional" identifiers for use by private entities, thus facilitating
discovery while preventing unnecessary release of correlation handles.
5. Pluralism of Operators and Technologies. A universal identity system must channel and enable
the inter-working of multiple identity technologies run by multiple identity providers. (Ellison drew a
contrast between this situation and DNS, which he suggested only worked because it was implemented
before anyone noticed.)
6. Human Integration. The universal identity metasystem must define the human user to be a
component of the distributed system integrated through unambiguous human-machine
communication mechanisms offering protection against identity attacks. (Ellison has been advocating
such mechanisms for years, under the label "ceremonies".)
7. Consistent Experience Across Contexts. The unifying identity metasystem must guarantee its
users a simple, consistent experience while enabling separation of contexts through multiple
operators and technologies. (Here is where the card metaphor comes in; as Cameron notes, "we must
'thingify' digital identities -- make them into 'things' the user can see on the desktop, add and delete, select
and share...How usable would today's computers be had we not invented icons and lists that consistently
represent folders and documents? We must do the same with digital identities.")
A great deal of detail on Cameron's Laws of Identity is available at http://www.identityblog.com/?
page_id=354.
The way to obey these laws is to build an "identity metasystem". This means not only creating a system
(like Microsoft's CardSpace) for presenting choices of identity to the user and conveying identities to
relying parties, but also creating a way for different such systems to interoperate.
Ellison's keynote was immediately followed by presentations on three more identity systems, and a panel
discussion of the relationships among the various identity systems and the identity metasystem. Eric
Norman moderated the discussion.
Mike Ozburn introduced OpenID. The main idea behind OpenID is to use a URL to identify the
individual; OpenID is the result of a recent pooling of effort by four separate projects that had been taking
similar approaches. This approach solves the namespace problem by leveraging DNS, creating a "single
point of contact, single point of control" for each individual. Ozburn stressed that "OpenID is NOT a trust
system...but it can be PART of one". OpenID already has millions of users and over a thousand sites
enabled to use it. OpenID is currently used mostly for low-risk applications like blogs and social
networking, not commerce, education, or government.
Mike McIntosh introduced the Higgins project. Higgins is an open-source identity framework and API
which can accommodate CardSpace, OpenID and other protocols; IBM and Novell have prominent
leadership roles in the project. Like CardSpace, Higgins uses a card metaphor for user identities, is
designed with interoperability with other identity systems in mind, and includes elements of an identity
metasystem. McIntosh noted that he is working closely with Kim Cameron, and cited Law of Identity #5 -
- Pluralism of Operators and Technologies -- as key to the effort. McIntosh also noted that the Eclipse
Public License will allow incorporation of Higgins into proprietary code.
Scott Cantor gave an overview of the Security Assertion Markup Language (SAML) space, including
the history and current status of the Shibboleth and Liberty Alliance projects. Cantor's most emphatic
point, however, was the danger of a new generation of web applications being tied to particular identity
systems: "BrokenWeb 2.0". Cantor stressed that "it's just as wrong to bind an app to SAML or OpenID"
as to bind it to passwords; in a correct, scalable architecture, applications trust the web server. But,
despite the broad emerging consensus on the need for an identity metasystem, the construction of
BrokenWeb 2.0 is already well underway.
Eric Norman underscored this concern in his informal definition of the concept of an "identity layer" for the
Internet: "application developers shouldn't have to write code to do identity stuff." Several points were
made about how to achieve this:
- There was general agreement that identity should be conceived as a collection of attributes, rather than
identity being counterposed to attributes. Carl Ellison stressed the distinction between an authenticator and
the attributes bound to that authenticator. In order for an identity metasystem to work, this distinction
needs to be rigorously maintained; attributes and authenticators should not be combined as with e.g. credit
card numbers.
- Scott Cantor observed that one huge problem is that users don't see identity as a collection of attributes,
and don't understand the nature and privacy implications of many of the low-level attributes. Work on user
interfaces that address this is underway, but still at an early stage.
- Cantor also noted that there are two reasons that deployers can't make the PKIX libraries work: the
implementations are poor and the protocol is too complicated to begin with. IETF Chair Russ Housley
agreed.
- Rich Guida noted that privacy concerns can be more readily addressed in intra-enterprise or enterprise-
to-enterprise communications, and that there is great need for, and benefit in, deploying identity systems
even with this more restricted scope. There are many complexities associated with the attribute-centric
approach, which helps explain why it is not prevalent today. Simpler approaches, where identity is tied to
an identifier such as an employee ID number, are much more commonplace and may be perfectly sufficient
for use within or between enterprises. This approach is what much of Microsoft's Active Directory
framework is based on.
- There was a discussion of duplication vs. specialization among identity systems. Mike McIntosh argued
that some systems are better for some purposes than others; Cantor argued that most of them can serve
most purposes. Nonetheless, there was general agreement that a plurality of systems is inevitable, so that
an identity layer / identity metasystem -- not an attempt to standardize on one identity system -- is the right
approach.
Continuing with the theme of attribute-centricity, Ken Klingenstein's invited talk explored the concept of an
"attribute ecosystem". Klingenstein envisions a central role for Shibboleth in this system: providing real-
time transport from identity providers to service providers for authorization decisions. Other "compile-time"
means will also be used to ship attributes to service providers, and intermediate entities such as proxies and
portals, as well as to the identity provider itself. Klingenstein's slides present a variety of scenarios for how
the pieces could fit together. The user needs to be able to manage all of this, which is a significant
challenge; the Autograph tool developed by the Australian Meta Access Management System (MAMS)
project is one attempt to meet that challenge. Klingenstein wrapped up by observing that if this sounds like
PKI, that's because what he's trying to create is PKI with a few more degrees of freedom.
Klingenstein, Georgia Marsh, and Jens Jensen presented experiences with federations in a panel discussion
moderated by Scott Rea, who posed the question, "how is the mix of SAML / PKI / other working out?"
Marsh described the approach of the General Services Administration's eAuthentication project as to
use commercial off-the-shelf (COTS) technologies to grow e-government; ease of use is key to this effort.
EAuth uses SAML for lower levels of assurance and PKI for higher levels, and is not limited to
government-issued credentials; in fact, Marsh noted, "the government really does want to get out of the
credential-issuing business". EAuth has been operational since October 2005; there are currently 46 relying
parties and six credential service providers. Business aspects remain more challenging than technical
aspects; lessons learned so far include "federate business not technology" and "align the data to the
business process".
Jensen gave an overview of lessons learned in running a Shibboleth federation in the UK. He stressed
the importance of policies in setting other federations' members' expectations; at the same time, keeping
them consistent is difficult, as updating policy requires you to then prod everyone to update their
procedures.
In his global federations survey, Klingenstein noted that the UK federation aims to encompass all of K-
12, higher education, and continuing education -- a much broader scope than any US federation.
Klingenstein also cited privacy guidelines from the UK
(http://www.ukfederation.org.uk/library/uploads/Documents/recommendations-for-use-of-personal-
data.pdf), including the mandatory provisions of the UK Data Protection Act. Klingenstein noted that
federations are being rapidly adopted by collaborative applications, wikis in particular; his slides also list an
impressive variety of other current and planned uses.
II. Current or imminent applications
Uri Resnitzky presented and demonstrated his Directory-Enabled PKI Appliance. The Appliance stores
users' digital-signing keys and leads them through the signing process via a simple graphical interface; the
signing key never leaves the Appliance. This is production technology; Resnitzky's paper provides details
on its ongoing use in a variety of settings.
Nick Pope described the application of OASIS Digital Signature Services (DSS) to e-invoicing in
Europe. The fact that the Value Added Tax (VAT) is applied at every stage of a commercial process, with
rebates available for tax paid in a different jurisdiction, presents rich opportunities for fraud; here DSS is
applied to stop such fraud. An implementation is in progress and is expected later this year. Pope noted
that, although the specification has only recently been ratified, DSS is based on a style of operation already
in use for years, e.g. in Thales SafeSign and the Norwegian BankID. See http://www.oasis-
open.org/committees/dss/.
David Salbego described how Argonne National Laboratories combined Microsoft Certificate Services,
KX.509 and Sun's Java Enterprise Suite to enable certificate-based access to applications. The
resulting access manager has been open-sourced at http://www.opensso.dev.java.net/.
R.J. Schlecht introduced the mortgage industry panel, noting that PKI can be applied at several different
steps in the mortgage-approval process. This process involves interaction among entities of widely differing
resources, and is heavily regulated; the industry has been working on PKI for about four years. Yuriy
Dzambasow introduced SISAC (http://www.sisac.org/), "a fully owned PKI subsidiary of the mortgage
industry." SISAC certifies accredited issuing authorities to provide certificates to mortgage industry entities
(not customers). Schlecht observed that pursuing consistency with FPKI has helped a lot, as parts of the
mortgage industry are part of the government.
Francois Leblanc and Jim Bacchus introduced two users for SISAC certificates: "eClosing and
eVaulting" and "eNotary" respectively. Leblanc noted that the goal of MERS, the Mortgage Electronic
Registration System, is to register every mortgage loan in the US; they are currently at 80%. Bacchus
noted that while the law requires you to notarize in person, the result of the process is an electronic
document that can go in a digital safe deposit box.
The mortgage panel generated extensive discussion.
- Carl Ellison pointed out that signings are just "little point samples" of the extremely complicated human
process of getting a mortgage, and expressed concern that if we automate the document process we'll end
up throwing out the human process. Schlecht countered that the intent is not to change the human process,
but to reduce the opportunity for error inherent in basing that process on paper documents, e.g. retyping
things and losing things.
- John Sabo pointed out that in most signature-fraud cases, what is in dispute is not whether something was
signed, but whether the signer was properly informed; he asked how technology could address this. There
was general agreement that, while this is more a legal issue than a technical one, document signing could be
helpful in creating auditable documentation that the signer was properly led through the process.
- Somewhat more prosaically, Leblanc noted that having electronic copies of documents often makes it
possible for the customer to review them individually ahead of time, instead of being confronted with a
mountain of documents all at once when visiting the mortgage office.
Peter Alterman led two panel discussions of PKI in the Federal Government. The first concerned current
applications:
- Jim Schminky presented the Treasury Department's Secure Extranet Gateway, used for secure
access to Treasury applications by business partners, remote Treasury users, and other Government
agencies.
- Cindy Cullen discussed SAFE digital signatures and the FDA Electronic Submissions Gateway
(ESG). Cullen noted that the FDA wants to get away from "semi trucks full of submissions" and is making
a big push for submissions to be made electronically. On the pharmaceutical-industry side, the Regulatory
Affairs department of AstraZeneca has been involed in the ESG pilot.
- Alterman stood in for Chris Jewell in presenting the Controlled Substances Ordering System (CSOS)
at DEA. CSOS has been a great success, with over 33,000 certificates issued and over two million line
items ordered so far. Working closely with industry has been key to this success. See
http://www.deaecom.gov/ for more information.
The second Federal PKI panel addressed issues around the August 2004 Homeland Security Presidential
Directive 12 (HSPD-12), which mandates Personal Identity Verification (PIV) cards, i.e. smartcards, for
Federal employees and contractors.
- Judith Spencer gave an update on HSPD-12 implementation. She noted that there have been many
queries from states, industry, and foreign governments about how HSPD-12 applies to them. The short
answer is that it doesn't, but many people want to be compatible with it anyway; FIPS 201 is seen as "the
gold standard". All Federal employees with less than 15 years service are to have PIV cards by October
27, 2007; all Federal employees and contractors should have them by October 27, 2008. (In the
mortgage panel, Jim Bacchus, a Marine Corps reserve officer, noted that he didn't use his smartcard for
the first six years he had it, but since HSPD-12 he's had to use it every time he sends email.)
- Debb Blanchard gave an overview of the implementation of HSPD-12 at the Veterans
Administration. They have issued about a thousand smart cards so far, and need to issue about 400,000
more before the October 2008 deadline.
- Tim Polk discussed PIV-enabling applications, noting that many applications -- both COTS and
custom -- have limited compatibility. Polk's presentation noted "Six Deadly Sins" of PIV-Enabling:
hardwiring to current cryptography modules, failing to allow for large certificates, overloading key-usage
extensions, processing only the common name rather than the full name, assuming that a valid path means a
valid user, and relying on a single type of certificate status information.
In the discussion, Peter Alterman (altermap@mail.nih.gov) asked the group for its help in documenting
issues that are inadequately addressed in the Common Policy
(http://www.cio.gov/fpkipa/documents/CommonPolicy.pdf). There was strong interest in seeing better
documentation of PIV-enabling best (and worst) practices; Polk noted his certainty that the list of Deadly
Sins will grow.
There was also a short rump-session presentation by Simon Godwin, discussing PKI in RFID passports.
US passports have been completely redesigned to include RFID chips with biographical and biometric
data (the latter is mostly the photo). Godwin noted that, in the US, "PKI as it relates to passports is really
all about signing data" -- there is no document-specific keypair on the passport, just the public key used to
sign the data on the chip. Sean Smith noted that Singapore is pursing a more advanced scheme, with
passports carrying keypairs. Godwin also reassured the group that there are no plans to remove humans
from the passport-inspection process.
III. Advanced approaches to infrastructure
Tan Teik Guan discussed digital signatures via One Time Private Keys (OTPK). This scheme builds
on the practice, already common in Singapore and Hong Kong, of using one-time passwords for everyday
banking transactions. With OTPK, a separate private key is created, used, and deleted for each signature;
the key never leaves the client. A demo is at
http://www.demo.com/demonstrators/demo2006fall/79808.php; a toolkit and pilot project are planned.
Wills, bids at auction, and bids for government contracts are examples of documents commonly put in
sealed envelopes in order to ensure that they are not read until after a certain point in time. Observing that
there is currently no electronic equivalent to this process, Ricardo Felipe Custódio introduced the proof-
of-concept Temporal Key Release Infrastructure. Custódio also further developed the analogy with
the sealed envelope, e.g. noting that TKRI provides a functional equivalent of a window in the envelope.
Custódio's team currently has a working prototype.
Nicholas Santos discussed Limited Delegation for Client-Side SSL. As evidenced by the endemic
practice of password-sharing, users really need a way to delegate their privileges to other users; Santos
noted that this concept is well-understood everywhere except in traditional PKI. His solution, developed
as a student of Sean Smith at Dartmouth, involves a non-standard use of X.509 proxy certificates, together
with dynamically loadable modules in Mozilla Firefox -- and, unlike password sharing, allows delegation of
a subset of privileges, not just all or none.
Paul Rabinovich made the case for standardizing Kerberos names in X.509 certificates, in order to
facilitate their use for cross-domain authentication. He outlined four possible approaches to doing this,
advocating the most vendor-neutral of the four. This talk generated lively discussion, including a suggestion
that at least one of the approaches be written up as an RFC, but overall there was little support for
Rabinovich's position. In particular, all four approaches were resoundingly rejected by Russ Housley, who
argued that the time for standarding X.509 on Kerberos names has come and gone.
Three of the five rump-session talks also fell into the "advanced infrastructure" category:
- Doug Engert discussed using PIV smartcards on Linux for authentication to Active Directory.
You can test this today; see http://opensc-project.org/.
- Olga Kornievskaia presented her work on PKINIT, which provides initial Kerberos authentication via
X.509 certificates. This work is further described in standards-track RFC 4556, and CITI is working
toward including it in MIT Kerberos 1.7. See http://citi.umich.edu/projects/pkinit/ for more information.
- Kent Seamons presented the work of his graduate student, Timothy van der Horst, on Simple
Authentication for the Web. SAW is inspired by the common practice of using email to help a user who
has forgotten their password. SAW introduces a variant of this approach as the primary means of
authentication, resulting in a system that removes the need for passwords at many web sites. The goals of
this work are convenience and security. Complete details are available in a paper to be published at the
3rd International Conference on Security and Privacy in Communication Networks in September
2007 (see http://isrl.cs.byu.edu/publications.php). The extension of this approach to IM and SMS was
discussed at length in the Wednesday night BoF.
Also in the BoF, Massimiliano Pala discussed his work on an OCSP-like protocol for PKI resource
discovery. See https://www.openca.org/projects/libprqp/ for more information.
There were three talks on PKI for Grids:
- Jens Jensen presented a PKI for the UK National Grid Service, complementary to but independent of
the UK Shibboleth deployment. Jensen noted that the UK e-Science CA is the world's second-largest
Grid CA, behind only the US Department of Energy Grid CA.
- Hoon Wei Lim outlined a Certificate-free Grid Security Infrastructure Supporting Password-
based User Authentication. This work is a variation on the Gentry and Silverberg approach to identity-
based cryptography, using IBC hierarchies that match the hierarchies of virtual organizations.
- Stephen Langella discussed Enabling the Provisioning and Management of a Federated Grid
Trust Fabric. In Langella's work with the Cancer Biomedical Informatics Grid (caBIG), a major problem
he encountered was how to know which CAs to trust. The approach developed to address this problem
uses a single trusted CA to bootstrap the process of identifying other trustworthy CAs.
Organizational and miscellaneous
John Sabo introduced the OASIS Identity and Trusted Infrastructure (IDtrust) Member Section,
formerly the PKI Member Section. IDtrust oversees the Enterprise Key Management Infrastructure
(EKMI) Technical Committee, which is concerned with symmetric key management, and the PKI
Adoption Committee. Sabo's slides note that "PKI is resurgent, driven by applications needing signatures,
esp. for paperless transacting." See http://www.oasis-idtrust.org/.
Sara "Scout" Sinclair gave a short rump-session presentation on the Dartmouth PKI Lab's planned
PKI Census. Where the OASIS survey focused on qualitative barriers to adoption, this will focus on
quantifying the status of PKI as it exists today, and in particular on how many people are using it for each
of its many current applications. Send questions you'd like included in the Census, and suggestions for
people to send the Census form to, to geetha.wunnava@dartmouth.edu and
scout.sinclair@dartmouth.edu.
Conclusion
PKI (more precisely, the distribution and use of X.509 digital certificates for authentication, digital
signatures and encryption) is not happening the way we originally expected -- by reaching a sudden tipping
point -- but it's happening nonetheless, via a patchwork of deployments, for a wide variety of purposes,
taking a correspondingly wide variety of approaches. The broadening of this year's program to include
discussion of identity systems and metasystems in general, reflects this turn of events.
The wrap-up discussion revealed authorization, delegation, and the delegation of authorization as additional
areas of particular interest for next year's workshop. Kent Seamons noted that while technical paper
submissions were up over last year, we still want a greater volume of submissions for next year. The
submissions deadline is expected to be sometime in October.
In program committee discussions shortly after the workshop, it was agreed that the scope of next year's
meeting will be broadened to "identity and trust". This will formalize the trend established at PKI07. Please
join us at the 7th Symposium on Identity and Trust on the Internet (IDtrust 2008), March 4-6, 2008;
watch http://middleware.internet2.edu/idtrust/ for details.
PKI 2007
Applications-Driven PKI
(It's The Apps, Stupid!)
Kent Seamons
Program Chair
6th Annual PKI R&D Workshop
NIST, Gaithersburg, MD
April 17-19, 2007
Program Committee
Kent Seamons, Brigham Young Eric Norman, University of Wisconsin
University (chair) Tim Polk, NIST
Peter Alterman, National Institutes of Scott Rea, Dartmouth College
Health John Sabo, Computer Associates
Bill Burr, NIST Ravi Sandhu, George Mason
David Chadwick, University of Kent University and TriCipher
Joe Cohen, Forum Systems Krishna Sankar, Cisco Systems
Carl Ellison, Microsoft Stefan Santesson, Microsoft
Stephen Farrell, Trinity College Dublin
Thank You!
Frank Siebenlist, Argonne National
Richard Guida, Johnson & Johnson Laboratory
Peter Gutmann, University of Auckland Sean Smith, Dartmouth College
Russ Housley, Vigil Security, LLC Von Welch, NCSA
Neal McBurnett, Internet2 Stephen Whitlock, Boeing
Clifford Neuman, University of Michael Wiener, Cryptographic Clarity
Southern California
Special Thanks
General Chair
Ken Klingenstein, Internet2
Steering Committee Chair
Neal McBurnett, Internet2
Local Arrangements Chair
Sara Caswell, NIST
Technical Program
Technical Paper sessions
DigitalSignatures
PKI Technology
Grid Security
Submissions - received: 24, accepted: 9
Industry vs. Government/Academia (2:1)
Each paper received 3+ reviews
Some papers received shepherding
Thank you authors and PC
Panels and Invited Talks
Last Minute Instructions - Speakers
Speakers please contact your session
chairs in advance
Atthe beginning of the break before your
session
An electronic copy of each presentation
should be given to Neal for the web site
(ppt, opendocument or pdf)
Social Gathering and Dinner Buffet
Tuesday, Holiday Inn, 6 PM
Work-In-Progress Session
Work-In-Progress Session on Wed
afternoon
Includes a rump session
Contact: Sean Smith
Bird-of-a-Feather
Propose a topic for informal Birds-of-a-
Feather sessions
Wednesday, 8 PM
Room available at the Holiday Inn
Industry PKI Survey
Voluntary survey available on table in the
registration area
Provide your input on the future direction
of PKI
Results will be made available to
attendees
John Vanston
Technology Futures
Looking to the Future
Please make plans now to submit a
technical paper next year
Complete a survey at the conclusion of the
workshop – your feedback is important to
us!
Enjoy the Workshop
The success of the workshop is in your
hands
Participate!
Name Peter
Carl Ellison, speaking for
Password The.usual
Kim Cameron
Chief Architect of Identity
Microsoft Corporation
Identity Crisis
The Internet is dangerous!
Identity theft, spoofing, phishing, phraud
Username + password is weak and overwhelmed
Enterprises are in identity silo hell
Goals
Safe and secure
Internet for all
Safely, reliably identify
sites to users…
…and users to sites
Connected Systems
Internal and external
Passport?
Identity provider for MSN
300M+ users, > 1 billion logons/day
Identity provider for the Internet
Unsuccesful
Why?
The Laws of Identity
1. User control and consent
2. Minimal disclosure for a defined use
3. Justifiable parties
4. Directional identity
5. Pluralism of operators and technologies
6. Human integration
7. Consistent experience across contexts
Identity Metasystem
Unifying identity meta-layer
Protect applications from
underlying complexities
Decouple digital identity from
implementation details
Not first time we’ve seen this
in computing
Use of Identity
Authenticator
Channel
Password
Symmetric key
Public key
Digital Identity
Bound to the authenticator
Any fact(s) useful to the RP
Issued by an appropriate identity provider
What is a Digital Identity?
Subject
Claims
Security Token
Abstracting Identity
Identity: set of claims in a security token
Roles:
Subject
Identity Provider
Relying Party
Protocol:
1) User is asked for identity
2) User chooses an identity provider
3) Identity provider gives user a security token
4) User passes the token to the requestor
Protocol Drill Down
User 7 User approves release of token
4 User selects an IP Client
1 Client wants to access a resource
Request security token 5 3 Which IPs can satisfy requirements?
2 RP provides identity requirements
6
Return security token based
on RP’s requirements
8 Token released to RP
Identity Provider Relying Party
(IP) (RP)
Windows CardSpace
Easily and safely manage your digital
identities
Authenticate with websites and web
services
Easier Safer
• No usernames Avoid phishes
and passwords Multi-factor
• Consistent login authentication
and registration
Built on WS-* Web Service Protocols
CardSpace (“InfoCard”)
SELF - ISSUED MANAGED
Contains self-asserted claims Provided by banks, stores,
about me government, clubs, etc.
Stored locally Cards contain metadata only!
Effective replacement for Claims stored at Identity
username/password Provider and sent only when
Eliminates shared secrets card submitted
Easier than passwords
Components Microsoft is Building
CardSpace identity selector
Component of .NET 3.0, usable by any application
Hardened against tampering, spoofing
CardSpace simple self-issued identity provider
Self-issued identity for individuals running on PCs
Uses strong public key-based authentication – user does not disclose
passwords to relying parties
Active Directory managed identity provider
Plug Active Directory users into the metasystem
Full set of policy controls to manage use of simple identities and Active
Directory identities
Windows Communication Foundation for building distributed
applications and implementing relying party services
Not just a Microsoft thing…
Based entirely on open protocols
Identity requires cooperation – and it’s
happening…
Interoperable software being built by
Sun, IBM, Novell, Ping Identity, BMC, …
For UNIX/Linux, MacOS, mobile devices, …
With browser support under way for
Firefox, Safari, …
Unprecedented things happening
Microsoft part of JavaOne opening keynote
Identity Providers
Relying Parties
Clients
Identity Providers
SSL Certificate
Security Token Service and policy
Information Card creation and provisioning
Examples
Employer, school, bank, government, club
The user!
Identity Provider = User
CardSpace system includes
Entropy for signing tokens
Security Token Service
Card creation
My Card
Personal or self-issued cards
Created in CardSpace control panel applet
Fixed set of claims
Card and data are stored on the client
Users no longer need passwords for websites!
Identity Provider ≠ User
Public-key Certificate
Security Token Service
Build, Buy, Device
Managed or Provider cards Woodgrove Bank
Created and signed by IP
User installs .CRD file
Data stored at IP
Any stack supporting WS-*
Relying Parties
SSL Certificate Web services use WS-*
Policy Web sites use HTTPS and
Code to process token
HTML
CardSpace Security
Architecture
Agent + Service
Doubly-encrypted store
All parties strongly identified
Multi-factor authentication
Privacy
RP can be hidden from IP
Different authenticator for each RP
User controls release of information
Summary
Users can control their digital identities
Simple, consistent and secure
Open and inclusive
Many contexts
Existing and future systems
Windows CardSpace is an identity selector
Very little developer effort is required
Resources
Windows CardSpace Community Site
http://cardspace.netfx3.com
Kim Cameron’s Identity Weblog
www.identityblog.com
.NET Framework 3.0
http://www.microsoft.com/downloads/details.aspx?
FamilyID=10cc340b-f857-4a14-83f5-
25634c3bf043&DisplayLang=en
Internet Explorer 7.0
www.microsoft.com/windows/ie/ie7
© 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market
conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation.
MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.
A Identity Layer
for the Internet
Application developers shouldn't have to write
code to do “identity stuff” just like they don't
have to write code now to do TCP/IP stuff
1
Dramatis Personae
User
Relying party (RP) -- service provider (SP)
Identity provider (IdP)
2
Identity Provider
Provides testimony regarding the accuracy of
claims
●
Maintains records about a user to back up that testimony
●
Always has an account with the user
●
Always has a registration process for account
establishment
It is understood that a user may act as their own
identity provider
Assumes liability if testimony yields a false positive
3
How Much
?
4
Code Availability
Is code available now?
If not now, when?
For which platforms?
For which browsers?
5
Encumbered
?
6
Likely Adopters
Commerce
●
Consumer products and services
●
Financial
Higher education
Social networks
Government
7
Collaboration
Mailing lists
Conferences
Wikis
Blogs
8
Intra-system Interoperability
What has been demonstrated?
Across platforms
●
Windows
●
Linux
●
Macintosh (without Windows emulation)
Across browsers
●
IE
●
Firefox
●
Safari (keychain)
9
Registration
With IdP (always)
With RP (sometimes)
What extra procedures are performed?
What information is exchanged and remembered
such that the entire process doesn't have to be
repeated to establish a session?
10
Level of Assurance
How is it determined?
Is self-asserted included?
How it is communicated?
11
Trust Basis
What is “trust” eventually based on? Among other
possibilities, how does RP trust testimony of IdP?
●
Trust anchor; i.e. “root” public key
●
DNS
●
Shared secret
●
Out of band
●
Other
12
Firewalls
What is the impact on deployment of firewalls?
That is, who needs to connect with whom
among IdP, RP, and desktop?
13
Audit Trails
What audit trails are available?
Who has to be involved?
Can user audit their identity transactions
●
With RP?
●
With IdP?
14
Support
What is available?
Can users be referred to local help desk if
appropriate?
How does someone figure out who to call if
there's a problem?
What diagnostic tools are available?
15
Usability
(for Scout)
Studies?
Mental models?
Signals to user?
16
%$#@ Happens
How can abuse be stopped if it happens?
Credentials are lost or forgotten or not available
●
What needs to be done to restore service?
Credentials are assumed stolen
●
What needs to be done to restore service?
●
How are old credentials rendered untrustworthy?
17
Phishing Attacks
How vulnerable is it?
What are the defenses?
18
Desktop Capabilities
Does system assume current browser capabilities?
●
Cookies
●
Redirects
●
SSL
What additional capabilities on the desktop would
be useful to simplify protocols, usage, security, etc.
●
E.g. Display that can't be completely controlled by
remote server and can be personalized
●
E.g. encrypt/decrypt with stored keys
Are the any capabilities not desired on the
desktop?
19
Combining Claims
Can claims (attributes) from different IdPs be
aggregated?
Can testimony about a claim be provided by
independent IdPs?
How are additional claims added to or
subracted from a session of warranted?
20
Grid Computing
A researcher launches a long running job into
the computing grid
Sometime later, an identity transaction is
needed when the researcher is absent
How can this be dealt with?
21
Multi-Factor Authentication
How does system support it?
●
RP?
●
IdP?
If federation or SSO is done, how does RP get
assurance that multi-factor authentication was
performed?
22
Peer-to-Peer
?
23
Nouns & Verbs
Between SAML and WS-*, we have some
different words written in the angle brackets
and we might even have some angle brackets
in one, but not in the other
But are there any important differences?
What is to be done? Too many MUSTs?
Ignore what you don't understand?
24
Session Management
Who does it
●
Desktop?
●
IdP?
●
Someone else?
Session termination?
●
The easiest thing for a user to do to terminate all
sessions is to walk away
Can sessions be suspended and resumed
tomorrow?
25
Inter-system Interoperability
Can, for instance, an RP be using one system
while the IdP and user are using another?
What would it take to do this?
Should it be done?
26
If Only
Complete this sentence.
We could realize an identity layer for the
Internet,
if only ...
27
Simple Identity From A User's Perspective
mike ozburn
President, NetMesh Inc.
NetMesh Proprietary and Confidential
The Problem:
• Too many user names and passwords
• 44 hours a year, logging in to an average of 4 applications per day
• 15-45% of all issues relate to usernames & passwords
• Internet "service" experience becomes a big hassle
• Implemented uniquely at each site
• Provide little value other than basic authentication
• High cost in terms of management, frustration, and lost transactions
• Cost of poor online experience may equal $60 Billion by 2010
• Harris Interactive study (9/06) finds online transaction problems cause:
40% of users to abandon transaction entirely
Of the total, 7% abandon the transaction entirely
Of the total 32% turn to competitors
• 91% of respondents question privacy & security of site if problem occurs
• Two top factors contributing to online satisfaction are security (26%) and ease of
completing a transaction (22%)
NetMesh Proprietary and Confidential
What happened?
Big Co. Big Co.
Me5
Me3
Big Co. Big Co.
Me2 Mex
Big Co.
Big Co. Me1 Me4 Big Co.
Vendor-Centric Websites Many, Many Services
NetMesh Proprietary and Confidential
What's happening?
Big Co. Big Co.
Me5
Me3
Big Co. Big Co.
Me2 Mex
Big Co. Me1 Me4 Big Co.
Vendor-Centric Model User-centric Model
NetMesh Proprietary and Confidential
The Solution:
• Consumer convenience of universal sign-on
• Support single password across all participating sites
• Single point of access / single point of control for web services
• Improves security by enabling universal password change
• Reduces hassle of managing passwords
• Replaces site-specific passwords with consumer controlled identity
• Integrates easily to existing site-specific authentication
• Reduces cost of password management
• Reduce "friction" in online interaction
• Improves "registration" and site activity by accepting consumer-controlled identity
• Reduces cost of lost transactions due to hassles of login or registration
• Improves site convenience and forms basis for more personalized services
NetMesh Proprietary and Confidential
What is OpenID?
• Single sign-on for the web
• Simple, light-weight
• Easy-to-use, easy-to-deploy
• Open development process
• Decentralized
NetMesh Proprietary and Confidential
OpenID is a URL
http://mozburn.myopenid.com
http://mylid.com/mikeoz
NetMesh Proprietary and Confidential
Why a URL?
• Biggest problem with identity is the namespace
• OpenID solves this by using DNS
• Your identity is a "destination"
• Each person is a unique point on the internet
• Single point of contact, single point of control
NetMesh Proprietary and Confidential
How does it work?
NetMesh Proprietary and Confidential
How does it work?
NetMesh Proprietary and Confidential
How does it work?
NetMesh Proprietary and Confidential
How does it work?
NetMesh Proprietary and Confidential
How does it work?
NetMesh Proprietary and Confidential
How does it work?
NetMesh Proprietary and Confidential
Can I trust it?
• OpenID is NOT a trust system … but it can be PART of one
• You can trust it to the extent that you control it:
•
•
• Different "persona" for different services
NetMesh Proprietary and Confidential
Who would ever use this?
• AOL • 90 million estimated users
• Microsoft • 1,200+ OpenID enabled sites
• SixApart • 15-20 new sites a day
• VeriSign • 7% growth every week
• Technorati
• Mediawiki
• …many others
NetMesh Proprietary and Confidential
OSIS: “Open-Source Identity System”
Projects
Higgins
Steering Committee
http://osis.netmesh.org/
NetMesh Proprietary and Confidential
Identity Landscape
URL-based
OpenID-
OpenID- paradigm
based
based
(blogs,
(blogs, grassroots,
grassroots,
bottoms-up)
bottoms-up)
SAML
integration
OSIS Agreement
“historic development” (ZDNet)
Identity
Invisible Card-based
to the user paradigm
Liberty-based
Liberty-based WS-*-based
WS-*-based
(Liberty
(Liberty Alliance
Alliance (Microsoft
(Microsoft
companies)
companies) Vista)
Vista)
NetMesh Proprietary and Confidential
User-Centric Economy (Architecture)
Browser-
Blogs & General Secure Rich, Profile
Based SSO
Social Apps E-commerce Services Based Services
(enterprises)
2-Factor
SAML WS-SX
Auth.
Commercially Useful Relying Parties
OpenID
Convenience Trust
NetMesh Proprietary and Confidential
Benefits of commercial adoption
• Commercially-defined
parameters for SSO
• Equal in strength to most
username/passwords in
place today
• Reduce "friction" in
relationship with "users"
• Increases registration
and site usage
• Becomes single-point of
contact and control
NetMesh Proprietary and Confidential
Chickens & Eggs
200
Active OpenID Users (Millions)
160 Portals Services
Blogs Emergency
Communities Services Vision
MVNOs WiFi IM Commerce Doctors
Supplemental
Satellite Mobile Insurance
Social
Care
Broadband Telcos Labs Hospitals
Network
Health
WiMax
120
Cable HMOs Dentists
3rd Party
email Work Finance Banks
Systems Brokers
Qu i c k Ti me ™ a n d a Qu i c k Ti me ™ a n d a Qu i c k Ti me ™ a n d a Qu i c k Ti me ™ a n d a
d e c o mp re s s o r d e c o mp re s s o r d e c o mp re s s o r d e c o mp re s s o r
a re n e e d e d to s e e th i s p i c tu re . a re n e e d e d to s e e th i s p i c tu re . a re n e e d e d to s e e th i s p i c tu re . a re n e e d e d to s e e th i s p i c tu re .
401K Gov. Credit Cards
HR Credit
Agencies
Insurance Building Federal Mortgage
State
Access Financial
Agency
Corporate Local Management
Media Multi-device Peer Situational Applications Quasi-
Governmental
80
sharing messaging commerce context
User-centric identity layer
InfoGrid ™
Personal
QuickTime™ and a
decompressor
are needed to see this picture.
60 Networks
Identity-based
QuickTime™ and a
decompressor
are needed to see this picture.
40
Services
Commercially
Useful Sites
20
OpenID
2007 2008
NetMesh Proprietary and Confidential
NetMesh Proprietary and Confidential
www.openid.net
NetMesh Proprietary and Confidential
Simple Identity From A User's Perspective
mike ozburn
President, NetMesh Inc.
NetMesh Proprietary and Confidential
Business Unit or Product Name
Higgins Trust Framework
Michael McIntosh
IBM Research
© 2003 IBM Corporation
Business Unit or Product Name
The Higgins Vision: “Bridging Contexts”
• eCommerce (e.g. Amazon, eBay)
• Social Networking (e.g. LinkedIn)
• Book club • Alumni websites
• Family
We • Healthcare System
ts bs ites
ddy Lis • Sales Force Automation
• Professional networks B u
• Corporate Directories
• Dating networks
st s
En ps
re t i e
Ap
te
t e uni
rp
of om m
ris
e
In
Social
C
Networks
Virtua
Space
• Lotus Notes
il
Ema
or IM
• P2P Apps
l
s
YOU
2
© 2003 IBM Corporation
Business Unit or Product Name
Eclipse Foundation
Best known for the Eclipse Java IDE
Has grown to include over 60 other projects
Extensive support for plug-in architectures
All code is under Eclipse Public License (EPL)
EPL allows linking with proprietary code
Project infrastructure: dev lists, CVS, Wiki, etc.
3
© 2003 IBM Corporation
Business Unit or Product Name
Broad Community Involvement
Committers Broader Community
• 12 individuals • Collaboration with closely related
• Organizations communities: OSIS, Identity Commons,
• IBM Liberty, OpenID, XRI, XDI
• Novell
• Parity We’ve co-founded and built on
• ooTao • IdentityGang.org
• IdentitySchemas.org
• Other vendors: VeriSign, Oracle, Ping,
Red Hat
4
© 2003 IBM Corporation
Business Unit or Product Name
Project Scope
1. Provide a consistent user experience based on card icons for the
management and release of identity data
2. Empower users with more convenience, control and privacy over personal
information
3. Provide an API and data model for the virtual integration and federation of
identity and security information from a wide variety of sources
4. Plug-in adapters enable existing data sources including directories,
communications systems, collaboration systems, and databases each using
differing protocols and schemas to be integrated into the framework
5. Provide a social relationship data integration framework that enables these
relationships to be persistent and reusable across application boundaries
5
© 2003 IBM Corporation
Business Unit or Product Name
Higgins Framework
Extensible Java framework
– Code not protocols!
Deployments vary from:
– Browser extension + hosted service
– 100% local
6
© 2003 IBM Corporation
Business Unit or Product Name
Multiple contexts, identities, profiles & links
Home Work Health Provider Visa United
329 Main HMO, GroupID, Account PTrev
Street, # number pw=batman8
Chestnut Hill,
Dr. James Credit limit = Window
MA
Levine $5,000 seating,
(617) 879 9971 vegetarian,
175lbs, Type Balance =
non-smoking,
ptrevithick@alu O- $1,250.22
economy
m.mit.edu
… ,,, Marriot
rewards, …
7
© 2003 IBM Corporation
Business Unit or Product Name
Existing protocols, systems and sites are adapted
using plugins
Higgins
Home Work HC Provider Visa United
8
© 2003 IBM Corporation
Business Unit or Product Name
Higgins as an Interoperability Framework
Eclipse IdPs and
Apps and Services HBX
RCP RPs
Higgins Framework (Core Components)
Plug-ins
Authentication Protocols CardSpace OpenID Liberty …more
Data Sharing JNDI/LDAP RDF RSS …more
Service Metadata WS-Addressing XRI/Yadis URI
9
© 2003 IBM Corporation
Business Unit or Product Name
For End Users: an “Identity Agent”
Provides a consistent user experience
– Identity information presented as i-card channels to identity data sources
Empowers: Designed around the user
– Provides more control over user’s personal data
– Protects and projects as the user desires
Protects
– Identity Mixer –Privacy enhancing technology contributed from IBM Zurich Research
Projects
– Provide rich profiles to trusted partners
Manages
– Links and syncs user’s information info across silos
10
© 2003 IBM Corporation
Business Unit or Product Name
Information Cards
• Store credentials, profiles,
personal data, and social
networks –not just for sign-in!
• Dynamic or Static
• Managed or Self-Issued
• Push or Pull synchronization
• CardSpace™ or OpenID or RSS
or …
11
© 2003 IBM Corporation
Business Unit or Product Name
Towards an Identity Metasystem
We want is to all “just work”
Manage our multiple identities in multiple contexts
Works with any protocol
Works on any platform
12
© 2003 IBM Corporation
Business Unit or Product Name
For Developers: Identity Tooling
Only one API to learn
Saves developer from the details of multiple identity
systems
Relies on plug-ins to support protocols and technologies:
CardSpace™, OpenID, RSS, XRI, XDI, LDAP, etc..
13
© 2003 IBM Corporation
Business Unit or Product Name
Higgins Data Model
14
© 2003 IBM Corporation
Business Unit or Product Name
Data Model Concepts
Contexts and ContextIds
Digital Subjects and SubjectIds
Attributes
Metadata
Ontologies (schema)
15
© 2003 IBM Corporation
Business Unit or Product Name
Contexts and ContextIds
A Context is a data set
Usually requires authentication
The data contained may vary by observer
Identified uniquely by ContextIds
ContextIds are URIs (and may be XRIs)
Examples
OpenID Provider (OP)
LDAP directory
PeopleSoft database
16
© 2003 IBM Corporation
Business Unit or Product Name
Context Data: Nodes and Arcs
Nodes are Digital Subjects
– A person, thing, event, group, etc
Arcs are relationships between Digital Subjects
– Within and across contexts
– Arcs are called Subject Relationships
Context boundaries
17
© 2003 IBM Corporation
Business Unit or Product Name
Kinds of Attributes
Identity Attributes
– E.g. self-assertion: {UserName, “foo”}
Profile Attributes
– E.g. self-assertion: {PreferredMealType, “vegetarian”}
Relationship Attributes
– A reference to another Digital Subject
– Comprised of (i) a ContextId (a URI or XRI) that identifies the target
Context and (ii) a SubjectId that uniquely identifies the target Digital
Subject in the target Context
18
© 2003 IBM Corporation
Business Unit or Product Name
Digital Subject, Attributes, Metadata
Person
[Mary]
uniqueIdentifier
String
Person:
eyecolor
Person: mary@socialphysics.org
phoneNumber String
String value
source
value Blue
creationDate expiration
Dept.
555-1212 Motor
Mar
Mar 3 20 Vehicles
1999 1999 19
© 2003 IBM Corporation
Business Unit or Product Name
Metamodel, Ontologies
Contexts describe their schemas using OWL
OWL builds on: RDFS, RDF, XML, XML Schema
Contexts base their OWL on higgins.owl
Otherwise free to define their own data model
E.g. a Context could define the concept of a Person, and
this Person having eyeColor and phoneNumber attributes
– Person would sub-class higgins:DigitalSubject
– eyeColor would sub-property higgins:Attribute
20
© 2003 IBM Corporation
Business Unit or Product Name
Higgins Identity Attribute Service
21
© 2003 IBM Corporation
Business Unit or Product Name
Context Providers:
Mapping data into the Higgins model
Context Provider lookup for a
given ContextId. Registration of
Higgins Identity Attribute Service ContextIds with Providers and
any configuration data (if
needed)
Context Context Context
Context provider plug-ins
Provider Provider Provider
IContext instances.
Each is authenticated to
underlying Context data
(view of data may vary by
who is authenticated)
Underlying bits (backing store)
22
© 2003 IBM Corporation
Business Unit or Product Name
Thank you!
23
© 2003 IBM Corporation
SAML, Liberty,
and the Shibboleth Project
Scott Cantor
cantor.2@osu.edu
Internet2/The Ohio State University
SAML 1.0 (2002)
Scope of Interoperability
• Source-site initiated web authentication
• POST Profile
• Artifact / Callback Profile
• Attribute exchange protocol
• Simple authorization query/decision protocol
2
SAML 2.0 (2005)
Scope of Interoperability
• Unified authentication protocol for browsers and
“active” clients, web services, etc.
• SOAP and browser-based logout
• Identifier types for privacy-oriented use cases
• Protocol for communicating identifier changes and
account termination
• Metadata schema for exchange of configuration and
keys
• Simpler assertion format
• Framework for bridging from SAML to current and
future security technologies
3
Industry/Open Source
Convergence
Liberty Liberty
ID-FF 1.1 ID-FF 1.2
SAML 1.0 SAML 1.1 SAML 2.0
Shibboleth 1.x Profiles
2002 2003 2004
4
Liberty ID-WSF 2.0 (2006)
• Identity-Aware SOAP Binding
• 95% WS-Addressing and WS-Security
• WS-Security and SAML 2.0 assertion profiles used
to represent N-tier/delegated access to services
• SASL-based authentication service for SOAP clients
• Active profile of SAML 2.0 SSO/Authentication using
Liberty’s SOAP binding
• Discovery Service for use cases geared around
personalized services
• People Service for personal group management
without resorting to global identifiers 5
Shibboleth (Multiply) Defined
• Shibboleth Project
• Umbrella of activities around federated
authentication and access management managed
by Internet2 and its international partners
• Shibboleth Profiles
• Wire protocols and conformance requirements that
define "Shibboleth Compatible", derived in large
part from SAML 1.1 with a few additions
• Shibboleth System
• Internet2-developed open source implementation of
the profiles and value-added components, along
with other SSO protocols and features
Shibboleth Software
Stable Branch (1.3)
• Java-based Identity Provider and Attribute Authority
designed to integrate with systems rather than
supplant them
• Apache, IIS, iPlanet Service Provider modules to
identity-enable applications without programming
• Support for SAML 1.1, 1.0, and WS-Federation
• Utilizes SAML 2.0 metadata and our own
extensions for federation and trust management
• Sophisticated attribute policy and filtering support
• Built on OpenSAML 1.1 libraries, also freely
available, but with lousy (as in no) documentation
Shibboleth Software
Development Branch (2.0)
• Redesigned, documented XML Tooling, Signature,
Encryption, and OpenSAML 2.0 libraries
• Redesigned IdP and SP platforms for multi-protocol
support and extension development
• SAML 2.0 Browser SSO and SLO profiles
• Security policy and metadata architecture to
accommodate a range of server authentication and
trust management strategies and strengths
• Redesigned attribute resolution engine to handle
different attribute representations
Shibboleth 2.Next
Planned/Potential Projects
• Additional SAML 2.0 profiles
• Cardspace / WS-Trust support
• Integration of real-time privacy controls for
users
• Collaboration / contributions to OpenLiberty
ID-WSF software projects
• Applying ID-WSF to multi-tier use cases
Shibboleth Use of PKI
• The obvious, using certificates to authenticate to an IdP
• Signed metadata is a primary distribution mechanism
• Metadata enables the use of raw public key cryptography
• Shibboleth metadata extensions enable use of PKIX
libraries at runtime to validate server credentials
• PKIX increasingly viewed as an albatross for deployers
• Need for encryption key distribution and other
considerations driving federations to embed keys or self-
signed certificates in metadata
• Large opportunity for PKI efforts to address evaluation of
metadata signatures
The OASIS Digital Signing Service
and its Application to E-Invoicing in Europe
Nick Pope – Thales e-Security, UK
(nick.pope@thales-esecurity.com)
Juan Carlos Cruellas - Universitat Politècnica de Catalunya,
Spain
(cruellas@ac.upc.edu)
Nick and Juan Carlos co-chair the OASIS Digital Signature Services TC and
have work together over a number of years on European Electronic Signature standards
including most recently the ETSI specification on “Signatures for Digital Accounting”
Abstract
This paper presents two related activities, the first is the OASIS Digital Signature Services (DSS)
standard, the second is the application of digital signatures to electronic invoicing as recognised under
recent European legislation. DSS can be used to support a range of signature formats including the binary
“cryptographic message syntax” and XML signatures, as well as related extended formats for “advanced
electronic signatures” defined in European standards. The DSS standard is built around the general
XML web based services structure and can be used with HTTP and SOAP transport protocols. The paper
describes how DSS supports the needs of eInvoicing signature creation and verification, minimising the
per user installation costs, improving security and reducing the need for revocation. It also describes how
DSS verification greatly simplifies the complexity of user systems and facilitates centralised management
of security within an organisation. Finally, the paper considers the requirements for maintaining the
verifiability of signed invoices stored over a period of around 10 years and how this can be met by DSS
verification services with time-stamping and / or archive services.
invoices, including requirements for the security
E-Invoicing in Europe of electronic invoices. It states that:
A directive was issued in 2001 with the aim of
harmonising the requirements relating to “Value “Invoices sent by electronic means shall be
Added Tax” (VAT) in Europe [VATDirective]. accepted by Member States provided that
This tax is a form purchase tax but is applicable the authenticity of the origin and integrity of
to all sales including supplies of goods between the contents are guaranteed ..”
companies to which value is added (hence the
name value added tax). VAT legislation The VAT directive then goes on to identify
requires invoices be produced and recorded on alternative solutions to providing such protection
all sales to which VAT is applicable and there including protection using a form of digital
are pan European rules on how this tax is signature based on a PKI (referred to in EU
itemised to facilitate auditing of the tax legislation as an “advanced electronic
collection. signature”).
The recent directive on VAT harmonisation Records of these signed e-invoices need to be
defines further rules for the form of VAT kept for a number of years, varying from country
to country, but can be up to 10 years or more. It
has been generally taken that the requirement for best practice for third parties providing signing
authentication and integrity extends for this and storage of invoices and other accounting
period. So it can be necessary for signatures to documents. It outlines the security controls that
be verifiable 10 years after the invoice was should be applied to ensure appropriate security
created, possibly long after any public key on signing services and insure integrity of signed
certificates involved in their creation have documents over the period of storage. It can be
expired or have been revoked. used as requirements external to an organisation,
or internal services provides for use within large
Recognising the need to establish techniques for organisations. The model used in the ETSI
maintaining the validity of signatures over the standard is illustrated below:
long term, a European based workshop operated
by CEN (Comité Européen de Normalisation)
has included as part of its CEN Workshop Internet or
any network
Agreement on E-Invoices and Digital Signatures
[CWA 15579] guidance on the maintenance of TRADING PARTY TRADING PARTY
signatures over the long term. This identifies the Report (e.g.
VAT return)
Invoices
etc
Signed Signed Invoices
Fiscal
Report
Invoices Invoices etc
need for controls to ensure that the information etc etc
needed to verify the signature at the time of
signing is maintained. This can be through use Authority
Authority
Authority
Authority
of technical measures such as the preservation of Signing and
storage Signed
Signing and
storage Signed
services Invoices services Invoices
relevant certificates and revocation information etc
Trusted Trusted
etc
such as OCSP (Online Certificate Status Applicable
Service
Provider
Service
Provider Applicable
regulations regulations
Protocol [RFC 2560]) or CRL (Certificate = Advanced Electronic
Signature
Revocation List [X.509]), along with a signature
time-stamp, augmented by archive time-stamps
where the algorithm strength dictates cannot be
guaranteed for the whole storage. Alternatively, Storage of Signed Invoices
this can be through use of organisational The issue of particular concern when storing
measures using, for example, trusted notaries to signed e-invoices is that when retrieved at a later
check signatures and maintain records. It is date (say after 5 years) the signature may need to
recognised that a range of solutions exist be verified by an auditor when looking back at
depending more or less on cryptographic old records. After such a period, it is likely that
technology, use of archive media such as the certificates used in signing the invoice have
WORM drives, and organisational controls. expired and it is possible that one or more of the
This requirement is discussed further below. certificates used have been revoked. The auditor
looking at an old signed document needs to be
Similar requirements can be applied not only to able to know that the signature was valid at the
the e-invoices, but other documentation for time the signature was applied.
company accounting and auditing, such as the
quarterly regular VAT reports required by the Two basic solutions have been identified, The
tax authorities, as well as other company reports first is to use a trusted service that stores all
required to support needs for secure accounting signed documents along with a trusted statement
such as those imposed through the Sarbanes- that the signature was verified to be correct at
Oxley Act in the U.S. the time when first placed in storage. Such a
trusted service would require the use of secure
The work of CEN has been taken further by databases or other forms of trusted storage and
ETSI (European Telecommunications Standards procedural controls to ensure that the
Institute) in a specification to be published appropriate checks are carried out when placing
shortly on “policy requirements for trust service data in storage.
providers signing and/or storing data for digital
accounting” [ETSI TS 102 573]. This identifies
The second solution is to use technical measures before placing in storage, and either the relevant
to establish: certificates and revocation information is
included with the signature by value or
a) The time when a valid signature existed, reference.
b) The certificates and revocation
information (e.g. Certificate Revocation When storing documents for very long periods
List or OCSP response) required to when the strength of the public key algorithm
verify the correctness of the signature at may not be assured (say longer than 10 years),
that time. additional protection needs to be applied. Over
This second solution allows an auditor to later such periods the integrity of the signed
verify the signature. document needs to be extended, for example, by
additional signatures, signed time-stamps or
The time of when a valid signature is known to secure storage mechanisms.
existed may achieved by verifying a signature
just before first storing and marking the Since in Europe electronic documents are not
signature with this time. generally required to be kept for longer than 10
years, this paper primarily considers the
The most widely accepted solution to getting requirements for storage of documents in the 1
assurance of the time is to use time-stamping to 10 year time-scale. The mechanisms to
produced by an server such as defined in RFC protect documents for longer than ten years are
3161. If applied over the signature this can be not generally necessary for eInvoicing.
used to demonstrate that the signature occurred
before the time-stamp. Further assurance of the
signing time can be achieved by including the Application of Conventional PKI to
signing time within the signed data and then E-Invoicing
apply a time-stamp afterwards. However, from The application of conventional PKI techniques
recent work on profiles for “advanced electronic to signing e-invoices stored for a period of
signatures” based on a survey of current practice around say 10 years is illustrated in the
[ETSI TS 102 704 and ETSI TS 102 904] following diagram:
indicates that a time-stamp applied after signing
is generally considered sufficient. It is
Purchasing
recognised that other mechanisms, such as System
(5)
secure audit logs, can be used to prove the time (4)
(5)
that the document was signed / stored. Archiving
(4)
Timestamp
Possibly the surest way of making the certificate (3)
and revocation information available is by (2) Revocation
Cert,
(1) CRL.
storing it with the signed document. This,
however, can be very inefficient requiring Registration (2)
significant amount of storage with much PKI Certificate
Cert.
Directory
Management
common information repeated across CRL.
documents. The alternative of depending on the (3)
certification authority (CA) to store all the
historical information and make it readily Fig 1: Conventional PKI solution for
available for access for any date for 10 years is e-Invoicing
beyond the capabilities of most CAs.
As illustrated each user needs to interact with
The solution adopted in European “advanced” several services to set up and apply digital
electronic signature format standards ([ETSI TS signatures and maintain all the necessary records
101 733], [ETSI TS 101 903]) is to recommend for e-invoicing documents produced by the
that signatures are time-stamped on receipt, purchasing system:
DSS Based Solution
1) When first setting up the capability to
create digital signatures, the user needs
Purchasing
to interact with registration services System
which will carry out the necessary
authentication and authorisation checks.
2) Some time later when the necessary
checks have been completed the
registration service interacts with the Internal user
PKI management services to produce Authentication &
authorisation
the necessary keys and certificates. The Revocation
certificates are placed in a directory Archiving
PKI Certificate Directory
system and the key is passed back to the Management
user, for example in a smart card device. Trusted time Registration
3) If after using the signing key the user
changes role and is no longer authorised Fig 2: DSS Based Solution for e-Invoicing
for signing, or the security of the key is
compromised, for example due to loss of An alterative solution to signing company
the smart card in a public place, the user documents, such as e-invoices, would be to
needs to interact with revocation employ a signing server which signs document
services to revoke use of the key. for authorised users within the organisation.
4) When applying the signature in order to
obtain a trusted indication of the time Such a server based solution can build on the
when the signature was applied the user existing user authentication and authorisation
(or purchasing system) timestamps the system to control the use of the signing function
signature using a timestamp server. and, if individual user signing keys are required,
5) In order to preserve the evidential value identify the appropriate signing key. All the
of the signed invoice the signed complexities of the PKI Management are
document is passed, either by the user or handled by the server without the need for any
purchasing system, to the archiving user involvement. The signing service can, in
system. The archiving system is addition, be extended to provide the necessary
required to maintain the integrity of the archiving functions to maintain the signatures
signature including the necessary CRLs over the lifetime of the document. Also, trusted
and certificates which may be retrieved time functions can be used to provide the
from the directory. necessary evidence of the signing time.
Some of the above steps may be simplified or The OASIS DSS Protocol
handled by the purchasing application on behalf
of the user (e.g. archiving and time-stamping). The basic aim of the OASIS Digital Signature
However, much of the complexities of the PKI Service (DSS) draft standard [OASIS DSS] is to
system (registration, revocation handling) are define protocols for a networked web service to
inherent in the design of client based PKI. support digital signatures. It also supports a
variety of variations on basic digital signature
In many European countries the need for digital services such as time-stamping.
(electronic) signatures is not limited to
purchasing. Many of the accounting reports (for DSS is designed to support a range of signature
example quarterly tax returns summarising total formats. Not only does DSS support the World
VAT paid and collected, yearly corporate Wide Web consortium XML Signature [W3C
accounts) also have to be protected by XMLDSig], but also the widely used
signatures, widening the need for support for Cryptographic Message Syntax (CMS) binary
digital signatures. signed data format [IETF CMS]. It can even be
extended to support other forms of signature
such as PGP. The protocol is also designed to The recipient may verify the signature himself or
be easily extensible to enable support of use the DSS verify protocol as indicated below:
advanced forms of CMS and XML based
signatures such as defined by ETSI [ETSI TS
101 733] & [ETSI TS 101 903].
(Signed document)
DSS supports two basic protocols one for the
creation of digital signatures, the other for 1)
4)
DSS-Verify request
verification of signatures. The basic operation (Signed document) DSS-Sign response
of a DSS sign and verify requests are illustrated (OK)
below: 2)
Public Key Archive
Store / directory
3)
(Signed document)
Fig 4 DSS Verify protocol
1)
DSS-Sign response 1) The user sends the request for the signed
4)
(Signed document) document to be verified through a
2)
secure channel (e.g. SSL).
3) 2) The server verifies the validity of the
User Authentication /
Authorisation DSS Server
Archive signed document including checking the
validity and revocation checks on any
keys or certificates as necessary.
Fig 3: DSS Sign Protocol 3) If required the verifying organisation
may keep its own copy of the signed
1) The user sends the request for the document and verification information
document to be signed through a secure (CRLs, Certificates, time at which
channel that authenticates the user (e.g. document was verified to be correct).
SSL + client authentication using one 4) The results of this verification is
time password). returned back to the user through the
2) The server checks that the authenticated same secure channel.
user is allowed to sign the document and
if acceptable signs the document on The DSS protocol removes from the user all the
behalf of the user with a corporate burdens normally associated with digital
signing key or a key which the server signatures. There is no need for the
holds on behalf of the user. management of large numbers of keys
3) If required, the server can be extended distributed throughout the organisation, and no
to archive the document, signature and special cryptographic code or keys are needed
appropriate supporting information on the client system. Where it is necessary to
(CRLs, certificates, signing time). authenticate the client existing mechanisms can
4) The server returns the signed document be used. All the problems of maintaining the
to the user back through the same security of the keys and cryptographic functions
secure channel. associated with digital signatures can be
managed by the organisation through centralised
Having obtained the signed document from the controls.
DSS server the user can then pass it on to one or
more recipients who may verify the signature DSS servers can be used to maintain an audit
themselves or use the DSS verify protocol. record to confirm that signatures are verifiable at
the time of receipt, and through use of time-
stamping ensure that the validity of archived confidentiality, authentication and
signed documents can be assured long after the integrity to the transport binding; TLS 1.0
applicable keys have expired as described support is mandatory and SSL 3.0 support
below. is optional. In this way clients may use
wide-spread tools that do not jeopardize
DSS specification set structure their implementation.
The DSS specification set is formed by the so- The profile documents further develop the basic
called core document (“Digital Signature messages so that they may be easily tailored to
Service Core Protocols, Elements and meet the requirements of a specific application
Bindings”) and a number of additional or use case. Profiles may restrict the values
documents defining specific profiles of the ranges of certain message elements, or, if
aforementioned core protocols. required, extend the basic core protocols
defining new optional inputs, outputs and/or
The core document defines the (XML-based) bindings.
syntax and semantics for the basic services,
namely: signature generation and signature The final result is not only a set of protocols
verification. This includes: targeting a number of relevant scenarios but also
a set of generic protocols which may be easily
• Definition of four basic messages: further profiled as new uncovered use cases are
SignRequest, SignResponse, identified.
VerifyRequest and VerifyResponse. They
are defined to easily manage the most
Variations and Profiling DSS
common signatures formats, ie, [XMLSig]
and [CMS]. The DSS protocol supports a number of
variations in this protocol. For example, the
• Definition of an extensibility mechanism signature may be passed back to the user on its
that allows the clients to further qualify or own, detached from the document to which it
even increase the extent of the requests applies, or placed within the document to which
through optional inputs. It also allows the it applies. Another variation is that the
servers to answer with extended responses document is reduced to a simple hash fingerprint
through the corresponding optional for sending to the server instead of the document
outputs. for either signing or verification, thereby
• Definition of a XML format for a time- reducing bandwidth requirements and reducing
stamp token, fully based on XML the opportunity for the confidentiality of the
signatures as specified in [XMLSig]. document to be compromised.
• Definition of mechanisms for managing
generation and verification of digital When signing a document the DSS server may
signatures carrying time-stamp tokens add additional attributes or properties to the
(both CMS-based as defined in [RFC signature such as the claimed signing time or a
3161] and the XML-based specified in the time-stamp against the content applied
core document itself) computed on the immediately before signing.
signatures themselves (signature time-
stamps). Due to the number of variations a specific set of
options can be selected in the DSS protocol to
• Definition of bindings for transport and
support a particular mode of operation or
security. The first ones specify how DSS
application requirement. This selection from the
messages are encoded and carried over the
DSS protocol is defined in separate DSS profile
most popular transport protocols (it defines
specification. The DSS protocol is also
bindings for HTTP –through HTTP POST
designed to facilitate extensions and so DSS
exchanges- and SOAP 1.2). The security
Profiles may also extend the protocol, as well as
bindings establish rules for providing
selecting specific options, defining its own invoicing, where the signature is generally
profile specific input or outputs for profile applied on behalf of a company, either as a
specific attributes of a signature. corporate signature or as the signature of an
individual who signs as a person responsible for
A number of profiles have been defined for the company, such as a chief executive.
DSS. This includes:
a) Time-stamp profile The authentication required to authorise a
signature request within an organisation, can be
As described above, including support for based upon internal security controls. Internal
XML format time-stamps. user identities can be assigned as part of the
b) DSS Entity Seal Profile normal internal user authentication and
This profile is a variation on a signed time- authorisation controls, there is no need to
stamp, where the signed object includes not interact with external registration services to set
only the time but the identity of the up each individual user that may be authorised
authenticated user requesting the "entity to sign. Furthermore, where more complex
seal". This provides further traceability and work flow processes are involved with
provides a form of "proxy" signature where authorisation of invoices this process can be
the signature is produced on behalf of controlled independent of the application of the
another identifiable party. signature. Finally, any changes in personnel or
removal of access rights, need not affect external
c) Advanced Electronic Signature revocation. Any authorisations to sign
Profile documents can be removed immediately without
This profile produces signatures that have any impact on external revocation services.
the attributes needed for legally qualified
and long-term signatures If required the method employed for user
d) Code signing Profile authentication to a DSS need not involve any
installation of security devices on the user PC.
This profile is designed to support the For example, simple challenge response systems
signing of code authorised for distribution using hardware tokens may be used to request
with an organisational signature indicating signing by the DSS server through a simple web
its authenticity. interface without the need for special security
e) Electronic (Digital) Post Mark Profile installation. Thus the common difficulties with
installing security devices such as smart card
This profile is for providing an electronic
readers can be avoided.
post mark used confirm authenticity of
email, as promoted by the Universal Postal
The centralised management of corporate
Union [UPU-EPM].
signing keys are also facilitated through the use
f) Signature Gateway Profile a signing server. Strict organisational controls
This profile supports the creation of can be applied to the server. If necessary it can
signatures at a gateway from a form only be held in a physically secure area. Dual control
recognised internally to a standard form / split keys can be applied so that the signing key
which can be recognised externally. can be used under strict controls. Thus the
probability of compromise, and hence the need
Authentication and Authorisation for for external revocation, is minimised.
Signature Creation
This ability in DSS to centralise signing
The DSS services decouple the authentication / capability not only improves security but also
authorisation of the signing request from the can reduce costs by minimising the per user
authentication in the signature. This installation costs.
significantly simplifies the management of
identities and authentication in the case of e-
Signature Verification for Stored DSS Within an eInvoicing
Signatures Architecture
As mentioned above, to assure that signatures
are verifiable for the period they are to be stored, The use of servers for signing and verification of
it is considered necessary to establish the time signatures fits naturally with the basic
that they are known to be valid and the architecture of many e-invoicing systems.
certificate and revocation information (e.g. Generally, back office systems are used to
Certificate Revocation List, OCSP response) handle invoices as part of the process flow.
used to confirm that validation. Whilst individuals may need to be accountable
for the creation of invoices within the
The DSS verification service can take the burden organisation, from the external viewpoint the
of obtaining and maintaining the supporting signature belongs to the organisation, or in some
evidence for “long term” signatures away from countries a senior executive who represents the
the user. Two basic solutions are envisaged. company.
One is to extend the signature structure adding
the signature time-stamp and references / values As illustrated below in the case of invoices the
of the certificates and revocation information creation of signatures may be initiated by an
employed in validating the signature (as invoicing and accounting system which prepares
described in [ETSI TS 101 733] and [ETSI TS and issues invoices under control of accounting
101 903]). The other is to include a trusted time clerks. The system is already trusted to properly
and relevant certificate and revocation maintain and control the creation of accounting
information in a secure audit log. In either case information. The private key used in creating
all the complexities are taken from the user and the invoice signatures can be managed centrally
handled by a trusted server. under clear security controls.
A further advantage of using a DSS server for Invoicing and
signature verification is that all the complexities Accountings system
of validating the certificate path are taken from
the user. This can be particularly onerous where ice
Invo
multiple certificate policies are involved or the
trusted root certificate authority of the
organisation where the signature was created is
different from that where the signature is
DSS
verified. By placing such functionality in the Signing Server
server the appropriate cross domain policy
controls can maintained and easily updated Fig 5 eInvoicing System with DSS Signing
under central control.
Similarly, the verification of incoming invoices
In general the ability of DSS verification server may be initiated by the accounting system. The
to be placed under central control enables all the information required for future verification of
appropriate security measures to be applied and the stored invoice can be maintained in two
maintained. The security management ways. This can be done the use of a secure audit
authorities for an organisation can ensure that log maintained by the server containing the
the procedures applied are secure and up to date. relevant validation information for later retrieval
There is no need to depend on users to properly when subsequently re-verifying a stored
apply signature verification policy and there is document. Alternatively, by use of advanced
no need to distribute up to date security software electronic signature structures the document
and information around the organisation. signature can be augmented with the information
necessary to later re-verify the signature. In
either case, the database used to store the
invoices do not need to be secure to ensure the platforms based on proprietary protocols are
integrity of the signatures as this is provided evolving towards DSS-compliant
through the DSS verification server. implementations.
Invoicing and One of the first major deployments using DSS
Accountings system specifications is the PSIS [PSIS]: a platform for
Invo
ice identification and signature services,
conceptualized, deployed and run by the
Agència Catalana de Certificació (CATCERT)
[CATCERT]. CATCERT is the CA for public
3)
administration agencies in Catalunya, Spain.
Along with provision of different types of
DSS Audit log
Verification Server certificates (among which the personal
certificate for Catalan citizens), CATCERT also
Fig 6 eInvoicing System with DSS Verification offers this platform to Catalan governmental
agencies, local administrations and private
companies that have to securely exchange
DSS Implementations electronic information with them. This platform
The first version of the DSS core working draft offers centralized services of signature
dates back to October 2003. In 2004 and first generation, signature verification, encryption,
half of 2005, the DSS Technical Committee and decryption. In addition to that CATCERT
developed a version of the core protocol also provides access control tools (that use
incorporating most of the features of the current Liberty Alliance protocols) based on unique
version, as well as the most important profiles. authentication or identity federation, to those
In 2006, the document went for public review. organizations that want to integrate these
The TC received several comments that proved services in their own applications. As for the
the attention attracted by his work. In parallel DSS, this platform implements the DSS-core,
several members of the DSS TC have started an the management of XML time-stamps, the DSS-
interoperability initiative for assessing the AdES profile and the DSS time-stamping
protocols under a practical perspective. At time profile. It is able to perform semantic validation
of writing this paper specifications are in the of certificates, CMS, XML-Sig XAdES and
final stage for ratification as OASIS CAdES signatures, indicating their validity and
specification early in 2007. the security level associated to the signing
certificate (this is important because each type of
Over the last few years several systems have electronic transaction with Catalan public
been deployed, which adopted DSS style of administrations requires that the signing
operation. As the specifications matured they certificate has a pre-determined level of
attracted the attention an increasing number of security).
manufactures of such a kind of systems. In the
end, DSS specifications provide a standard way In Norway a consortium of banks and CAs offer
of operation for centralized services for an optional lightweight web based signing, of a
electronic signatures generation and verification, style similar to DSS, to over 600,000 banking
which ensures interoperability. customers [BankID] [EEMA-Award] with the
aim to extend this to 2.3 million.
2007 will likely start a period of extensive
deployment of DSS-compliant applications. A The UPU EPM, adopted by several postal
number of organizations exist interested in service organisations, has been working closely
providing centralized services for generation and with OASIS to incorporate DSS verification
verification of electronic signatures, which have services in its global digital post mark system
decided to build a DSS-compliant application [UPU DPM].
from the scratch. In addition, owners of
Also in Spain the “Ministerio de Trabajo y preservation of signatures over a period of up to
Asuntos Sociales” (Ministery of Labour and around 10 years.
Social Affaires) [MTAS], runs a centralized
system that verifies digitally signed labour The features of DSS make it particularly suited
accidents reports. Within the framework on the to meeting the requirements of applications such
currently on going initiative for a Spanish as eInvoicing. DSS matches the need for
electronic ID card [DNIE], the “Ministerio de invoice signing to be controlled on an
Administraciones Públicas” (Ministery for organisation basis and handles the requirements
Public Administration) [MAP] also runs a for verification of stored signed documents.
platform offering, among others, a centralized
service for electronic signatures validation. The DSS specification is at its final stages of
These two platforms were firstly developed ratification. Interoperability trials have been run
using a proprietary protocol. Without no doubt, between separate implementations, and several
all these platforms deployed in different major implementations are expected to appear
governmental agencies will have to evolve and over the next year.
become DSS-compliant for the sake of
interoperability. Within Europe, and globally, there is significant
interest in the use of web based and trusted third
By the time this paper is written, the authors party services for the creation of digital
know of several commercial systems DSS- signatures. Electronic invoicing is one of the
compliant that are offered to both private sector major applications requiring digital signatures
and public administrations all over Europe, which is likely to be a major driver for a cost
which demonstrates the timeliness of the effort effective solution to digital signing.
done by the DSS TC.
By implementing DSS, the power of digital
signatures can be provided without the
Conclusions headaches of installing PKI capabilities at every
The work of OASIS in developing the standard user system and ensuring signing keys and
for Digital Signature Services has provided a devices are managed securely.
fruitful alternative to conventional client based
PKI systems. The approach has been
demonstrated to significantly reduce the cost of Acknowledgement
the per user installation, whilst features inherent
in this approach can improve security. The authors wish to acknowledge the significant
contribution made to the members of the OASIS
The use of DSS signing servers have significant DSS Technical Committee and the ETSI
advantages. By detaching the authentication of Technical Committee on Electronic Signatures
internal end users from security of external keys and Infrastructures in developing the ideas
requirements for revocation can be minimised. represented in this paper.
Also, by placing the server under central control
proper administrative control can be applied to References
ensure the security of signing keys.
[VAT Directive] Council Directive
The use DSS verification servers provides 2001/115/EC of 20 December 2001
straightforward verification of signed documents amending Directive 77/388/EEC with a view
both on receipt and when retrieved from storage to simplifying, modernising and harmonising
several years later. It can be used to remove the the conditions laid down for invoicing in
burden of complex certificate path validation respect of value added tax.
from users, and maintain information required http://europa.eu.int/eur-
lex/pri/en/oj/dat/2002/l_015/l_01520020117e
n00240028.pdf
[CWA 15579] CEN Workshop Agreement “E- [ETSI TS 102 573] policy requirements for trust
Invoices and Digital Signatures“ service providers signing and/or storing data
http://www.cenorm.be/CENORM/BusinessDom for digital accounting.
ains/businessdomains/isss/cwa/electronic+bu
All ETSI documents are available from:
siness.asp
http://pda.etsi.org/pda/queryform.asp
[OASIS DSS] OASIS Digital Signature
[X.509] ITU-T Recommendation X.509:
Services Technical Committee
Information Technology - Open Systems
http://www.oasis-
Interconnection - The Directory: Public-key
open.org/committees/tc_home.php?wg_abbre
and attribute certificate frameworks (Latest
v=dss
version 08-2005)
[BankID] Bank ID
[CATCERT] Agència Catalana de Certificació
http://www.bankid.no
http://www.catcert.cat
[EEMA-Award] The eema Award for
[PSIS] Plataforma de serveis d’identificació i
Excellence in partnership
signatura
with Infosecurity Today
http://www.catcert.cat/web/cat/1_4_3_plataform
http://www.eema.org/static/isse/awards.htm
a.jsp
[ETSI ESI] ETSI Electronic Signatures and
Infrastructures public home page [MTAS] Ministerio de Asuntos Sociales.
http://portal.etsi.org/esi/el-sign.asp http://www.mtas.es
[UPU-EPM] Electronic Post Mark
[MAP] Ministerio de Administraciones
http://www.globalepost.com/
Públicas.
[W3C XMLDSig] XML-Signature Syntax and http://www.map.es
Processing, W3C Recommendation 12
February 2002 [DNIE] DNI Electronico
http://www.w3.org/TR/xmldsig-core/ http://www.dnielectronico.es/
[IETF CMS] Cryptographic Message Syntax http://www.dnielectronico.es/seccion_aapp/cata.
(CMS) IETF RFC 3852, R. Housley, July html
2004
[RFC 2560] “X.509 Internet Public Key
Infrastructure Online Certificate Status
Protocol – OCSP“, M. Myers et al, June
1999.
[ETSI TS 101 733] Electronic Signatures and
Infrastructures (ESI); CMS Advanced
Electronic Signatures (CAdES)
[ETSI TS 101 903]. XML Advanced Electronic
Signatures (XAdES)
[ETSI TS 102 734] Profiles of CMS Advanced
Electronic Signatures based on TS 101 733
(CadES)
[ETSI TS 102 904] Profiles of XML Advanced
Electronic Signatures based on TS 101 904
(CadES)
OASIS Digital Signing Service
and E-Invoicing in Europe
Nick Pope – Thales eSecurity
Juan Carlos Cruellas - Universitat Politècnica de Catalunya
NIST PKI Workshop – April 2007
Outline
EU Requirements for eInvoices
Need for security in electronic invoices under European
VAT Tax System
How can be met by digital signatures
Requirements for verifiability of stored signature
OASIS Digital Signature Services
Web based service for digital signatures
Application to signing tax invoices
1
NIST PKI Workshop – April 2007
1
European Value Added Tax System
Chip Co €15
Inv 27
TAXMAN
€100 +
€ 15 VAT
€3
€45 – 15 - 3
Phone Co
Inv 27
Casing Co €300 +
Inv 27 € 45 VAT
€20 +
€ 3 VAT
2
NIST PKI Workshop – April 2007
European Value Added Tax System - Export
Chip Co €15
Inv 27
TAXMAN
€100 +
€ 15 VAT
€3
€0 – 15 - 3
Phone Co
Inv 27
Casing Co €300 +
Inv 27 € 0 VAT
€20 +
€ 3 VAT
3
NIST PKI Workshop – April 2007
2
Example VAT Fraud
4
NIST PKI Workshop – April 2007
EU VAT Harmonisation Directive
“Invoices sent by electronic means shall be accepted by
Member States provided that the authenticity of the
origin and integrity of the contents are guaranteed ..”
Recognised mechanisms
“EDI Service Provider”
“Advanced Electronic Signature”
X.509 based Digital Signature
From company / company officer
5
NIST PKI Workshop – April 2007
3
Requirement for Storage of Signed Invoices
Internet or
any network
TRADING PARTY TRADING PARTY
Fiscal
Report (e.g. Invoices Signed Report
Signed Invoices
VAT return) etc Invoices Invoices etc
etc etc
Authority Authority
Authority Authority
Signing and Signing and
TAXMAN storage Signed
storage Signed
TAXMAN
services Invoices services Invoices
etc etc
Trusted Trusted
Service Service
Applicable Provider Provider Applicable
regulations regulations
= Advanced Electronic
Signature
6
NIST PKI Workshop – April 2007
Requirements for stored signed documents
Technical
Information used to verify signature when stored
Certificate path
OCSPs / CRLs
Time of verification
Signature Time-stamp
Means to maintain integrity beyond algorithm life-time
(e.g. 10 years)
Archive time-stamp (e.g. LTANS)
Or trusted organisation
Notary
Ref: CWA 15579
ETSI TS 102 573
7
NIST PKI Workshop – April 2007
4
Conventional PKI Approach
Purchasing (5)
System
(5) (4)
Archiving
(4)
Timestamp
(3) (5)
Cert,
(2) Revocation
(1) CRL.
Registration (2)
Cert.
PKI Certificate
Directory
Management
CRL.
(3)
8
NIST PKI Workshop – April 2007
DSS Server Based Solution
Purchasing
System
Internal user
Authentication &
authorisation
Revocation
Archiving
PKI Certificate Directory
Management
Trusted time Registration
9
NIST PKI Workshop – April 2007
5
OASIS Digital Signing Services
Networked web service protocol
Supports range of signature formats:
W3C XML Signature
Cryptographic Message Syntax (CMS - RFC 3852)
RFC 3161 / XML Time-stamps
Extended Formats
XML Advanced Electronic Signature
CML Advanced Electronic Signature
… extensible for other formats
Two basic operations:
Create signature
Verify signature
10
NIST PKI Workshop – April 2007
DSS Sign Protocol
(Signed document)
DSS-Sign request DSS-Sign response
(document) (Signed document)
Archive
DSS Server
11
NIST PKI Workshop – April 2007
6
DSS Verify
(Signed document)
DSS-Verify request DSS-Sign response
(Signed document) (OK)
Public Key Archive
Store / directory
12
NIST PKI Workshop – April 2007
DSS Specifications
DSS Core
General purpose tools for range of applications
Includes:
Sign request, Sign response
Verify request, Verify response
Optional inputs / outputs for handling common features of
CMS / XML Signatures
XML Signature Time-stamp Format
Document value / Document Hash / SOAP Attachment
Detached / Enveloped / Enveloping Signatures
Transport request / response
HTTP, SOAP
SSL, Web Security Services
13
NIST PKI Workshop – April 2007
7
DSS Profiles
XML Time-stamping
Entity seal
“Advanced” / Long term Electronic Signatures
(ETSI TS 101 733, TS 101 903, RFC 3126)
Code Signing
Electronic Post Mark
German Signature Law
Signature Gateway
14
NIST PKI Workshop – April 2007
DSS Signature Creation applied to eInvoicing
eInvoicing
Application
c
Jo In
Local authentication & 0
€10 .5
7
Access control + 1
VAT
DSS
Signing Server
15
NIST PKI Workshop – April 2007
8
DSS Signature Creation applied to eInvoicing
Authentication of user separated from management of signature key.
Hence:
Can apply controls on who may apply “corporate” signatures
Based on existing internal security controls using existing
authentication and authorisation controls within normal work flow
If user’s authorisation is revoked, organisation can stop use of
signature
Immediate
No need to publish external revocation
No need for special device on user system
Strict organisational controls can be applied to handling of signing key
Improved security & reduced per user cost
16
NIST PKI Workshop – April 2007
DSS Signature Verification applied to eInvoicing
eInvoicing
Application
c
Jo In
0
€10 .5
7
+ 1
VAT
DSS Audit log
Verification Server
17
NIST PKI Workshop – April 2007
9
DSS Signature Verification applied to eInvoicing
Support for later “re-verification” of signature
DSS Server can maintain audit log of verification information
(Cert, CRL/OCSP, verification time), or
Signature can be augmented to contain verification
information
All complexities of PKI hidden from user
18
NIST PKI Workshop – April 2007
DSS Implementation
Now fully ratified as OASIS Specification !!!
DSS “Style” of operation used for a number of years
Norwegian BankID
Thales SafeSign
Interoperability trials between several implementations
Adopted in Universal Postal Union
- Electronic Post Mark
Major conformant implementation being operated by
CATCERT for public agencies in Catalonya, Spain
19
NIST PKI Workshop – April 2007
10
Conclusions
Can provide improved security at reduced per user costs
By detaching individual user authentication from signing
function reduces need for revocation handling
Supports verification of signatures stored for up to about
10 years
A number of implementations appearing in 2007
Matches Corporate signing requirements of eInvoicing
Provides the power of PKI without headaches
20
NIST PKI Workshop – April 2007
Thank You
DSS Specification available at:
http://www.oasis-open.org/committees/dss/
Contact us at:
nick.pope@thales-esecurity.com
cruellas@ac.upc.edu
21
NIST PKI Workshop – April 2007
11
The Directory-Enabled PKI Appliance:
Digital Signatures Made Simple,
Approach and Real World Experience
Uri Resnitzky
Chief Scientist
Algorithmic Research (ARX)
uri@arx.com
http://www.arx.com
Abstract transitions from traditional pen and paper
solutions to efficient paperless processing
We present a novel approach for a systems, as well as the advent of regulatory
PKI based digital signature system for requirements in certain markets.
documents in an enterprise setting. A By and large traditional PKI has yet
centralized appliance securely stores users’ to deliver on its promise to fully answer
private signing keys. The appliance these requirements in the mass market.
interfaces with the existing enterprise Traditional PKI systems are based on
directory to automatically provision users’ distributing private keys to the end-users,
keys and certificates. Users authenticate to which aside of security concerns
the appliance using their existing directory [Marchesini], creates a high burden in
credentials in order to access their signing logistics, cost, help-desk support and user
keys. Client applications send document acceptance [Whitten] and also introduces
hash values to the appliance to be signed education obstacles [Nielsen]. Management
therefore the signing keys themselves never of a large distributed system of any kind is
leave the appliance. Streamlined user extremely hard and PKI is no exception.
interface methods enable easy acceptance by On the other hand, simplistic
users, while streamlined management approaches for non-standard electronic
enables minimal ongoing investment by IT signatures are increasingly being adopted
staff. Real world experience with the [Gartner]. These solutions range from so-
described system is presented and shows called click-wrap signatures and use of static
successful deployment in a variety of signature images to proprietary keyed hash
organizations and markets. solutions. For many organizations expedited
business processes, cost reduction and user-
1. Motivation and Related Work friendly systems – rather than the security
concerns of signer authenticity, data
In recent years the market demand integrity and non-repudiation – drive the
for electronic signature solutions in the decision to use electronic signatures
enterprise market has increased substantially [Gartner].
(Gartner estimated in July 2006 between 5 Unless low cost and easy to use and
to 20 percent current market penetration and manage PKI-based systems are developed,
less than 2 years for mainstream adaptation the electronic signature market in general
of electronic signatures. In July 2005 the will leave PKI technology behind, or at best,
estimate was 2-5 years [Gartner], while the PKI based systems will be deployed only by
2004 report did not even include electronic a relatively few enterprises that can afford
signatures). This is due to increasing the demanding costs.
Some related work aimed at making associate the digital signature with the
PKI systems easier to deploy and use has traditional pen-and-paper signature.
been presented in the past: A Plug and Play Minimize the overhead of PKI
approach to PKI [Gutmann], Password management by not assuming or requiring
Enabled PKI [Sandhu], Cryptographic that the administrator has background or
Mobility Solutions [Gupta], Hardware training in PKI. Such assumptions may be
secured Credential Repository [Lorch], incorrect, especially in small and medium-
Delegated Cryptography [Perrin] and putting sized businesses, and may lead to
CAs on the RA desk [Ellison]. deployment frustrations or increased
Specifically for digital signatures, manpower and training related costs. The
recent developments such as the OASIS administrator should not be required to
Digital Signature Service (DSS) perform ongoing PKI-related per-user or
specification draft [OASIS] [Pope] - a per-certificate management tasks. The
specification for digital signature processing system installation should be as painless as
by web services - and the support in Adobe possible with defaults that cover most
Acrobat 8.0 for so-called “Roaming deployment scenarios.
Credential” servers [Landwehr] shows some The provided system should contain
promise. all the required components. There should
We aim to make further advances in be no need for additional 3rd party
simplifying PKI deployments for digital components such as a CA service contract,
signature purposes in enterprises of any size. private key tokens, signature capture pads or
electronic signature software / plug-ins.
2. Design Criteria and Goals
3. Our Approach
Simplify the PKI problem domain by
concentrating on digital signatures only and Secure appliance with Central
on deployments characterized by a well- Storage of Signing Keys – The system is
known set of registered users defined in a based on a secure, centrally installed,
directory (such as applications for internal network-attached appliance that provides all
enterprise employees as well as some the required features and manages the
business to consumer scenarios). private signing keys and certificates. The
The system should be as transparent signing keys in this system are RSA [RSA]
and invisible to the end-user as possible in private keys with modulus size ranging from
order to increase user acceptance levels and 1024 to 4096 bits. The appliance meets the
reduce the need for training. There should be security requirements for Host Security
minimal or no direct end-user involvement Modules (HSMs) [FIPS140] and smartcards
in PKI-specific tasks (which may be difficult including a hardened operating system and
for end-users to perform) such as key tamper resistance. Signing keys and user
generation, certificate enrollment or certificates are stored in a database within
certificate renewal. The system should the appliance and are encrypted using a key
natively support file formats and which is erased upon physical tampering of
applications users are already familiar with. the appliance. Users can securely (see
Graphical User Interface (GUI) elements for “Application Integration” below) access
signing and verification should be their signing keys from whatever computer
simplified. Graphical signature images they are working on, but the signing keys
should be used to enable the user to themselves are never exposed outside the
appliance. In essence the secure repository existing authentication system in use by the
can be regarded as a multi-user network- organization is used to enable users’ access
attached smartcard. to their appliance stored signing keys. The
During a signature operation, once a user is prompted for their directory logon
user is authenticated (see the next section), credentials which are then transmitted
the document's hash value (i.e., the result of securely (see “Application Integration”
applying the SHA-1 [SHA1] cryptographic below) to the appliance. The appliance
hash function to the document's content) is verifies the credentials against the
sent to the appliance and is then signed organization’s existing directory servers
within the appliance using the user’s private using the LDAP [LDAP] protocol and grants
key according to the PKCS#1 [PKCS1] access to the appropriate signing key
specification. The resulting signature data is accordingly. Secure LDAP authentication
returned to the client and is used to build a methods (such as LDAP over Transport
Cryptographic Message Syntax [CMS] Layer Security [TLS] and digest
signature which is stored back into the authentication) are used so as not to expose
document. the user’s credentials on the organization’s
Kerberos
based SSO
Signature User
Login
End-User returned to Directory
auth.
application
+ auth. per
signature Keys and certs
lifecycle in sync
Document Hash with user
sent securely management
Appliance
Management
Console
User may register
graphical signature Built-in CA Private Keys Graphical
Repository Signatures
Figure 1: Architecture
The system provides a per-signature network. In essence this approach means
audit log. This enables an auditor to track that the signing key is viewed as a resource
each and every usage of any of the private on the enterprise network to which only the
signing keys contained within the appliance authorized owner has access. In cases where
including the date and time of signature, the single-sign-on to the directory is possible
name of the signer and the hash value (specifically when the appliance is installed
signed. within an existing Microsoft Active
Leverage existing enterprise Directory environment which uses the
authentication infrastructure – The pre- Kerberos protocol [Kerberos]), there is no
need to prompt the user for his credentials. email address), generates a new RSA
Instead the Kerberos protocol is performed private-public key pair and issues an X.509
such that the user’s identity is proven to the certificate using the built-in CA. The
appliance using tickets granted by the certificate is constructed using a built-in
directory server. template (which defines the value of
A policy setting, centrally enforced extensions such as the key usage) and
by the appliance, can be set to require users includes the subject’s common name and
to manually re-enter their credentials each email as retrieved from the directory. Note
time they want to sign. These prompt-for- that the administrator is not required to
sign credentials are then securely configure the above mentioned template,
transmitted to the appliance which validates rather it has default values which are
them using secure LDAP authentication designed to produce a certificate which can
methods with the directory server. In be used for as many purposes as possible
addition, the appliance can be configured to with the currently known PKI-aware
use the Remote Authentication Dial in User applications. The newly issued certificate is
Service [RADIUS] protocol in order to stored, along with the private key, in the
authenticate prompt-for-sign credentials internal database. The appliance
with an additional external authentication automatically refreshes soon-to-be-expired
server. This configuration is used to support user certificates for users who are still part
a variety of authentication schemes such as of the directory. When a change is made to
two-factor authentication using one-time the attributes of the user’s directory object
password devices. (e.g. an employee changing her surname),
Leverage existing enterprise the appliance retrieves the updated
directory and trust – User key generation, information, revokes the existing certificate
certificate enrollment, certificate renewal as and issues a new certificate for the user,
well as revocation is automated based on based on the updated information and the
data taken from and continuously existing private key. When an existing user
synchronized with the organization’s pre- is removed from the directory (in most cases
existing user directory. The appliance upon leaving the organization), the
includes a standalone built-in Certificate appliance revokes the user’s certificate from
Authority which is initialized during the CA and deletes the user’s records
appliance installation. The CA private RSA including the private signing key from the
key is stored in the secure internal database. internal database. This provides immediate
The CA root certificate is self-signed and revocation of the key material preventing
includes subject name attributes which are any risk of forged signatures and greatly
defined during appliance installation. The simplifying one of the major hurdles in
appliance uses the LDAP protocol to traditional distributed PKI namely the risk
periodically query the directory for users that compromised signing keys will continue
within a specific organizational unit (OU) to be used. All the directory-enabled
which are members of a specific user group. certificate management operations described
These OU and group names are defined above are performed transparently without
during appliance installation. Efficient query end-user involvement.
techniques are used to limit the load on the In essence this approach means that
directory server. When a new user is the directory administrator (usually working
detected the appliance retrieves the new with the HR department) serves as the
user’s information (common name and system’s RA. We rely on the fact that
organizations already have procedures and Word XP and above). In order to enable
mechanisms in place to validate and control legacy applications to produce digitally
the trusted creation, modification and signed documents, a printer driver (i.e., a
deletion of user objects and user attributes PDF distiller) is used that converts any data
such as name and email in the directory. printed to it from any application into a
Instead of the built-in CA, the signed-PDF document. Extensive use is
appliance can be configured to communicate made of the concept of Signature Fields
with an online CA service (using a which are visually distinct blocks added into
proprietary web based protocol). In this case the document which display the following
the same functionality is provided, with the data: signer’s graphical signature image,
difference being that the online CA enforces signer’s name (taken from the signer’s
its certificate policy by validating the certificate subject common name), signature
domain name used in the subject’s email date and time (in a variety of configurable
address as well as the organization name display formats), signature reason (if
attribute in the certificate request. The entered) and the signature validation mark
online CA’s policy delegates the verification which indicates the validity status of the
of end-user identities and management of digital signature.
the credentials used to access the signing
keys within the appliance to the customer
organization’s IT staff.
Publication into the directory of the
CA root certificate, the CRL and users’
certificates is also automatically and
continuously performed. This enables
smooth integration of PKI-aware directory
enabled applications. This feature also Figure 2: Signature Field Block
enables automatic distribution of the CA
root certificate into the trusted CA certificate Streamlined GUI - Users may
stores of all clients in the Microsoft Active optionally register their graphical signature
Directory domain, thus helping to automate image (sometimes referred to as ‘wet
trust in the CA root certificate within the signature’) using an electronic signature pad.
organization. The graphical signature image is securely
Signing Documents in Native Format stored within the appliance and is integrated
– The approach for producing signed into the signature block in native file
documents follows the most popular file signing. The combination of wet signature
formats users work with everyday: and digital signature provides a visual
Microsoft Word and Excel, Adobe PDF, indication that the user is accustomed to
TIFF and XML forms. Native file signing enabling easy adaptation of the system by
produces signed files which preserve the end-users. When using desktop applications
original file format and can be viewed by the to produce signed files, a streamlined user
native associated applications. Where interface is presented to the user. In most
possible, verification of the signature will be scenarios it is sufficient to place the cursor
done using built-in support within the native in the desired location or drag and mark an
PKI-aware application (for example the area on the document and then click a single
ubiquitous Adobe Reader, and the built-in button to sign. After the appliance
signature validation ability of Microsoft successfully generates the signature using
the user’s signing key, a signature field and high availability with data replication
block will be inserted into the document at between appliances secured using Internet
the specified location. Protocol Security [IPSEC]. The appliance’s
A signing ceremony is not required. clock can be synchronized with the directory
However it can be configured to include the or an external time server using the Network
optional elements of entering prompt-for- Time Protocol [NTP]. It is used to provide
sign credentials, and specifying a reason for the signature-timestamp authenticated
signing. Signing pre-existing empty attribute when building CMS signatures.
signature fields (inserted at design time into Application Integration – The
the document template or form) is similarly appliance integrates with the signing
easy. applications using either client-side
Users should be aware that the act of software, or using a web services interface.
signing a file does not prevent the file from The client software contains plug-ins
actually being modified either from within and applications to support native file
the native application (such as Word or signing. The client software communicates
Excel) or from the outside (using a hex with the appliance over a TLS secured
editor for example). However such channel using a proprietary protocol. It
modifications (and even ‘benign’ provides support for the standard
modification such as updating a date/time cryptographic APIs (Microsoft’s
field within a Word document) will result in Cryptography API [CAPI], RSA’s
signature validation failure. Dealing with PKCS#11 [PKCS11] and Sun’s JCA [JCA])
these issues of limiting modification access for seamless integration with PKI-aware
rights to signed documents is in the domain applications (such as Microsoft Outlook and
of document management and archiving Adobe Acrobat). The client software also
systems. includes Signature API [SAPI]. This easy to
Streamlined Management - use, high-level API is a wrapper over the
Management of the system requires minimal lower-level cryptographic APIs and is
attention from administrators and is limited intended to be used by applications that are
to system-wide tasks such as backup and not PKI-aware and do not or cannot
restore of the appliance's encrypted interface with the more complex
database, secure loading of digitally signed cryptographic APIs. SAPI is a native file
firmware updates, modification of system- format signature API supporting the concept
wide parameters and policy settings and of signature fields as well as graphic
download of audit logs. Management signature image handling. As an example,
functions are only allowed for authenticated SAPI can be used by a custom workflow
users that belong to a well-defined application to enumerate and validate all the
administrators group in the pre-existing signature fields in a document, and route or
organizational directory. Client software can process the document according to a
be centrally deployed and configured by business logic based on the number or
administrators. The client software detects identity of the persons which signed the
and automatically connects to the appliance. document.
This is achieved by searching the directory The appliance can be accessed
for an object created during appliance directly by applications using a web-services
installation which contains the appliance’s (WS) protocol. This protocol is a profile of
addressing information. Additional the latest draft of the OASIS DSS core
appliances can be added for load balancing protocol specification and implements the
full SAPI functionality direct from the as long as the user is still defined in the
appliance. When SAPI WS is used, no client directory, automatically refreshes them.
component is needed, the entire document to It may be reasonable under the
be signed is sent to the appliance and the described approach to issue a single very
signed document is returned. In some cases long lived CRL once at system installation,
(for example when signing PDF files) it is and then to issue very long lived certificates
possible to save bandwidth by returning only for each user instead of renewing them each
the portions of the file which include the year.
signature. The limitations and tradeoffs of our
Signature Specific Features –The approach include the need to be online when
system provides a rich set of functionality signing documents. This has to be weighed
specific to native digital-signature support against the resulting benefit of the
for popular file formats. Within Microsoft immediate revocation capability.
Word and Excel it is possible to add multiple Our system provides true user
signature fields in order to support multiple mobility which is independent on the
levels of approvals. It is possible to require installation of smartcard readers and does
dependence of signature fields in order to not use software keys that need to be
make sure that clearing a signature field will exported and imported to new machines. In
‘break’ the validity of dependent signatures. addition, the most insecure point in the
This supports hierarchical vs. side-by-side system, namely the end-user’s machine,
approvals. Sectional signing allows the user does not contain any sensitive cryptographic
to specify that only the content of a specific keys, even in encrypted form, at any point
cell-range or a document section is be during the use of the system. However the
signed. This has the advantage that other end-user’s machine is still vulnerable to
parts of the document can be updated or abuse by attacks which allow a capable
annotated within a workflow after the intruder to generate arbitrary signatures (but
application of a signature without not to duplicate the private signing key for
invalidation. The implementation uses these offline signatures). These same
signature field attributes to decide which vulnerabilities exist in any smartcard based
parts of the document content will be added PKI system.
to the hash value calculation. Our centralized approach may
present to a potential attacker an attractive
4. Discussion online target which, if successfully attacked,
can yield access to many users’ keys. This
Note that due to the immediate means that the physical and logical security
revocation feature mentioned earlier, of the appliance and its computing
publication of a CRL by the built-in CA is environment must be sufficiently high to
not really needed. However a CRL is still offset the risk. Further discussion on the
published in order not to adversely affect subject of the security risks of centralization
existing functionality in PKI-aware client can be found in [Schneier] and [Perrin]
applications (for example the Adobe Reader which also covers some other relevant
enforces revocation checking by default). criticisms.
Because a CRL is published, and in order to It should be noted that the system
limit its size, the built-in CA issues users described here is most suitable for internal
certificates valid for one year only and then, use within a single organization. This means
that relying parties trust issues are limited to
securely distributing the built-in CA’s root use the system to digitally sign (including a
certificate following appliance installation to graphical signature) transcribed medical
all machines within the organization. reports that are then electronically sent to
Existing IT management tools can easily patients’ primary care physicians. This
support automating this task. In the case the replaces the previously labor-intensive
online CA service is used, external trust is process of typing, printing, manually signing
automatically achieved due to the fact that and faxing reports. Following an exam, a
the online CA’s root certificate is already radiologist reviews a patient’s films and
built into most client platforms trusted other images, compares them with previous
certificate stores. studies if available, and dictates a report. An
In cases where relying parties exist on-site medical transcriptionist types the
outside the organization and the built-in CA report (typically in Microsoft Word) and
is used, the organization needs to publish its stores it in a secure internal database. The
built-in root CA certificate and relying radiologist can then retrieve the report to
parties must manually import it into their review and digitally sign as required.
trusted root stores. The system is delivered Regulations such as HIPAA dictate that
with a web site template to help IT staff healthcare organizations must implement a
setup a web page for easy download and system that ensures that electronic records
installation of their root CA certificate by and signatures are trustworthy, reliable and
outside relying parties. secure. Note that in this case the PKI
signature is used to maintain integrity within
5. Real World Experience the radiology center’s own electronic record
system. The electronically delivered reports
In this section we provide details of are not verified by the receiving primary
four real-world deployments of the system care physicians based on the digital
presented above. For each of these signature, but rather by viewing the
deployments we describe the target market, radiologist’s graphical signature image.
types of documents signed, and usage Transition to electronic signatures enabled
statistics. The statistics were collected from the center to reduce report turn-around time
the appliance audit logs, in each case from two or three hours to approximately
covering a period of at least 4 months of ten or fifteen minutes from dictation to
usage. The statistics include the number of electronic delivery. Labor costs decreased
actual signing users, the average and peak significantly and accounts receivable billing
number of total signatures per working day and reporting also improved. This
and the average and peak signature rate per deployment illustrates that the PKI system
user. We assume working weeks have 5 has practical value, even within very small
days of 8 hours each, and that each year has installations. The PKI system was installed
52 working weeks. Peek values are by the customer with phone support only.
measured over a full working week. Note that such small organizations do not
have significant in-house IT expertise. The
5.1 Radiology Center successful installations and use of the
system indicates that the goals of making a
This Missouri based center performs simple to manage and use PKI system were
a full range of outpatient diagnostic met.
radiology studies for approximately 300
referring physicians. The center’s physicians Industry Healthcare
Signing users 9
Average 95 smooth and was followed by quick user
signatures per acceptance reaching a usage level of over
working day
100 signatures per day in under 2 weeks.
Peak signatures 153
per working day
Average signature once every 45 working minutes Industry Engineering for Manufacturing
rate per user Signing users 98
Peak signature once every 5 working minutes Average 370
rate per user signatures per
working day
Peak signatures 676
5.2 Bus Manufacturer per working day
Average signature once every 2.1 working hours
This leading North American bus rate per user
manufacturing company employs about 100 Peak signature once every 6 working minutes
engineers which handle more than 200 rate per user
electronic change orders per week. The
company’s business is characterized by 5.3 Clinical Trials Management
intensive customizations which require just-
in-time design, engineering and This company is a leading clinical
manufacturing with a short lead time. technology services provider for the
Design engineers use CAD applications pharmaceutical industry, assisting drug
which render drawings in PDF format. Each manufacturers to setup systems to manage
PDF file is then digitally signed together clinical trials. All 600 employees in three
with the engineer’s professional stamp and world-wide locations are using the system to
graphical signature. Drawings are then sign large numbers of Word & PDF
electronically stored and managed by a documents. These documents (such as
Product Lifecycle Management (PLM) Standard Operating Procedures and Audit
system. Previously, each drawing was Reports) are needed to demonstrate that the
plotted on paper, signed by hand and then company’s systems and operations are
scanned (using a manual, expensive-to- validated and quality controlled. The
maintain scanner) back into electronic form company is required to meet stringent
to be stored in the PLM system. In some industry standards such as GxP and the FDA
cases physical transportation between Title 21 CFR Part 11 regulations for
facilities was required to achieve the manual electronic records and electronic signatures.
signing process. The biggest benefit of the These regulations aim to ensure the
installed system to the company is the accountability and data integrity of sensitive
process streamlining from design to internal documents when moving from
document control to production, saving a lot paper to electronic documents. The company
of time, eliminating manual phases and undergoes between 40–50 customer audits
increasing the productivity of the annually to verify its adherence to those
engineering workforce. While the standards. The rapid deployment of the
investment in the new system was justified digital-signature system and its ease of use
by the savings related to the scanning of and tight integration with the existing user
drawings alone, the company is now better directory allowed it to be quickly adopted by
suited to face its main challenge of high company employees. Installation was
throughput design / build-to-order. The achieved in a single day. Users were able to
installation of the PKI system, performed by start signing documents right away and the
local IT staff with phone support, was signatures offered a look and feel that
emulated the traditional 'wet-signatures' rate per user
people were comfortable with. To meet
specific requirements in the FDA's Title 21 5.4 Analytical Laboratory
CFR Part 11, users are required to enter both
user name and password each time they This company is one of the largest
want to sign and in addition add their reason privately owned analytical laboratory
for signing. In some locations the system network in North America. Their diverse
was implemented using a thin client range of high-quality analytical testing and
approach – the end users remotely login into consultation expertise support numerous
a Citrix server located at the HQ data center industries including environmental sciences
and sign documents directly on the HQ (water, air, soil, waste and toxicity testing),
network. As a result of the deployment the petroleum testing and field sampling
approval process for new SOPs was services, food safety (food chemistry and
expedited from 2 weeks to less than an hour. nutritional labeling, veterinary drug residues
In the past, getting signatures from 3 people and inspection), and forensics (human drug
in 3 different offices around the world and alcohol testing, DNA, paternity and
required the use of fax and courier services genetic identification). Approximately 100
which are no longer needed. Electronically project managers (located in 15 different
signing documents also reduced the need for labs) are using the system to electronically
every document to be printed, filed, sign Laboratory Information Management
microfilmed and archived. Lost or misfiled System (LIMS) reports and Certificates of
documents are no longer a problem, saving Authority in PDF, Word and Excel formats.
the company considerable time and money. The labs have over 1,500,000 samples tested
The physical archive was replaced with an every year in a wide spectrum of
electronic document repository. Signed applications. With the digital signatures
documents can be viewed and validated for system implemented, signed reports can be
long periods into the future as the validation submitted to clients as soon as the results are
uses the time when the signature was made available in a compliant manner and as
(and not the current time) when computing electronic evidence in a court of law.
the validity of the signer’s certificates. Previously the lab employees had to print,
However, we recognize that this does not hand sign, fax, mail and archive hard copy
address long term archival and documents associated with the paper-based
cryptographic issues related to encryption processes. The labs increased their
algorithm aging, new analytical attacks competitive advantage by decreasing the
being discovered, or evolution of storage time it takes to submit reports to clients
technologies etc, which are outside the (from 1-3 business days with a paper
scope of our work. process to immediately available using an
electronic process). The lab is using dual
Industry Life-Sciences appliances in high availability configuration.
Signing users 520 In addition, SAPI was used to directly
Average 72 integrate report file signing into their LIMS
signatures per
working day
system. Since signed documents need to be
Peak signatures 133 validated outside the organization, the lab
per working day had set up their system so that the CRL is
Average signature once every 3.5 working days published to an externally accessible web
rate per user address (instead to the default location on
Peak signature once every 56 working minutes their internal directory). The lab’s root CA
certificate was also published to an of electronically-signed documents. We
externally accessible web address along with have shown how this approach is
instructions to clients on how to install this successfully deployed in the field by diverse
certificate in their local trusted root organizations. We believe that wide spread
certificates store. It should be noted that use of PKI for electronic signatures is at
since reports in this system are securely hand using the approach outlined here and
delivered to clients using a web portal, the that every effort should be made to continue
lab’s clients themselves are not necessarily to bridge the gap between PKI technology
concerned with validating the signatures. and the mass market.
However the lab needs to protect itself from
a scenario in which external parties may 7. Acknowledgements
want to change a report to suit their needs.
In this case the ability for stand-alone Thanks are due to David Chadwick and the
verification of a signed document outside of anonymous referees for their thoughtful
the lab’s system is important for dispute comments and the patient support received
resolution. while drafting this paper.
Industry Sciences 8. References
Signing users 110
Average 1180 [CAPI] R. Coleridge, “The
signatures per
working day Cryptography API, or How to Keep a
Peak signatures 1400 Secret”, http://msdn2.microsoft.com/en-
per working day us/library/ms867086.aspx, August 1996.
Average signature once every 45 working minutes
rate per user [CMS] R. Housley, “Cryptographic
Peak signature once every 5 working minutes
rate per user
Message Syntax”, IETF RFC 3852,
http://www.ietf.org/rfc/rfc3852.txt, July
5.5 Environmental Impact 2004.
We calculate the weight of paper [Ellison] C. Ellison, “Improvements on
saved on a yearly basis in the above four Conventional PKI Wisdom”, Proceedings of
deployments assuming each signature saves the 1st Annual PKI Research Workshop, pp.
the printing of one standard letter-size sheet 165-176, August 2002.
of paper. This results in an annual saving of
4480 lb (2030 kg) of paper. [FIPS140] National Institute of
Please note that the cost saving Standards and Technology (NIST), “FIPS
associated with the paper alone is very small Publication 140-2: Security Requirements
compared with the other savings and for Cryptographic Modules”,
benefits introduced with the digital signature http://csrc.nist.gov/publications/fips/fips140-
system. 2/fips1402.pdf, May 2001.
6. Conclusions and Further Work [Gartner] V. Wheatman et al, “Hype
Cycle for Information Security”, Gartner
In this paper we have presented a RAS Core Research Note G00139428
market-driven approach that enables the use http://www.gartner.com/DisplayDocument?
of PKI technology for driving the adoption doc_cd=139428, July 2006.
International Symposium on Cluster
[Gupta] S. Gupta, “Security Computing and the Grid, pp. 640-647, April
Characteristics of Cryptographic Mobility 2004.
Solutions”, Proceedings of the 1st Annual
PKI Research Workshop, pp. 117-126, [Marchesini] J. Marchesini, S.W. Smith,
August 2002. M. Zhao, “Keyjacking: Risks of the Current
Client-side Infrastructure”, Proceedings of
[Gutmann] P. Gutmann, “Plug-and-Play the 2nd Annual PKI Research Workshop,
PKI: A PKI your Mother can Use”, pp. 128-144, April 2003.
Proceedings of the 12th USENIX Security
Symposium, pp. 45-58, August 2003. [Nielsen] R. Nielsen, “Observations
from the Deployment of a Large Scale PKI”,
[IPSEC] S. Kent and R. Atkinson, Proceedings of the 4th Annual PKI Research
“Security Architecture for the Internet Workshop, pp. 159-165, August 2005.
Protocol”, IETF RFC 2401,
http://www.ietf.org/rfc/rfc2401.txt, [NTP] D. L. Mills, “Network Time
November 1998. Protocol”, IETF RFC 1305,
http://www.ietf.org/rfc/rfc1305.txt, March
[JCA] Sun Microsystems, Inc., 1992.
“Java Cryptography Architecture, API
Specification & Reference”, [OASIS] S. Drees et al, “Digital
http://java.sun.com/j2se/1.4.2/docs/guide/sec Signature Service Core Protocols, Elements,
urity/CryptoSpec.html, August 2002. and Bindings”, OASIS Digital Signature
Services Technical Committee Draft,
[Kerberos] Microsoft Corp., “Windows http://docs.oasis-open.org/dss/v1.0/oasis-
2000 Kerberos Authentication”, dss-1.0-core-spec-cd-r5.pdf, August 2006.
http://www.microsoft.com/technet/prodtech
nol/windows2000serv/deploy/confeat/kerber [PKCS1] RSA Laboratories, “PKCS #1
os.mspx v.21: RSA Cryptography Standard”,
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-
[Landwehr] J. Landwehr, “Making digital 1/pkcs-1v2-1.pdf, June 2002.
signatures easier to use and deploy with
roaming credentials”, Adobe Security [PKCS11] RSA Laboratories, “PKCS
Matters Blog, #11 v2.20: Cryptographic Token Interface
http://blogs.adobe.com/security/2006/09/ma Standard”,
king_digital_signatures_easi.html, ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-
September 2006. 11/v2-20/pkcs-11v2-20.pdf, June 2004.
[LDAP] K. Zeilenga, “Lightweight [Perrin] T. Perrin, L. Bruns, J. Moreh
Directory Access Protocol”, IETF RFC and T. Olkin, “Delegated Cryptography,
4510, http://www.ietf.org/rfc/rfc4510.txt, Online Trusted Third Parties, and PKI”,
June 2006. Proceedings of the 1st Annual PKI Research
Workshop, pp. 97-116, August 2002.
[Lorch] M. Lorch, J. Basney and D.
Kafura, “A Hardware-secured Credential [Pope] N. Pope, J. C. Cruellas,
Repository for Grid PKIs”, 4th IEEE/ACM "Oasis Digital Signature Services: Digital
Signing without the Headaches," IEEE Evaluation of PGP 5.0”, Proceedings of the
Internet Computing, vol. 10, no. 5, pp. 81- 8th USENIX Security Symposium, pp. 169-
84, September/October 2006. 184, August 1999.
[RADIUS] C. Rigney et al, “Remote
Authentication Dial In User Service”, IETF
RFC 2865,
http://www.ietf.org/rfc/rfc2865.txt, June
2000.
[RSA] R.L. Rivest, A. Shamir and L.
Adleman, “A method for obtaining digital
signatures and public-key cryptosystems”,
Communications of the ACM, vol. 21, no. 2,
pp. 120-126, February 1978.
[SAPI] ARX, “SAPI Signature API
Programmer’s Guide Version 4.1”, Pub. No.
CSN.SAPI.V32.1206, Available on request
from info@arx.com, December 2006.
[Sandhu] R. Sandhu, M Bellare and R.
Ganesan, “Password-Enabled PKI: Virtual
Smartcards versus Virtual Soft Tokens”,
Proceedings of the 1st Annual PKI Research
Workshop, pp. 89-96, August 2002.
[Schneier] B. Schneier, “Security Risks
of Centralization”, Crypto-Gram,
http://www.schneier.com/crypto-gram-
0403.html#11, March 2004.
[SHA1] National Institute of
Standards and Technology (NIST), “FIPS
Publication 180-1: Secure Hash Standard”,
http://www.itl.nist.gov/fipspubs/fip180-
1.htm, April 1995.
[TLS] T. Dierks and E. Rescorla,
“The Transport Layer Security (TLS)
Protocol”, IETF RFC 4346,
http://www.ietf.org/rfc/rfc4346.txt, April
2006.
[Whitten] A. Whitten and J.D. Tygar,
“Why Johnny Can’t Encrypt: A Usability
The Directory-Enabled PKI Appliance:
Digital Signatures Made Simple,
Approach and Real World Experience
6th Annual PKI R&D Workshop
NIST, Gaithersburg MD, USA
April 17th 2007
Uri Resnitzky, Chief Scientist,
Algorithmic Research (ARX)
The Directory-Enabled PKI Appliance, 6th Annual PKI R&D Workshop, April 17th 2007
Agenda
Motivation & related work
E-Signature Market Trends
» Security is NOT the main driver for Adoption
» Why Worry?
Our Aim
What to do?
Design criteria and goals
Approach
Appliance
Authentication
Architecture Diagram
Provisioning
End user experience
Administrator experience
Developer experience
Discussion
Real world experience
Radiology Center
Bus Manufacturer
Clinical Trials Management
Analytical Laboratory
Conclusion
Q&A
The Directory-Enabled PKI Appliance, 6th Annual PKI R&D Workshop, April 17th 2007
E-Signature Market Trends
“…the adoption of electronic signatures is no
longer a question of if but a question of when…”
(Gartner, 2006)
The Directory-Enabled PKI Appliance, 6th Annual PKI R&D Workshop, April 17th 2007
Security is NOT the main driver for Adoption
“Recognize that for many organizations and for many applications,
speedy processing, saved money, user-friendly input screens, and
competitive advantage - rather than security concerns - drive the
decision to use e-signatures. Also recognize that less technically
complex electronic signatures may be best rather than complicated
digital signatures that require key management in order to work.”
-- (Gartner Group)
The Directory-Enabled PKI Appliance, 6th Annual PKI R&D Workshop, April 17th 2007
Why Worry?
PKI is loosing ground to
simplistic approaches, i.e.,
Security Placebos like:
Click-wrap signatures
Image capture
Closed systems
etc.
The Directory-Enabled PKI Appliance, 6th Annual PKI R&D Workshop, April 17th 2007
Our Aim
Lets make Electronic
Signatures the ‘killer app’ for
PKI
Recent related work:
OASIS: Digital Signature
Services (DSS) v1.0 approved
as OASIS standard
SAFE-BioPharma
Association: Hosted
Certificates
Adobe Acrobt 8.0: Roaming
IDs
The Directory-Enabled PKI Appliance, 6th Annual PKI R&D Workshop, April 17th 2007
What to do?
Simplify PKI deployment to
drive digital-signature adoption within
enterprises of ANY and ALL sizes.
The Directory-Enabled PKI Appliance, 6th Annual PKI R&D Workshop, April 17th 2007
Design Criteria
Application (Digital Signature) driven PKI - versus
Infrastructure for everything
DoD CAC lessons (Nielsen 2005):
» “The return on investment in PKI does not become measurable until
applications have started to use the technology”
» “[We need to] provide users with new capabilities that help them to get their
jobs done, not just PKI certificates”
Philosophy
Leverage existing technology, procedures, trust, security
Separate authentication from PKI
Enterprise setting – well known users managed in a directory, no
need to re-invent the identity proofing process nor user-enrollment
system
The Directory-Enabled PKI Appliance, 6th Annual PKI R&D Workshop, April 17th 2007
Design Criteria (cont’d)
Transparent to end users
No user involvement for enrollment / renewal
Natively support file formats and application people use everyday
Traditional “wet signatures” look and feel
Minimal management
Require no PKI knowledge from IT manager
No per-user / per-cert management activities
Easy installation with defaults
All-in-one solution
Include CA services
No need for 3rd party tokens
Include client side application software as well as backend
Include ePads where required
The Directory-Enabled PKI Appliance, 6th Annual PKI R&D Workshop, April 17th 2007
Appliance
Secure appliance with central storage of keys
Multi-user network-attached smartcard
Signing keys never exposed outside the appliance
HSM level of security (tamper resistance)
Encrypted internal database (keys, certs, images)
Sign where-ever you are (secure connection)
Connect → authenticate → send hash → receive PKCS1 signature
Immediate revocation!
Central audit log!
HA/LB secured using IPSEC
The Directory-Enabled PKI Appliance, 6th Annual PKI R&D Workshop, April 17th 2007
Authentication
Leverage existing authentication to control access to key
Directory credentials to login (SSO where avail.)
Verified securely at back end (secure LDAP)
‘Prompt for sign’ policy
‘Extra’ authentication using RADIUS for OTP
Other authentication types…
The Directory-Enabled PKI Appliance, 6th Annual PKI R&D Workshop, April 17th 2007
Architecture
Kerberos
based SSO
Login User
End-User auth. Directory
ba Sign
ck at + auth. per
to ure signature
ap
Do pli sen Keys and certs
cu ca t lifecycle in sync
se m tio
nt en n with user
se t H
cu a management
re sh
ly
Appliance
Management
Console
User may register
graphical signature
Private Keys Graphical Administrator
Built-in CA
Repository Signatures
The Directory-Enabled PKI Appliance, 6th Annual PKI R&D Workshop, April 17th 2007
Provisioning
Directory driven provisioning and trust
100% automated: keygen / cert issue, revoke, renew, update
Built-in standalone CA or online Webtrusted CA service
Online CA CPS: http://www.arx.com/documents/cps.php
Use OU and group to specify relevant users
Mapping of directory user object attributes to cert attributes
Common-name, email, template
IT admin is the RA - HR actions automatically reflected in PKI
We trust existing HR/IT management procedures (vetting, etc.)
Directory trust: distribution of root CA cert and CRL
AIA and CDP attributes
Automatic enterprise trust
The Directory-Enabled PKI Appliance, 6th Annual PKI R&D Workshop, April 17th 2007
End user view
Native file signing
Embed signature field / block into document
Sign within your favorite app
View & verify with pre-existing software
Sign any file format
» Printer driver, works via any application's File → Print
» Documents converted to PDF
» User reviews document and graphically signs
Streamlined GUI
Single click to sign
Wet signature
Signature specific features
Multiple
Dependant
Sectional
The Directory-Enabled PKI Appliance, 6th Annual PKI R&D Workshop, April 17th 2007
Administrator view
Streamlined administration
System wide tasks only
Download audit log, restart, policy settings, etc
Directory group membership defines admin rights
Time sync from domain / NTP server
Document signature time always taken from appliance with time
zone from client
Easy deployment of client software
Client software auto detects appliances
The Directory-Enabled PKI Appliance, 6th Annual PKI R&D Workshop, April 17th 2007
Developer view
Application integration
Client side standard crypto APIs: PKCS11, MS CAPI, JCA
SAPI – Signature API
Digital signature API versus Cryptographic API
Functionality includes:
» Native file format signing
» Signature fields (create, sign, clear, remove, enumerate, verify)
» Graphic signature image handling
Workflow example: enumerate and validate all signature fields in a
document, route according to number / identity of signers
Server side: SAPI Web Services – a profile of OASIS DSS
Client-less document signatures via a web application based on SAPI /
SAPI-WS
See demo including document preview and interactive signature placement
at: http://cosignet.com
The Directory-Enabled PKI Appliance, 6th Annual PKI R&D Workshop, April 17th 2007
Discussion
CRL
CRL publication done in order not to break some pre-existing client applications
(Acrobat default)
To limit CRL size users certificates valid for one year and automatically refreshed
Reasonable alternative - issue an empty long lived CRL at system installation, then
issue long lived users certificates without automatic renewal
Limitation: need to be online when signing documents. Resulting benefit:
immediate revocation capability
True user mobility (no smartcard readers / drivers, no software keys)
Security
End-user’s machine does not contain any long term secrets, however if static
authentication is used, client is still vulnerable to attack in the same manner as any
smartcard solution
Centralized approach presents an attractive online target → physical / logical security
of appliance and environment must be sufficiently high to offset the risk
System is most suitable for internal use within a single organization to
minimize relying parties trust issues (mitigated when the online CA service is
used)
The Directory-Enabled PKI Appliance, 6th Annual PKI R&D Workshop, April 17th 2007
Real world experience
Four real-world deployments in each describing the target
market, types of documents signed, and usage statistics.
Statistics collected from appliance audit logs covering a few
months of usage.
Assume working week = 5 days x 8 hours and 52 working weeks /
year.
Peek values measured over a full working week.
Environmental Impact
Weight of paper saved per year assuming one letter-size sheet
saved per signature: 4480 lb (2030 kg)
Paper cost saving is small compared with the other benefits
The Directory-Enabled PKI Appliance, 6th Annual PKI R&D Workshop, April 17th 2007
Radiology Center
Provides full range of diagnostic Industry Healthcare
radiology services for approx. 300
referring physicians Signing users 9
Radiologists digitally sign transcribed
dictated Word format medical reports Average 95
PKI signature used to maintain
integrity within the center’s own signatures per
electronic record system due to working day
regulations (HIPAA)
Reports verified by viewing signature Peak signatures 153
image per working day
Paperless transition:
Reduced dictation to electronic
delivery turn-around time from 2-3
hours to 10-15 minutes Average Once every 45
Labor costs decreased and accounts signature rate working minutes
receivables improved
Illustrates PKI system has practical per user
value even within very small
installations: Peak signature Once every 5
Installed by customer with phone rate per user working minute
support
No significant in-house IT expertise
The Directory-Enabled PKI Appliance, 6th Annual PKI R&D Workshop, April 17th 2007
Bus Manufacturer
Leading North American bus Industry Engineering for
manufacturer - 100 engineers - 200 Manufacturing
ECOs/week - just-in-time design,
engineering and manufacturing Signing users 98
CAD applications → PDF drawings
→ digitally signed with engineer’s Average 370
professional stamp and graphical signatures per
signature → electronically stored
and managed by PLM system
working day
Previously: drawing plotted on Peak signatures 676
paper → hand signed & stamped → per working day
scanned → stored in PLM system
Investment justified by savings
related to scanning alone; the Average Once every 2.1
“gravy”: increased productivity of signature rate working hours
engineers
per user
Smooth system installation
performed by local IT with phone Peak signature Once every 6
support; quick user acceptance: rate per user working minutes
reaching over 100 signatures per
day in under 2 weeks
The Directory-Enabled PKI Appliance, 6th Annual PKI R&D Workshop, April 17th 2007
Clinical Trials Management
Leading clinical technology services provider for
pharmaceutical industry - clinical trials Industry Life-Sciences
management systems
600 employees in 3 world-
world-wide locations sign Signing users 520
SOPs and Audit Reports in Word & PDF format
GxP,
GxP, FDA 21 CFR Part 11 - demonstrate systems
and operations are validated and quality Average 72
controlled with accountability and data integrity -
40–
40–50 customer audits annually signatures per
Rapid deployment, ease of use, look and feel that
emulated traditional 'wet-
'wet-signatures' and tight
working day
integration with existing user directory → quick
adoption by users Peak signatures 133
Single day installation → users were able to start
signing documents right away per working day
21 CFR Part 11 → user name / password and
reason required for each signature
Approval for new SOPs expedited from 2 weeks →
less than an hour (previously 3 people in 3 Average Once every 3.5
locations signed using fax and courier)
Electronic signature reduced the need for
signature rate working days
printing, filing, microfilm and archive → lost / per user
misfiled documents no longer a problem
Physical archive replaced with an electronic Peak signature Once every 56
document repository
rate per user working minutes
The Directory-Enabled PKI Appliance, 6th Annual PKI R&D Workshop, April 17th 2007
Analytical Laboratory
One of the largest privately owned Industry Sciences
analytical lab network in North
America. Over 1,500,000 samples Signing users 110
tested per year (environment,
petroleum, food, veterinary, Average 1180
forensics) signatures per
100 project managers in 15 working day
locations electronically sign LIMS
reports and CoA’s in PDF, Word and Peak signatures 1400
Excel formats per working day
Signed reports submitted to clients
immediately (previously paper
based process took 1-3 days) Average Once every 45
Using dual appliances in high signature rate working minutes
availability / DR configuration per user
SAPI used to directly integrate
report signing into LIMS Peak signature Once every 5
Stand-alone verification of a signed rate per user working minutes
document outside lab
The Directory-Enabled PKI Appliance, 6th Annual PKI R&D Workshop, April 17th 2007
Conclusion
A market-centric approach is enabling the use of PKI and
driving the adoption of electronically-signed documents
Successfully deployed in the field by diverse organizations
Wide spread use of PKI for electronic signatures is at hand
using this approach
Every effort should be made to continue to bridge the gap
between PKI technology and the mass market
The Directory-Enabled PKI Appliance, 6th Annual PKI R&D Workshop, April 17th 2007
Q&A
Uri Resnitzky
Chief Scientist, ARX
uri@arx.com
www.arx.com
The Directory-Enabled PKI Appliance, 6th Annual PKI R&D Workshop, April 17th 2007
A New Paradigm in PKI Architecture:
OTPK Technology
For Online Digital Signature
Data Security Systems Solutions Pte Ltd
teikguan@dsssasia.com
efroni@datasecurity3.com
http://www.dsssasia.com
In this paper, we present a paradigm shift in PKI architectures. The OTPK concept
is alarmingly simple to understand. Whenever a digital signature is required, the
private key is generated, certified, used to compute the digital signature and
immediately deleted. All that remains is the digital signature and the public key
certificate from the Certification Authority (CA) that is used to verify the digital
signature. There is no possible compromise on the private key, no need for user
smart cards/USB tokens, no need for CRLs, no need for LDAP directories, no need
for OCSP. It is compliant to international digital signature laws. The OTPK
technology should be evaluated as a new and cost effective solution for on-line
digital signature providing full mobility for mass usage of the public in different
industries. It should be evaluated for this perspective, not from a CA perspective.
1 Introduction integrity. But as of today, a full PKI solution
for applications such as retail internet
banking for banks that have a few millions
The growth of on-line activities strongly
of users have not been successfully
depends on the reliability and availability of
deployed. This is because the cost of
the service. The recent attacks on the on-line
deployment is huge, the key management is
services such as phishing, man-in-the-
troublesome, annual renewal of certificates
middle and others have forced us to react.
and the operation of CA is a ‘big headache’.
To meet the needs, a strong two-factor
But, can we simplify the process to take the
authentication has been introduced and
advantages of the non-repudiation by means
become increasingly popular. In Singapore
of digital signature? DSSS introduces a new
and Hong Kong, it is already mandatory to
concept with the OTPK.
use two-factor authentication in finance
sectors. In USA, two-factor authentication
The objective of this document is
solutions were recommended last year.
not to introduce a new CA technology. The
Subsequently, many organizations have
aim of the paper is to introduce a new flow
been moving to a strong two-factor
to implement digital signature, based on the
authentication using different solutions, for
recent endorsement of strong user
example, tokens, Vasco, RSA, Verisign,
authentication, to deliver an On-Line Digital
Active Card and many others. In addition,
Signature with full mobility that will make
software tokens such as the OATH tokens, a
the digital signature affordable to all internet
Java midlet on mobile devices, SMS, scratch
and intranet users.
card, biometrics have been deployed to
protect online applications against the
hackers who try to steal users’ identities and
make use of them. 2 About OTPK
It is well known that PKI 2.1 Background of OTPK
authentication and PKI digital signatures
provide the best security for on-line The OTPK technology relies upon
activities for authentication and data using a strong authentication infrastructure
(e.g. OTP token authentication) to provide transaction to the security accorded to the
the functionality of on-line digital signature. protection of the entities’ private keys. Each
entity’s private keys need sufficient
As for today, the use of asymmetric protection to ensure that the keys are always
cryptographic keys to carry out data security in the possession and control of the rightful
functions such as digital signatures is owners and cannot be stolen or duplicated.
becoming prevalent. Many countries Smart cards (or USB tokens) are commonly
including USA, European countries, used, as the medium, to protect private keys.
Australia, Japan, Hong Kong and Singapore But smartcards or USB tokens introduce
have passed some forms of legislation to additional problems of costs and logistics.
recognize PKI, thus, to legalize the use of The cost of a large PKI rollout using smart
digital signatures as equivalent to hand- cards (taking into account of the cards,
written signatures in contracts, transactions, personalization, certification, etc) has been
etc. The applications that can use digital estimated at about US$100 per user. This
signatures range from a paperless-office to estimation is extremely prohibitive for a
high-value B-to-B transactions over the regular day-to-day PKI usage and probably
Internet to high-security health-care has been one of the most widely quoted
information systems. reasons for the apparent slow adoption rate
of PKI in most of the countries worldwide.
In a PKI, all communicating In contrast, the total cost for a recent
entities 1 or users rely on a trusted body, Internet Banking Security 2-factor
typically a trusted-third-party, to perform the authentication implementation using Vasco
necessary validations on the identity. This OTP tokens that we deployed for 1 million
trusted-third-party, known as the users was less than US$18 per user.
Certification Authority (CA), will issue
(directly or indirectly via a Registration This paper, presents a revolutionary
Authority) to each of the participating method to implement and deploy PKI,
entities, a digital certificate containing ensuring the same, if not higher, level of
information about the entity such as the integrity and non-repudiation of the
name, organization, country, the policies transactions, and yet not needing to incur the
governing the use of the certificate and, costs and logistics involved in deploying
most importantly, the entity’s public key. smart card solutions to apply to the digital
The certificate asserts that the entity is the signature law. We predict that this is the
rightful and sole owner (and user) of a secret catalyst that the PKI boom has been waiting
private key with which the public key is for.
associated. If there are asymmetric
cryptographic operations, such as a digital
signature which is carried out using the 2.2 The Concept of OTPK
particular private key, it can only be carried
out by this certified entity and easily verified The main concept behind OTPK is
using the entity’s public key published in the that the private key is a “One-Time Private
digital certificate and up the certificate chain Key” that works in connection with a short
to the trusted key by CA. time certificate and is used for digital
signature only to secure on-line transactions.
Naturally, we can equate the As it is, OTPK cannot be used effectively
integrity and non-repudiation of the for data encryption and user authentication.
1
There are essentially four steps that
An entity here is used loosely in this paper to are carried out for each OTPK digital
represent a machine, a user, a group of users, an signature:
organization, a country, etc.
i. Generate the asymmetric key even as a zero-install Java applet embedded
ii. Send the public key for certification within the web browser.
with the CA. At this step, OTPK
relies on some form of
authentication (strong 2-factor 3 Related Work
authentication is recommended)
with the CA
There have been many attempts to
iii. Receive the certificate and sign the
address the cost and logistics problems, each
transaction
with varying degrees of success. Among all
iv. Delete the private key.
the attempts, perhaps the most widely
deployed solution is the Microsoft CSP
The validity of PKI certificate in
(Cryptographic Service Provider) [1] that is
this case need only be an extremely short
installed with the Windows Operating
term (in the order of minutes or seconds) to
System. The Microsoft CSP is implemented
remove any chances of compromise. Since
as a software-token that operates as if it is a
OTPK would result in a one-to-one mapping
smart card and would perform the
between the certificate and the transaction to
cryptographic functions of digital signing,
be signed, details of the transaction can even
encryption, key storage, etc. Access to the
be embedded in the certificate request for
CSP can be protected by a password. The
time stamping purposes.
obvious problem behind the Microsoft CSP
and all software tokens per se is that the
In a typical PKI system, the user
private keys are typically stored in local
does a one-time generation and registration,
hard disk storage which opens the chance
and stores the certified key in a smartcard
for hackers to make duplicated keys.
(or USB token) for a longer period of use.
In contrast, the private key in the OTPK
A HSM (Hardware Security
system is for one-time use only. A user
Module) is a widely deployed solution, too.
always generates a new private key and
While HSMs have traditionally been used as
authenticates securely with the CA in order
a host-attached appliance to carry out
to get a digital certificate for every
cryptographic operations for the host, many
transaction. Once the private key is used, it
commercial HSM vendors, such as Eracom
is expired and erased. There is no need to
[2], nCipher [3], SafeNet [4] and Thales [5]
permanently store the private key in any
have implemented HSM devices that
media. Such a process sounds cumbersome;
communicate via network and, hence, can
however, the overheads are actually not
support multiple client/user connectivity.
much more than any mobile credential
The network-attached HSM could, thus,
solution.
function as a pseudo smart card for each of
the entities connected on the network and
The setup of OTPK requires the CA
would be responsible for the cryptographic
to have an online authentication and
storage and operations. However, the legal
certification facility to fulfill all certification
definitions of PKI may be violated, as the
requests at a much higher throughput than
private key would not be technically in the
existing setups of PKI. The entity could
possession of the entity and the digital
require a plug-in, implemented entirely in
signature is carried out on behalf of the
software to generate the private key, send
entity.
the public key for certification, perform the
digital signature operation, and delete the
Another alternative that can be seen
private key securely. The plug-in can be
to address the problem is the Keon Web
implemented as a PKCS#11, CAPI DLL or
Passport solution [6] by RSA Security, Inc.
Keon Web is a “virtual” smart card
implementation which relies on a backend This represents very significant savings in
server to secure and store private keys. terms of costs, resources and time overheads
When the entity requires the private keys, in implementing and maintaining a PKI
the keys can be downloaded securely to the system.
entity’s machine for usage, but it is still not
foolproof. Backups in the backend server
mean that multiple copies of the private keys 4.2 Much Smaller Window of
exist. Moreover, the private keys are not Compromise
always in the physical possession of the
entity. This is a point of contention with In the OTPK system, the duration of
some of the legal definitions [7, 8, 9] of a validity of the private key and certificate is
trusted and reliable PKI. extremely short. Also, by tying the
certificate request to the content of the
The Cosign [11] by Algorithmic transaction and by adding time stamp we
Research Ltd is a very good example of a reduce misuse of the signing key. Typically
full digital signature solution. Cosign is the private key is used to generate only one
mainly designed to support the enterprise or a few digital signatures for its lifetime.
that have a central user management like Moreover, the private key is erased after
Microsoft Active Directory and strip most of use. The combination of short duration, the
the management issues. But again, the lack of substantial signature data and
signing keys are stored in the server and the absence of any key storage makes the OTPK
server signs on behalf of the user. system more difficult to compromise.
In the market, there are solutions
that use on-line remote registration to 4.3 No Need for Large LDAP
acquire PKI credential including MyProxi,
Systems
Kx509, Kerberized-CA and MyCA, to name
a few. For authentication purposes, these
solutions acquire long term or short term In a typical PKI system, the CA,
certificates and store them in either the after issuing the user’s certificate, would
server or client machine or other external publish the certificate with a LDAP system.
storage device like smartcards. But they do This is to allow other participating entities to
not provide support for a short time retrieve the certificate for verification
certificate for digital signature. purposes. Such LDAP systems have to be
able to handle large amounts of load in order
to support the verification process. In the
OTPK system, since each certificate has
4 OTPK vs PKI small and limited time validity, the use of
the LDAP for storing and publishing the
The advantages of OTPK over the entities’ certificates is not feasible. Instead,
existing PKI systems include: the OTPK protocol would require that the
certificate be attached with the digital
signature in the transaction, for validation
4.1 No Need for Smart Cards for purposes only.
Entities
In the OTPK system, since the 4.4 No Need to Maintain CRL or
entities’ private keys are generated prior to a OCSP for User Certificates
transaction and discarded after use, there is
no need for traditional smart cards (or USB
tokens) to store and protect the private keys.
In a typical PKI system, a CRL with the media such as a smartcard that
(Certificate Revocation List) and/or OCSP contains the private key. Authentication to
(Online Certificate Status Protocol) the media is usually static PIN-based, as it is
mechanism has to be in place to maintain the the media that enforces the authentication. If
up-to-date status of the certificates. If a user the protection of the media requires more
has lost the private key, the corresponding complicated or stronger authentication, a lot
certificate should be revoked and listed in of more complexity will have to be built into
the CRL. By doing so, the corresponding the media, resulting in higher costs.
entities do not rely on the certificate from Moreover, not all media can support all
that point onwards. However, the CRL and forms of strong authentication.
OCSP mechanisms add significant
overheads to the entire PKI process. In the In the OTPK system, only one point
OTPK system, the CRL and OCSP are no of authentication (with the CA) is needed. It
longer relevant because the private keys and is carried out when a private key needs to be
certificates have limited time exposure and used. Since the authentication can be
would not be compromised. centralized to a CA or a collection of CAs,
there is economy of scale in implementing a
strong authentication (such as 2-factor,
4.5 Lower Learning Curve biometric etc) to the CA and the cost can be
shared across a large pool of entities. There
One of the problems with existing is also no constraint on the media. This
PKI implementations is the need to educate makes it easier to integrate a strong
and re-educate the users. Most users find authentication mechanism into the OTPK
PKI rather confusing with the need to system.
understand how to use smart cards including
installing smart card readers, entering pins, However, we do recognize that there
changing the pins on a regular basis, how to are limitations to the implementation of the
use certificates, and what to do when the 2-factor or biometric authentication to the
certificates expire, etc. Educating users takes CA. For example, while OTP tokens are
up significant time, costs and resources. For suitable for Internet-based transactions,
the OTPK system, all the confusing remote authentication over Internet using
cryptographic technology and PKI protocols biometrics is inherently insecure, and
are abstracted from the users. Instead, the subject to replay attacks. On the other hand,
users will need to use a more familiar 2- using biometrics within a controlled office
factor OTP authentication to approve the or a Kiosk environment for paperless e-
transaction. The complexity of the Document systems is more convenient as
certificates and digital signature is either compared to the OTP tokens. These
made redundant by the OTPK design or considerations will have to be taken into
handled easily by the client plugin’s account when designing the OTPK
interaction with the CA. deployment.
We envision several scenarios
4.6 Easy Interface into 2- where OTPK can be deployed:
Factor/Biometric and Other
Authentication Solutions • Internet Transactions.
A merchant operates an Internet trading
portal which requires the user to
In a typical PKI system, there exists digitally sign transactions to signify
two points of authentication. One is with the approval. Users will login to the portal
CA for issuing an initial certificate which is using a browser. In such case, the
carried out once in a long time. The other is
OTPK client is a Java-Applet that is issuing a prescription, the doctor will
dynamically downloaded within the enter the OTP from the token to the e-
browser and users can be issued an OTP prescription application which will
hardware token (e.g. Vasco or RSA generate the one-time-use key and
SecurID) to authenticate with an authenticate to the OTPK CA for the
Internet-based online CA for OTPK certificate before submitting the
certificates. prescription and signature to the health-
care e-prescription system.
• Enterprise eDocument
A large enterprise operates an electronic
document system to digitize the entire 4.7 Private Key Always in the
business workflow for processing Possession of Users
efficiency and regulatory compliance.
The application requires Microsoft Many of the legislation regarding
Office and Adobe Acrobat documents to Digital Signatures and PKI explicitly require
be digitally signed during the creation that the user’s private keys be always in the
and approval process. For this scenario, possession and control of the user [7, 8, and
the OTPK client can be in the form of a 9]. Such requirements imply that some of
pre-installed CSP (Cryptographic the mobile credential solutions would not be
Service Provider) DLL, and users can recognized as compliant to the Act. The
use UserID-Password, or Active- OTPK system relies on a client plug-in to
Directory authentication to authenticate generate and temporarily store the private
to the enterprise OTPK CA for OTPK key for the short duration that the Private
certificates. Biometrics, in the form of Key is used. In the entire process, the private
hand-written signatures, can also be key remains in the possession and control of
used as the authentication means to the the user.
OTPK CA.
• Banking Kiosk 4.8 Protocol Is Interchangeable for
A bank operates an ATM (auto-teller All Asymmetric Algorithms
machine) network and requires the use
of digital signatures for high-value
transfers. The ATM can be deployed The OTPK system does not
with finger-vein or palm-vein biometrics differentiate between different asymmetric
to serve as a stronger form of algorithms and allows for entities using
authentication. In this case, the end-user different asymmetric algorithms (e.g. RSA,
can use biometrics to authenticate to the DSA, ECDSA, etc) to participate within the
OTPK CA (via the bank’s internal ATM same PKI. This means that one user can use
network) to get the certificate. RSA to perform digital signatures while
another user can use ECDSA. Since the CA
handles the certification collectively at the
• Mobile phone
point of performing the digital signature, the
A healthcare provider operates an e-
OTPK solution is flexible enough to allow
prescription system that allows doctors
different entities using different algorithms
to issue patient prescriptions
to participate together. For example, the
electronically. All prescriptions need to
same user may use RSA in one country and
be digitally signed. In this scenario, the
ECDSA in another country depending on the
doctor’s mobile phone can be installed
electronic regulations and laws governing
with an e-prescription application with
the countries.
OTPK capability. Doctors can be issued
with a hardware OTP token. When
Also, in the event that an algorithm 4.10 Efficient and Effective Business
is deemed undesirable, due to whatsoever and Pricing Model for CA
reason such as cryptographically broken,
insufficient key length, licensing, poor In the typical PKI, the CA charges
performance, platform constraints, etc, the on per-certificate basis. However, since the
user can easily use a different algorithm or private key to the certificate can be used to
key length without affecting all the other sign many transactions, the CA charges a
participating entities. The CA may also significant amount of money per certificate.
seamlessly migrate entities from using one Such a pricing model does not efficiently
algorithm to another without affecting the charge according to the actual usage since a
PKI or the PKI operations. user that uses the private key regularly
versus another user that uses the private key
This flexibility allows different rarely are charged the same amount.
entities to use different applications. It also
allows entities with certain platforms and In the OTPK system, since the
restricted type of algorithms to participate in certificates are issued each time a private
the system. Finally, it allows entities that are key is used, the CA can charge a much
unable (or not allowed) to use certain types smaller amount for each certification. Such a
of algorithms or certain key lengths to pricing model will mean that entities that
participate in the PKI. Such flexibility is use the private key more often will incur
currently not practical within the existing more charges, and vice versa. This results in
PKI system. a fairer and more acceptable pricing model.
It also allows CAs to price the certificates
and services differently for different
4.9 Solution Is Very Scalable applications such as (but not limited to) the
following:
Since most of the cryptographic
load (i.e. Key generation, etc) is actually Mode - online certification versus batch
carried out at the user end, the load on the certification are priced differently
CA is only the cost of 1 asymmetric key Timing - certification requests during
signing operation per transaction. Each peak hours will incur higher charges
signing operation is also stateless, meaning Loyalty - the more certificates are
that multiple CAs performing the OTPK requested, the cheaper the cost of each
certification need not synchronize the keys certificate
or certificates with each other. Branding - different classes of certificate
with different certification policy are
From an operational perspective, the priced differently
OTPK solution can be easily scaled up to Algorithm - certificates for different
handle larger volumes by adding more algorithms are priced differently.
points of presence of the certification and Insurance - price of certificate includes
authentication servers. The implementation insurance on the transaction that is tied
can rely on a certification chain, leading up to the certificate
to the root CA, where sub-CAs that operate Duration - one-time use versus per-
the certification and authentication servers session use certificates cost differently
can perform the user certification on behalf
of the root CA. These sub CAs spread out A further advantage is that the
the certification load and do not compromise OTPK certificates can integrate
the overall security of the OTPK solution. transparently with current PKIs. Relying
party software that can process traditional
PKI certificates can also process OTPK
certificates, barring a possible X.509
extension indicating that status information • Stolen CA Key
is not published. An existing CA can The use of a high-level FIPS-certified
choose to issue both traditional PKI as well HSM (at least Level 3) will mitigate
as OTPK certificates and allow both systems this risk by making it impractical to
to interoperate, ensuring the maximum extract the private key.
flexibility for the CA to adjust the business
model. • Fake certificate requests
All OTPK certificate requests come
embedded with the authentication
5 Addressing OTPK Issues credentials of the user. The
authentication credentials can be in
While OTPK is able to solve some of the form of a one-time-password from
the very key issues (e.g. logistics, costs, the user’s token. This allows the CA
compliance to laws) plaguing traditional to verify the user before issuing the
PKI setups, OTPK introduces a number of certificate.
new issues that have to be addressed in order
to make OTPK a viable digital signature The process of verifying the
solution. authentication credentials + certifying
the key should be done in one atomic
step within the HSM to ensure that a
5.1 Online CA key compromised system is unable to
illegally send certification requests to
the HSM. By insisting on the use of
The most distinct difference in the strong authentication + HSM with
backend setup of a traditional PKI CA OTPK, we are able to mitigate this
versus an OTPK CA is the use of the CA exposure.
Key, or the key that is used to certify the
certificates.
5.2 User Registration
For the OTPK CA, the CA Key has to
be accessible online as the certification
requests are expected to be fulfilled in real- Another difference is in the user
time. The entire certification process is registration process. In the traditional PKI
expected to be carried out within a couple of CA, the user registers with the CA once to
seconds to ensure that the transaction generate the user’s private key, and get the
approval process is not delayed. In contrast, public key certified by the CA. During the
the CA Key in traditional PKIs need not be registration process, one key step is that the
online as the certification process may take CA would verify the credentials of the user.
up to 48 hours to allow for manual processes Once done, the user is free to use the private
to be carried out. The concern here is if the key without needing to contact the CA.
security of the CA Key is compromised in
any way by making the key online, versus For OTPK, this registration process
using some physical means to ensure that seems to be missing while the certification
the key is not accessible on the Internet. process is repeated each time the user needs
to sign a document or transaction. However,
We argue here that while the concerns, we need to clarify here that the registration
on the surface, seem to point to a more process did happen. If we are to extrapolate
vulnerable CA, having an online CA Key backwards to the point in time when the user
does not lower the security of the PKI setup. was first assigned the authentication token
This is because: (assuming a one-time-password token), this
was when the registration process actually requirements for key deletion is not as
took place. As for the repeated certification pronounced.
processes, it is simply equivalent to the user
authenticating to the CA and obtaining For OTPK certificates, a new key is
services from the CA. used for each digital signature which may
result in hundreds (or even thousands) of
keys used by a user in a year. This gives a
5.3 Secure Time-stamping hacker potentially more chances to obtain a
user’s private key, albeit with an expired
Current time-stamping (or electronic certificate.
notary) solutions rely on a central time-
stamping server that essentially signs on the For OTPK, we are able to address the
hash of the transaction and include a time- problem in two ways: directly and
stamp with the transaction [15]. This is an indirectly. In the direct approach, we have
issue that is relevant even for traditional PKI to ensure that the private key is deleted as
digital signature implementations which designed. This can be achieved by
typically rely on the user’s PC date/time for implementing the key deletion process in the
the time stamp. How can we prove that the OTPK client as part of the atomic function
user signed the transaction at a particular of the signing process (i.e. Generate Key-
time? Get certificate-Sign-Delete Key), and
ensuring that this process cannot be
For OTPK, the solution is rather modified through secure programming
apparent. This can be done by simply techniques as well as sending the OTPK
allowing the CA to also function as the client for FIPS-140 certification. We
secure time-stamping service. When the recognize that this method is not foolproof
user generates the certificate request, the standalone and is vulnerable to a crafty
hash of the transaction to be signed is also signer who fully intends to cheat the system.
embedded as part of the certificate request,
along with the authentication credentials. In the indirect approach, we have to
This allows the CA to issue the short-lived make sure that the private key cannot be
OTPK certificate of the user key, and with a used for any other transaction. This can be
reliable time-stamp on the hash value (e.g. implemented similarly to the secure time-
as one of the X.509 extensions) back to the stamping in Section 5.3. Since the
user. This certificate can thus be used as the certificate and key is directly tagged with
proof for the time-stamp. the transaction, using the private key to sign
a different transaction would result in a
signature validation failure.
5.4 Secure Private Key deletion
The issue for private key deletion 6 Conclusion
comes in when the certificate has expired,
and we do not want the private key to be The OTPK technology is bringing
used for any other purposes (since it is no up a new concept in which a user will
longer valid). For traditional PKI setups generate a signing key with an extremely
where the private key is securely stored in a short lived certificate to perform the digital
smartcard or USB token, the destruction of signature. The PCT (Patent Cooperation
the private key is more visible, and since Treaty) has defined the OTPK as ‘novel and
certificate expiries do not happen as often innovative’ [14]. The key of the
(typically only once a year or once in 3 innovativeness is that the OTPK technology
years) as OTPK certificates, the allows an implemention of on-line digital
signature system that complies to the digital [5] Thales e-Security. http://www.thales-
signature law with full mobility and low cost esecurity.com
of ownership. The entity is generating the
signing key and owns it during the whole [6] RSA Keon Web PassPort. http://www.
process of “Key Generation” “Certification” rsasecurity.com/node.asp?id=1230
“Signing” and after signing deleting the
Signing key. It could be regarded as a new [7] Electronic Transaction Act 1998,
paradigm in the “PKI” technology that Singapore, Part IX – Duties of
allows the population of the digital signature Subscribers, Clause 39.
to many vertical markets. http://www.ida.gov.sg/idaweb/pnr/info
page.jsp?infopagecategory=regulation:
To put things in perspective, we pnr&infopageid=I1944&versionid=1
have benchmarked a Java applet OTPK
implementation which uses RSA-1024 keys [8] Utah Digital Signature Act, Part 3.
on an IE browser. The time taken for the Duties of certification authority and
key generation + certificate request + digital subscriber, Utah Code 46-3-303.
signing takes less than 7 seconds on a http://www.jus.unitn.it/
Pentium 3 machine and less than 2 seconds users/pascuzzi/privcomp97-
on a Pentium 4 machine. For the mobile 98/documento/ firma/utah/udsa-3.html
phone, a J2ME OTPK application using
ECDSA-P192 averages between 3 to 10 [9] Georgia Digital Signature Act. Section
seconds on various mobile phones. 1, Article 3, Clause 10-12-33,
Subscriber’s Warranties
DSSS is currently implementing
OTPK protocol and proof of concept into [10] Peter Gutmann, “Plug-and-Play PKI: A
the DSSS Authentication Server for demo PKI your Mother can Use”, Usenix
purpose only. It is planned to be further Security Symposium, 2003
enhanced with XKMS and WS-Security. http://www.cs.auckland.ac.nz/~pgut001
(The OTPK is patent-pending USPTO /pubs/usenix03.pdf
60/590,348)
[11] Algorithmic Research Cosign –
www.arx.com
References
[12] AlphaTrust PRONTO™ Server-
[1] Microsoft Platform SDK: http://www.alphatrust.com/
Cryptography.
http://msdn.microsoft.com/library/en- [13] Deepnet Technology Smart ID VSC
us/seccrypto/security/microsoft_crypto http://www.deepnettechnologies.com/
graphic_service_providers.asp
[14] PCT Review, PCT/SG2005/000226
[2] Eracom Technologies.
http://www.eracom-tech.com
[15] RSA Security, “What is digital
[3] nCipher Corporation Ltd. http://www. timestamping ?”.
ncipher.com http://www.rsasecurity.com/rsalabs/nod
e.asp?id=2347
[4] SafeNet Inc. http://www.safenet-
inc.com
OTPK Technology for Online
Digital Signature
Apr 2007
Data Security Systems Solutions
www.datasecurity3.com
Presentation Agenda
The presentation will cover
Background
Traditional PKI – What are the issued faced ?
Alternative technology
Introduction to OTPK
Comparing OTPK vs PKI
Issues surrounding OTPK
Demo
Future of OTPK
2 Copyright © DSSS 2007. All rights reserved
Background
Traditional PKI
Application Server
1. Please Sign
Transaction
User
4. Digital
Signature 5. OCSP / CRL
lookup
3. Time-Stamp
transaction
Time-stamp Server
2. Insert card / token
and enter pin. Digital Issue Certificate
signature created
Certificate Authority (CA) /
Registration Authority (RA)
3 Copyright © DSSS 2007. All rights reserved
Background
Problems with Traditional PKI
Cost of issuance
Cost of Smartcard / USB Token
Card personalization
Cost of deployment > $100 per user
Massive Logistics
Helpdesk support
Cost of Certificates
High upfront and recurrent certificates
Lack of mobility
Client installation
4 Copyright © DSSS 2007. All rights reserved
Background
Existing solutions
Microsoft CSP
Microsoft CSP exists in all machines using Windows OS.
Addresses cost of issuance and cost of deployment
Introduces problem: key stored in software makes it easy for hackers to
steal
HSM-backend signing / Virtual smartcard
Solutions on SafeNet, nCipher, Thales HSM to implement a “smartcard on
the network” which hosts and signs transactions on behalf of user
Solutions by RSA Keon, ARX CoSign extend the HSM-signing solution to
implement a PKCS#11/CAPI layer to communicate seamlessly with the
HSM to sign the transactions.
Addresses cost of issuance and cost of deployment + keeping key secure
Introduces problem: Signing key not in possession of user. Not in
accordance with legislation
5 Copyright © DSSS 2007. All rights reserved
Background
Motivation for new solution – Addressing the problems
Addressing cost of issuance and deployment
Can we remove the prohibitive cost of PKI without compromising on the
legality of the digital signatures ?
Cost of 2-factor authentication (2FA)
The use of OTP (One-time password) for 2FA is growing very significantly.
Already, countries in Singapore and Hong Kong require 2FA for Internet Banking
The cost of deploying 2FA using OTP works out to less than $20 per user.
Addressing cost of certificates
Cost of certificates is not aligned to cost of business / transactions. Can we
reduce the upfront certificate costs ?
Need for Mobile PKI
Can users perform digital signatures on mobile phones ?
6 Copyright © DSSS 2007. All rights reserved
Introducing OTPK
OTPK is NOT a new PKI platform.
It is about making PKI
Easier to use
Cheaper to implement & deploy
Faster to adopt
7 Copyright © DSSS 2007. All rights reserved
Introducing OTPK
Basis
One-time use, short-lived certificate
Each time a signature is needed, the key is generated, certified, used to
sign the transaction, and then deleted
Key always remains in client possession throughout the short lifetime,
and never stored on a permanent basis.
Main security lies in the online certification process where the user
would use strong (2-factor) authentication to the CA/RA.
Compatible to existing PKI application architectures
In its current form, only usable for authentication and digital signatures.
8 Copyright © DSSS 2007. All rights reserved
Introducing OTPK
2 Phases
Registration
User is issued a 2FA OTP token, e.g. RSA SecurID, VASCO, Aladdin.
Alternative forms of 2FA such as software tokens on J2ME phones, OTP
sent through SMS, email, etc can be considered but will impact security.
Face to face verification, if required, will take place at this stage.
The 2FA OTP token will allow the user to authenticate to the CA/RA during
the online certification process.
Biometric authentication can be utilized under circumstances where remote
biometric authentication is secure. i.e. OTPK is not restricted to 2FA OTP,
although authentication credentials should be time-bound to ensure
freshness of certificate request.
Signing
9 Copyright © DSSS 2007. All rights reserved
Introducing OTPK
2 Phases (con’t)
Signing
When a digital signature (an asymmetric decrypt operation) on a transaction is
required, the user has to download an OTPK module.
OTPK module will
Generate public-private key pair.
Prompt the user to provide the 2FA OTP credentials
Embed the 2FA OTP credential and transaction hash (for time-stamping) within certificate
request.
Certificate request is end-to-end encrypted for the CA/RA
Certificate request is sent to CA/RA
CA/RA verifies 2FA OTP credentials, and issues short term (e.g. 5 min) certificate.
Certificate contains transaction hash for time-stamping purpose
OTPK module will return the digital signature of transaction and delete the private
key.
User now has the certificate and signature, without private key.
10 Copyright © DSSS 2007. All rights reserved
Introducing OTPK
OTPK PKI
Application Server
1. Please Sign
Transaction
User
4. Digital
Signature 5. OCSP / CRL lookup
(is it needed) ?
3. Certificate
request
Online CA / RA
2. Download OTPK
module and enter
2FA details.
Generate Certificate Issue Authentication token
request and digital
Certificate Authority (CA)
signature
11 Copyright © DSSS 2007. All rights reserved
Comparing OTPK with PKI
The advantages of OTPK over Traditional PKI are:
No need for smartcards for users
Lower cost of issuance from smartcard to OTP levels
Much smaller window of compromise
Private Key is now valid for only short time (e.g. 5 minutes) as compared to 1-3 years.
No need for large LDAP systems
Strong of OTPK certificates in LDAP is no feasible. Instead, certificate should be
attached with signature.
No CRLs or OCSP for certificates
Short certificate lifetime ensures CRLs/OCSPs not relevant.
Low learning curve
All complexities abstracted for users to presenting 2FA OTP.
12 Copyright © DSSS 2007. All rights reserved
Comparing OTPK with PKI
The advantages of OTPK over Traditional PKI are: (cont’)
Easy Interface into 2FA / Biometric authentication
Traditional PKI has 2 different points of authentication – point of issuance & point of
signing. Only single point of authentication exists for OTPK
Private Key always in possession of user
As compared to software / HSM alternatives. OTPK is closer to the PKI legislation
around the world.
Protocol is interchangeable for all asymmetric algorithms
OTPK can be used for RSA, DSA, ECDSA. If algorithm is not suitable e.g. broken,
insufficient key length, licensing, platform incompatibility, it can be changed quickly
by replacing the OTPK module. This contrasts with a total recall smartcards/tokens
which is highly infeasible.
Solution is very scalable
OTPK Backend handles only 1 asymmetric operation (key certification). This can be
spread over several sub-CAs in a horizontal scaling infrastructure.
13 Copyright © DSSS 2007. All rights reserved
Comparing OTPK with PKI
The advantages of OTPK over Traditional PKI are: (cont’)
Efficient Pricing model for CA
Since each certificate is tied to a transaction, CAs can charge on a pay-per-use basis.
Differentiation can be :
Mode – online vs batch processing, per transaction or per authentication session
Timing – peak hour vs off-peak hours
Loyalty – more usage => cheaper certificates
Branding – Different classes of certificates
Algorithm – Different pricing for different certificates
Level of Insurance / liability
OTPK certificates can be supported on applications that are expecting traditional PKI
certificates since OTPK also uses X.509 certificates, barring a possible X.509
extension indicating that status information is not published.
CAs can support both traditional and OTPK PKI and allow both systems to
interoperate.
14 Copyright © DSSS 2007. All rights reserved
Issues surrounding OTPK
Issues surrounding OTPK
Online CA Key
As compared to traditional PKI, the OTPK CA key is online and certificates
are issued in real-time.
Mitigating controls:
Stolen CA Key - Use of FIPS certified HSM to house CA key
Fake certificate requests – Use of strong 2FA with end-to-end encryption for
certificate requests.
User Registration
In traditional PKI, key is generated once during the registration process.
The registration process may require a face-to-face verification.
In OTPK PKI, the authentication token is issued during the registration
process. The face-to-face verification step is complied with.
15 Copyright © DSSS 2007. All rights reserved
Issues surrounding OTPK
Issues surrounding OTPK (con’t)
Secure Time-stamping
Time stamping is a deliberate process in traditional PKI where the user or
server will send the hash for time-stamping.
For OTPK, the transaction hash should be included in the certificate request
so that the CA can also provide time-stamping services at no extra procesing
costs.
Secure Private key deletion
The deletion of the key, when the certificate has expired is important. For
traditional PKI, proof of private key destruction can be the destruction of the
smartcard / token.
For OTPK, besides using properly designed software with FIPS certification,
the indirect way is to ensure that the key cannot be used for any other
operation. This is similar to the Secure Time-stamping approach where the
transaction hash is included in the certificate, ensuring that improper use will
result in a signature verification failure.
16 Copyright © DSSS 2007. All rights reserved
Demo
Internet
Signing a transaction using a browser
Intranet
Using Microsoft CSP with OTPK
Mobile
Digital signatures on a mobile phone.
http://www.demo.com/demonstrators/demo2006fall/79808.php
17 Copyright © DSSS 2007. All rights reserved
To be discussed
Strong authentication
While we have advocated the use of hardware OTP tokens for user
authentication in OTPK, the use of very simple and inexpensive 2-factor
authentication solutions such as challenge-response “bingo cards” can be used.
While it may make OTPK more compelling, what is its implication with the
legality of digital signatures ?
CAs issuing more certificates
In OTPK, the CAs will potentially issue certificates at much higher volume and
speed. Is the CA infrastructure at risk ?
Interoperating traditional PKI with OTPK PKI
Does it make sense to CAs ?
Can we simply introduce new extensions to make traditional PKI operate with
OTPK PKI ? What else is needed ?
18 Copyright © DSSS 2007. All rights reserved
Future of OTPK
DSSS is planning the following:
Building an OTPK toolkit with HSM providers
Operating OTPK pilots in various industries including:
Government
Banking
Internet transactions
Healthcare
Build an OTPK-adoption community.
All support welcome. Email: teikguan@dsssasia.com
19 Copyright © DSSS 2007. All rights reserved
Thank you
Data Security Systems Solutions
Website: http://www.datasecurity3.com
Zvi EFRONI
410 Park Avenue, 15th Floor
New York, NY 10022, USA
Mobile: +1-408-8344430
efroni@datasecurity3.com
TAN Teik Guan
371 Beach Road, #17-08
Keypoint, Singapore 199597
Mobile: +65 97469386 Fax: +65 62956778
Teikguan@dsssasia.com
20 Copyright © DSSS 2007. All rights reserved
Security Identity in
the Mortgage Industry
NIST PKI R&D Workshop
April 17, 2007
Panelist
» Yuriy Dzambasow
» Principal
» A&N Associates
» Francois Leblanc
» Director of Professional Services
» Silanis Technology
» Jim Bacchus
» CEO
» Digital Presence (National Notary Association)
eMortgage Process Flow
Legal eDocs
(Land records,
tax liens, other eRecording Servicing
External
docs/affidavits
Docs
)
eOrigination Secondary
eDoc
& eClosing Investor,
Prep
Underwriting Aggregator
eDocuments
eSignature
s
Service eNotarizatio
Ordering: n eVault eVault
Credit
Flood Buyer Seller
Hazard eNote Data, Messaging & Control
Title
MI MERS® eRegistry
(National eNote Registry)
Legislation & Regulations
» Gramm-Leach-Bliley (GLB) Act (Section
501)
» PATRIOT Act (Section 326)
» State Identity Thefts Legislation
» International
» FFIEC High Risk Transaction Guidance
» Federal Trade Commission (FTC)
» eSign (Federal) & UETA (46 State)
Secure Identity Services
Accreditation Corporation
NIST PKI R&D Workshop
April 17, 2007
Overview of SISAC
• Wholly-owned subsidiary of the Mortgage
Bankers Association (MBA)
• Responsible for defining and maintaining
interoperable policy, technical and accreditation
requirements for issuing and managing digital
certificates to be used in support of electronic
mortgage processes and applications
• More information can be found at www.sisac.org
2
SISAC Model – Accreditation
6. Audit
Letter SISAC
7. Accredit
3. Accredit
2. Apply 4. Apply
1. Requirements
Accredited
Accredited 5. Audit
Issuing
Auditors Authorities
(AIAs)
8. Credential Reliance
Relying Relying
Parties Parties
3
SISAC Model – Operations
SISAC Accreditation, Policy and Technical Requirements
AIA1 (Approved AIA2 (Approved AIAn (Approved
CPS, Root Key and CPS, Root Key and CPS, Root Key and
Policy IDs) Policy IDs) Policy IDs)
Issuance, Issuance, Issuance,
Management & Management & Management &
Validation Services Validation Services Validation Services
Certs Certs Certs
Validation Services Validation Services Validation Services
Relying Relying Relying
Subscribers Subscribers Subscribers
Parties Parties Parties
4
Assurance Levels
Parameter Basic Medium High Device
Identity Proofing •On-line or in-person •In-person •In-person •Org. verification
•Org. verification if •Org. verification if •Org. verification if •Administrator
affiliation required affiliation required affiliation required verification
•Org. certs allowed •Org certs allowed •Org. certs not allowed •PoP verification
•Domain name
verification
Initial Credential User provided User provided Out-of-band Out-of-band
Activation PIN/password PIN/password
Token Authentication Single Factor Single Factor Multiple Factor Multiple Factor
Private Key Storage No stipulation FIPS 140-2 Level 1 FIPS 140-2 Level 2 FIPS 140-2 Level 2
(Hardware) (Software or
Hardware)
AIA Insurance $1M Aggregate $5M Aggregate $10M Aggregate $50K / certificate
Credential Revocation Within 24 hours Within 12 hours Within 6 hours Within 24 hours
Public Key Size 1024 (minimum) 1024 (minimum) 1024 (minimum) 1024 bit (minimum)
5
SISAC Subscriber Certificate Taxonomy
Subscriber
Certificates
Individual Organizational
Certificates Certificates
w/ no
w/ Organizational
Organizational Group Certificates Device Certificates
Affiliation
Affiliation
6
CA Certificate Profile
• Non-critical authorityKeyIdentifier
• Non-critical subjectKeyIdentifier
• Critical basicConstraints with cA=TRUE
• Non-critical keyUsage with keyCertSign and
cRLSign asserted
• Non-critical certificatePolicies with SISAC
approved policy OID asserted
• Non-critical cRLDistributionPoints containing
location of CRL information
• Non-critical authorityInfoAccess containing
location of OCSP Responder
7
User Certificate Profile
• Non-critical authorityKeyIdentifier (must be same as
subjectKeyIdentifier defined in CA Certificate for CA that
issued this Device Certificate)
• Non-critical subjectKeyIdentifier
• Non-critical keyUsage with appropriate key usage bits
asserted (except for keyCertSign and cRLSign, which
are reserved for CA Certificates only)
• Non-critical certificatePolicies with SISAC approved
policy OID asserted
• Non-critical cRLDistributionPoints containing location of
CRL information
• Non-critical authorityInfoAccess containing location of
OCSP Responder
8
Device Certificate Profile
• Non-critical authorityKeyIdentifier (must be same as
subjectKeyIdentifier defined in CA Certificate for CA that issued this
Device Certificate)
• Non-critical subjectKeyIdentifier
• Non-critical keyUsage with appropriate usage asserted (except for
keyCertSign and cRLSign, which are reserved for CA Certificates
only)
• Non-critical extendedKeyUsage with appropriate usage asserted
based on device application (e.g., SSL); must adhere to
extendedKeyUsage OIDs defined in RFC 3280
• Non-critical certificatePolicies with SISAC approved policy OID
asserted
• Non-critical cRLDistributionPoints containing location of CRL
information
• Non-critical authorityInfoAccess containing location of OCSP
Responder
9
Issues and Lessons Learned
• Key generation tags need to match with certificate profile keyUsage
extension
• Interest in carrying static attribute information
– Considering optional, non-critical private extensions that are application
specific (e.g., notary)
• Certificate renewal notices need to go out before certificates expire
• Interest in defining software vs. hardware token at the Medium
Assurance level
– Will probably follow what FPKI did
• Staying consistent with the FPKI/FPBCA policies has helped greatly
– Parts of the mortgage industry exist in Government
• Applications driving use of certificates
– Electronic notary services
– MERS Registry
– Electronic closing and recording (coming…)
10
PKI in eMortgages
(eClosing and eVaulting)
We make paperless happen™
NIST PKI R&D Workshop
April 17 2007
PKI in eMortgages
Context: from eClosing to eSecuritization
eClosing: eSignature platform
MERS: Mortgage Electronic Registration System
MERS eRegistry
Communication with the MERS eRegistry
We make paperless happen™
© Silanis 2007 – Proprietary & Confidential – Under NDA Only 2
Context: from eClosing to eSecuritization
We make paperless happen™
© Silanis 2007 – Proprietary & Confidential – Under NDA Only 3
eClosing: eSignature Platform
Several documents to present & capture intent to sign
Buyers & sellers: use system’s private key
Notary: use notary’s private key (and seal image)
Promissory note uses SMART Document format
SMART Document is XML file: use XML Dig Sig
standard
We make paperless happen™
© Silanis 2007 – Proprietary & Confidential – Under NDA Only 4
SMART Document Basics
SMART stands for Securable, Manageable,
Archivable, Retrievable, and Transferable
XML document
Re-uses existing standards whereever possible,
including
– XML (eXtensible Markup Language)
– XHTML (eXtensible HyperText Markup Language)
– XML Digital Signatures
– XPath
– XLink
We make paperless happen™
© Silanis 2007 – Proprietary & Confidential – Under NDA Only 5
SMART Doc Structure: Framework
…
…
…
…
We make paperless happen™
© Silanis 2007 – Proprietary & Confidential – Under NDA Only 6
SMART Doc Structure: Framework
We make paperless happen™
© Silanis 2007 – Proprietary & Confidential – Under NDA Only 7
SMART Doc Structure: HEADER
We make paperless happen™
© Silanis 2007 – Proprietary & Confidential – Under NDA Only 8
SMART Doc Structure: HEADER
We make paperless happen™
© Silanis 2007 – Proprietary & Confidential – Under NDA Only 9
SMART Doc Structure: HEADER
We make paperless happen™
© Silanis 2007 – Proprietary & Confidential – Under NDA Only 10
SMART Doc Structure: SIGNATURE_MODEL
We make paperless happen™
© Silanis 2007 – Proprietary & Confidential – Under NDA Only 11
SMART Doc Structure: SIGNATURE_MODEL
We make paperless happen™
© Silanis 2007 – Proprietary & Confidential – Under NDA Only 12
SMART Doc Structure: VIEW
We make paperless happen™
© Silanis 2007 – Proprietary & Confidential – Under NDA Only 13
SMART Doc Structure: VIEW
We make paperless happen™
© Silanis 2007 – Proprietary & Confidential – Under NDA Only 14
SMART Doc Structure: VIEW
We make paperless happen™
© Silanis 2007 – Proprietary & Confidential – Under NDA Only 15
SMART Doc Structure:
SIGNATURES
We make paperless happen™
© Silanis 2007 – Proprietary & Confidential – Under NDA Only 16
MERS – Mortgage Electronic Registration System
What is MERS?
– www.mersinc.org
– Created by the mortgage banking industry to leverage
electronic commerce to eliminate paper
– Mission: to register every mortgage loan in the United States
We make paperless happen™
© Silanis 2007 – Proprietary & Confidential – Under NDA Only 17
MERS eRegistry
Industry’s initiative to meet requirements imposed by
UETA and ESIGN
One registry to identify what organizations are the
current controller & location for the authoritative copy
of an electronic promissory note
We make paperless happen™
© Silanis 2007 – Proprietary & Confidential – Under NDA Only 18
Paper vs Electronic
PAPER ELECTRONIC
Original Document Authoritative Copy
Possession Control
Custodian Location (eVault)
Endorsement Transfer of control
We make paperless happen™
© Silanis 2007 – Proprietary & Confidential – Under NDA Only 19
Communication with the eRegistry
Individual
certs
SSL certs
SISAC cert
We make paperless happen™
© Silanis 2007 – Proprietary & Confidential – Under NDA Only 20
Communication with the eRegistry
HW tokens
HSM
We make paperless happen™
© Silanis 2007 – Proprietary & Confidential – Under NDA Only 21
Lessons learned
Even tamper sealed documents need to be modified
(e.g. stamped)
Delicate balance between security and ease of use &
management
Keep your eye on the ball: certificate renewals
We make paperless happen™
© Silanis 2007 – Proprietary & Confidential – Under NDA Only 22
Thank you for your time
We make paperless happen™
© Silanis 2007 – Proprietary & Confidential – Under NDA Only 23
Presence
, Inc.
PKI Observations
17 April 07
Boring Topic?
Tired of listening to visions of the future?
There is not the slightest indication that nuclear energy
will ever be obtainable. It would mean that the atom
would have to be shattered at will. Albert Einstein, 1932
It will be years--not in my time--before a woman will
become Prime Minister. Margaret Thatcher, 1974
No matter what happens, the U.S. Navy is not going to be
caught napping. U.S. Secretary of Navy, December 4, 1941
I think there's a world market for about five computers.
Thomas J. Watson, chairman of the board of IBM.
There is no reason anyone would want a computer in their
home. Ken Olson, president of Digital Equipment Corp. 1977
Managed PKI – Point Solution?
Aren’t we headed to a world of tunneled VPNs …..
Trading Partner / Customer Client / Government
Interaction
Watching Advances in PKI Management & Business
Processes
HSPD-12
DoD Key Management
Industry Best Practice Next Page >
PKI in the new topography . . . .
•Medical
•Financial
•GPS,
•HSPD-12 /
•WiFi,
CAC
•Credit
Identity Location •Readers
•Cellphone
•Personal
•GSM / CDMA
•Barcode •SATCOM
•eNotary PKI •WiFi
•Telephony Connectivity •RS232
•RFID •Ethernet
•Unique ID •USB
•DoD
Biometrics
Example; eWills
By show of hands – How many of you
know exactly where your will is?
– know that your loved ones know where it is?
– think that a safety deposit box is convenient?
eWills
Storage / Location with IPv6
Notary today….
Is paper-based, not electronic….
Relies on human-based
quality control….
Can’t be reliably authenticated
after the fact…
Is difficult to locate after long
periods of time…
Most Important – is inconvenient, time-consuming
and sometimes difficult to execute
And, if that’s not enough….
There’s Notary fraud…..
Illegal sale of Notary Seals…..
Misidentification of participants….
Misidentification of a Notary…..
A Decade of PKI Innovation… that can fuel
eNotary
CAs – Notaries across US are not the same . . .
RAs – Who does the Notary back office management?
Local RAs – Do we want to really distribute authority
Lot’s of tools . . . Hardware – Transport, Node, Enclave,
Biometric; etal
Next Page >
Best Practice; DoD and the “outside” world
CONFIDENTIAL
Yin & Yang of PKI / Crypto . . .
• GOTS v. COTS for HW, SW, Mgmt
• Public v. Private Management
• Authorities -- Government v.
Private
Next Page >
Art of the Possible -- SISAC accreditation
of NNA certs …
eNotary
eNotary
PKI eNotary eNotary
PKI
PKI PKI
eNotary PKI CAC/Cred. is used….
1. As the identifier for each entity (NEMS Identifier)
2. As an authentication mechanism
3. Serialization Server organizes “numbering”
Every Person, System, Document/Transaction and
Storage Location has an “PKI” Address….
twalsh
**********
Log In Now
OK
Next >
Select
Next >
Finish
Next >
DPI / NNA Proprietary
Presence
, Inc.
For more information:
Jim Bacchus
Digital Presence, Inc.
Cell: 704-756-8947
j.bacchus@digitalpresence.us
Universal Certificate Authentication to Key Applications
at Argonne National Laboratory
Doug Engert
Rich Raffenetti
David Salbego
John Volmer
Argonne National Laboratory
9700 South Cass Avenue, Argonne IL 60439
February 26, 2007
Argonne National Laboratory has implemented a laboratory-wide portal that provides
centralized access to key administrative applications and employs certificates for
authentication. This portal relies on an infrastructure comprising Microsoft Active
Directory, Microsoft Certificate Services, Sun Microsystems Java Enterprise Suite, and
open-source software. The capabilities of the Microsoft, Sun, and open-source products
have enabled Argonne to readily deploy certificates for partial, as well as for end-to-end,
authentication from all Argonne client operating systems. The Argonne experience
demonstrates that certificate authentication to corporate applications is readily doable
today. Further, the adoption of these technologies positions Argonne to exploit
widespread certificate deployments, as intended by Homeland Security Presidential
Directive-12.
Introduction Solution
Argonne National Laboratory has overcome
Challenge both of these issues and enabled certificate
In enabling certificate access to applications, authentication to corporate applications for most
organizations must address two issues: users by using commercially available and open-
source technology. Argonne addressed the issue
• Providing users with certificates, and of providing users with certificates by adding
Microsoft Certificate Services and the
• Enabling applications to accept certificates.
University of Michigan’s KX.509 package to its
authentication infrastructure. Microsoft
Users cannot be easily provided with certificates
Certificate Services enable organizations to issue
because certificates (and their corresponding
either short-term or long-term certificates to
private keys) are difficult — if not impossible —
hundreds of users. Simultaneously, Argonne
for users to simply manage. The certificate and
adopted Sun Microsystems Java Enterprise Suite
private key comprise a few thousand bytes of
to incorporate certificate authentication into
binary data. Further, the private key must be
web-based applications. The Sun Microsystems
safeguarded because control of the key is the
suite includes simple mechanisms for adding
basis for assuring identity.
certificate processing to applications.
Certificate authentication also cannot be easily
The combination of these two commercial
incorporated into applications because enabling
technologies and open-source software provided
certificate authentication requires considerable
immediate and unexpected benefits. Not only do
technical knowledge of Public Key
users have certificate-based application access,
Infrastructure (PKI) concepts and public/private
but in many cases, the approach that we used
key algorithms.
enables single sign-on. Further, with the addition
of smart cards, we were able to provide end-to- computers and users. One use of Active
end authentication based on certificates. Directory is to define trusted root certificate
authorities. Certificate authorities defined in
An organization that is readily able to accept Active Directory are automatically trusted by all
certificates for authentication is ideally clients and domain controllers.
positioned for the implementation of Homeland
Security Presidential Directive-12 (HSPD-12). Approximately 60% of Argonne’s desktop
The intent of HSPD-12 is for smart cards workstations have Microsoft Windows 2000/XP
containing certificates to be issued to all federal operating systems, and nearly all of these
employees and contractors beginning in October workstations are members of the ANL.GOV
2006. An organization able to capitalize on the domain managed by Active Directory. The other
widespread availability of certificates can 40% of Argonne’s workstations are Macintosh
greatly simplify the user’s password (20%) and Unix (20%). Argonne’s Mac and
management burden. Unix workstations are not managed by Active
Directory. Argonne’s ANL.GOV domain
This paper presents a detailed discussion of how processes 1,500 unique logins per day.
Argonne National Laboratory addressed the two
challenges associated with certificate access: Because all employees are provided with an
providing user certificates and enabling identity in the ANL.GOV domain (Active
applications. Directory), they all have Kerberos principals.
All employees, regardless of their desktop
Background platform, are able to acquire Kerberos
authentication credentials from the
authentication infrastructure.
The Argonne National Laboratory authentication
infrastructure has developed over the years from
standalone Kerberos servers to a Distributed Unix
Computing Environment (DCE) and, recently, to ANL.GOV Windows Domain
Microsoft Active Directory. Active Directory
has become Argonne’s institutional Ticket
authentication mechanism.
XP Ticket
Upon date of hire, employees are provided with XP
an identity in Active Directory, which is a Domain
Controller
combination data store and service provider. Mac
Domain controllers are computers that manage
the data store and offer, for example, the
following services to clients: Fig 1: All Platforms Can Authenticate to
Active Directory
• Kerberos ticket services, and
As shown in Figure 1, Argonne’s Unix and
• Lightweight Directory Access Protocol
Mac computers can take advantage of the
(LDAP) access to Active Directory’s
Kerberos services provided by Active Directory
contents.
if they are configured to do so. Unix
workstations implementing pam_krb5 and Mac
A domain is the collection of computers and
workstations configured to use Active Directory
users managed by an active directory instance.
obtain Kerberos tickets automatically during
login processing. If the computer is not
Active Directory is a powerful tool in the
configured to perform Kerberos logins, the
management of a Microsoft Windows domain. It
Kerberos kinit command (“acquire a Kerberos
permits distribution of information and policies
ticket”) can be run on the computer to acquire
to all members of the domain, both client
Kerberos credentials after logon.
Many of Argonne’s administrative systems rely of Argonne’s 38 domain controllers detected its
on the ANL.GOV domain to authenticate users, presence and requested domain controller
particularly systems that are used directly by all certificates from Certificate Services. In
employees. These systems include high-profile response, Certificate Services automatically
applications such as Human Resources’ issued domain controller certificates to each of
Performance Appraisal and Open Enrollment the domain controllers, as shown in Figure 2.
systems. Enterprise
Certificate
Services
Certificate Authentication
Architecture
Certificate Issuance
In the spring of 2002, Argonne began
experimenting with the University of Michigan’s XP XP
KX.509 suite to enable testing of certificates
with real-world applications, particularly for the ANL.GOV Windows Domain Domain
Globus project. Globus relies on certificates to Controller
perform user authentication, and KX.509 Fig. 2: Issuance of a Certificate to a
permits organizations with a Kerberos Domain Controller
infrastructure to easily issue short-term user
certificates. KX.509 constructs short-term A web application associated with Enterprise
certificates from existing Kerberos credentials. Certificate Services provides the means to
manually submit requests and obtain certificates.
Subsequently in 2004, Argonne began The web site acts as an enrollment station for
investigating two-factor authentication for its agents to provide smart cards on behalf of
Microsoft Windows-based administrative users. clients.
Microsoft Windows naturally supports smart
cards; the most straightforward path for enabling Auto-Enroll Certificates
a smart card pilot was to install Microsoft Microsoft Enterprise Certificate Services
Certificate Services. provide a capability known as Auto-Enroll
Certificates. Auto-enrollment allows
Microsoft Certificate Services are primarily a organizations to avoid the high effort costs
certificate authority coupled with a web associated with traditional certificate issuance by
application. Smart cards require the deployment using domain policy to automatically issue
of Microsoft Enterprise Certificate Services 1 . certificates. No new services need to be installed
to enable auto-enrollment.
Microsoft’s Active Directory provides the
framework for Enterprise Certificate Services. Users who log in to Windows XP work stations
For example Certificate Services uses Active and who are members of the domain are selected
Directory to identify users for smart card by group policy to trigger the auto-enrollment
issuance and to publish Certificate Revocation process. A certificate request is issued, and
Lists (CRL). Additionally, Active Directory Certificate Services immediately responds with a
policies can draw on Enterprise Certificate certificate for the user. The certificate and
Services. One of these policies (which will be private key are stored in the user’s profile, and
discussed later) is the ability to automatically the certificate is propagated to the user’s
issue certificates to users — in effect, to auto- certificate store. Figure 3 depicts this process.
enroll users.
At Argonne, approximately 2,000 users are
As an example, within 24 hours of our presently selected to receive auto-enroll login
installation of Enterprise Certificate Services, all certificates. Each week, 600 Auto-Enroll
user name Win XP
password user name Unix/Mac/XP
password
Ticket
Ticket Ticket
CA
KCA
Domain
Controller
Fig. 4: Issuance of a KX.509
Fig. 3: Issuance of an Auto-Enroll Certificate to a User
Certificate to a User
Certificates are issued to users. These Because the certificate lifetime is usually less
certificates have a lifetime of 30 days. than a day, CRLs are not issued or checked. A
user can also discard the certificate and the
KX.509 Certificates private key by using the kx509 program or by
The University of Michigan’s Kerberized destroying the Kerberos ticket cache.
Certificate Authority (KCA) and kx509 (an
element of the KX.509 suite) programs are used KX.509 certificates are rarely requested. The
to provide short-term certificates to users of two KCA servers issue fewer than two
workstations that are not members of the certificates per day.
ANL.GOV domain managed by Active
Directory. These tools provide the same service Smart Card Issuance
as the Auto-Enroll Certificate, i.e., short-term Smart card issuance requires the following two
login certificates derived from login credentials. additional components beyond the installation of
The KX.509 tools are available on workstations Microsoft Enterprise Certificate Services:
that do not run Windows, such as Unix and
Macintosh, and to non-domain Microsoft • The physical equipment of smart cards and
Windows clients as well. readers, and
• Smart card middleware — specifically a
Two KCA servers issue certificates to users. Cryptographic Service Provider (CSP) that
KCA certificates are derived from the Kerberos provides an interface between Microsoft
tickets of the users who make kx509 requests. Windows and the smart card.
The certificate subject name is derived from the
Kerberos principal name, and the certificate Argonne chose Gemalto GemSAFE smart cards
lifetime is the remaining lifetime of the Kerberos and Gemalto GemLIB v4.2 middleware for its
ticket used in the request. The subject name is smart card pilot 2 . The middleware includes both
always the same for a given user. Figure 4 a CSP for accessing the card, as well as a tool
shows the KX.509 certificate issuance process. for managing the card.
When kx509 is run on a Windows machine, the Microsoft Enterprise Certificate Services
certificate and private key are stored in the provide a web interface for smart card issuance.
user’s certificate store, and are thus accessible The default interface assumes that smart cards
— like any other certificate. When kx509 is run will be issued in person by an authorized
on a non-Windows machine, the certificate and official, such as an enrollment agent. At
private key are stored in the Kerberos ticket Argonne, the Laboratory’s Account Services
cache. Both are made available to applications personnel issue smart cards. Account Services
via the KX.509 kpkcs11 executable. personnel select the user who is being issued a
smart card from Active Directory.
Microsoft Enterprise Certificate Services Portal Architecture
interact with the smart card to generate a
public/private key pair, construct a certificate In 2004, Argonne National Laboratory
request, issue a certificate, and place the undertook a strategic business initiative to
certificate on the smart card. Smart card implement a web portal for its business systems.
issuance requires 5 minutes, and the certificate is The developers envisioned a single framework
valid for 2 years. that would serve as the official repository for all
Enterprise administrative applications and information —
CA enabling Argonne to manage identities, roles,
and responsibilities and providing employees
with customized access to information.
Employees would benefit from a single sign-on
interface that would speed entry to the
administrative applications.
XP XP Initially, the portal was designed to host in-
Smart
Domain house developed applications for Human
Card
Controller Resources and Payroll transactions. The goal
Fig. 5: Issuance of a Smart Card was to automate these tasks in order to
Certificate to a User significantly increase employee productivity.
As shown in Figure 2 earlier, Microsoft Overview
Enterprise Certificate Services automatically The Argonne Administrative Systems Portal
issued certificates to domain controllers. With architecture is based on the 2005Q4 release of
the issuance of a certificate to the user, as shown the Sun Java Enterprise System (JES). The JES
in Figure 5, a third-party trust model is created suite consists of a number of related products,
within the Windows domain. including a directory (LDAP) server, a web
server, a Java application server, a portal server,
Once issued, the smart card instantly enables and an access manager. These products represent
login to Microsoft Windows workstations the core of the product suite, and they are all in
equipped with smart card readers and the smart use at Argonne in a redundant, load-split
card middleware. No additional configuration architecture.
action is required by computer administrators.
At login or when the smart card is inserted in the The Sun JES was chosen by Argonne for two
reader, the certificate is propagated to the user’s primary reasons: past positive experience and
certificate store. attractive cost. Several of Sun’s software
products have been in use at the laboratory for
Today, Microsoft smart card login certificates many years, including the web server and
contain the User Principal Name (UPN) in the directory server. Argonne had an established
Subject Alternate Name field of the certificate. group of administrators who were familiar with
The UPN form is username@domain, which is Sun products and whose positive experiences
the Active Directory identity of the user. This with these products allowed us to experiment
UPN is used by the domain controllers to select with additional Sun software. Sun software is
the user account for login when presented with a also relatively inexpensive compared with other
smart card. Thus, the mechanism for issuing the commercial software; the Sun JES software
smart card requires smart card users to be itself is free, although support is not. A
members of Argonne’s Microsoft Windows comparison of the cost of the Sun software with
domain (ANL.GOV). Approximately 60 users at that of competing commercial single sign-on and
Argonne have smart cards. identity management products and our past
positive experiences with Sun products made the
selection of Sun JES straightforward. The Sun These authentication modules may be chained
JES suite is licensed across the Argonne together. Chaining allows multiple
campus. authentication modules to be used in succession.
Rules define the requirements for each module.
Internet Explorer, For example, users may be required to
Netscape Mozilla, authenticate against module “A,” with
Firefox, Safari authentication against module “B” being
optional. Another scenario may require
authentication against both module “A” and
module “B.”
In Argonne’s scenario, two modules are chained
Content Web
together for public use: a certificate module and
Policy Agent
Policy Agent
Java App
Server
Servers
Servers
Portal
a user name and password module. The
certificate module is invoked first. If a user has
established a Transport Layer Security (TLS)
connection to the Access Manager by using a
client certificate, the certificate module attempts
to use that certificate to authenticate the user. If
no client certificate is available, a username and
password prompt appears.
When an X.509 certificate is presented by an
Access Directory end user, it must be signed by a trusted
Manager Server certificate authority 3 , and there must be a map
Fig. 6: Authentication Communication of between a distinguished name component and
the Sun Access Manager the user profile stored in the LDAP server of the
portal. The map defines which components of
Access Manager the presented certificate are to be used to locate
The Access Manager is the central the correct user profile in the LDAP server. The
authentication and authorization mechanism user profile specifies the Active Directory
used by other web services and resources. All identity (i.e., Kerberos principal) of the user.
requests for authentication, authorization, and
session state flow through this service. As Authorization
shown in Figure 6, the Access Manager is the The Access Manager employs an LDAP service
key component — bringing together disparate to store configuration data, user session
web services and resources. information, user portal profiles, and
additionally authorization data such as group
Authentication and role information. Applications use these
A number of different authentication protocols authorization data to determine user privileges.
(including LDAP, Unix, SecureID, RADIUS,
and X.509) are accepted by the Access Manager. Argonne has developed an in-house centralized
At Argonne, the LDAP and X.509 modules are “role” (or group) management system called
used in production. The LDAP module is Information Services Authentication and Access
configured to work with Argonne’s Active Control (ISAAC). Users of ISAAC may create
Directory infrastructure for user name and new roles, modify the membership of roles, and
password authentication. The X.509 module is produce reports based on given criteria. Roles
configured to accept several types of X.509 user are defined and managed within ISAAC and
certificates for authentication. distributed to multiple systems, including
Oracle, Active Directory, and LDAP (for Access
Manager).
Directory browsers, to automatically trust
Portal User Interface Argonne’s administrative web servers.
The Argonne Administrative Systems Portal The key to a seamless portal experience is single
represents the gateway to other web applications sign-on (SSO). Although not required, single
and resources throughout the organization. This sign-on allows users to jump from resource to
web site provides access to related applications. resource and application to application within
In Argonne’s case, the portal is used to co-locate the portal without having to log in to each
the entry points for many administrative systems component individually. If a user had to provide
required by individual employees. Users access credentials to each application he accessed, even
the portal applications via their web browsers. if those credentials were identical, the
One feature of portals is that users can experience would be severely diminished.
customize their portal experience; their
preferences are saved as part of their user Policy Agents
profiles. The Access Manager provides for SSO
capabilities within the portal through the Policy
The Administrative Systems Portal relies on the Agents, i.e., the security layer between the user
Access Manager to provide authentication and and the resource. When a protected resource is
authorization services. The portal also heavily accessed, the Policy Agent determines whether a
relies on the directory service to store user user is authenticated, whether a resource is
profiles and related information. The Portal is protected, and whether an authenticated user has
the largest user of roles stored in Access access to a protected resource (authorization).
Manager. These aspects are configured through the use of
a local configuration file and a central policy
By utilizing roles, portal developers create a repository located on the Access Manager.
dynamic, customized end-user experience. An
example role is “supervisor.” After logging in to Traditionally, simple web applications request a
the portal through the Access Manager, an user name and password by using Hypertext
employee with a “supervisor” role will have Transfer Protocol (HTTP) basic authentication.
additional application links visible to them. For this type of authentication request, the web
Applications such as “Performance Appraisal” server instructs the client browser to bring up a
will behave differently when used by a pop-up window that asks for a user name and
supervisor, as opposed to an employee. password. The provided user name and
password are returned to the web server, which
Content Web and Java Application Servers validates the response against a local data store
A number of web and application servers are (can be a simple text file or perhaps an LDAP
used at Argonne, and many of them provide server). If the proper information was provided
laboratory applications. The most well known is by the client, the environmental variable
the Human Resources Performance Appraisal REMOTE_USER is set by the web server. The
application. Frequently, these applications web application can then use the
require authentication before they can be used. REMOTE_USER variable in any way it wishes.
All portal-based applications use Access The authentication layer is therefore separated
Manager Policy Agents to conduct from the application layer.
authentication on their behalf. Different Policy
Agents are available for a wide variety of web The Policy Agent works in a similar fashion.
and application servers. For cases in which Accesses to protected URLs are intercepted by
authentication is required, Argonne’s web the Policy Agent, which asks the Access
servers use TLS. The server certificates that Manager to validate the end-user’s credentials. If
enable TLS are signed by widely trusted external the end-user has not previously authenticated
commercial certificate authorities. This approach (does not have a proper SSOToken browser
allows all browsers, specifically the non-Active cookie), he is redirected to the Access Manager
for authentication. After credentials are
provided, the Access Manager redirects the end- authentication credentials. For example, if a site
user back to the Policy Agent. were to move from username and password to
When the Policy Agent returns control to the certificates as its primary authentication
application, it also returns several standardized mechanism, each application must be modified
data objects, including REMOTE_USER. The to accept this new credential. By using the
Policy Agent sets the same environmental Access Manager, credential changes only need
variables that are set by a web server using basic to be made in one location. Applications using
authentication, so for the application being Policy Agents or the Access Manager API do
protected, it does not generally matter whether not need to be altered. Once an application is
HTTP basic authentication or Policy Agent integrated into the Access Manager
authentication is used. The underlying environment, little else needs to be done to
application can then use the environment accommodate new authentication mechanisms.
provided by the Policy Agent for further
authentication and authorization. Policy Agents are available from Sun
Microsystems and third-party vendors for a wide
A simple application that previously used basic variety of web resource environments, such as
authentication can easily be configured to use the commercial Java application servers (IBM
the Policy Agent, which is installed as a separate WebSphere, BEA WebLogic, Oracle
component onto a web server or application Application server, and Redhat JBoss),
server. In the case of Sun Web Servers, the name Microsoft Internet Information Server (IIS),
of the shared library containing the Policy Agent Apache, and Tomcat, among others. The Agents
executable is added to the magnus.conf file. A allow third-party web providers to be integrated
configuration file is simultaneously created on into a centralized authentication infrastructure.
the web server that simply defines which URLs The Access Manager API can be used directly to
are to be protected by the Policy Agent. The integrate almost any application, provided
native web server access control list is modified source code is available. Commercial software
to disable protection of the resource. vendors have been willing to modify their
products to integrate into SSO solutions.
The specific access control list for the URL is
maintained by the Access Manager. The Sun Browsers
JES includes a graphical user interface to Browser compatibility is a significant issue in
manage access control lists. enabling a successful portal. Argonne’s portal
components have been tested with Microsoft’s
Complex web applications — typically larger Internet Explorer, Firefox, and Mozilla.
open-source projects and commercial products
— require code modification and customization Multiple browsers (including Internet Explorer,
to integrate into a Policy Agent environment. A Mozilla, and Firefox) can use the University of
direct API is available for applications needing Michigan’s KX.509 certificates. Mozilla and
to forego the Policy Agent and communicate Firefox require the kpkcs11 component of the
directly with the Access Manager. The amount KX.509 suite to be installed on the client
of effort required to integrate a product into the workstation.
Access Manager SSO environment depends
heavily on the complexity and implementation The kpkcs11 component implements the RSA
of the application. PKCS#11 standard to enable applications such
as web browsers to access certificates stored by
A significant advantage of using the Access kx509. The Windows version is a dynamic link
Manager to provide authentication to a large library (dll), and the Unix version is a shared
number of applications is consolidation of library. These executables emulate security
authentication. Assuming a modest application devices (e.g., smart cards) to Mozilla or Firefox.
inventory, it would be challenging to upgrade
each application to accept a new form of
Authentication Process issued by the domain controller and a certificate
issued by either Microsoft Enterprise Certificate
Workstation Login Services or the KX.509 package. The user can
Workstation login that results in users having a immediately access resources that request either
personal certificate can be conducted in three form of authentication.
ways:
Figure 7 summarizes authentication credential
• With a user name and password using auto- flow from user workstation logon to application
enroll certificates, admission.
• With a user name and password using
KX.509 certificates (manual), or
• With a smart card.
The highlight of all logins is that, at the end of
login, the user has both a Kerberos credential
Auto-Enroll Log in
user name Win XP
password
CA
Ticket
Portal
Non AD Log in Server
user name Unix
password Access
Content Web Manager
Servers
Controller
Domain
Policy Agent
Ticket
KCA Java App
Servers
Ticket
Policy Agent
Win XP Directory
Server
Smart Card Log in
Fig.7: Authentication Communication From Logon to Application
User Name and Password Certificate acquisition may be automatic and
In this mode, the users log in to their invisible when using auto-enroll or manual
workstations by using their user name and when using the KX.509 process.
password and then acquire a certificate.
• Auto-Enrollment • Smart Card
Users initiate a standard Microsoft Windows The insertion of a smart card is
domain login by providing their user name automatically recognized by Microsoft
and password. At login, the user obtains Windows Graphical Identification and
Kerberos credentials. As part of the login Authentication (GINA). Windows
process, Group Policy settings are evaluated immediately prompts the user for the
(including the policies for auto-enrolled Personal Identification Number (PIN) that
certificates). If there is no certificate or if it permits use of the private key functions of
has expired, an auto-enroll certificate is the card.
obtained. The process is completely
transparent; users are unaware of the auto- The client workstation uses the PKINIT
enroll certificate process, and no action is component of the Kerberos protocol to
required on their part to obtain or renew a obtain Kerberos credentials. The User
certificate. Principal Name contained in the Subject
Alternate Name field of the certificate
Auto-enroll certificates are usable only as enables the domain controller to select the
long as the associated Windows domain user for which a session should be initiated.
account is enabled. In a non-Roaming
Profile environment, a user logging onto Validation of the user’s certificate by the
another Microsoft workstation obtains a new domain controller is included in the login
auto-enroll certificate. In a Roaming Profile process. The controller validates the
environment, the certificate is transmitted certificate chain and inspects the CRL of
with the user profile. Microsoft Enterprise Certificate Services.
• Dynamic KX.509 Certificates Smart card login is quick and easy for users.
Kerberos Login. If the desktop computer In the Argonne smart card pilot program,
conducts a Kerberos login, the user receives several non-technical users have been issued
a Kerberos ticket as part of the login smart cards. They use the cards routinely
process. The user then manually requests a with no complaint (even though they are
short-term certificate by running the kx509 optional).
client program on his/her desktop computer.
Access Manager Authentication
The kx509 program uses Kerberos to The end-user portal authentication
authenticate to one of the KCA servers. The experience is straightforward. All web and
program generates a public/private key-pair application resources that are protected by a
and sends the public key to the KCA server. Policy Agent rely on the Access Manager to
The KCA server returns a certificate good provide authentication and authorization.
for the lifetime of the Kerberos ticket used Therefore, accessing any protected resource
in the request — typically 12 hours or less. results in the same experience.
The certificate and private key are stored on
the local computer. The only variation is whether the client has
previously authenticated to the Access
Non-Kerberos Login. If the desktop Manager and still owns a valid session.
computer does not conduct a Kerberos login,
users must manually obtain a Kerberos The general end-user experience can be
ticket using kinit. Users request a short-term described as follows:
certificate by running the kx509 client
program on their desktop computers, as they 1. The user starts a new browser and points
would if they had performed a Kerberos it at https://www.anl.gov/protected/.
login.
2. The Policy Agent uses information from a The result is that Argonne employees
requested cookie and the Access Manager routinely and transparently use certificates
to determine whether access can be to access Laboratory applications.
granted.
3. If access can be granted, the user is Argonne succeeded in this endeavor by
granted access to the resource. successfully leveraging and integrating a
4. If access cannot be granted (no session), number of authentication and related
the user is redirected to the Access technologies to use certificates in a real-
Manager to provide credentials. world, end-user environment. Certificate
5. The user provides a certificate to the deployment was accomplished by using two
Access Manager. types of technology:
6. The user is redirected to the protected
resource, and the process resumes at • Short-term user certificates issued via
Step 2 Microsoft’s auto-enroll technology or the
University of Michigan’s KX.509 suite,
By default, Internet Explorer will and
automatically present a certificate in the • Long-term user certificates contained on
certificate store to a web site that requests smart cards.
one, assuming that only one certificate is
present. Most Argonne users have only the We enabled the applications to accept
auto-enroll certificate available in their certificates by adopting the Sun Java
certificate store. Therefore, when such users Enterprise System. The Microsoft, Sun
contact the Access Manager for Microsystems, and University of Michigan
authentication, the authentication process products demonstrate daily that certificate
begins immediately; no user action is authentication — even end-to-end certificate
required. The Access Manager accepts the authentication — is doable today.
certificate and creates a user session.
Argonne has accrued several specific
Authentication is virtually the same if the benefits through its certificate-enabled
certificate is contained on a smart card. The infrastructure, as described below.
only difference is that the user is prompted
for the PIN so that the private key functions Benefits
of the card may be used. Approach Enables Single Sign-On for
Users
During an average business day at Argonne, In Argonne’s authentication infrastructure,
roughly 1,000 users will authenticate to the one authentication credential provides
Access Manager. Half of these users access to many applications. Successfully
authenticate by using a certificate. obtaining a Kerberos ticket permits the user
to obtain a certificate (auto-enroll, KX.509).
Conclusions On the other hand, possessing a valid
certificate allows the user to obtain a
Argonne National Laboratory’s deployment Kerberos ticket (smart card). At the
of a certificate-enabled infrastructure and completion of login, the user possesses both
portal technology addresses the two vexing types of credentials and can immediately
challenges associated with enabling interact with downstream applications
certificates for authentication: requiring either authentication technology.
• Providing certificates to users, and Short-Term Certificates Eliminate User
• Enabling applications to accept certificates Certificate Management Burdens
for authentication. The Microsoft auto-enroll and the
University of Michigan KX.509
technologies provide a quick and simple in which authentication occurred is not
way to issue certificates to users and thereby critical.
accelerate certificate deployment. These
tools eliminate many of the burdens of Approach Allows End-to-End Certificate
certificate management for the user — such Authentication
as issuance, private key management, and Via smart cards, Argonne is providing end-
renewal. Overnight, users can be certificate- to-end SSO based on certificates. That is,
enabled. users rely totally on certificates for
authentication; they never present a user
Short-Term Certificates Jump Start name and password. Indeed, in the future,
Application Certificate Enablement users will not have passwords.
Organizations should consider using
Microsoft’s auto-enroll technology to allow Smart Cards Allow Functional Certificate
rapid deployment of applications that use Portability
certificate authentication. Auto-enroll Adding smart cards to a certificate instantly
technology allows certificate deployment to enables certificate portability. Microsoft
be decoupled from application enablement. Windows manages smart-card-stored
Organizations can benefit from certificate- certificates as seamlessly as it manages
enabled application without having to internally stored certificates. Users find that
address the burdensome aspects of smart cards have a negligible impact on
certificate deployment. workplace efficiency and permit certificate
authentication from any workstation. In a
With auto-enroll technology, organizations properly equipped environment, the
can prepare their applications now for certificate is as portable as the user name
HSPD-12 certificate availability. and password.
Approach Provides Universal Application Approach Increases HSPD-12 Readiness
Access An outcome of smart card deployment, as
Argonne has made use of proprietary, open- required by HSPD-12, is that users possess
source, and standard protocols and portable long-lived certificates. The
technologies to enable employees using deployment of portal technology has
various desktop operating systems to access positioned Argonne for the availability
Laboratory applications by using HSPD-12-compliant smart cards and
certificates. Whether the end-user is running certificates. The versatility of X.509
Windows, Linux, Solaris, or Macintosh, authentication included in the Sun Access
there is a method to acquire a certificate and Manager enables Argonne to readily accept
import it into a browser for use in portal an HSPD-12 certificate for application
applications. authentication.
Applications Are Authentication-Neutral Lessons Learned
The applications provided in the portal are Two-Factor Authentication Can Enable
authentication neutral. The application SSO
authentication process is centralized through Two-factor authentication requirements that
the Sun Access Manager, which provides require smart cards (e.g., HSPD-12) can be a
the flexibility to support future vehicle for user certificate deployment.
authentication mechanisms without making Argonne’s smart card deployment has
changes to the applications that depend on shown that users can readily employ smart
authentication. A certificate can be used for cards for client authentication and
authentication just as easily as a user name subsequently use the same smart card for
and password. The application only knows application access. Smart cards and their
that the user has authenticated. The manner supporting software readily interact with
browsers. The user impact of performing a presented by Microsoft’s Internet Explorer
smart card login is negligible. to the Sun Access Manager. As a result,
Argonne Human Resources representatives
Auto-Enroll Certificates Complement do not receive auto-enroll certificates.
Smart Cards
Argonne has realized the benefits of issuing User education is therefore an important part
auto-enroll certificates to users who log in of certificate rollout. Confusion may arise
with smart cards, especially users who must unless an employee understands how
frequently authenticate to applications. authentication is occurring and how to
Application authentication via certificates change default browser behavior.
requires access to the private key. Repeated
presentation of the smart card becomes System Administrator Skills
burdensome to the user. Issuing an auto- Similarly, system administrators are
enroll certificate to smart card users permits generally unfamiliar with certificates and
two-factor authentication for the initial login public key infrastructure concepts.
without requiring two-factor authentication Technical staff charged with maintaining the
for each successive application. desktop environment and supporting users
may not understand the roles of certificate
Automation Is Key to Certificate Usage authorities, certificates, and smart cards. Too
As noted above, Argonne’s Administrative often, system administrators equate the
Systems Portal processes 500 certificate smart card PIN to the user’s password.
authentications per day. Argonne’s KX.509
KCA servers issue fewer than two short- The challenges that system administrators
term certificates per day. The vast majority face will increase with the adoption of
of application certificate authentications rely HSPD-12 smart cards for authentication.
on auto-enroll certificates. Today at Argonne, the certificate authority
is local, and certificate issues can be
So, although only two commands (kinit and addressed by on-site staff. As Argonne
kx509) are required by users to enable accepts externally signed certificates for
certificate authentication — and thus SSO authentication, its staff must be prepared to
— from Linux and Mac desktops to work with external service providers to
Argonne’s Administrative Portal, these users address real-time authentication issues.
continue to rely on user name and password. During Argonne’s smart card pilot program,
It is clear that certificate acceptance is staff experienced the absence of a valid
achieved through automation of certificate CRL, which disables Microsoft smart card
issuance and management. login. Under HSPD-12, organizations will
have to depend on external information
Issues sources for authentication.
Undesirable SSO
The concept of using a certificate instead of Smart Card Certificate Requirements
a user name and password for authentication The current requirement that the Subject
is new to many users. Confusion can arise Alternate Name field of the smart card
when a user wishes to access an application certificate contain the User Principal Name
as another user. For example, a Human of the user prevents the card from being
Resources representative may wish to have used for desktop logins in other Windows
an employee who is sitting in his or her domains. As described earlier, the UPN is
office log in to an application. When the username@domain, and a domain controller
application is accessed, the Human cannot normally establish a session for a
Resources representative is automatically user of another domain. Microsoft is
logged in because the certificate contained expected to remove the requirement for the
in the user’s profile is automatically
UPN in the next version of Microsoft Foster, I., and C. Kesselman, “Globus: A
Windows. Metacomputing Infrastructure Toolkit.” Intl
J. Supercomputer Applications, 11(2):115–
Related Work 128, 1997.
PIV Smart Card Support
Argonne National Laboratory sees great Heimdal Kerberos Implementation (http://
value in having a broadly trusted and www.pdc.kth.se/heimdal/), October 5, 2006.
interoperable identity credential as
envisioned by HSPD-12. The Laboratory Komar, B., “Microsoft Windows Server
has obtained NIST SP 800-73-1-compliant 2003 PKI and Certificate Security,”
smart cards from vendors and has developed Microsoft PKI Team, Microsoft Press,
enhancements to the Open Source Smart Redmond, WA, 2004.
Card Project (OpenSC) to enable Linux and
Mac platforms to use the certificates Microsoft Corporation, “2821A: Designing
contained on these cards. These PIV and Managing a Microsoft Windows Public
enhancements have been donated to Key Infrastructure,” Microsoft Official
OpenSC. Curriculum 2821A, Redmond, WA, 2003.
OpenSC provides a PKCS#11 interface, thus Neuman, B.C., and T. Ts’o, “Kerberos: An
making the smart card available for Authentication Service for Computer
Kerberos login via PKINIT. For example, Networks,” IEEE Communications,
the Heimdal Kerberos with PKINIT enables 32(9):33–38, September 1994.
smart card login for open systems such as
Linux. Open Smart Card Project (http://www.
opensc-project.org/), October 5, 2006.
Acknowledgements
RSA Laboratories, PKCS #11 v2.20:
This work was produced with funding from Cryptographic Token Interface Standard,
the U.S. Department of Energy’s Office of Bedford, MA, June 2004.
Science under Contract Number DE-AC02-
Sun Documentation (http://docs.sun.com/,
06CH11357.
http://docs.sun.com/app/docs/prod/entsys.05
q4#hic).
The authors would like to thank Gemalto,
MobileMind, and Oberthur for providing
Sun Java Enterprise Server 2005Q4,
sample PIV cards.
(http://www.sun.com/software/javaenterpris
esystem/index.xml).
References
U.S. Department of Homeland Security,
Butler, R., D. Engert, I. Foster, C. Kessel- Homeland Security Presidential Directive
man, S. Tuecke, J. Volmer, and V. Welch, (HSPD-12): Policy for a Common
“A National-Scale Authentication Identification Standard for Federal
Infrastructure,” IEEE Computer, 33(12):60– Employees and Contractors (http://www.
66, December 2000. whitehouse.gov/news/releases/2004/08/2004
0827-8.html), August 27, 2004.
Doster, W., M. Watts, and D. Hyde, “The
KX.509 Protocol,” University of Michigan,
Zhu, L., and B. Tung, RFC 4556 Public Key
Ann Arbor, MI, 2001 (http://www.
Cryptography for Initial Authentication in
citi.umich.edu/techreports/reports/citi-tr-01-
Kerberos (PKINIT), The Internet Society,
2.pdf).
June 2006.
1
Microsoft offers both Standard Certificate Services and Enterprise Certificate Services. All of the
Microsoft functionality discussed in this paper is achieved via the Enterprise Certificate Services.
2
The selection of smart cards and corresponding middleware is in itself a research undertaking and so
outside the scope of this paper. The smart card market is fragmented and proprietary. Homeland Security
Presidential Directive 12 (HSPD-12) and Federal Information Processing Standard 201 (FIPS-201) will
enable significant improvement in the standardization and interoperability of smart cards.
3
The Access Manager uses an internal list of trusted root certificates to validate user certificates; it does not
rely on root certificates contained in Active Directory.
Universal Certificate
Authentication to Key
Applications at
Argonne National Laboratory
Presented at
6th Annual PKI R&D Workshop
April 18th, 2007
Doug Engert, Rich Raffenetti,
David Salbego, John Volmer
2
Introduction
In 2003, Argonne set out to re-architect its operations web presence
Primary issues:
– Key web resources and applications spread far and wide
– No central employee web site
– Poor search engine
– Weak security due to multiple authentication back-ends
– Multiple development platforms
– Few standards
– No redundancy
3
Technical Solutions
Implement Sun Java Systems product suite
– Portal Server
– Access Manager and Policy Agents
– Directory Server
– Application Server
Use F5 BigIP load balancers for redundancy
Use Google Search Appliances for search engine
Develop an internal Portal to centralize information
Standardize Java development
Link password authentication to Active Directory
Investigate widespread use of other authentication methods,
especially user certificates
… this talk focuses on the bolded items!
4
Policy Agents Overview
Provide single sign-on capability for external applications and services
Supported on most major web and application servers
Utilizes SSO cookie token provided by Access Manager
– Cookie must be protected
– Cookie can be made “restricted” to prevent unauthorized use
• Cookie can be tied to specific agent and application
Policy agents do not directly accept user credentials
– They rely on SSO tokens provided by Access Manager
– Access Manager performs actual validation of credentials
5
Policy Agent Flow Diagram
6
Policy Agent Flow Description
1. User accesses application through a web browser. Agent intercepts and
checks for a valid SSO token (browser session cookie)
2. If not valid, redirect to Access Manager Authentication Service. Agent
also provides its identity.
3. After successful authentication, redirects user back to target application
with SSO token as part of URL query parameter.
4. Agent receives SSO token and sets it as session cookie for the host.
5. Agent validates SSO token with Session Service.
6. Agent checks permissions against Policy Service.
7. User is allowed to access application.
8. Same SSO token cannot be used to gain access to another application
since SSO token is unique to each application and may not be shared or
reissued to other agents or applications.
7
Policy Agent Usage Example – Web Server
Convert existing application which relies upon HTTP “basic”
authentication to use Access Manager Policy Agent
– Assumes web server owns access control
– Assumes simple application that relies upon REMOTE_USER
Simplified outline of steps to convert application:
– Install policy agent on SSL-protected web server
• Adds a few lines into web server configuration to load the module
• Agent uses a separate configuration file
– Modify agent configuration file to protect resource
• https://myserver.gov:443/my/protected/URL
– Create policy on Access Manager for web server and URL
• https://myserver.gov:443/my/protected/URL
– Remove original web server access control
8
Policy Agent Usage Example – continued
Common problem:
– Many applications include their own authentication mechanisms
• Form-based logins instead of HTTP “basic” authentication
• Examples: Forum software, Stellent, Wikis, …
– Such applications require more work to convert
• Level of difficulty depends upon how code is structured
However…
– Many enterprise application vendors are learning to accept the growth
of SSO within infrastructures
• A number of vendors claim to integrate with such solutions, usually
with a bit of consulting services
• Simple LDAP-based mechanisms to tie into enterprise
authentication/authorization services are not enough anymore
9
Policy Agents – Supported Software
URL Agents for web servers
– Sun
– Microsoft IIS
– Apache
J2EE Agents for Java Application servers
– Sun Application Server 7, 8, BEA WebLogic, IBM WebSphere
– Red Hat JBoss 4, Oracle
Many others exist, including:
– Tomcat, Domino, SAP Portal
10
Access Manager Overview
Provides single sign-on capabilities in conjunction with Policy Agents
Centralizes authorization services
Integrates with many external authentication providers if desired
Component of larger “Identity Manager” product suite
Open-sourced at http://www.opensso.dev.java.net/
11
Access Manager - Authentication Modules
All Argonne employees and on-site users have Active Directory accounts
– About 8,000 total
Argonne uses two authentication modules:
– X.509 User Certificates
• Smartcards
– ~100 users in pilot test
– Includes PIV smartcards for use in Windows and Unix
• Microsoft Certificate Authority
– for all Active Directory users
• Kerberos Certificate Authority (KCA)
– KX509 – for use on any platform
– LDAP
• For those not using certificates (usernames/passwords)
12
Access Manager - Authentication Chaining
An authentication chain is a list of possible user authentication modules
– Preference to particular modules can be given
– Multiple modules can be required
– Modules can be given an ‘authentication level’
Benefit as a transition technology – multiple authentication techniques
can be used simultaneously
At Argonne:
– Look for user certificate
– If not available or not accepted, request username and password
• Password checked against Active Directory
• Provides ability to bypass certificate authentication!
13
Access Manager – Module Diagram
14
Access Manager - Certificate Notes
The certificate issuers’ certificates must be imported and trusted by the
Access Manager web server
Client-side certificates must be defined as “optional” by the web server
– Must allow username/password logins
Access Manager must be able to map a certificate to an Access Manager
profile
– This is not a requirement in general, but it is enforced at Argonne
The certificate subject CN is used to map to an Access Manager profile
15
Benefits
~600 users daily rely on their browser certificate to reach key applications
– Goes up dramatically during key times (appraisals, benefits)
Applications rely upon Policy Agent for authentication and authorization
information – do not have to code for authentication
– Developers can code to the same standards
Applications do not have to be re-written to conform to new or changing
security standards – changes isolated to Access Manager
– Using certificate authentication instead of passwords did not require
any application re-writing, for example
Non-web-based applications can be integrated using standard API
16
Credentials Diagram
Auto-Enroll Log in
user name Win XP
password
CA
Ticket
Portal Server
Non AD Log in
user name Unix
password Access Manager
Content Web Servers
Controlle
Domain
r
Policy Agent
Ticket
KCA Java App
Servers
Ticket
Policy Agent
Win XP Directory Server
Smart Card Log in
Fig.7: Authentication Communication From Logon to Application
17
Access Manager Diagram
18
Site Map
19
Temporal Key Release Infrastructure
∗ † ‡
Ricardo Felipe Custódio Júlio da Silva Dias Fernando Carlos Pereira
§
Adriana Elissa Notoya
Abstract ance is provided through non-retractability and non-
refutability, and is claimed to be technologically ful-
Timed release of confidential information, where in- filled through authentication [2, 3]. Confidential-
formation is revealed at the date and time established ity, is achieved using symmetric cryptographic algo-
by the author, is a security requirement in applica- rithms [4, pg. 44]. The time-related evidence is the
tions such as auctions, wills, and government buying precise time at which the existence of an electronic
processes. We have found that this security require- document can be proved, along with the fact that it
ment is achieved through the fulfillment of a group has not been modified since that time. This prop-
of requirements that are not completely understood. erty is provided by a trusted third party, an entity
We propose the development of an infrastructure that called Time Stamp Authority (TSA), that issues a
enables the fulfillment of the studied security require- time stamp [5, 6, 7]. This work deals with timed re-
ments. The infrastructure, Temporal Key Release lease of the document content. It is a special case
Infrastructure (TKRI), was developed as a proof of of the confidentiality security requirement where the
concept. We also discuss the advantages of our ap- information is to be revealed only at the moment es-
proach against other proposals. tablished by the author.
There are three different aspects to consider when
dealing with paper documents confidentiality: trans-
1 Introduction portation in order to guarantee confidentiality during
the communication process, the sealed envelope as a
Electronic documents have been used to substitute
way to guarantee document content confidentiality,
paper documents in many computer applications and
and timed release of the document content to address
information systems. The ease of their use, trans-
the act of opening the sealed document at the time
mission, and storage has motivated this substitution.
and date established by the author.
However, in some practical situations, the use of elec-
tronic documents is possible only with some secu- Exactly the above aspects also arise when dealing
rity assurances1 . These security assurances are au- with electronic documents. First, the communication
thenticity, integrity, non-repudiation, and confiden- protocols usually employed in data communications
tiality. Additionally, the use of time-related evi- use cryptographic techniques in the transport or net-
dence is also necessary. Authentication and integrity work layers, which are similar to those of the ISO/OSI
are assured through cryptographic methods such as model such as TCP/IP. The best known protocols are
hash functions in conjunction with digital signatures IPSec in the network layer and SSL/TLS [8] in the
schemes [1, pg. 425]. The non-repudiation assur- transport layer.
Second, secure electronic document storage can be
∗ R. F. Custódio is with Departamento de Informática e de obtained using a trusted third party or symmetric
Estatı́stica, Universidade Federal de Santa Catarina (UFSC),
Florianópolis, Brazil. E-mail: custodio@inf.ufsc.br.
and asymmetric cryptographic techniques. A trusted
† J. S. Dias is with Universidade do Estado de Santa Cata- third party receives the document, stores it, and only
rina (UDESC), Florianópolis, Brazil, E-mail: jdias@inf.ufsc.br reveals its contents after the required authentication
‡ F. C. Pereira is with PGEEL, Universidade Federal de
is provided. This approach presents high cost and risk
Santa Catarina (UFSC), Florianópolis, Brazil. E-mail: fcar-
because it is necessary to trust that the third party
los@inf.ufsc.br
§ A. E. Notoya is with PGEEL, Universidade Federal will be honest, will maintain the document’s integrity,
de Santa Catarina (UFSC), Florianópolis, Brazil. E-mail: and will allow access to authorized entities only. The
elissa@inf.ufsc.br use of cryptographic techniques allows those inter-
1 In Brazil, the legal validity of the electronic documents is
based on the fulfilment of security assurances. However, in
ested in providing confidentiality to a document to
some applications or countries, the observance of these assur- encrypt and store it securely. However, care must be
ances cannot be obligatory for the use of electronic document. taken because the loss of the encryption key renders
the electronic document illegible. Therefore, the en- infrastructure would need to offer. The aim of this
cryption key must be securely stored for the entire paper is to present the security requirements and pro-
period of time over which confidentiality is required. pose an infrastructure for electronic document tem-
We can use various approaches to solve this prob- poral confidentiality.
lem. One strategy consists of encrypting the docu- The rest of this paper is organized as follows. Sec-
ment with the public key from a trusted third party. tion 2 states the problem. In the subsection 2.1 is
In this situation, the RP may lose the private key, showed the security requirements necessary to achieve
and the trusted third party can be contacted in or- temporal confidentiality, obtained through the study
der to decrypt the document. Another approach con- of applications in which the controlled storage, trans-
sists of an encryption of the document with a public port and release of the document content is essen-
key whose private key is distributed to an authorized tial. In the subsection 2.2 is presented a review of re-
group of people, in parts, using of secret sharing tech- lated studies that apply cryptographic techniques to
niques. Using these techniques, the RP could lose achieve timed release of electronic documents. Con-
the private key and still submit a request to an au- fidentiality is achieved in this proposal through the
thorized sub-group of the complete group that has encryption of the electronic document. An encryp-
received parts of the key, for the reconstruction of tion module is proposed and presented in section 3
the original decryption key. to allow fast and secure encryption following policies
The third aspect of confidentiality in paper docu- established by the document author. The infrastruc-
ments that needs to be considered in electronic ones ture for the temporal confidentiality of electronic doc-
is timed release of documents. As with storage, this uments is presented in section 4. In section 5, an
requirement can be achieved with the use of crypto- implementation of the infrastructure that was devel-
graphic techniques or trusted third parties. Trusted oped is presented. In section 6, the results of the
third parties are trusted to only release the docu- study are discussed and improvement possibilities are
ment content at the specified time. This solution presented. The appendix A summarizes the notation
presents high risk and cost. This is because in order and symbols used throughout this paper.
for the third party to be trusted, they are required to
have both the ability and the robustness necessary to
maintain the document’s integrity and confidentiality 2 Problem Statement
until the time of release. When using cryptographic
To date there is no a definitive solution for tempo-
techniques, the problem is reduced to keeping secret
ral electronic documents confidentiality as we have
the decryption key until the time of release. After with paper documents. We show in this paper, a
the key has been released, the document can be read.
new way to analyze and propose a different solution
Applications which require document confidential- to this problem. Our approach consists in emulate
ity, such as public and private buying processes, elec- in the electronic world all features we have with a
tronic auctions, e-voting schemes and wills, require paper envelope. Then our problem is to present the
secure storage and later release of electronic docu- security requirements and propose an infrastructure
ment content. In all this applications the unautho- for electronic document temporal confidentiality with
rized release of the information before the specified the same requirements.
time can invalidate the whole process. In order to
make the document confidential it is necessary to
encrypt the document and keep the decryption key 2.1 Security Requirements
secret. The existing solutions used to perform this The establishment of an infrastructure for the tem-
task employ complex and expensive systems such as poral confidentiality of electronic documents begins
trustworthy environments and specialized computer with the definition of the security requirements that
platforms to keep the decryption key secret. must be fulfilled by this infrastructure. This is an
Despite the importance of the fulfillment of the essential step to guarantee the correct utilization of
confidentiality security requirement and timed release the services provided. In order to determine these
of documents, little effort has been made to provide a security requirements, we have studied applications
simple and inexpensive infrastructure. It is not pos- in which electronic documents must be kept confi-
sible in present applications identify document con- dential for specified periods of time, such as secret
tents or modify document usage policies during the price proposals in public bidding processes [9] and
document life cilcle. To achieve this aim it is nec- wills in notary services [10]. Both applications can be
essary to carry out a rigorous study of the security compared to a paper document in a sealed envelope.
requirements, as well as the services which a proposed After sealing the envelope, the document content is
confidential and will only be released when the seal 2.2 Timed-release Cryptography
is broken and the envelope opened at the specified
time. Timothy May [11] was the first author to use cryp-
This study leads us to the following general require- tography to address timed release of electronic docu-
ments for electronic or paper documents. Addition- ments, using the term timed-release cryptography to
ally, where appropriate, we add what a specific re- discuss this problem. May has presented as a solution
quirement if the means of implementing the temporal the use of trusted third parties (TTP) to store and
confidentiality on an electronic document is through release the document at a specified time. In addition,
the use of encryption. he proposed to encrypt the document maintaining se-
cret the cryptographic decryption key. For economy
r1. After the document was sealed, it must not be of performance, scale and resource, the second ap-
possible to determine its content before the spec- proach is the most common choice. In this approach,
ified time of release; the decryption key must be kept secret by the TTP
until the time specified by the author. The TTP re-
(a) The decryption key that allows access to the ceives the decryption key and the time of release of
document content cannot be known before the document and agrees to keep the key secret until
the specified time of release; the date and time specified. Thus, the TTP is most
sensitive and most vulnerable to threats.
(b) It must be possible to control access to the There are two main approaches to increasing trust
document content; in the TTP with respect to key encryption and timed
(c) The decryption key must be given only to release. In the first approach, the decryption key is
the authorized entities; produced as the solution of a problem whose resolu-
tion time is known [12]. The challenge in this ap-
(d) It is necessary a mechanism to show the proach is to construct an algorithm whose resolution
public part of the electronic document; is as independent as possible of the computer process-
ing power and memory available and takes exactly
r2. Once the document is released, the entity hav- the time specified to reveal the document content.
ing the document cannot deny knowledge of the Following this approach, Ronald Rivest [12] has pro-
document content; posed to model the problem as a time-lock puzzle.
The puzzle is designed so as to perform only sequen-
r3. It must be possible to prove, after the decryption tial tasks not allowing parallel operations. The puzzle
key was published, that the document content can only be solved after the execution of a series of se-
has been revealed; quential steps, where each step takes a constant time
t to be executed. The total time T = nt will be the
r4. It must be possible to destroy the document time specified to release the decryption key necessary
without accessing its content; to reveal the document content. However, the puzzle
proposed in the literature depends on the computer
r5. It must be possible to determine the group of processing power and memory available to the com-
users that witnessed the opening of the docu- puter. An alternative solution is the insertion of the
ment; puzzle into a sealed computer system. The process
must be carried out in such a way that it is not pos-
r6. It must be possible to verify in a non-repudiable sible to have access to intermediate results without
form the authenticity and integrity of the docu- destroying the puzzle. The computer must be kept in
ment. After being revealed, the document must a secure and monitored environment. After the time
be authentic and its content must be related and specified the computer will reveal the decryption key
equal to that provided by the author; to allow the release of the document content. The
most well-known implementation of this approach is
r7. It must be possible to audit the activities per- the time capsule LCS35 built by Rivest [13]. Wenbo
formed by the entities involved as well as to audit Mao [14] has improved Rivests work, proposing a
the resources used. technique to control execution times of the puzzle.
In this way, the puzzle is parameterized in terms of
These security requirements are general and some floating point operations that have almost constant
of them can be waived or may not be necessary for execution times. The control of floating point opera-
some applications. tions allows better control of the total execution time
of the puzzle. use of a random number generator may be used in the
The second approach to increase trust in the symmetric cipher. This key would then be encrypted
process is to share the key using secret sharing tech- using the RPs public key. In this concept, only the
niques [15, 16]. In this technique, the decryption key RP, who is the owner of the corresponding private
will be divided into pieces, each called a share. Each key, can decrypt the session key and then decrypt the
share is given to a different TTP, which agrees to re- document. This approach is well-known and used in
lease it at a specified date and time. The reconstruc- many information systems to encrypt documents.
tion of the decryption key is permitted by an autho- A detailed analysis of this scheme shows that it is
rized subgroup of TTP, which must agree on releasing not an efficient way to achieve the security require-
its shares to reconstruct the key. If we have honest ments listed in section 2.1. This is because the user
TTP subgroups, we can guarantee that the decryp- who encrypts the document can keep a copy of KS .
tion key will be released at the programmed time. In this case, any entity, regardless of whether they
Although it is possible to control the exact time of have the decryption key necessary to release KS or
the decryption key release, we cannot guarantee the not, can decrypt the document using KS . To solve
correct decryption key reconstruction. There must this problem and allow more flexible encryption poli-
be additional procedures to ensure that the shares cies, we propose the use of an Encryption Module
released are in fact those, which were produced when (EM). EM is a hardware and it must be developed
the secret was shared [17]. A system developed using according to FIPS140-2 secure cryptographic module
this approach was proposed by Fernando Pereira [9]. recommendations [22]. This precludes access to in-
Marco Mont et al. [18] proposed the use of Identity- formation that could lead to the disclosure of the de-
based Encryption (IBE) to address this problem. The cryption keys, or loss of sensitive data from the EM.
encryption key is constructed based on a public N The basic EM is presented in Figure 1 and receives
that the T T P has published, the identity of the client the document (DOC) to be encrypted, along with
and the time that the corresponding decryption key
will be released. On a certain date, at a specified
time, the T T P will calculate the decryption key as
a function of the encryption key, the identity of the
client, and the time of release. As an advantage, the
decryption key is only calculated at the time it is
released. The drawback to this approach is the ne-
cessity to protect the parameters needed to calcu-
late the decryption key. If one of these parameters is
published or becomes public, so will all the decryp-
tion keys. This property makes it difficult to build
such an infrastructure. Another drawback is the lack
of standards related to Identifier-based Encryption
(IBE).
Recently, Aldar C. -F. Chan and Ian F. Blake[19]
proposed that the TTP be completely passive with-
Figure 1: Basic Encryption Module.
out interaction between it and the RO or RP,
thus assuring the privacy of the document and the
anonymity of both its RO and RP. digital certificates from the users who would decrypt
The present study was developed using known the document once the decryption key has been re-
asymmetric cryptosystems such as RSA and stan- leased. The EM, using a Random Number Generator
dards like X.509v3 digital certificates [20] and (RNG), generates a symmetric key KS used to en-
PKCS [21] to represent key pairs. crypt the document DOC, creating EKS [DOC]. The
symmetric key KS is then encrypted using asymmet-
ric techniques for each of the m public keys KUi sup-
3 Encryption Module plied by the client, and then destroyed. The differ-
ent files containing encrypted KS s are then attached
The electronic document encryption may be per- to the encrypted DOC, creating the encrypted doc-
formed with the aid of symmetric cryptography, since ument DS = [EKU1 [KS ], ..., EKUm [KS ], EKS [DOC]].
this kind of algorithm is more efficient than asymmet- Then DS and its digital signature EKREM [H(DS)],
ric algorithms. A session key KS , obtained with the are sent to the user that requested the encryption. In
all figures of this paper, a shaded rectangle represents proach a polynomial F (x) = a0 +a1 .x+...+an−1 .xn−1
a encrypted data. of degree (n − 1) is constructed in such way that the
Only user who has KRi is able to access the content coefficient a0 is the secret to be shared. Let m ≥ n
of the electronic document encrypted using the KUi be the number of participants that will receive the
public key used to encrypt KS , as showed by Figure 2. shares. Each participant receives a point (F (xi ), xi )
The user having KS can decrypt DOC but he can called a share with xi 6= 0. To reconstruct the secret,
n participants are required. With these n points, the
secret a0 can be reconstructed through polynomial
interpolation.
Figure 3 presents an architecture for the EM that
uses secret sharing schemes. An aspect that must be
Figure 2: Electronic Document Disclosure When Us-
ing the Basic EM
also verify the DOC integrity through the EM digital
signature attached to DOC. Figure 3: Secret Sharing Encryption Module
However, this mechanism cannot guarantee the
achievement of all functional requirements necessary
for applications that require document confidential- considered in secret sharing schemes is the possibil-
ity. There are applications where the document can ity to verify the generated and disclosed shares. The
only be decrypted under conditions previously spec- secret sharing schemes using exclusive-OR or polyno-
ified by the decryption policies established for each mial interpolation do not address this problem. It is
document. One alternative to improve the encryp- necessary to use techniques such as the one proposed
tion process is to aggregate secret sharing schemes. by Gennaro [23] to guarantee verifiability. However,
Let P be a set of participants. The decryption key in our approach, the encrypted parts are signed by
is segmented in many parts called shares and each the trusted EM so we do not need more elaborate
segment is given to a different entity of P . Let Γ schemes. The disclosure process of DOC is presented
be a set of subsets of P . The elements of Γ are in Figure 4. The RP can verify the EM digital sig-
the subsets of P capable of reconstructing the de-
cryption key. Γ is called the access structure and
its elements are the authorized subsets. The decryp-
tion key reconstruction is only possible with the par-
ticipants of an authorized sub-group B ⊆ P pool-
ing their shares[16]. Many different algorithms have
been proposed with respect to this problem. The
simplest secret sharing scheme L shares the secret in
m parts using an exclusive-OR operation. Let x
be the secret to be shared in m parts, and yi num-
bers
L randomly
L Lgenerated, with i = 1 . . . m − 1. z =
x y1 . . . ym−1 will be calculated. The shares
are z, y1 , ..., ym−1
L . To
L reconstruct
L the secret we cal- Figure 4: Electronic Document Disclosure When Us-
culate x = z y1 . . . ym−1 . In this scheme ing Secret Sharing EM.
B = P , and is the only element of Γ which implies
that all participants must agree and contribute to the
secret reconstruction. Another well-known scheme is nature before choosing the set of encrypted shares.
based on polynomial interpolation [15]. In this ap- The private key owners decrypt the shares and send
the result to the user in charge of reconstructing the infrastructure. In this way, the stamp, which can
session key. The user that receives the shares can ver- be made public, would be issued by the entity that
ify their validity using the public keys from the users controls the service being provided. The stamp would
that sent the shares. be obtained from this entity and would be used by the
EM in the session key generation. Only signed stamps
would be validated by the EM and would allow access
3.1 Stamp
to the encryption service. This provides a second
In order to enable a better control of the confiden- mechanism to control the access to the DOC content
tiality the electronic document, the use of external and accountability.
information called a stamp is proposed. The crypto-
graphic hash value from the stamp is combined with
3.2 Public Windows
the session key KS as presented in Figure 5. The
cryptographic hash value from this combination, KS∗ , Public windows, as illustrated in Figure 7, are sup-
plied to attach public information regarding the en-
Figure 5: Stamp Insertion
Figure 7: Electronic Document Information Window
is used as the session key to encrypt DOC. Note that
it is necessary to have both KS and the stamp in or- crypted document subject. There are two types of
der to have access to the session key KS∗ that can be windows: internal and external. The internal window
used to decrypt DOC. is the part of the document that the author decides
The stamp can be kept secret and its owner can may be provided to the public. The external win-
give it only to the authorized entities or it can be dow is an electronic document that is attached to the
public, since the stamp knowledge is not sufficient to original document and is not encrypted, allowing the
have access to KS or KS∗ . Figure 6 shows how to user to read its content. These windows are present
disclose the document using a stamp. and are readable in the encrypted document. The
internal window is bound to the electronic document
DOC using a digital signature supplied by the au-
thor of the document. This signature is part of the
document that is encrypted by the EM. The exter-
nal window is bound to the sealed document through
the digital signature by the EM using its private key
KREM . The sealed envelope contains the readable in-
ternal and external windows contents that can be ac-
cessed without any cryptographic operations. Figure
8 shows how to decrypt and verify the authenticity
Figure 6: Electronic Document Disclosure When Us- of the electronic document.
ing Stamp
3.3 Complete Encryption Module
Another approach is to use the stamp as an access The complete encryption module illustrated in Fig-
control mechanism for the services provided by the ure 9 presents all the functionalities of the basic, se-
Figure 8: Window Verification.
cret sharing, stamps and public windows encryption
modules. The complete EM carries out the session
key generation using external control mechanisms,
the stamps. On the other hand, the insertion of pub-
lic windows, internal or external, allows readable in- Figure 9: Complete Encryption Module
formation to be attached to the encrypted document.
Module flexibility is achieved using a Control Unit
that receives the encryption requests and a set of poli-
cies. This Control Unit is responsible for interpreting
the policies and generating operational instructions
for all the elements within the module. Therefore,
the policies allow the user to establish the EM oper-
ational behavior.
It would be possible for a malicious EM to disclose
document contents to other entities besides those au-
Figure 10: Use of Multiple EM
thorized. We could also suppose that a malicious
EM could disclose the document. Our model does
not allow generation of evidence that could lead to
disclosure of the electronic document by the author, the module is turned on, the module owner must
the EM, or the computational platform. In order to define the manager and users of the module. User
address these threats, we propose that the document authentication can be performed using passwords or
be partitioned and each part sent to a different EM. digital certificates. Once the MG has been created,
We propose the use of client software that divides the this user can begin the cryptographic key pair gener-
document into small blocks and submits then ran- ation that is done in two steps.
domly to different EMs as presented in Figure 10, In the first step, the asymmetric key pair of the
using a secure channel achieving communication con- EM is generated along with a certificate request for-
fidentiality. Once the client has received all the en- matted as a PKCS#10 file containing the public key.
crypted blocks from the different EMs, these are tied This request is sent to a Certification Authority that
together to form the encrypted document that is sent issues the X.509V3 digital certificate. The second
to the RPs. step is the digital certificate importation by the EM.
In this way, the EM never has access to the com- The private key will always be kept secret and will
plete electronic document content. The access to the never leave the module. This private key is used by
complete document is possible only with all the EMs the EM to sign the encrypted data. The EM must
work together to defraud the system, which is not an also import the trusted Certification Authorities dig-
easy task. ital certificates as well as its Certificate Revocation
Encryption module management is achieved Lists. Once this step is finished, MG specifies the op-
through configuration and auditing processes, carried erational policies. These policies can activate or not
out by the module manager, MG, only. The first time activate EM functions as required by the applications
that will request EM services. of the electronic document and the TSA, used to at-
Periodically, MG must perform tasks such as the tach a time record token to the events and actions
renewal of the digital certificate, the verification of occurring in the TCA. Aspects about the security
the EM operational status, the creation of new users, of these components are not examined in this work.
the management of the trusted certification authori- However, related topics like safe code execution and
ties, and auditing processes if required. hardware security modules, used to provide such se-
All the information required to verify the digital curity, are objects of study in parallel projects lead
certificate validity must be supplied by the user re- by our research group2 .
questing service to the EM, so it will not be necessary Additionaly, there are seven entities involved in the
for the module to access any external entities. The management, operation and use of a TKRI: the man-
Certificate Verifier in the EM is responsible for this agers MG and operators OP of on-line and off-line
task. TCAs, the request managers RM, the request origi-
nators (RO), who have an interest in achieving confi-
dentiality, and RP to whom the encrypted electronic
4 Temporal Key Release In- document is destined.
frastructure The off-line TCA is responsible for the generation
of a long-term cryptographic key pair for the issuing
The aim of the Temporal Key Release Infrastructure of TDCs, for safe private key storage, and for event
(TKRI) is the management of temporal digital certifi- log auditing. This entity is kept isolated, usually in
cates. The temporal certification authority (TCA), a safe room, without data communication connec-
one of the infrastructure elements, generates a pair tions. In this way, the off-line TCA is not subjected
of asymmetric cryptographic keys. The private key to threats from public data communication channels.
is stored and kept secret until a future specified date Data insertion and retrieval in the off-line TCA are
when it is published. The public key is embedded in carried out using removable media.
an electronic document called temporal digital certifi- The on-line TCA is responsible for the short-term
cate (TDC) as specified by X.509v3 standard. Users cryptographic key pair generation, issuing of TDCs,
can use this digital certificate to encrypt documents. and private key storage. The on-line TCA is also in
Once encrypted, the document, and its contents, will charge of receiving the TDC requests and its poli-
only be known when the private key is published. cies and disclosing the private key at the time spec-
The TKRI architecture is presented in Figure 11. ified. The private keys that will be necessary in the
We have three main components: TCA, working on- long-term are sent to the off-line TCA. The on-line
TCA can also receive private key publication delays
or private key destruction requests. This entity must
produce audit logs of its activities and publish them
with the audit logs from the off-line TCA.
The TSA issues time stamps that are attached to
the electronic document and thus can prove its exis-
tence at a specific time [5, 24, 25]. The TSA, in this
infrastructure, is in charge of producing time-related
evidence for the electronic documents received or sent
by the on-line and off-line TCA. The TSA clock is
synchronized with trusted-time sources [26, 7].
The use of the TSA guarantees that the TCA clock
will be synchronized and all the transactions carried
out will be associated with the correct date and time,
bringing trust to the temporal aspects of the process.
As the on-line TCA is in charge of private key dis-
closure, its clock must be synchronized with a trusted
Figure 11: TKRI Architecture time source. The off-line TCA does not require the
same precision. The private keys are released in
blocks by the off-line TCA to the on-line TCA. Each
line or off-line, which is responsible for the crypto- block has a group of private keys that must be dis-
graphic key pair and the temporal digital certificate
generation; EM, responsible for the secure encryption 2 LabSEC - Computer Security Lab (www.labsec.ufsc.br)
closed in the next window of time to release private the long-term private keys generated. These collected
keys. The window of time is the time in which the data are sent to the off-line TCA. This operator must
on-line TCA can publish each one of the private keys also receives the block of TDCs and corresponding
stored. This period of time is previously configured private keys from the off-line TCA to be inserted in
by the MG of on-line TCA. Once all the necessary re- the on-line TCA and published in the next release
quirements for the private key disclosure are satisfied window.
and the time of release has been reached, the private The activities and processes related to the TCA
key is published. manager and operators as well as the guarantees are
The EM, described in section 3, is in charge of elec- present in the document TDCs Declaration Practices
tronic document encryption. The confidential elec- (TDCDP).
tronic document is sent to the EM, with the group The TKRI is operational from the moment that we
of TDCs and decryption policies. It is essential that have an operational on-line TCA. The requirements
RO knows that he is sending the document to some of the requesters can lead to the off-line and EM de-
known and trusted EM, but for the EM to know the ployment. The TCA deployment begins with the on-
client identity is not required, and in some situations line TCA installation and configuration followed by
it is not necessary. As described in section 3 the client the installation of one or more off-line TCA.
can break the document into pieces that are submit- The decryption key publishing is carried out by the
ted to different EM. After receiving the parts from on-line TCA using a PKCS#12 electronic document
the different EMs, the client can build a single en- that contains the TDC and the related private key.
crypted document. This file must present all the in-
formation necessary for the RP to decrypt and access 4.1 TKRI Operation
the document content at the specified time when the
decryption keys are published. To describe the TKRI operation it is necessary to
The RM is in charge of requesting the issuing of the understand the events associated with the life cycle
TDC from the on-line TCA, presenting all the corre- of a TDC as shown in Table 1.
sponding private key release policies, authorizing the
release, and delay or destruction of the private key if Table 1: Events associated with the time life of a
allowed by the release policies established. TDC.
Time Description
The RO is the entity that uses the TKRI to make
t1 RM requests TDC.
the electronic document confidential. The RO re-
t2 Key pair is generated.
quests a previously issued TDC from the on-line TCA
t3 TDC is issued.
or asks the RM to request a new TDC that fulfills his
t4 TDC is published.
requirements. When the client has the TDC, he can
t5 RO requests TDC.
submit the document to the EM who encrypts, and
t6 RO submits DOC and TDC to a set of EM.
sends it back to the client. The client having the en-
t7 RO receives the encrypted DOC and sends
crypted document can send it to any authorized RP.
it to RP.
In the cases where it will be necessary anonymity, the
t8 RM can destroy the decryption key, as
RO can use a generic TDC for a required time to re-
stated in TDC.
lease the associated private key. The generic TDC
t9 TDC expires.
are a set of certificates for predefined time to release.
t10 Decryption key is released.
The RP, at the specified time, must request the
t11 DOC is decrypted by RP.
private key from the on-line TCA in order to decrypt
the document.
The on-line or off-line TCA manager is responsible The issuing of the TDC is carried out by the TCA
for the TCA installation and configuration. The MG that generates a key pair, where the private key will
is also responsible for: OPs creating and delegating be encrypted and kept secret. The public key is in-
tasks to these entities; creating of the policies and serted into a public key certificate, along with infor-
defining of the operational parameters that establish mation regarding the disclosure strategy and time.
the TCA operation and functionality; and backup After being issued, the certificate can be accessed by
and restoration procedures of the entities. The au- the RO and used to make its documents confidential.
dit trail log is maintained by the MG and can be These are the major steps, as shown in figure 4, of a
used by auditing and accounting procedures. TKRI:
The on-line operator is in charge of tasks such as 1 An RM can request the issuing of a new TDC. The
collecting requests received by the on-line TCA and RM must supply, at the time of the request, the
time for the release of the decryption key related asking the TCA to discard the decryption key cor-
to the digital certificate to be issued, the purpose responding to the public key used to make the doc-
of the certificate, and the strategy to be used to ument confidential. The decryption key is not dis-
release the private key; carded immediately, it remains stored during a pe-
riod of time T after the disclosure time specified by
2 All the requests received and documents issued by the RM. At the disclosure time, the on-line TCA is-
the TCAs are time stamped for auditing pur- sues an electronic document advising that the private
poses; key temporal digital certificate will not be released
because the RM has requested the destruction of the
3 The key pair related to TDC can be issued by the private key. The RM has until the end of T to request
on-line or off-line TCA. If (t4 − t0 ) <= L1 then the private key disclosure. If the RM cancels the de-
the key pair is generated by the on-line TCA struction before T the decryption key is immediately
otherwise by the off-line TCA. L1 is supplied by released, otherwise is destroyed. It is important to
the TCA manager and represents the minimum note that only digital certificates with the destruc-
time necessary to operate the off-line TCA. tion possibility specified by the RM in their policies
4 If (t10 − t1 ) <= L2 then the decryption key is kept can be used this way. Thus, the RO who requests an
in the on-line TCA, otherwise it is kept in the encryption using this type of certificate is aware that
off-line TCA. L2 represents the minimum time the RM can negate the release of the private key.
necessary to manage the decryption key by the The RP, having the encrypted document, wishing
TKRI in the on-line TCA. to disclose its contents must verify through the public
key TDC at what time and under which conditions
5 If the current time > (t10 −L2 ) then the decryption the document can be disclosed. At the time speci-
key, if it is in Key’s Database of off-line TCA, fied, following the instructions informed by the RM,
must be sent to the on-line TCA; the RP can request the PKCS#12 file with the de-
cryption from the on-line TCA. After receiving the
6 Any RO interested in making its documents con- PKCS#12, the entity can use the private key in or-
fidential for a specific period of time has to ac- der to disclose the document content. Once the entity
cess the public interface of an on-line TCA, and requests and receives the private key, the document
download a TDC, prior to sending it to the en- is considered disclosed.
cryption modules; Another accepted possibility is the issuing of a pri-
vate key temporal digital certificate by the on-line
7 The document submission to the encryption mod- TCA only after an authorization is granted by the
ule is performed by the RO through a program RM.
that breaks the document into blocks that can be
Two complementary documents are required for
sent to different EMs, as presented in Figure 10.
the operation of the system. They are: Temporal
The blocks are encrypted by the EM and sent
Digital Certificates Issuing Policy (TDCIP) and Tem-
back to the RO who can send it to a RP or store
poral Certificates Practice Declaration (TDCDP).
it. Once the document is encrypted, its contents
The TDCIP establishes the TCA operational con-
can only be released after the disclosure of the
straints. In this document it is established that:
private key digital certificate, which will be per-
formed by the on-line TCA at the time specified
• All the off-line and on-line TCA operations must
by the RM;
be registered;
8 The disclosure of the decryption key can be auto-
matic, allowing direct access to the contents of • An issued certificate must be time stamped and
the document or can be made using secret shar- this time stamp must be present along with the
ing techniques, allowing access only to a group of certificate;
users that must agree with the disclosure of the
document in order to reconstruct the decryption • As soon as the off-line TCA receives a certificate
key. request, this request must be time stamped and
this time stamp must be present in the digital
Paper documents can be destroyed using fire or pa- certificate as an extension.
per shredders that make it impossible for the docu-
ment content to be read. In this proposal, the doc- The TDCDP presents the way that the TCA im-
ument RM can destroy the electronic document by plements the TCDIP.
5 Implementation
The viability of the proposed structure was confirmed
with the implementation of a TCA. The implemented
system includes an on-line TCA functionality with
three modules: management, client and public.
The management module allows clients configura-
tion and managers configuration, as well as on-line
TCA configuration and temporal private key control.
Access to this module is allowed only to managers.
The client module implements request mechanisms
and TDC management. Only registered clients can
have access to this module.
The public module allows users to access the pub-
lic TDCs issued by the on-line TCA. Through this
module, users can have access to the corresponding
private key temporal certificates. Access to this mod-
ule can be restricted or not depending on the policies
established by the MG.
The client authentication required by the system is
done through the use of digital certificates issued by Figure 12: Temporal Digital Certificate Request In-
the TCA. The server digital certificate allows secure terface
communication with users using SSL/TLS protocol.
The client digital certificate is used to identify the
client to the server and also to determine the client this document, digitally signed by the on-line TCA,
access level through the extensions in the certificate. are the request, creation, destruction, and disclosure
The user enrollment is done by the TCA, using an dates.
appropriate form in the client module, in which the The PCKS#12 file and the report can be down-
user data is collected for later confirmation by the loaded by an authorized user through the client tem-
TCA manager. If the data is confirmed, the MG can poral certificate management interface, as presented
allow the digital certificate issuing that will permit in Figure 13, and also in the public module, if
access to the infrastructure by the user. previously authorized by the solicitant of the certifi-
The public key TDC request is performed using
the form presented in Figure 12, where the client can
submit the necessary data to digital certificate issu-
ing. After the TDC has been issued the MG can con-
trol the respective private key using the client mod-
ule. It is possible for the MG to postpone the private
key disclosure, and release or destroy the private key.
However, this control is possible only following limits
established by the on-line TCA policies.
The private key TDC issuing can be done in two
ways. The first is through authorized client authenti-
cation, and the second is through automatic key dis-
closure. The prototype includes only automatic key
disclosure.
The automatic disclosure mechanism verifies the Figure 13: Client TDC Management Interface.
on-line database once a minute in order to collect the
temporal private keys to be released at that time.
Once the key is collected, the system issues, for each cate.
key, a PKCS#12 file containing the temporal private The temporal certificate issuing policy, defining the
key along with the public key temporal certificate. As on-line TCA operation, is configured by the system
soon as the PKCS#12 file is issued, the system gen- administrator through the use of the interface pre-
erates a report describing the key pair life cycle. In sented in Figure 14. All the functions performed by
the system are constrained by the parameters estab-
Figure 15: Bid System.
Figure 14: TCA Administrator Interface 6 TKRI Analysis
The Temporal Key Release Infrastructure was de-
lished in the policy. veloped according to the security requirements pre-
The TDC issued by the on-line TCA can be used sented in section 2.1. In this section, we discuss the
in any application that supports X.509v3 certifi- achievement of all the security requirements.
cates, examples include e-mail clients and Internet The private key, necessary for the electronic doc-
browsers. We performed several tests with different ument decryption, is controlled by a TTP, called
types of clients and we found that documents en- the TCA, that only releases it after a specified time
crypted using the TDC were correctly received and and after the necessary authentication has been per-
were only disclosed at the time specified, when the formed. In this way, the TKRI fulfills the security
TCA released the private key and this private key requirements r1-a, r1-b, and r1-c. The r1-d is fulfilled
was imported by the application. The encryption and through the public window mechanism.
decryption operations were performed by the appli- Using the private key destruction mechanism, it is
cations. possible for the MG of a specific private key to re-
As soon as the private key temporal certificate quest the TCA to destroy this key if this possibility
was released by the on-line TCA, the certificate was has been specified in the TDC request. After the
installed in order to proceed with the decryption private key is destroyed, the documents can be con-
process. sidered unavailable since they will remain secret until
the cryptographic technique has been broken, which
We have proposed to use the system developed in could occur at some future time. This mechanism
public buying processes. In this application the pro- allows the achievement of security requirement r4.
posals must present information related to the buying
Access is controlled by the TCA and all the trans-
process, using a form which lists all the products be-
actions performed by the entities are registered. Since
ing bought, with their prices. The public key TDC is
it is possible to determine which entities have ac-
requested by the on-line TCA and published by the
cessed, the temporal private key and when it was
person in charge of the buying process.
accessed, the security requirement r5 is achieved.
Each supplier that wants to take part in the buying Based on the TCA operating mechanism and poli-
process fills out the form with the appropriate data cies, it is possible to determine that the electronic
and sends it to the Encryption Module, along with document content protected by a specific private key
the published public key TDC. After being encrypted, will be disclosed only after this private key has been
the proposal is sent to the buying commission, which released. In this way, the entities that have access
will at the correct time, request from the on-line TCA to the encrypted document and to the private key
the related private key temporal certificate required used to decrypt the document cannot deny knowledge
for proposal disclosure. of the electronic document. If the TCA keeps the
Figure 15 presents the relation of this system with private key secret, the electronic document will re-
the EM and on-line TCA components. main confidential, fulfilling the security requirements
r2 and r3. readers for their detailed comments and help us to
The encryption module usage does not allow the improve considerably our paper.
establishment of relationship between the plain text
document and the encrypted document. This ap-
proach allows the fulfillment of the security require- References
ment r1.
The plain text and encrypted documents are digi- [1] A. J. Menezes, S. A. Vanstone, P. C. V. Oorschot,
Handbook of Applied Cryptography, CRC Press,
tally signed. It is also possible to include plain text
Inc., Boca Raton, FL, USA, 1996.
information that will remain readable to interested
users. In this approach, it is possible to prove elec- [2] A. McCullagh, P. Little, W. Caelli, Electronic sig-
tronic document integrity and authenticity, fulfilling natures - understand the past to develop the future,
security requirement r6. University of NSW Law Journal 21 (2).
The use of a TSA, in conjunction with stamps and [3] B. Balacheff, L. Chen, D. Plaquin, G. Proudler, A
audit trail registration allows the auditing process to trusted process to digitally sign a document, in: Pro-
be performed in the infrastructure and in its services, ceedings of the 2001 workshop on New security par-
fulfilling r7. adigms, ACM Press, 2001, pp. 79–86.
This analysis shows that the proposed Temporal [4] B. Schneier, Applied Cryptography: Protocols, Al-
Key Release Infrastructure fulfills all the security re- gorithms, and Source Code in C, 2nd Edition, 2nd
quirements specified in section 2.1. Edition, John Wiley & Sons, Inc., New York, NY,
USA, 1995.
[5] S. Haber, W. S. Stornetta, How to time-stamp a dig-
7 Conclusions ital document, in: CRYPTO ’90: Proceedings of the
10th Annual International Cryptology Conference on
Applications that require temporal confidentiality Advances in Cryptology, Springer-Verlag, London,
were studied in order to specify the relevant security UK, 1991, pp. 437–455.
requirements. Solutions found in the literature did [6] A. Buldas, H. Lipmaa, Digital signatures,
not fulfill all the requirements listed. A Temporal timestamping and corresponding infrastructure,
Key Release Infrastructure was then proposed, and Technical report, Küberneetika AS (1998).
shown (a) fulfill all the security requirements speci-
[7] J. Dias, D. B. Demétrio, R. F. Custódio, C. R. De
fied in the initial study, and (b) the performance re- Rolt, Reliable clock synchronization for electronic
quirements of the applications. The functionality of documents, in: Proceedings of III IEEE Latin Ameri-
the prototype developed was described in detail. can Network Mangment Systems, 2003, pp. 550–559.
We believe that, using this approach to the tempo-
[8] T. Dierks, C. Allen, The tls protocol version 1.0, Rfc
ral confidentiality problem, the use of electronic docu-
2246, Network Working Group, , United States (Jan
ments in applications such as public buying processes, 1999).
wills, and confidential data storage is secure and vi-
able. The authors agree that the policy model is flex- [9] F. C. Pereira, Criptografia temporal: Aplicação em
ible to satisfy any applications requirements without processo de compras, Master’s thesis, Universidade
Federal de Santa Catarina, Florianópolis, Brazil
changes.
(2003).
The TKRI was developed using known asymmet-
ric cryptosystems such as RSA and standards like [10] D. L. Bortoli, O documento eletrônico no ofı́cio de
X.509v3 and PKCS. However, the inherent character- registro civil de pessoas naturais, Master’s thesis,
istics of the TKRI allow that these technologies could Curso de Pós-Graduação em Ciência da Computação
da Universidade Federal de Santa Catarina, Flo-
be replaced, if necessary, by new technologies like el-
rianópolis, Brazil (2002).
liptic curve cryptosystems and one-time pad ciphers.
These characteristics, of flexibility and adaptability, [11] T. C. May, Timed-release crypto,
will be explored in a future work. (1993).
Another questions of our proposal need to be con- [12] R. L. Rivest, A. Shamir, D. A. Wagner, Time-
sidered in the future: a) how ensure that an entity lock puzzles and timed-release crypto, Tech. Rep.
with a given public key really is a trustworthy TCA, MIT/LCS/TR-684, Cambridge, MA, USA (1996).
and what if its key gets compromised? b) what per- [13] R. L. Rivest, Description of the
formance loads and interoperability issues emerged in lcs35 time capsule crypto-puzzle,
the implementation?
The authors would like to thanks the anonymous (1999).
[14] W. Mao, Timed-release cryptography, in: SAC • DOC - Electronic document.
’01: Revised Papers from the 8th Annual Interna- • DCUi - User i’s digital certificate.
tional Workshop on Selected Areas in Cryptography,
Springer-Verlag, London, UK, 2001, pp. 342–358. • EK (x) - the ciphertext of data x, encrypted with key
K.
[15] A. Shamir, How to share a secret, Communications
of the ACM 22 (11) (1979) 612–613. • EM - Encryption Module.
[16] D. R. Stinson, Cryptography : Theory and Practice, • H(x) - one-way hash function.
CRC Press, 1995. • KS - Session key.
[17] R. Gennaro, Theory and practice of verifiable se-
• KRi - i’s Private key.
cret sharing, Ph.D. thesis, Massachusetts Institute
of Technology (May 1996). • KUi - i’s Public key.
[18] M. C. Mont, K. Harrison, M. Sadler, The hp time • Li - a period of time.
vault service: exploiting ibe for timed release of confi- • MG - a Manager (can configure a TCA or an EM,
dential information, in: In Proceedings of the twelfth create keys and state policies but cannot operate a
international conference on World Wide Web, ACM, key).
2003, pp. 160–169.
• OP - an Operator (can use a cryptographic key).
[19] A. C. F. Chan, I. F. Blake, Scalable, server-
passive, user-anonymous timed release cryptography, • P - a Policy that state how a system or a secret
in: ICDCS ’05: Proceedings of the 25th IEEE Inter- sharing scheme work.
national Conference on Distributed Computing Sys- • RM - the Request Manager (responsible for request-
tems (ICDCS’05), IEEE Computer Society, Wash- ing temporal digital certificates with a specific pol-
ington, DC, USA, 2005, pp. 504–513. icy).
[20] C. Adams, S. Farrel, Internet x.509 public key in-
• RNG - Random Number Generator.
frastructure certificate management protocols, Re-
quest for comments: 2510, Network Working Group • RO - the Request Originator (uses a TDC and an
(1999). EM to encrypt electronic documents).
[21] RSA, (2004). • RP - the Recipient (receives an encrypted document
[22] NIST, Fips pub 140-2 security re- and will decrypt it when he obtains the decryption
quirements for cryptographic modules, key).
(Janu- • Si - a share i in a secret share scheme, SS.
ary 2002).
• SKi (x) - the digital signature of data x, by signer i.
[23] R. M. O. R. T. Gennaro, R., Simplified vss and
fast-track multiparty computations with applications • SS - Secret Sharing scheme.
to threshold cryptography, Proceedings of the 1998 • TCA - Temporal Certificate Authority.
ACM Symposium on Principles of Distributed Com- • TDC - Temporal Digital Certificate.
puting.
• TDCIP - TDC Issuing Policy.
[24] E. S. Pasqual, J. D. S. Dias, R. F. Custódio, A new
method for digital time-stamping of electronic doc- • TDCDP - TDC Declaration Practice.
ument, in: FIRST (Ed.), Proceedings of the FIRST • TKRI - Temporal Key Release Infrastructure.
14th Annual Computer Security, Phoebe J. Boelter
• TSA - Time Stamp Authority.
Conference and Publication Services, Ltd., 212 West
Washington, Suite 1804 Chicago, IL 60606, 2002. • TTP - Trusted Third Party.
[25] V. Costa, Um estudo da confiabilidade do processo
de protocolação digital de documentos eletrônicos,
Master’s thesis, Universidade Federal de Santa Cata-
rina (2003).
[26] D. L. Mills, Improved algorithms for synchronizing
computer network clocks, in: SIGCOMM ’94: Pro-
ceedings of the conference on Communications ar-
chitectures, protocols and applications, ACM Press,
New York, NY, USA, 1994, pp. 317–327.
A Notation and Symbols
The notation and symbols to be used throughout this
paper is summarized as follows:
Temporal Key Release
Infrastructure
(TKRI)
Ricardo Felipe Custódio
Júlio da Silva Dias,
Fernando Carlos Pereira, Adriana Elissa Notoya
Federal University of Santa Catarina
Brazil
PKI 2007, NIST
April, 2007 Copyright Ricardo Custódio
Summary
● General Idea
● Requirements
● Timed Released Cryptography Bibliography
● Encipherment Module (EM)
● Temporal Key Release Infrastructure (TKRI)
● Prototype
● Example of Application
● Final Considerations
General Idea
Document
is sealed
Define Time using Document is
to release “Temporal Certificate” opened
Time
Key pair PKCS#12 is
generation is released
X.509 certificate Key release
is published is known
General requirements for
electronic or paper documents
● After the document has been sealed, it must not be
possible to determine its content before the
specified time of release
– The decryption key that allows access to the document
content cannot be known before the specified time of
release
– It must be possible to control access to the document
content
– The decryption key must be given only to the
authorized entities
– A mechanism is necessary to show the public part of
the electronic document
General requirements for
electronic or paper documents
● Once the document is released, the entity having
the document cannot deny knowledge of the
document's contents
● It must be possible to prove, after the decryption
key has been published, that the document content
has been revealed
● It must be possible to destroy the document
without accessing its contents
● It must be possible to determine the group of users
that witnessed the opening of the document
General requirements for
electronic or paper documents
● It must be possible to verify in a irrefutable way the
authenticity and integrity of the document. After
being revealed, the document must be authentic
and its content must be the same as that provided
by the author
● It must be possible to audit the activities performed
by the entities involved as well as to audit the
resources used
Time Release Cryptography
Bibliography
● Timothy May ( 1993 )
– “Timed-release cryptography”
– trusted third parties (TTP) to store and release the
document (or Key) at a specified time
● Ronald Rivest ( 1996 )
– proposed to model the problem as a time-lock puzzle
( time capsule LCS35 )
● Wenbo Mao (2001 )
– technique to control execution times of the puzzle
● Marco Mont, Keith Harrison and Martin Sadler ( 2003 )
– use of Identity-based Encryption (IBE)
General Considerations
● Use of Digital Certificates
– X.509
– PKCS#12
● FIPS 140-2
– Encipherment Modules
● Infrastructure
– TSA
– TCA
– EM
Envelope
Opened
Sealed
Basic Encryption Module
KUm KU1
Encipherment
Module
RNG E K S1 K S1
. . .
KS . . .
. . .
E K Sm KSm
H
Doc E Doc Doc
KREM E S KR
EM
Secret Sharing Encryption Module
P KU1 K Um
Encipherment
Module
RNG E S1 S1
.
.
. . .
KS . .
. .
S1
Secret
Sharing E Sm Sm
Sm
H
Doc E Doc Doc
KREM S KR
E EM
Stamp Insertion
KURP
Encipherment
Module
Stamp H RNG
KS
|| E KS KS
Doc Doc
H
K*S
H Doc S KR H S KR
A A
E
E S KR KREM
A E S KR
EM
KRA
Electronic Document Disclosure
When Using Stamp
KRRP
H Stamp
KS
KS D || H
K*S
Doc Doc
D
S KR S KR
A A
S KR
EM
Window in a business envelope
Electronic Document Information
Window
KURP
Encipherment
Module
External External
Window Window
Internal Internal
Window Window
KS
External E KS KS
Window RNG
Internal
Window Doc Doc
H
Doc S KR H SK R
A A
E
E S KR KREM
A E S KR
EM
KRA
Window Verification
KRRP
External
Window
Internal External
Window Window
Internal
KS D Window
H
KS H
Doc Doc
? D ?
S KR S KR D
A A
D S KR
EM KUA
Encipherment DCU1 DCUm1
Module
Certificate Verifier
Complete Encryption RNG
KS1
E
KU1 KUm1
KS1 KS1
.
KS2 . .
. . .
. . .
E KSm1 KSm1
SS1 ... SSb
Module
P1
Control E S1 S1
Unit .
Pn . . .
. .
. . .
E Sm2 Sm2
Stamp H || . .
. .
E S1. S1.
.
. .
. . .
. . .
E Sm3 Sm3
External External External
Window Window Window
Internal Internal Internal
Window Window Window
H
Doc Doc H Doc
E
E SKR KUm3 KU1 KUm2 KU SKR SKR
A 1 A A
Certificate Verifier
E SKR
KRA KREM EM
DCUm3 DCU DCU DCU1
1 m2
Use of Multiple EM
EM
EM
EM
EM
Document EM Enciphered
Document
Temporal Key Release Infrastructure
Off-line On-line TSA
TCA TCA
Internet
EM1 . . .EMf
RP RM
RO
Temporal Digital Certificate
Request Interface
Form for Request of Temporal Digital Certificate
Information for the management of the private key:
Time release / / - :
Release method Automatic Manual (against authentication)
Allowed delay days
Purpose of the
temporal certificate
Password for release
Password confirmation
Distinguished Name:
Common Name
Organization
Organization Unity
Locality
E-mail
State
Country
Request Certificate Cancel
Client TDC Management Interface
Temporal Certificate Authority
Client: Adriana Elissa Notoya
Temporal Digital Certificates
Request a new temporal digital certificate
Server Current Date and Time: 11/16/2005 10:21:31 am
Common Name Issue Date Release Date Temporal Digital Private Key Report
Certificate
Adriana Elissa Notoya 11/10/2005 09:42:07am 11/10/2005 10:00:00am Download Download View
Adriana Elissa Notoya 11/10/2005 10:12:44am 11/10/2005 11:00:00am Download Download View
Adriana Elissa Notoya 11/12/2005 05:10:55pm 11/14/2005 08:45:00am Download Download View
Adriana Elissa Notoya 11/15/2005 02:30:22am 11/20/2005 08:00:00am Download Unavailable --
Adriana Elissa Notoya 11/15/2005 02:40:09am 11/20/2005 09:30:00am Donwload Unavailable --
TCA Administrator Interface
Policy
Additional validity 30 days
Key length 2048
Algorithm:
Key Usage: digitalSignature nonRepudiation keyEncipherment
dataEnciphemernt cRLSign keyAgreement
keyCertSign encipherOnly decipherOnly
CPS Pointer: www.labsec.ufsc.br/ac-temporal
CPS text:
insert cancel
Bid System EM
Brazilian 5
Act 8666
Stockist
Electronic 4 Electronic
Form 3
Form
System Edit
2 6
On-line 1 Purchase
TCA Commission
Final Considerations
● Real and practical solution
● Needs to be better codified in law
● Simulates a paper based envelope
● Testing a prototype
● Product already in use in Brazil
● Safe place created to install the infrastructure
Questions?
Suggestions?
Please, send
your questions/suggestions to
custodio@inf.ufsc.br
Electronic Document Disclosure
When Using Secret Sharing EM
KRi ... KRi+t
S1
. Secret
. t shares Key
. Reconstruction
Sm
KS
Doc D Doc
S KR
EM
Electronic Document Disclosure
When Using the Basic EM
KRi
K S1
. EKU (KS)
i
. D
.
K Sn KS
Doc D Doc
S KR
EM
Limited Delegation for Client-Side SSL∗
Nicholas Santos Sean W. Smith
nicholas.j.santos@gmail.com sws@cs.dartmouth.edu
Department of Computer Science
Dartmouth College
Abstract Like it or not, users are accustomed to this paradigm.
For many reasons, security experts promote PKI
Delegation is the process wherein an entity Alice des- as a replacement for passwords. Our own university
ignates an entity Bob to speak on her behalf. In has rolled out an X.509 identity PKI to over 75%
password-based security systems, delegation is easy: of the user population, and has migrated its Web-
Alice gives Bob her password. In the real world, end- based applications from legacy passwords to client-
users find this feature rather useful. However, secu- side SSL for user identification and authentication.
rity officers find it infuriating: by sharing her pass- However, we fear that if PKI does not offer a way
word, Alice gives all of her privileges to Bob, who for users to delegate permissions for the scenarios
then becomes indistinguishable from her. As enter- they feel are reasonable, users will again force their
prises move to PKI for client authentication, such own form of delegation into the system. PKI advo-
secret sharing becomes impractical. Although se- cates may shudder to imagine one user lending an-
curity officers appreciate this, end-users may likely other her private key, but unless there’s an easy-to-
be frustrated, because this more secure approach to understand way to delegate rights, that might be her
authentication and authorization prevents their ad only option.1 Hence, in order to be usable in many
hoc but reasonable delegation. In this paper, we real-world enterprises, client-side PKI authentication
present a solution that satisfies users as well as se- needs a secure, generalizable way to allow for delega-
curity officers: using X.509 proxy certificates (in a tion. This delegation mechanism should be decentral-
non-standard way) so that user Alice can delegate ized, to avoid the cost and hassle of enterprise-wide or
a subset of her privileges to user Bob in a secure, even application-specific databases that need to keep
decentralized way, for Web-based applications. We track of every user and every privilege. (That would
validate this design with an SSL-based prototype: an negate many of the reasons for PKI in the first place.)
extension for the Mozilla Firefox Web browser and a
In this paper, we develop a system—Web-based
module for the Apache Web server that allow them
delegated authentication via proxy certificates—that
to handle multiple chains of these certificates.
empowers Alice to unambiguously specify a limited
subset of her privileges to pass to Bob, so that he
can take care of business on her behalf. We equip
1 Introduction Web browsers with the ability to issue proxy certifi-
cates carrying security policies, and the ability to pass
In real-world situations, users often want to tem- proxy certificates to a Web server via client-side SSL.
porarily delegate some of their privileges to others, for We equip Web servers with the ability to pass the cre-
reasons that are often rather legitimate. Most legacy dentials encoded in these proxy certificates to server-
computer systems implicitly tie a set of privileges to a side scripts, which can then make their own security
password and thus make delegation surprisingly easy. decisions.
If a user wants to use her computer—or read her Pushing the delegation process below the applica-
e-mail, or sign onto her favorite chat account—she tion layer makes this solution generalizable. If Alice
types in her password. If she wants to let her friend wants to delegate privileges to Bob, she does not have
check her e-mail for her, she gives him her password. to visit each one of her Web applications and explic-
∗ This work was supported in part by the NSF, under grant
itly delegate to Bob. She can issue one proxy certifi-
cate encoded with the policies for all these applica-
CNS-0448499. The views and conclusions do not necessarily
represent those of the sponsors. A preliminary version of this tions. Also, developers can build secure Web applica-
work appeared as the technical report [13]. The first author is
now affiliated with Google. 1 Indeed, we’ve already seen this happen.
tions on top of this Web server, and take advantage cate signed by Alice’s secret key. This new certificate
of delegated authentication without implementing it contains Bob’s name and public key, and explicitly
themselves. authorizes Bob to log into Alice’s e-mail account and
read e-mail. It contains no statement that autho-
rizes him to send e-mail, nor to log into the university
This Paper. Section 2 discusses the high-level record system and view her grades. Alice e-mails this
goals of our system. Section 3 discusses the PKI certificate to Bob, along with the certificate chain at-
framework we used. Section 4 discusses our design. testing to her own public key certificate. Bob installs
Section 5 discusses our prototype. Section 6 discusses this certificate in his Web browser. When he logs in
related work. Section 7 concludes with some direc- to the Web-based e-mail account via an SSL session,
tions for future work. he presents the delegation certificate issued by Alice.
The Web server logs the fact that Bob logged in with
Alice’s identity. The server’s environment variables
2 Goal indicate to the Web application that Bob has per-
mission to read but not send Alice’s e-mail. If it is a
well-designed application, it will check these permis-
We’re considering an enterprise with a standard sions and act accordingly.
X.509 identity PKI for its users. We consider two
classes of entities: end users (like Alice and Bob),
and service providers (Web sites that Alice visits). Rejected Options. In our protocol, Alice issues
The service providers follow the PKI gospel and use the certificate herself. She then transmits her certifi-
client-side SSL to identify and authenticate users. cate to Bob on her own, or via a disinterested third
Alice has privileges on these Web sites, and may party like a public certificate database. But this isn’t
wish to delegate some of these privileges to Bob. To the only way to solve the same problem. The delega-
support this action, we need three things. For the tion of privileges could also be handled through the
PKI, we need a format for a delegation certificate, a enterprise’s CA or through the service provider. For
digitally signed statement from Alice giving Bob some example, the CA could provide a Web-based service;
rights. For the end users, we need a Web browser Alice submits authenticated delegation requests, and
plug-in to issue and manage delegation certificates. the CA then issues the certificate. Or, alternatively,
Finally, for the service providers, we need a server Alice could log into the service provider’s Web appli-
module to verify delegation certificates during client- cation, and tell that application explicitly that Bob
side SSL, and interpret the delegation appropriately. has permission to speak on her behalf. This second
method bypasses certificates completely.
The Web browser plug-in is easily distributed.
Most modern browsers have a system for installing These other approaches have disadvantages. First,
such a plug-in automatically by clicking a link, and they both put a burden on a central server. Decen-
users are accustomed to installing such add-ons. tralization is a boon to all parties—the process is less
Mozilla Firefox, for example, has “extensions,” and a complicated for Alice, and it relieves the server of
similar plug-in could be written for Internet Explorer. the responsibility. Consider banks that charge ridicu-
lously large “service fees” for printing an on-line bank
The module for the service provider will be more statements, in the hopes that customers will just
cumbersome to install, and will vary depending on
print the bank statement out at home. They want
the particular Web server software. Apache servers
users to take care of business on their own. Second,
provide support for configurable modules that are dy- they may have privacy problems. Suppose that Alice
namically loaded on start-up. The SSL-handling code delegates access to Bob for emergencies—she may not
is one such Apache module. So a service provider want anyone to know about this delegation until he
with Apache would have to replace the SSL-handling
steps forward. Direct correspondence between Alice
module with one equipped to handle delegation cer-
and Bob allows them to keep this arrangement (rel-
tificates.
atively) secret. Lastly, these approaches may have
We imagine a typical end user scenario might work scalability problems. For example, it would be ineffi-
as follows. Alice asks Bob to check her Web-based cient for each service provider to keep its own list
e-mail account while she’s out of the country. He of the parties to whom Alice has delegated privi-
agrees. Bob e-mails Alice his public key certificate. leges. In the approach where the CA issued the del-
Alice inspects this certificate, then uses it as the ba- egation certificate, the CA delegation service would
sis for a new certificate for Bob: a delegation certifi- have to change to accommodate every new service
provider and every new privilege that service might The ruling certificate standard, X.509, is rigidly hi-
provide. But if Alice and Bob issue their certifi- erarchical and does not allow the average user to issue
cates to each other directly, then the scalability issues certificates. In X.509, there are certificate authorities
aren’t so bad—Alice only has to keep track of which (CAs), and there are end entities (normal users like
delegation-enabled service-providers she has visited. Alice). CAs can issue certificates, but only to enti-
ties that are “subordinate” to the CA. End entities do
not have the authority to issue any certificates—the
Orthogonal Issues. Before we move on, we should reason that they are called “end entities” is because
clarify what problems we’re not trying to solve. their certificates can only appear at the end of a cer-
tificate chain [6]. To delegate her privileges to Bob
Once we give Alice the ability to delegate her priv-
in the X.509 system, Alice would need to find a CA
ileges to Bob, Bob may want the ability to act on
that she and Bob had in common, and ask this CA
behalf of two people at once. He may want to read
to sign her privileges over to Bob. Such a common
both his mail and Alice’s mail at the same time—in
trusted CA might not even exist. And even if Alice
other words, he may want to assert multiple iden-
does find a common CA, delegation may be difficult.
tities. There are some tricky semantics involved in
CAs are the bureaucrats of the X.509 world—it can
how applications should deal with a user with multi-
be cumbersome (and often financially expensive) to
ple delegated identities. We recognize that these se-
get their approval
mantics are difficult. And different applications will
have different ways of handling such users. But the The Globus Toolkit (http://www.globus.org/)
scope of this project does not extend beyond the low- ran into this problem while building a secure frame-
est level of multiple-identity authentication. We will, work for distributed computing. But part of its goal
however, provide a framework for application devel- was to share “securely,” and “without sacrificing lo-
opers to deal with multiple identities. cal autonomy.” A process sitting on a remote, au-
tonomous machine may need access to restricted re-
Additionally, the goal of this project is not to ex-
sources, so it needs a mechanism to authorize this
plore how we can specify delegation in policy state-
access dynamically. The CA approval process was un-
ments. There are many standardized languages, such
satisfactory, for the exact reasons noted above. CAs
as XACML, that allow security professionals to pre-
were too cumbersome to be practical for authorizing
cisely specify authentication and access control rules.
short-lived processes [15]. Thus, the Globus Toolkit
They are a useful tool for security administrators.
developers invented proxy certificates for delegation.
But we assume that most users will not care for such
This is probably the most widespread use of PKI-
a fine level of access control when they are determin-
based delegation in real-world applications today. Af-
ing which privileges to delegate in a proxy certificate.
ter some evolution, proxy certificates were standard-
We need a simple mechanism for users to describe
ized for X.509 in RFC 3820.
this delegation. This simplicity should be reflected
in the server-side directives as well. A set of rudi- Proxy certificates are an extension to the X.509
mentary directives—based loosely on the directives certificate standard that allow end entities to sign
defined for access control in Apache—will be enough certificate statements that delegate their own privi-
to demonstrate the possibilities of delegation. For theleges to other entities. By the standard, an end entity
purposes of this project, that’s what we care for. generates temporary private and public keys, signs a
short-lived proxy certificate that passes on some of
her privileges to the temporary keypair, then gives
those credentials to a third party entity. The iden-
3 Delegation Certificates tity of the proxy certificate is derived from the iden-
tity of the end entity. Because a proxy certificate can
As Section 2 described, we need a format for “delega- also testify to another proxy certificate, the identity
tion certificates.” We chose X.509 proxy certificates. of a chain of proxy certificates is the last non-proxy
certificate in the chain (the end entity certificate).
SDSI-SPKI is attractive because it provides a much
more straightforward and simple syntax for the del- Notice that when we say that these credentials are
egation of credentials [3]. However, it’s an X.509 “temporary,” this is merely a convention. There is
world, and that’s what the standard infrastructure no rigorous definition for the length of a “temporary”
supports. Prior experience in our lab (e.g., [4]) sug- period of time [14]. This flexibility is intentional, be-
gested that swimming against the current is not pro- cause simplicity is of the essence. On the Grid, these
ductive. proxy certificates can be issued to dynamically cre-
ated processes without requiring the approval of a for which previous certificates—an identity certifi-
CA. cate, and perhaps other proxy certificates—exist.
The X.509 proxy certificate offers numerous advan- This departure from the standard gave us several
tages for our scheme. Because it contains so much advantages. It does not require Alice to send a new
auxiliary information, the server can keep compre- temporary private key to Bob. In fact, no secret in-
hensive server logs on who Bob is and which iden- formation is exchanged between them. Only their
tities he’s assuming. It’s also explicitly intended for public key certificates are transmitted. As long as
delegation, as opposed to X.509 attribute certificates, Alice can verify Bob’s certificate, this will be secure.
which can handle more general attributes. But most Secondly, in our application scenarios, having lots of
importantly, current tools actually contain support temporary keypairs will not be appealing for users. In
for X.509 proxy certificates. The OpenSSL libraries a human-usable delegation system, simplicity should
can issue and verify them [8]. The same support is be a major goal, and a single keypair for each key-
not behind X.509 attribute certificates. And it cer- store is much more simple. Lastly, notice that we
tainly cannot be said for SDSI/SPKI, for which there can repeat the delegation process with other users
is little support in major applications, with the ex- each delegating their own privileges to Bob’s public
ception of some closed environments. key. This allows Bob to obtain a grab bag of cer-
tificates, all with the same name and public key, but
X.509 proxy certificates piggy-back off standard
X.509 certificates. The major technical differences corresponding to different delegated identities. This
are that proxy certificates can be signed by end en- could be useful in scenarios when Bob needs to repre-
tities, and a proxy certificate must define a critical sent more than one party in a service request authen-
ProxyCertInfo extension [14]. ticated via client-side SSL—which, by design, allows
Bob to prove knowledge of only one private key. (The
first author actually has done this in a process that
has not yet made it to the Web: Dartmouth’s on-
4 Our Design campus housing auction. Two friends wished to share
a room with each other. Neither could make it to the
To achieve the vision of Section 2, we need several event, so they both delegated to the author, who then
things. Alice needs a way to issue proxy certificates. made a selection representing both of them.)
The Web application needs a way to tell Alice what
permissions she can delegate, so that Alice can select
Revocation. Because proxy certificates are usually
which of these permissions to encode in her proxy
short-lived, researchers often wave their hands at the
certificate. Bob’s Web browser needs to be able to
problem of revocation, as the potential for damage
send multiple chains of proxy certificates in an SSL
is reduced greatly by the certificate’s early expira-
session. Bob must be able to choose which identities
tion date. In some projects, delegation is used to
he would like to assert. (In this example, he has a
make the revocation process obsolete—the proxy cer-
choice between his own identity “Bob” and his del-
tificates expire more quickly than a certificate revo-
egated identity “Alice.”) The Web server must un-
cation list (CRL) could be issued. For this project,
derstand proxy certificates, and be equipped to deal
we take this approach.
with multiple chains of them.
This section explains the design of these tools for a
suite of Web applications and Web standards: X.509 Privilege Attributes. In order to give a user the
proxy certificates (Section 4.1), Mozilla Firefox (Sec- ability to pick and choose which applications the del-
tion 4.2), SSL/TLS (Section 4.3), and the Apache egate can use on their behalf, we allow them to define
Web server (Section 4.4). attributes in terms of a service (the URL of a service
provider) and an ability (an arbitrary string expres-
sion).
4.1 Non-standard Proxy Certificates This will become clearer with an example. Suppose
Alice wants to delegate to Bob the ability to read her
For our project, we decided to depart from the stan- mail from her Web-based www.mail.gov account, and
dard that a proxy certificate must testify to the public to edit and post on her blog www.aliceblog.com. So
key of a temporary keypair generated exclusively for she gives him the attributes “www.mail.gov: read”
that certificate [14]. Instead, in our system, proxy and “www.aliceblog.com: edit post.” In other
certificates will testify to an existing public key, and words, the attributes will consist of a list of permis-
sions, and each list will be tied to a service provider. sive, encapsulated components that each implement a
Proxy certificates have a space allotted to specify such well-modularized set of functions. These components
a list of permissions as a policy OCTET-STRING in can be written in any language for which XPCOM
the ProxyCertInfo extension [14]. language bindings are defined, including Python and
This list of attributes constitutes a list of privileges Java—but are typically written in C++ or Javascript.
granted to Bob. Alice must explicitly name each ser- The methods and attributes of an XPCOM compo-
nent can only be accessed by defining a public inter-
vice provider that Bob can interact with on her be-
face through a second language called XPIDL (long-
half. This allows each service provider to define its
own set of privileges at any granularity. We tie priv- wise, that’s the Cross-Platform Interface Description
ileges to service providers to avoid the trouble that Language). This interface then allows the component
would arise if two service providers use the same priv- to be used as an object in any XPCOM-supported
ilege name. For example, this prevents Alice from language. One can define an interface in XPIDL, then
implement it with several different components (pos-
confusing “edit” privileges on mail.gov with “edit”
privileges on aliceblog.com. Because the privileges sibly in different programming languages), that sat-
are tied to the URL of the service provider, they re- isfy the interface in different ways. For example, the
main unique. In effect, we solve the name collision nsISocketProvider interface is implemented by one
problem by leveraging somebody else’s infrastructure component that handles SSL sockets, and another
that has already solved the problem. component that handles TLS sockets. See Chapter
8 of [1] for more information.
At least, that’s how we’ll think about the situa-
tion. URL addresses are not unambiguous. First, The components are managed by a component
some Web pages use server farms, with one address manager, which keeps a hash table with entries for
mapping to multiple servers. Secondly, an adversary each component. The entries of the hash table are in-
dexed by human-readable URIs called contract IDs.
can spoof a URL. But for our purposes, these nuances
Each entry also contains a universally unique identi-
are orthogonal. When we use the URL in this con-
text, we are not assuming a trusted relationship with fier (UUID) as a sequence of integers, and the mem-
the service provider at that address. The URL sim- ory location of a constructor for this component.
ply allows us to differentiate between different service When one component wants to use another, it gives
the component manager the URI, and the component
providers and the privilege sets that they offer.
manager gives it back an object.
We have not yet answered the question: How do
service providers notify Alice of their set of privilege This structure is relevant to our project. If we
names? We will do that in Section 4.4 below. could overwrite an entry in the hash table, we could
replace any native Firefox component with our own
component. As long as the custom component im-
4.2 The Browser plements all the XPIDL-defined functions, the rest of
the Mozilla Framework will treat it exactly like the
The Mozilla Framework is an open source software native component.
development framework. The most famous (cur-
rent) application to come out of it is the Firefox Extensions. The Mozilla Framework provides a
Web browser. The framework strives to be cross- simple mechanism for installing “extensions” from
platform, programming-language-independent, and over a network. The modification for proxy certifi-
locality-independent. The framework also has use- cates should be packaged as such an extension. After
ful properties that make it easier to modify—most all, few users would be willing to download a custom
notably the availability of the source code. browser with modified source code to use delegated
authentication.
The Framework. First, we quickly review We create new XPCOM components that handle
Mozilla’s high-level code architecture to help the proxy certificates. We then develop a GUI for this
reader to understand how we modified Firefox. application to interact with the local XPCOM com-
Mozilla’s organizes its code via the XPCOM (the ponents, and by extension, the proxy certificate li-
Cross-Platform Component Object Model). XPCOM brary. In this way, our extension can be divided into
is the system for organizing all of the software li- three pieces.
braries underlying Mozilla. In XPCOM, a central First, we need an interface to allow Alice to issue
component manager keeps track of a number of exclu- proxy certificates. At first glance, there’s no reason
for this to be built into the browser—it could easily fies to the public key of the keypair that signed the
be a stand-alone application. The reason it’s in the certificate that came before it [2]. But for delega-
Web browser is not for Alice’s benefit, but for the tion, the client might need to transmit several cer-
service provider’s benefit. As we will soon see (Sec- tificate chains, with one chain corresponding to each
tion 4.4), each service provider will propagate the set delegated identity. To make this work, we have the
of privilege names that it defines by talking to this ex-
client transmit the certificate chains for each dele-
tension. Then the user interface can show Alice a list gated identity in serial, and assert that the first proxy
of delegation-enabled service providers she’s visited, certificate in each chain must testify to the same pub-
as well as the privileges she can delegate for them. lic key. Figures 1 and 2 demonstrate the change in
3
Secondly, we need a back-end database to manage the protocol when we add multiple certificate chains .
proxy certificates issued to Bob. Network Security We do not permit Bob to use two different keypairs
Services (NSS), the cryptographic library underly- in the same session.
ing the Mozilla Framework, does not behave properly The “one public key” rule gives us an easy way
around proxy certificates. At best, it’s schizophrenic. to distinguish between certificate chains—when the
NSS will often accept them at first—but as soon as it validator sees a certificate in the chain that contains
realizes that the proxy certificates have been signed the same public key as the first certificate, this is the
by an end entity, it may immediately trash them. We bottom of a new chain. As an additional bonus, this
simply need a database that can handle proxy certifi- ensures that legacy certificate-validation code (appli-
cates properly, and will safely store them outside of cations that don’t know about multiple-identity dele-
NSS. gation) will reject any user that tries to assert multi-
Finally, we need a way for Bob to use his proxy ple delegated identities. A certificate chain, after all,
should not have a cycle.
certificate(s) in client-side SSL authentication. This
part of the extension will be responsible for getting From a theory standpoint, the idea that “public
the proxy certificates to the server during an SSL key” is a unique identifier of the user is also a cleaner
session. This is more difficult than it sounds, because way to think about PKI. The SDSI/SPKI certificate
this will require slight changes to the SSL protocol. model makes this observation elegantly. The secu-
rity of public-key crypto-systems implicitly depends
on the assumption that public keys are unique. If
4.3 SSL/TLS two users had the same public key, then their cryp-
tographic operations would be indistinguishable [3].
SSL/TLS is the ubiquitous protocol for secure com-
munication on the Internet2 . It consists of three es-
sential pieces. In the “Hello” phase, the client and 4.4 The Web Server
server initiate communication. In the “Handshake”
phase, the server and client exchange information For the Web server, we focused on Apache, which is
using a chosen asymmetric-key algorithm, with the both open-source and market-dominant. For Apache,
goal of establishing a session secret. This informa- we only have to modify mod ssl, which can hook into
tion may optionally include a certificate exchange, the Apache server from a dynamically loaded library.
and the server and client may optionally verify each We can easily distribute this library to server admin-
other’s certificates before they agree to connect. Fi- istrators to enable delegation.
nally, in the “Application” phase, we can now send
data across the network encrypted and MAC’d with
the session secret via our favorite symmetric-key al- Code Additions. We need to modify the certifi-
gorithm [2]. To incorporate delegation into this pro- cate validation code to accept proxy certificates and
tocol, we only need change a narrow segment of the to be able to recognize when the client is sending
client behavior during the Handshake phase. We can multiple chains of proxy certificates. Recognizing the
leave the rest of the protocol alone. proxy certificates is simple—that functionality comes
standard with OpenSSL, the cryptographic library
The Handshake phase changes because SSL/TLS underlying Apache. The validation of multiple chains
expects the client to transmit no more than one chain
of certificates. In this chain, each certificate testi- 3 TLS protocol extensions (RFC 4366) could make this
change more graceful by allowing the client to explicitly ask
2 SSL/TLS is a suite of several different standardized proto- the server to accept multiple certificate chains. These stan-
cols. All these protocols are just variations on the same high- dards are recent, and were not available at the implementation
level ideas, though. For our purposes, they’re interchangeable. phase of this project.
Bob's
The CA's
Public
Public
Bob Key, Server
Key, Self-
Signed by
Signed
the CA
Figure 1: Passing client certificates to the server by the TLS 1.0 standard. Notice that Bob’s public key
certificate is sent first, while the CA certificate that testifies to it comes afterwards. (The self-signed CA
certificate is optional. We include it here to enhance the illustration.)
Charlie's Charlie's Alice's Alice's
The CA's The CA's
Public Proxy Cert Public Proxy Cert
Public Public
Bob Key, for Bob, Key, for Bob, Server
Key, Self- Key, Self-
Signed by Signed by Signed by Signed by
Signed Signed
the CA Charlie the CA Alice
both certificates attest to
the same public key, Bob's
Figure 2: Passing multiple certificate chains to the server. As before, each certificate in the same chain
testifies to the one sent before it. The dashed arrow represents the point where a traditional TLS server
would register an error, because Bob did not sign the CA’s public key certificate.
of certificates is not so easy to implement, because it keep track of the list of privileges delegated by that
requires changes to both Apache and OpenSSL. It user.4 To ensure the same privilege is not counted
has also some tricky semantics. What happens if the twice, we ensure that if there are multiple certificate
client sends two certificate chains, and only one of chains, no two chains derive authority from the same
them is valid? On one hand, the SSL protocols im- end entity.
ply that if the server sees an invalid client certificate,
The SSLExclusiveIdentity directive tells the
it should notify the client by sending an error mes-
server to accept only the first identity. In truth, it
sage, and should cut short the SSL session. But it is the default case. But because these directives are
seems more natural for the server to accept the valid interpreted on a per-directory basis, this directive is
chain, and quietly fail to grant the privileges speci- useful for overriding the SSLMultipleIdentities di-
fied in the invalid chain. In this implementation, the rective in a parent directory.
tie goes to the specification—if one certificate chain
is invalid, the whole authentication should fail. This A server connection environment variable
will make it clearer from a user interface perspective
that something has gone wrong. SERVER[ ‘‘SSL DELEGATED IDENTITIES’’ ]
will be set to STRING, an ASCII character string en-
coded as a Lisp s-expression. It will contain the com-
Access Control Directives. We also define some
mon name of each certificate in an identity asserted
additional directives in the Apache configuration files.
by Bob. Obviously, this encoding doesn’t work if
These directives will tell Apache how to respond to
common names have parentheses. So if the server
proxy certificates. A legacy server will only accept a
sees a common name with a parenthesis, it simply re-
single certificate chain. So the modified server will, by
fuses to grant this identity. Application-level scripts
default, only accept a single identity. It will consider
can read this environment variable, and thus find out
multiple identities only when it sees a special directive
easily which identities Bob has.
in the configuration files.
We will also have directives for interpreting the
These new directives are as follows.
policy field of the ProxyCertInfo extension.
The SSLMultipleIdentities directive tells the 4 This is the simple-minded way to enumerate sets of priv-
server to allow a user to assert multiple identities
ileges delegated by a set of users. There are more special-
at once. The server will accept multiple certificate ized ways to model multiple simultaneous identities. We’ve
chains, one for each identity. And for each user, it will explored this a bit elsewhere [13].
The SSLRequirePrivilege directive takes a name When Bob wishes to assert the privileges granted
and a Description. The name must be an alphabetic by Alice, he authenticates with this certificate in a
character string (with no white space), and must not client-side SSL session. He will pass the server the en-
conflict with any other privilege names. It will speci- tire certificate chain, so that the server will see both
fying the name of a privilege as it appears in the proxy Alice’s end-entity certificate, and the proxy certifi-
certificate policy. If this directive is used, then Bob cate she signed for Bob. The server then interprets
will be allowed access in the current directory subtree the policy in the proxy certificate, and records in an
iff he has this privilege. If SSLMultipleIdentities environment variable that Alice granted Bob those
is given as well, Bob will need to have this privilege privileges.
for every identity that he tries to assert, or he will The reader should take note that this still leaves
be rejected. The Description portion of the directive the Web application with a lot of responsibility to
will be used for the propagation of the privilege set, make authorization decisions. Our system simply
which we will discuss shortly.
records what Alice has granted in the proxy certifi-
The SSLRequestPrivilege directive also takes a cate policy—it makes no claim that Alice had the
name and a Description. This directive is similar authority to grant Bob this privilege. An applica-
to the SSLRequirePrivilege directive. But in this tion can use the identity and privilege information to
case, Bob can access the directory whether or not he make authorization decisions; our directives are part
has the described privilege. The directive is used to of a server-level system that make it a easier to pro-
specify privileges that are not used to restrict access cess and manage this information.
at the server level, but are exposed via the environ-
ment variables anyway. (An application-level script
might use this privilege as part of an XACML-based 5 Our Prototype
decision request.)
Notice that with these directives, every server can To illustrate the functionality of our prototype, we’ll
define a set of privileges. After the server verifies consider an example. Nicholas Santos has hired De-
Bob’s proxy certificate chain(s), it will check the tective Sam Spade to represent him. He would like to
policy field of each ProxyCertInfo extension in the sign a proxy certificate for Spade that will delegate
chain, and grant Bob the privileges encoded in it. all his permissions to Spade for a period of five days.
It will then set a connection environment variable (He’s trying to get back a jeweled falcon, and he’s
SERVER[ ‘‘SSL DELEGATED PRIVILEGES’’ ] to be asked Spade to negotiate on his behalf.) The next
STRING, a Lisp s-expression. Bob’s privileges will be five figures illustrate the process he goes through to
stored as a list of lists. Each sub-list will start with do this.
the identity name (the user delegating to Bob), fol-
lowed by the privileges granted by that end entity. We will also discuss how to manipulate and issue
proxy certificates with NSS, the Mozilla Framework’s
cryptography library, and to understand them with
Apache. The point of this discussion is to examine
Privileges in the Grand Scheme. To deter- the particular successes and pitfalls of our implemen-
mine its set of privileges, the server parses all of tation, so that the reader has an idea of what it would
its access files for the SSLRequirePrivilege and take to reproduce such a system.
SSLRequestPrivilege directives described above,
then builds a set of ( name , description ) or-
dered pairs of privileges. They are keyed by the 5.1 The Mozilla Extension
name, so if the same name appears twice, one pair
is rejected. All servers implicitly define the reserved Making Room for Proxy Certificates. The
pair ( all , ‘‘All privileges’’ ). When Alice ProxyCertInfo X.509 extension must be attached
visits the server, the server gives her a cookie contain- to all proxy certificates and marked critical [14].
ing the privileges defined as Lisp s-expressions. The By specification, cryptographic libraries must trash
Firefox extension can then read these cookies, and any certificate with unrecognized critical extensions
add them to its list of ( service provider, privilege ) [6]. So before we load any components that handle
pairs. When Alice wants to sign a proxy certificate proxy certificates, the Object Identifier (OID) for the
for Bob, the user interface will provide her with a list ProxyCertInfo extension must be dynamically reg-
of all the servers that she’s ever visited that support istered with NSS. RFC 3820 additionally lists a num-
this form of delegation. ber of OIDs for proxy policy languages that must be
Figure 3: Using our Delegation Wizard (part 1):
Choosing a user certificate (any certificate for which Figure 5: Using our Delegation Wizard (part 3): The
we have the private key) and a target certificate to constraints page, which allows setting a path length
which its identity is delegated. constraint and a validity period.
Figure 4: Using our Delegation Wizard (part 2):
Choosing permissions to delegate. Each tree orga-
nizes the permissions by service provider. The tree
on the left is a list of all available permissions; the tree
Figure 6: Using our Delegation Wizard (part 4): Sav-
on the right is a list of the permissions that will be
ing the certificate to a file, so it can be e-mailed to
delegated. The tree of available permissions is built
Detective Spade.
by iterating through the cookies, and parsing them
for the permissions.
handling code, modifying it slightly for proxy certifi-
cates (and for publicly exported APIs), and compiling
it into the extension. It’s not academically interest-
ing, and we will say no more of it.
Issuing Proxy Certificates. To issue a proxy cer-
tificate, we need an issuer and a target. The issuer
testifies to the private key that will sign the new cer-
tificate. The target testifies to the name and public
key that will be the subject of the new certificate (see
Figure 3). This information is used to construct a cer-
tificate request internally. We call an NSS function
to transform this certificate request into an unsigned
certificate, at the same time adding an issuer and a
validity period.
When creating any certificate—not just proxy
certificates—there are standards and there are styles.
The first is mandated in writing, the second is man-
dated by strong social pressure and convention. For
standards, it’s best to work straight from the source,
RFCs 3280 and 3820. For style, we recommend Peter
Figure 7: Using our Delegation Wizard (part 5): The
Gutmann’s “X.509 Style Guide.”[5]
ASN.1 structure of the new proxy certificate.
For every proxy certificate we issue, we copy the
name and public key directly from the target certifi-
cate. Per Gutmann’s recommendation, we use the
understood by any proxy certificate implementation.
time in seconds since the UNIX epoch as the serial
Those OIDs must be registered as well.
number, to ensure unique serial numbers5 .
The ProxyCertInfo extension contains three
We additionally attach several extensions. We
fields. The optional pCPathLenConstraint describes
have already covered the ProxyCertInfo extension.
the depth of the cert chain below this one. The re-
On the advice of OpenSSL’s proxy certificate guide
quired policyLanguage is an OID for a policy lan-
[8], we include a BasicConstraints extension that
guage. The optional policy is, as noted earlier, the
indicates that this certificate may not be a CA.
designated place for issuers to record policy info on
We include a SubjectKeyIdentifier extension that
what permissions they’re delegating.
contains a SHA-1 hash of the target certificate’s
NSS allows developers to write templates—arrays DER-encoded public key data. Finally, we attach
of constants—that tell the ASN.1 encoder how to en- an AuthorityKeyIdentifier if and only if the is-
code and decode types. A few wrapper functions and suer certificate has the SubjectKeyIdentifier ex-
a ProxyCertInfo template are required to encode tension. If it does, the key identifier from the issuer
and decode that extension. The Mozilla Framework is simply copied into the key identifier field of this
also has a separate ASN.1 handler that pretty prints AuthorityKeyIdentifier.
ASN.1 sequences for GUIs. A few more functions
The SubjectKeyIdentifier and
on top of that object will make the ProxyCertInfo
AuthorityKeyIdentifier extensions are not
extension readable from a dialog box, as shown in
really necessary, and may just be another example
Figure 7.
of redundancy in the X.509 standard. However,
The reader should be aware that in order to handle they do reinforce the idea that the public key
proxy certificates adequately, our extension needed a identifier is a better indicator of identity than a
lot more infrastructure than this. To handle the cer- X.500 distinguished name, because an identity is
tificates internally, the extension needed access to raw only as unique as its keypair. We mainly include
data structures, including wrapper objects for the 5 A malicious user could certainly issue multiple certificates
certificates, for their validity periods, and for some
with the same serial number by changing the system clock,
certificate-based GUI objects. But these needs were but this would do no actual damage. It would merely spite the
satisfied by simply copying the existing certificate- standard.
this extension for ideological reasons. But we should “delegator” certificate is the end-entity certificate in
mention that these extensions made the certificate the chain ending in this proxy certificate. It names
validation code easier to debug, because the crypto the end entity from which this proxy certificate de-
library code that compared two key identifiers was rives its identity. (In chains with only one proxy cer-
usually much simpler than the crypto library code tificate, the issuer is the delegator.)
that compared X.500 names. The database can be described in two sections: del-
NSS did not encode the AuthorityKeyIdentifier egated certificates and the user’s proxy certificates.
correctly, so we copied the encoding function, fixed it, The sections must not be assumed to be mutually
and compiled it into our library. exclusive, although they likely will be for most users.
Once the extensions are added, the certificate is The portion for delegated certificates is merely a log.
It tells Alice which proxy certificates she has issued,
ready to be signed. A Mozilla XPCOM component
and allows her to re-export them if she needs to send
provides functionality to log into any PKCS #11 in-
terfaces (cryptographic tokens), asking the user for them again (Figure 8). The other section of the
a password if we need one. Other publicly-exposed database holds certificates delegated to the user, cer-
NSS functions allow us to get a handle on the private tificates for which the user has the private key (Fig-
ure 9). These are the identities that can be used in
key, and use it to sign the data in a DER encoding.
an SSL session.
To our knowledge, this is the first implementation
of a proxy certificate issuer with NSS.
Using Proxy Certificates, in Theory. The code
to inject proxy certificates into an SSL session per-
Storing Proxy Certificates. Once we have a forms an interesting acrobatic stunt.
DER encoding of the proxy certificate, we need a
place to store it. NSS is no good, for numerous rea- Recall from the original discussion of the Cross-
sons. It is not aware that end-entities can sign cer- Platform Component Object Model (XPCOM) that
tificates. Furthermore, this Firefox extension may be the Mozilla Framework keeps all its components in a
uninstalled, and if it is, it shouldn’t be abandoning hash table, hashed by a human-readable contract ID.
proxy certificates in the regular NSS database. If we ask the component registrar to load a compo-
nent with the same contract ID, the registrar will, by
The key insight to storing proxy certificates is that default, simply overwrite that entry of the hash table.
the storage medium does not need to store any secrets From reading the source code, this feature seems to be
(such as private keys). It can leave the private keys intentional, although it is not otherwise documented.
in the NSS secure storage, and only needs to remem- But this also means that there is no documentation
ber where those private keys are located. The only assuring us that this is a safe mechanism for extension
disadvantage of this method is that the user could development. Thus, we use it cautiously.
delete his private key from the NSS database, thus
rendering his proxy certificates useless. Our imple- This feature allows us to play man-in-the-middle
mentation does not protect against this case; it just with Firefox’s SSL/TLS handling code. First, the
blames the user for the problem. XPCOM objects that handle SSL and TLS sessions
are registered at a second contract ID. Then, custom
Because proxy certificates do not need to be pro- SSL/TLS handlers are registered at the first contract
tected for confidentiality, it would have sufficed to IDs, overwriting the entries there. These custom han-
keep them in any non-volatile storage mechanism. In dlers intercept method calls intended for the origi-
our extension, they are simply stored in an SQLite nal handlers, change the passed arguments, and then
database6 . The database key for each proxy certifi- pass the altered arguments along to the traditional
cate is derived from the serial number and the issuer handlers by looking them up at the second contract
name. Because issuers should issue certificates with ID. The same man-in-the-middle game can be played
unique serial numbers, this database key should be with return values. Thus, we can change the method
unique. Each entry in the database also contains a arguments and return values at will to produce the
DER encoding of the certificate, as well as database desired effect. That’s the theory—but it’s not so sim-
keys to access the issuer certificate, “delegator” cer- ple in practice.
tificate, and private key in the regular database. The
6 SQLite is a open source file-based database engine with
Using Proxy Certificates, in Practice. The ac-
a C API that accepts and executes queries in a subset of the
SQL language. More information can be found at http://www. tual implementation is far more complicated and in-
sqlite.org/. volves several levels of indirection. The flow can be
Figure 8: Viewing the certificates in the database that have been issued by this user.
Figure 9: Viewing the certificates in the database that have been issued to this user. Observe that only fools
delegate their privileges to this particular user.
confusing. There are custom SSL/TLS handlers that tom certificate-retrieval callback only returns a single
intercept calls to the traditional SSL/TLS handlers in certificate—NSS builds the rest of the chain. Fortu-
XPCOM. But those handlers turn around and use the nately, there is a way to fool NSS into building an
pure C NSS libraries to handle the SSL handshake. arbitrary chain. NSS stores its certificates in data
Our method only allows us to intercept method calls structures with a lot of redundant information. These
between the object-oriented XPCOM components. data structures contain a DER encoding of the certifi-
Pure C method calls cannot be intercepted by the cate, as well as pre-computed fields so that it doesn’t
same trick. So we need to use a different trick. have to decode and re-encode the certificate repeat-
edly. But there’s the rub: it uses the values of the pre-
The SSL/TLS handler objects allow clients to set
computed fields to decide which certificates to push
a callback function that retrieves the client certificate
for the SSL handshake. (In the NSS documentation, onto the certificate chain, but the it uses the DER
this callback is known as the ClientAuthDataHook encodings to construct the bits of data actually sent
[12].) We can apply a second man-in-the-middle across the network. And it assumes these fields are
strategy to this function, by changing the function in-sync. By feeding it out-of-sync data, we can fool
pointer to point to a function of our choosing. NSS NSS to build a certificate chain based on the mock-up
certificate fields, and NSS will end up sending arbi-
calls the callback function when it needs a certificate.
trary DER data across the SSL session. This DER
Unfortunately, that’s not the end of it. The cus- data will, by more than coincidence, be the proxy
New Directives. The Apache build system leans
heavily on an automated parser generator. A
single macro can add a new configuration direc-
tive, and define the callback function that will
process the arguments to that directive. The
new proxy certificate-handling directives defined in
Section 4.4 were designed to take advantage of
this existing infrastructure. Adding them is not
complicated. The SSLMultipleIdentities and
SSLExclusiveIdentity directives are processed by
changing global context variables. The two privilege
directives are processed by adding them to a global
Figure 10: Registering two proxy certificates to use privilege table, sorted by unique privilege name. For
in an SSL session. The chains for both will be sent each directory-specific SSLRequirePrivilege direc-
in client-side SSL/TLS authentication. tive, we take the corresponding directory context
structure and give it a pointer to the required entry
in the global privilege table.
Privilege Propagation. Apache comes packaged
with a module, mod usertrack, that enables track-
ing cookies. This module supplies the basis for the
code needed to pass the supported privilege set to the
client via a cookie. We register a hook function with
the main Apache module to get called every time a
client connects. When this function gets called, we
can iterate through the permission table, encode it
in a cookie, and add that cookie to the HTTP reply
headers. (Actually, since the same cookie is transmit-
Figure 11: This test page shows the values of en- ted each time, and no permissions can be added after
vironment variables SSL DELEGATED IDENTITIES and the server starts, we just compute this cookie once.)
SSL DELEGATED PRIVILEGES.
Certificate Verification. Because there may be
certificates that we intend to transmit. multiple chains of proxy certificates in an SSL session,
OpenSSL needs to be modified to accept a) proxy
And that’s how an extension can add limited dele- certificates, and accept b) multiple chains of them.
gation with proxy certificates to Firefox without mod-
ifying any existing code.7 Proxy certificate support in OpenSSL is contingent
upon the state of a particular environment variable.
But the Windows code for reading this environment
variable did not appear to be working correctly, so
5.2 The Apache Codebase OpenSSL was modified to accept proxy certificates
all the time.
The Apache codebase is much smaller than the Apache lets OpenSSL take care of the standard cer-
Mozilla codebase, and our application allows its tificate verification, but sets a callback function to go
source code to be modified. The changes made to through the certificates after OpenSSL has verified
Apache are thus much more lightweight. them, and do any custom verification. The OpenSSL
verification function normally stops immediately as
7 A lot of our reviewers were surprised by this result—in soon as it can’t find the issuer for a certificate in the
particular, that a Firefox extension could throw so much weight chain, then looks in the local store for a trusted chain
around and behave so intrusively. It’s worth pointing out that of issuers. The verification succeeds iff it finds such a
the term “extension” is slightly misleading. “Extension” sug-
chain. If there are multiple chains, OpenSSL accepts
gests that the software is sandboxed; that it can only “extend”
the browser. But in reality, installing an extension is just as the first chain and says that it is satisfied. This ap-
dangerous as executing a binary. pears to be non-standard. We modify the OpenSSL
verify function so that after it verifies the first chain, end-user standpoints.
it looks at the first certificate in this chain and the
In order to sign these delegation certificates, both
first certificate in the chain of the “unverified” certs.
the regular user and her guest would visit a Web site
If these two certs match, and the global flag for mul- (the guest via a captive portal). This site provided
tiple chains is set, it calls itself recursively on the an interface wherein the regular user could verify the
“unverified” cert chain to verify the other chains. guest and create the certificate, and the guest could
When the Apache callback function receives the import the new certificate into her browser. Neither
verified certificate chains, it iterates through them had to install new software; they only needed to run
again. For each chain, it looks for the end-entity a trusted Java applet [4].
(the first non-proxy certificate) in each chain, and Notice that the Greenpass project and our project
pushes it onto an identity list. It also interprets the
ran into a similar problem: how does Alice transmit a
ProxyCertInfo extension’s policy field, and deter-
delegation certificate to Bob? We could circumnav-
mines which privileges are delegated all the way down igate this problem by using public e-mail. Because
the chain. The implementation of this part should be the guests in Greenpass did not have access to the
self-evident. network, they accomplished the same task with the
assistance of an internal Web server.
6 Related Work
Distributed Systems. Delegation offers a decen-
tralized way to propagate privileges. It can also be
SDSI/SPKI SDSI/SPKI is an alternative certifi-
used to delegate a limited set of privileges for a very
cate standard that stresses simplicity over the com-
limited time to a less trustworthy key. For these
plication of X.509.
reasons, people working in distributed systems love
The SDSI/SPKI group at MIT developed an delegation. They use it as a lightweight mechanism
Apache module and Netscape Communicator plug-in for granting privileges to temporary processes. It’s
that allowed users to authenticate with the server us- lightweight because it doesn’t require a central au-
ing SDSI/SPKI certificates. (Project Geronimo was thority, and no new identities need to be created. The
the name of the Apache module.) To accomplish this Grid created proxy certificates to take advantage of
goal, they developed an entire new protocol on top of these features of delegation [15, 11]. Marchesini et al
HTTP that performed this authentication. In their married Grid-style MyProxy to hardware trustwor-
system, the server notified the client of the permis- thiness levels [9]. Howell specifically extended Lamp-
sions it supported by sending an access control list son’s access control calculus to include delegation, so
(ACL) to the client during the authentication hand- that he could use formal semantics to analyze dis-
shake. (Thus, the protocol handshake was used for tributed systems that lacked a central authority [7].
authorization as well as authentication.) The client
could then use this ACL to determine which certifi-
cates to send back [10]. This ACL solved the prob- 7 Conclusions
lem that we addressed by sending the permissions in
cookies.
In the real world, users like to delegate privileges.
Our system differs in that it is also concerned with If next-generation authentication systems (such as
providing the user with an interface to delegate their PKI) do not allow for this delegation, users will find
credentials. We also depend more on the existing a way to work around them—and undermine the se-
protocols and standards (X.509 and SSL/TLS) when curity that drove adoption of the strong system in
we can, rather than creating new ones. the first place. In this paper, we have presented both
the design and prototype of a way to extend PKI (via
Greenpass The Greenpass project grafted SDSI- standard client-side SSL) to permit this delegation.
SPKI delegation on top of X.509 identity certificates When users can delegate rights to each other, we
for EAP-TLS. In that project, system administrators can end up with a user with a set of delegated rights
could maintain a secure wireless network without the from multiple sources. This raises the question: how
hassle of verifying the identity of temporary guests. can applications make sense of this heterogeneous set
Regular users could delegate access to the network of rights? Consider some real-world examples. When
to their guests. This made the network more man- a group of people elect a delegate to the U.S. Electoral
ageable and usable from both the administrative and College, they delegate a simple duty—to elect a presi-
dent. But when a number of persons sign their power nical Report PCS-TR99-361, Dartmouth College,
of attorney over to a single lawyer, a complex set of 1999.
rules governs how the lawyer can use these rights, [8] Richard Levitte. HOWTO Proxy Certificates,
to prevent a conflict of interest. Clearly then, some May 2005. Retrieved on March 11, 2006
applications need fine-grained controls over how to from http://www.openssl.org/docs/HOWTO/proxy_
enforce delegated rights, and some don’t. Further certificates.txt.
exploration there is one area of future work. Another [9] J. Marchesini and S. W. Smith. SHEMP: Secure
area is exploration of the user interfaces involved in Hardware Enhanced MyProxy. In Proceedings of
delegation. Third Annual Conference on Privacy, Security and
Trust, October 2005.
There is a lot of political theory behind the de-
sign of X.509 and how it propagates authority. En- [10] Andrew J. Maywah. An Implementation of a Secure
gineers have politics too. Indeed, certificate theory Web Client Using SPKI/SDSI Certificates. Master’s
thesis, Massachusetts Institute of Technology, May
raises questions about authority and trust that have
2000. Retrieved on-line from http://theory.lcs.
been wrestled with since the Greeks. We have no mit.edu/~cis/theses/maywah-masters.ps.
hope of setting those issues to rest here. But the
reader should be aware that one motivation behind [11] J. Novotny, S. Tueke, and V. Welch. An Online
Credential Repository for the Grid: MyProxy. In
this paper is the political ideal that Alice and Bob
Proceedings of the 10th International Symposium on
should have the authority to delegate their own priv- High Performance Distributed Computing (HPDC-
ileges. This paper seeks to empower them with that 10), pages 104–111. IEEE, 2001.
authority.
[12] Bob Relyea, editor. Network Security Services
(NSS). The Mozilla Foundation, May 2005. Re-
trieved on March 11, 2006 from http://www.
Code Availability mozilla.org/projects/security/pki/nss/.
[13] Nicholas Santos. Limited Delegation (Without Shar-
We plan to make the code available for public down- ing Secrets) for Web Applications. Technical Report
load in 1Q2007. TR2006-574, Dartmouth College, May 2006.
[14] S. Tuecke, V. Welch, D. Engert, L. Pearlman, and
M. Thompson. Internet X.509 Public Key Infras-
References tructure (PKI) Proxy Certificate Profile. IETF RFC
[1] David Boswell, Brian King, Ian Oeschger, Pete 3820, June 2004.
Collins, and Eric Murphy. Creating Applications with [15] Von Welch, Ian Foster, Carl Kesselman, Olle Mulmo,
Mozilla. O’Reilly, September 2002. Retrieved on-line Laura Pearlman, Steven Tuecke, Jarek Gawor, Sam
from http://books.mozdev.org/index.html. Meder, and Frank Siebenlist. X.509 Proxy Certifi-
cates for Dynamic Delegation. In 3rd Annual PKI
[2] T. Dierks and C. Allen. TLS Protocol Version 1.0.
Research and Development Workshop, 2004.
IETF RFC 2246, January 1999.
[3] C. Ellison, B. Frantz, B. Lampson, R. Rivest,
B. Thomas, and T. Ylonen. SPKI Certificate Theory.
IETF RFC 2693, September 1999.
[4] Nicholas C. Goffee, Sung Hoon Kim, Sean Smith,
Punch Taylor, Meiyuan Zhao, and John Marchesini.
Greenpass: Decentralized, PKI-based Authorization
for Wireless LANs. In 3rd Annual PKI Research
and Development Workshop Proceedings, pages 26–
41. NIST/NIH/Internet2, 2004.
[5] Peter Gutmann. X.509 style guide. October 200.
Retrieved on March 9, 2006 from http://www.cs.
auckland.ac.nz/~pgut001/pubs/x509guide.txt.
[6] R. Housley, W. Polk, W. Ford, and D. Solo. Internet
X.509 Public Key Infrastructure Certificate and Cer-
tificate Revocation List (CRL) Profile. IETF RFC
3280, April 2002.
[7] Jon Howell and David Kotz. An Access Control Cal-
culus for Spanning Administrative Domains. Tech-
Dartmouth College PKI Lab
Limited Delegation
for Client-Side SSL
Nick Santos and Sean W. Smith
Dartmouth College
6th Annual PKI R&D Workshop
April 18, 2007
Dartmouth College PKI Lab
Worse Than Failure
(doubles as a database of usability lessons)
From http://worsethanfailure.com/Articles/Twice_Annual_About_Security.aspx
2
Dartmouth College PKI Lab
But sharing passwords is a great use case!
Sean Smith says:
• It’s not about who you are.
• It’s not about what you know.
• It’s about who sent you!
“Sharing passwords” might as well be called
“user-to-user delegation of a well-defined set of
privileges via a shared secret”
3
Dartmouth College PKI Lab
Who Understands User-to-User Delegation?
• Lawyers
• Doctors and Nurses
• Most Democracies
• Managers and Secretaries
• H&R Block
• Anyone who has ever gone on vacation
• Teenage babysitters everywhere
And Who Doesn’t?
• Traditional PKI
4
Dartmouth College PKI Lab
A Belated Summary of This Talk
Three Major Questions We Want to Think About:
• How important is user-to-user delegation for a usable
PKI?
• How could this feature complicate (and enhance) a PKI
implementation?
• How feasible would it be to build and deploy such a
feature?
5
Dartmouth College PKI Lab
The Experiment
To help give us insight into some of these questions,
we built a bunch o’ stuff for client-side SSL:
• Limited delegation using proxy certificates
• …with a user interface
• …for use with Mozilla Firefox and an Apache web server
• …as part of a deployable browser-extension with a
corresponding server plug-in
6
Dartmouth College PKI Lab
Proxy Certificates
Easy implementation on top of X.509
(all we do is add a ProxyCertInfo extension)
Here, Charlie has
access to Alice’s hay
With traditional
X.509, the chain
must end here
Dartmouth College PKI Lab
What else can we do with delegation?
Multiple Identities!
Alice Xavier Yolanda Zeke
Bob
(with identities A, X, Y, Z)
If people are delegating access willy-nilly, maybe we should let Bob speak
on behalf of multiple people at once?
Dartmouth College PKI Lab
Modified Client-Side SSL
(There’s more to it than just updating cert-validation code!)
The standard…
…and non-standard, with multiple identities
Dartmouth College PKI Lab
Firefox
Alice will
use her web browser to issue proxy
certificates
Bob will
use his web browser to manage his
proxy certificates
A point to ponder:
how does Alice give Bob the proxy
certificate she issued?
Dartmouth College PKI Lab
Apache
The Server will
send a list of “privileges” that it supports—
to Alice, in a cookie
Alice will
choose a subset of this
list of privileges to delegate to Bob
Bob will
present one or more certificate chains to
The Server in an SSL session
Dartmouth College PKI Lab
User Flow
12
Dartmouth College PKI Lab
User Flow
Service providers use cookies
to tell Alice what
“permissions” they support.
13
Dartmouth College PKI Lab
User Flow
14
Dartmouth College PKI Lab
User Flow
By the proxy cert standard, I
shouldn’t be creating proxy
certs for pre-existing private
keys.
But it’s so much easier to
ignore this!
15
Dartmouth College PKI Lab
User Flow
Teaching NSS to read and
write proxy certificates:
Easy!
16
Dartmouth College PKI Lab
User Flow
Teaching NSS to store proxy
certificates without blowing
up:
Really hard!
17
Dartmouth College PKI Lab
User Flow
Thanks to XPCOM, we can dynamically (at run-time)
unload Firefox’s SSL handlers, and load our own in their
place. So we can enable/disable delegation as needed.
18
Dartmouth College PKI Lab
Victory!
19
Dartmouth College PKI Lab
Conclusions
• Firefox and Apache, with their dynamically loaded modules, are
well-architected to deploy such a system
• Delegation does complicate PKI implementations, especially if
you want limited privileges and multiple identities
• How hard will it be to teach users how to delegate their PKI
credentials? We still have no idea!
20
Dartmouth College PKI Lab
Thanks
Thanks to our friends at the
Dartmouth College PKI Lab,
Doug McIlroy, Michael Fromberger,
our PKI07 Reviewers,
and the National Science Foundation
21
www.oasis-open.org
The OASIS IDtrust
(Identity and Trusted Infrastructure)
Member Section
John Sabo, CA, Inc.
For more information please see:
http://www.oasis-idtrust.org/
For more information related to „Joining OASIS,‟ please see:
http://www.oasis-open.org/join
www.oasis-open.org
OASIS provides a neutral setting where
government agencies, companies, research
institutes, and individuals work together to
advance the use of trusted infrastructures.
The OASIS PKI Member Section has restructured
as the OASIS Identity and Trusted Infrastructure
(IDtrust) Member Section
The IDtrust MS has expanded its scope to
encompass additional standards-based identity
and trusted infrastructure technologies, policies,
and practices.
Transformation
Old PKI Forum
Migration to OASIS PKI MS in November 2002
One TC
Focus on use of PKI and addressing barriers to
deployment, not development of technical
standards
London OASIS Adoption Forum in November
2006
Led to transformation into IDtrust MS in 2007
Four Strategic Focus Areas:
• Identity and Trusted Infrastructure components
such as cataloguing and carrying out studies and
projects addressing technology-based Identity and
Trust models and standards, including those that
are PKI-based as well as those utilizing other
security mechanisms; relevant protocols and
standards; trust infrastructures in use; and costs,
benefits and risk management issues
• Identity and Trust Policies and Enforcement,
including policies and policy issues; policy
mapping and standardization; assurance; technical
validation mechanisms; and trust path building and
validation
Four Strategic Focus Areas:
• Education and Outreach: documenting trust use
cases and business case scenarios, best practices
and adoption reports and papers; organizing
conferences and workshops; and establishing
Web-based resources
• Barriers and Emerging Issues associated with
Identity and Trusted Infrastructures, including data
privacy issues; interoperability; cross border/
organizational trust; outsourcing; cryptographic
issues; application integration; and international
issues
PKI IDtrust Steering
Committee
Dr. Abbie Barbir, Nortel
June Leung, FundSERV
Arshad Noor, StrongAuth
John Sabo, CA, Inc.
Ann Terwilliger, Visa International
Two Technical
Committees
Enterprise Key Management
Infrastructure TC
Chairs:
Hans van Tilburg, Visa
Arshad Noor, StrongAuth
PKI Adoption TC
Chair: Stephen Wilson, Lockstep LLC
www.oasis-open.org
Enterprise Key Management
Infrastructure (EKMI) TC
www.oasis-open.org
Business Motivation
Regulatory Compliance
PCI-DSS, HIPAA, FISMA, SB-1386, etc.
Avoiding fines
ChoicePoint $15M, Nationwide $2M
Avoiding lawsuits – BofA, TJX
Avoiding negative publicity
VA, IRS, TJX, E&Y, Citibank, BofA, WF,
Ralph Lauren, UC, etc.
e-Business/e-Government
Challenges
Sharing data while keeping it secure
Protected Critical Information
Infrastructure (PCII) at the DHS
Medical, Taxpayer and Employee data
Other sensitive data
Protecting data across the enterprise
Laptops, Desktops, Databases, PDAs,
Servers, Storage devices, Partners, etc.
Encryption Problem
● Generate ● Generate ● Generate ● Generate ● Generate ● Generate
● Encrypt ● Encrypt ● Encrypt ● Encrypt ● Encrypt ● Encrypt
● Decrypt ● Decrypt ● Decrypt ● Decrypt ● Decrypt ● Decrypt
● Escrow ● Escrow ● Escrow ● Escrow ● Escrow ● Escrow
● Authorize ● Authorize ● Authorize ● Authorize ● Authorize ● Authorize
● Recover ● Recover ● Recover ● Recover ● Recover ● Recover
● Destroy ● Destroy ● Destroy ● Destroy ● Destroy ● Destroy
.........and on and on
Encryption Solution
• Encrypt
• Decrypt
• Encrypt
• Decrypt
SKS Server
• Encrypt • Generate
• Decrypt • Protect
• Escrow
WAN
• Authorize
• Recover
• Encrypt • Destroy
• Decrypt
SKS Server
• Encrypt
• Decrypt
• Encrypt
• Decrypt
What is an EKMI?
An Enterprise Key Management
Infrastructure is:
“A collection of technology,
policies and procedures for
managing all cryptographic keys in
the enterprise.”
EKMI Characteristics
A single place to define EKM policy
A single place to manage all keys
Standard protocols for EKM services
Platform and Application-independent
Scalable to service millions of clients
Available even when network fails
Extremely secure
EKMI Components
PKI
For digital certificate management; used for
strong-authentication, and secure storage &
transport of symmetric encryption keys
Symmetric Key Management System
SKS Server for symmetric key management
SKCL for client interactions with SKS Server
EKMI = PKI + SKMS
EKMI-TC Goals
Standardize on a Symmetric Key
Services Markup Language
(SKSML)
Create Implementation &
Operations Guidelines
Create Audit Guidelines
Create Interoperability Test-Suite
EKMI-TC
Members/Observers
FundServ, PA Consulting, PrimeKey, Sterling
Commerce, StrongAuth, US DoD, Visa
International, Wave Systems
Booz Allen Hamilton, EMC (RSA), Entrust, Mitre
Corporation, Oracle, Sigaba, Symantec
Individuals representing Audit and Security
backgrounds
PKI Adoption TC
The PKI environment c. 2006
PKI is resurgent, driven by applications needing
signatures, esp. for paperless transacting
Embedded keys & certs now commonplace
Certificates now more about relationships
between issuer & subject than “identity” of
strangers
In the midst of paradigm shift to identity plurality
PKI becoming application specific,
not general purpose
Resurgent, Embedded
Business-Driven PKI
Closed/Vertical/Community based schemes
US PIV, Identrus, ICAO e-passports, CableLabs,
Skype, BankID (Sweden)
National ID smartcards with PKI
Hong Kong, Malaysia, Estonia, Belgium, Thailand …
Health smartcards with PKI
France, Germany, Taiwan, Italy, Austria, Australia …
Digital Credentials based on certificates
US Patent Office, Australia, France, Taiwan, …
PKI Adoption: Draft objectives
Note: These are proposed objectives of the new PKI Adoption TC,
yet to be ratified by the Committee.
Continue to overcome obstacles with targeted practical
initiatives that improve understanding of PKI
Re-vitalise and complete the Third International Survey
See www.oasis-open.org to download survey
Canvass and disseminate PKI case studies
Modernise the PKI message so it reflects real needs
De-mystify legal, governance and interoperability issues
Liaise more closely with other OASIS efforts
Study on the Use of PKI in
OASIS Standards
Chet Ensign
Overall project goals
Document use & applicability of PKI for
OASIS standards
Identify expectations re authentication,
integrity, confidentiality, etc.
Identify assumptions re specific PKI
methods/systems available
List explicit standards referenced
Identify possible issues & barriers
Provide recommendations
Status
2nd stage of study on use of PKI &
related technologies in OASIS
standards
Study has 3 stages:
Update earlier 2003 report
Write new report on applicability,
expectations and assumptions in
OASIS TCs
Provide briefings to Member Section
Approach to TC reviews
Group TCs by importance of e-business
services to TC success
Interview 3 - 5 TC chairs or technical leads
Review email archives & documents for
discussion of:
Services, e.g. authentication, trust, encryption, digital
signature
Specific standards, e.g. PKI, X.509, Kerberos, SAML
Summarize trends, observations, themes &
provide any recommendations
Preliminary observations (1)
Acronym “PKI” not broadly used. Instead,
TCs discuss services (e.g. authentication,
digital signature) or standards (e.g. X.509,
Kerberos, SAML)
Concepts and issues generally lumped
under “Security”
„End-user‟ standards (e.g. Election &
Voter Services, Court Filing) leave
solution to implementation or reference
other standards
Preliminary observations (2)
PKI perceived as big, expensive and
complex relative to the issues users
believe they need to solve. Also has
reputation for interoperability problems.
Many standards leave flexibility to
implementation to ensure use.
General sense that buyers do not
understand issues, so do not call for PKI
solutions.
TC PKI References
Closed TCs
Since 09/03, 27 TCs closed
22 in original 2003 study; 5 were not
Of 22, only 7 (about 1/3/) discussed
PKI concepts or standards in
archives or specifications
Only 1 explicitly addressed
authentication & security in its spec
Closed TCs
Published documents & discussion of
PKI (4 TCs):
Business Transactions; Application
Vulnerability Description Language;
Directory Services ML; XML Common
Biometric Format
XML Common Biometric Format was
only spec to address PKI in depth
New TCs
Since 09/03 draft, 37 TCs started
6 completed & covered above
Of 31, 15 (about 1/2/) discuss PKI
concepts or standards in archives or
documents
7 explicitly address PKI concepts or
issues in their work
New TCs
New TCs most actively addressing PKI
issues, concepts and standards:
Enterprise Key Management Infrastructure
Framework for Web Services Implementation
International Health Continuum
WS Quality Model
WS Reliable Exchange
WS Secure Exchange
WS Transaction
Study Next Steps
Chet Ensign now completing
interviews
Analysis of findings
Development of inferences and
conclusions
Final report and presentation to the
MS within next two months
IDTrust Summary
Steering Committee developing new
work plan for 2007 and 2008
Many opportunities to get involved
Invitation to join OASIS and
participate in the MS and/or TCs
Contact Dee Schur
Dee.schur@oasis-open.org
On Standardization of Kerberos
Names in X.509 Certificates
Paul Rabinovich
Exostar, LLC
6th Annual PKI R&D Workshop
April 18, 2007
Names in X.509 Certificates
Names Other name
Subject Type
Subject alternative Name proper
name Examples
E-mail address
DNS name
Federal Agency Smart
IP address Credential Number
URI (FASC-N)
X.500 name
Permanent identifier
Other (RFC 4043)
Name constraints User principal name
Kerberos Names: Applicability
MS Windows J2EE
Kerberos GSS-API and Kerberos
Ubiquitous in Ubiquitous in enterprise
enterprise
Primary name: UPN Kerberos names
UNIX Ubiquitous
Vintela Authentication Unique
Service Stable
Centrify DirectControl
Requirements
Standardize
Name representation
Name constraint representation
Option 1: MS Windows
Option 1: Name Constraints
[NameConstraintsExtension]
Include=Permit
Exclude=Exclude
Critical=TRUE
[Permit]
UPN=xyz.com
Exact
UPN=.xyz.com match
[Exclude]
Subtree
match
Option 1: Analysis
Pros
Available everywhere MS Windows is
Cons
Proprietary object ID
Option 2: RFC 1964
Object ID
iso(1) member-body(2) United
States(840) mit(113554) infosys(1)
gssapi(2) krb5(2) krb5_name(1)
Name encoding
As in MS Windows
Name constraints
As in MS Windows
Option 2: Analysis
Pros
Standard-based object ID
Cons
Name encoding foreign to Kerberos
Option 3: PKINIT
KerberosString ::= IA5String
Realm ::= KerberosString
NT_PRINCIPAL
PrincipalName ::= SEQUENCE {
name-type [0] Int32,
name-string [1] SEQUENCE OF KerberosString
} OtherName
type
id-pkinit-san OBJECT IDENTIFIER ::= {
iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) x509SanAN (2)
}
OtherName
KRB5PrincipalName ::= SEQUENCE { value
realm [0] Realm,
principalName [1] PrincipalName
}
Option 3: Name Constraints
Exact match
EXAMPLE.COM matches EXAMPLE.COM
Suffix match
%EXAMPLE.COM matches FOO.EXAMPLE.COM
Escaping
\%EXAMPLE.COM matches %EXAMPLE.COM
\\%EXAMPLE.COM matches \%EXAMPLE.COM
Option 3: Analysis
Pros
Standard-based object ID
Kerberos-native name encoding
Cons
Still OtherName
Option 4: X.509 GeneralName
Name encoding
GeneralName ::= CHOICE {
otherName [0] OtherName,
rfc822Name [1] IA5String,
dNSName [2] IA5String,
x400Address [3] ORAddress,
directoryName [4] Name,
ediPartyName [5] EDIPartyName
uniformResourceIdentifier [6] IA5String,
iPAddress [7] OCTET STRING,
registeredID [8] OBJECT IDENTIFIER,
krb5PrincipalName [9] KRB5PrincipalName
}
Name constraint: As in Option 3
Option 4: Analysis
Pros
Well-known name type
Kerberos-native name encoding
Cons
Requires change to X.509 GeneralName
Not too bad: backward compatibility still
maintained
Summary
Option Name Name Type Object ID Name Encoding Name
Constraints
1 OtherName Microsoft UTF8String Exact/subtree
2 OtherName RFC 1964 (GSS-API) As above As above
3 OtherName PKINIT PKINIT Exact/prefix
4 GeneralName N/A As above As above
Regardless of the option need to
Take advantage of Kerberos principal names
Standardize name encoding
Define syntax and semantics for name constraints
Acknowledgement
David Cooper (NIST) for helpful
suggestions
Thank You.
E-Government Program
E-Government Program Office
April 2007
Expanding and Facilitating Citizens Access to Government 1
Agenda
– What is the Secure Extranet Gateway (SEG)?
– SEG History
– Providing Secure Access
– The SEG and E-Authentication
– Supported Applications
– Questions
Expanding and Facilitating Citizens Access to Government 2
August 8, 2017
What is the Secure Extranet
Gateway? (SEG)
• Treasury’s E-Authentication solution for access to public
facing web applications requiring level three assurance (PKI
credential).
• Entrust COTS products TruePass and GetAccess provide
authentication and authorization services.
• The SEG provides a central point of access and
authentication for Treasury web-based application users
– Internal and external users are supported
Expanding and Facilitating Citizens Access to Government 3
August 8, 2017
SEG History
• Implemented in 2003 as a solution for former Treasury
bureaus that required secure uninterrupted application access
that leveraged the Internet
– Primary customer is the Department of Homeland Security
• Access requires an X.509 PKI credential.
– Other authentication methods in support of eAuthentication are under
review.
Expanding and Facilitating Citizens Access to Government 4
August 8, 2017
Providing Secure Access
External
Users
Secure
Treasury Treasury
Business Applications
Partner
The SEG
Treasury
Remote
User
PKI Enabled
Authentication
Required
Other
Agency
User
Expanding and Facilitating Citizens Access to Government 5
August 8, 2017
Providing Secure Access (con’t)
• The SEG uses a reverse proxy approach to access protected resources.
This provides for increased security over the VPN approach
– Requires minor client modification
• TruePass enables web applications for authentication, digital signature
and encryption
– Acts as a “Gatekeeper” ensuring only authenticated users can access
protected resources
• GetAccess enables centralized security management of user identities,
and enables authentication and authorization across multiple applications.
– Provides Role Based Access Control
– Supports multiple authentication methods to include:
UserID/Password, Random Number Token, PKI credentials etc.
Expanding and Facilitating Citizens Access to Government 6
August 8, 2017
The SEG and E-Authentication
• The SEG has been a member/relying party of the E-
Authentication federation since Sept 06
• In a federated environment the SEG will consolidate 80% of
the compliance for all protected resources
– Reduces costs on federating/compliance to Federation
Membership documents.
– All path validation and processing functions are
performed by TruePass. This removes the burden of PKI-
enabling each protected resource.
Expanding and Facilitating Citizens Access to Government 7
August 8, 2017
Supported Applications
• Office of Foreign Asset Control (OFAC) Automated
Blocking and Reporting Reject System (ABaRRS)
– Supports financial institutions in reporting “blocked transactions”
– ABaRRS has been a member/relying party of the E-Authentication
Federation since Sept 06
• Treasury Executive Office of Asset Forfeiture (TEOAF)
Automated Joint Operation Payment Processing System
– Automates the allocation of funds to Treasury and other law
enforcement agencies
– The Joint Operation Payment Processing System will join the E-
Authentication federation by Sept 07
Expanding and Facilitating Citizens Access to Government 8
August 8, 2017
Questions and Comments
Expanding and Facilitating Citizens Access to Government 9
August 8, 2017
SAFE Digital Signatures
&
FDA Electronic Submissions Gateway
(ESG)
Cindy Cullen
SAFE CTO
609 818 4152
1
Agenda
• SAFE credentialing process
• Electronic Submissions Gateway
• Regulatory Affairs
• Implementation
• Keys to Success
2
SAFE Credentialing Process
3
SAFE Signatures on FDA ESG
Issuer AstraZeneca FDA
1
2
3 4
•D1 Digital signature applied to the FDA form
•V2 Validation of signature credential requested
•V3 Validation report received
•V4 Validation report and signature bound to document
•D5 Digitally signed FDA form placed within compiled
electronic submission. Submission moved to electronic
archive
•S6 Submissions sent to FDA via the FDA ESG
•S7 Submission acknowledgments received
7
•S8 Submission acknowledgment (receipt) placed into 5 6
electronic archive with submission link page
8
4
AZ Regulatory Affairs and SAFE
• AZ Regulatory Affairs - why we got involved in
implementing SAFE
In conjunction with the implementation of the FDA Electronic
Submissions Gateway
AZRA involved in the pilot for the FDA ESG
• Implementation FDA ESG
Requirement for digital signatures on FDA forms
Leverage experience and benefit from AZ membership on SAFE
Part 11 compliant
Future extension of benefit internally
Small group requiring credentials
5
AZ Regulatory Affairs and SAFE Key
Concerns for the Business
• Compliance
• Cost
• Complexity
• Training
• Efficiency gained
• Support
• Timing
• Reputation
6
First Steps
• Formation of Project Team
• Seek expertise
• Determine user requirements
• Investment/”buy-in” by key stakeholders
Legal
Records Management
Architecture
Infrastructure
Security
7
Implementation
• Regulatory Affairs - determine and address process implications
“live” digital signature vs. flattened file
• Software – off the shelf, Arcot addressed version SAFE 2.x
ruleset
• Validation - (eg, system requirements, user acceptance testing)
• Infrastructure implications – Firewall (open required ports) and
Proxy issue
Arcot software does not use proxy connection
AZ Internet Security Policy does not allow direct access on port 80
• Deployment - Scripting for installation and rollout plan
Scripted for automatic rollout to users, complicated by reboot
required after driver installation
Adobe Acrobat 7 Pro
SafeNet token drivers
SafeNet Middleware (policy)
Arcot Universal Client
8
Implementation
• Training
• Credentialing - AZ's Trusted Agent – “pain-free registration”
• Communications
• Trouble shooting
Java version issues with RACCA registration application
Windows SmartCard services are activated by driver install – side
effects
Apparent interaction with latest Citrix client
SafeNet installs four devices by default
Scripting difficulties in Arcot installation
Server based implementation for SAFE should reduce number of
issues encountered
• Security
Firewall policy
• Support
9
Keys to success
• Leadership support
• Use of experienced consultants
• Communication,Communication,Communication
• Training
• Support
• Lessons Learned
10
Questions?
11
Implementation Architecture
1. Electronic record represented
using a PDF document.
2. the client-side document
display application
3. SAFE-compliant Signing
Interface, which generates
and verifies the Digital
Signature.
4. User SAFE Credential stored
on a SafeNet Hardware
Token and appropriate driver
and middleware software
5. Regulatory compliant data
repository
6. User credential certification
authority which validates the
digital signature – (via an
OCSP request / response
over the secure Internet
connection)
12
Controlled Substances
Ordering System (CSOS)
A Case Study – April 18, 2007
Agenda
• CSOS History and Overview
• Benefits and Challenges to Adoption
• CSOS Current Status
• Ongoing Challenges
• Moving Forward
History of CSOS
• DEA tasked under the Controlled Substances Act
of 1970 to regulate controlled substances
• Purchasers (pharmacies and distributors) of
controlled substances have historically used a
controlled paper DEA Form 222 to place their
orders
• Industry requested DEA provide a provision to
enable electronic orders for controlled
substances to integrate with their existing
electronic orders for non-controlled substances
– An allowance to existing regulations, not a mandate
Concept of Operations
DEAE-Commerce
E-Commerce DEA
DEA
DEA $
Certification Headquarters
Headquarters
Certification Policy
Authority
Authority
DEACSOS
DEA CSOS
Certification
Certification
Authority
Authority ARL
ARL
Reporting of
CRL Reporting of
CRL Order form
Order form
information
information
Enrollment Verification
Enrollment Verification
Digitally signed controlled
Digitally signed controlled
substance orders
substance orders
Checkorder
order
Pharmacy
Pharmacy Distributor
Distributor
Check
foralteration
alteration
Controlled Substance for
Controlled Substance
Shipments
Shipments
DEA E-Commerce
Controlled Substance Ordering System (CSOS)
The Benefits of CSOS
• Improved customer service
– The Regulations provide allowances for new business processes
such as centralized ordering from a single location for all stores
within a chain
• Reduced manual effort
– Manually prepared paper order forms will be replaced by
electronically generated orders
– Paper order form is limited to ten line items per order;
No limit on the number of line items on electronic orders
• Reduced errors
– Paper order form requires handwritten product description
– Electronic orders will identify the product by its National Drug Code
(NDC)
• Improved security measures
– Order originator authentication
– Order content integrity
– Non-repudiation of involvement by parties to a transaction
CSOS Milestones
• Initiation Phase began 1999
• Industry Pilot conducted 2002 through 2005
• Final Rule published June 2005
• CSOS launched August 8, 2005
• Obtained WebTrust for Certification Authorities
(CA) April 14, 2006
• FBCA Cross-Certification awarded July 2006
Software Challenges Faced
by Industry
• Subscribers may hold multiple certificates
– one for each location for which they are
ordering. Software needed to select which
location and use appropriate certificate
• Integrating PKI into existing ordering
software systems across multiple and
diverse platforms
Success Factors
• DEA worked extensively with industry groups:
– Early engagement with Healthcare Distribution Management
Association (HDMA), National Association Chain Drug Stores (NACDS)
and many other major pharmacies, distributors, and manufacturers
– 3-Year CSOS Pilot to demonstrate proof of concept
– Test platform to provide industry with suite of test certificates
– Commercial software vendors to CSOS-enable software
• Assisted industry with technical challenges
– HDMA EDI 850 Working Group extend the 850 Purchase Order
transaction set to accommodate digital certificates
• Incorporated DEA authorization information (schedules, authorized
shipping location, etc.) into X.509 v3 extensions to replace DEA
Form 222 data
Electronic Order (Example)
Business Activity
Code Registrant
Information
Order Line
Elements
Certificate Extensions Containing
DEA Form 222 Information
Microsoft Certificate Viewer DEA Extension Information
OID Value Extension Name Value
Id-DEA.1 Certificate version 00
number
Id-DEA.2 Registrant Name “Acme Drug”
Id-DEA.7 Hashed Registrant 160 bit value
Number
Id-DEA.4 Schedules 7E=0111111
0
Id-DEA.6 PostalAddress Add1$Add2$
Add3$City$S
tate$Zip
Id-DEA.5 BcRole A
Registrant Information printed on DEA 222 form
Results!
• Several commercial CSOS software
packages now available to industry
• 33,569 certificates issued to 12,333
Registered DEA locations to date –
majority of these have been smaller
independent pharmacies
• Larger chains have indicated a readiness
to adopt in 2007
CSOS Ordering Trend
To date – there have been 2,211,151 transactions (order line items)
ordered electronically, providing significant savings in processing
costs to the Pharma industry
Ongoing Challenges
• Educating others on CSOS’ unique role as
a Credential Service Provider (CSP) to
industry
• Signed B2G transactions are not required
by DEA
• Certificates only used in B2B transactions
between supply chain partners within a
regulated industry
Ongoing Challenges
• Ensuring that systems not under DEA
governance are compliant with
performance standards specified in
updated 21 CFR
– DEA requires external audit of system to
ensure that FIPS 140-2 and 21 CFR
requirements are met
– DEA Diversion Investigator’s Toolkit
developed so that DEA can audit and analyze
electronic transactions in the field
Ongoing Challenges
• Industry cannot be required to operate on
a specific platform
– Minimal support for SHA-256 and RSA 2048
algorithms presently available
• Software development time
– Commercial vendors and industry require
sufficient lead time to update software in
accordance with changes to the Regulations
or NIST algorithms
• Educating Pharma community about PKI
Moving Forward
• Successfully completed second WebTrust
for CA audit
• Readying for increased adoption rates as
chain pharmacies come on board
• Working with industry to prepare them for
new NIST algorithms
Questions?
www.deaecom.gov
1-877-332-3266
1-877-DEA-ECOM
Federal Identity Credentialing
Implementing HSPD-12
Judith Spencer
Chair, Federal Identity
Credentialing Committee
judith.spencer@gsa.gov
October 27, 2006
• Deadline for Federal Agencies to
begin issuing PIV cards to
employees.
• All major agencies issued at least
one smart card to at least one
employee in the agency
October 27, 2007
• All Federal employees (under 15
years service) should have a PIV
card.
October 27, 2008
• All Federal employees and
contractor staff should have a PIV
card.
Getting There
• Managed Service Offerings
– GSA Managed Service Offering
– DOI/NBC Managed Service
Offering
• Going it alone
– Social Security Administration
– Veterans Affairs
– Department of Defense
– State Department
– & others
Enrollment
Implementing PKI. . .
• Shared Service Providers
– Commercial service providers & Federal
agency providers
– Mandated by M-05-05 & FIPS 201
– COMMON Policy Driven
– FPKI Certified Provider List
– GSA Schedule 70 SIN 132-61
• Legacy Federal Enterprise PKI
– Cross-certified with the FBCA at Medium
Assurance or Higher
– Must migrate to new key sizes as specified
Trust Framework DHS DOJ
Treasury
Federal Common
Policy CA NASA
Entrust DOD
cross-certified
Exostar
USPTO
Federal
Bridge CA
DOS
Treasury ORC
Cybertrust
Verisign
DOE
Certipath
State of Illinois
Wells Fargo
GPO ACES
Federal Identity Management
E-Authentication
Federal Bridge
Common Policy High Certification Authority
Certification Authority
Level 4 MediumHW
HSPD-12 Medium
Basic
Level 3 Rudimentary
Level 2
Level 1
Beyond HSPD-12
• Extra-Federal Interest in Harmonization
– States
– Industry
– Allied Governments
• HSPD-12 Compatibility
– Technical interoperability
• Use FIPS-201 compliant smart cards
– Recognition by Trust Framework
• Cross Certify with the FBCA at Medium
Assurance-Hardware or Higher
So I’ve got my PIV card. . .
now what?
Well. . . . .
It’s the Apps, stupid!
PIV, Apps, and Protocols
Tim Polk
April 18, 2007
Rejected Titles
• Seven Deadly Sins of PIV-Enabling
• Mythbusters: The PIV Episode
• It’s the PIV-Enabled Apps, Stupid!
It Really Is All About the Apps
• Without Apps, the PIV Card is a horribly
expensive flash pass
– And the ROI just isn’t there
• But many COTS and custom
applications have limited PIV
compatibility
PKI and PIV
• Contact side: up to three key pairs and
certificates
– PIV Authentication certificate (mandatory)
– Optional digital signature certificate
– Optional key transport/key agreement
• Contactless side: one optional key pair
– Card Authentication Certificate
What’s different about PIV
Enabling Apps?
• Departs from current best practice to
meet new requirements
– Different public keys & signature options
– Larger certificates
– Extended key usage extension
– Quasi-global PKI
– Different types of names
– Multiple status mechanisms
Be Cryptographically Agile!
• Don’t hardwire to current practices/modules!
• PIV (as specified in SP 800-78) supports
– 1024 and 2048 bit RSA user keys
– P-256 and P-384 ECC
– new signature formats (RSA-PSS)
– SHA-1, SHA-256, and SHA-384
• PIV phases out 1024 bit RSA and SHA-1 by
12/31/2010
• Solution: Design apps to recognize ALL
algorithms specified in SP 800-78 so that it is a
cryptomodule issue…
Allow for Large Certificates
• This one is from painful experience!
– NIST tried to specify maximum values in SP 800-
73, and this proved impossible
• PIV Certificates may include 2048 bit user
keys and 4096 bit signatures
• PIV certificates include many URLs to support
path discovery
• Suggested Solution: Use baseline sizes from
SP 800-73 and add a big fudge factor
Don’t Overload Key Usage
Extensions
• Application & Protocol designers forget that
PKI is a general infrastructure and over
specify key usage as a general rule
– Don’t insist on the nonrepudiation bit unless you
mean it!
– Don’t insist on an app specific EKU (delays rollout)
– Recognize the “anyExtendedKeyUsage” EKU OID
• Solution: Application & Protocol Designers
should be flexible wrt key usage
Name Collisions Happen
• Need to process the entire name, not
just the common name
• There are two Thomas Rhodes at NIST
– I sent the wrong a party invitation last
month, and I know better!
• Solution: Include mechanisms to relate
the name to a known user list!
Don’t Assume A Valid Path
Means a Valid User!
• The Federal PKI is connected with
commercial enterprise PKIs directly and
through the CertiPath bridge
– Certificates exist at several levels of
assurance
– Certificate subjects inside the FPKI include
contractors and guest researchers
• Solution: Process policies, policy
mapping, and name constraints
Be MultiLingual for Status
• There is no single right answer for
obtaining status information
– LDAP and HTTP CRL distribution for all
PIV certificates and CA certificates
– OCSP status distribution for PIV
Authentication certificate
What If PIV Isn’t Core for My
Organization?
• These are still good rules of thumb
• They will save you trouble later
HSPD-12 Case Study – Veterans Affairs
Debb Blanchard
Senior Program Manager
NIST R&D PKI Conference
Session 8 – PKI in Government
April 18, 2007
Topics
Genesis of VA Employee Credentials
Changes Required for HSPD-12 and FIPS 201
Current Status
Future Plans
©2006 Cybertrust. All rights reserved. www.cybertrust.com
Genesis of VA Employee Credentials
• March, 2004 – GSA and FPKI PA announced SSP program
• August, 2004 – Cybertrust became an approved SSP under the Federal
Common Policy
• September 2004 - VA contracted with Cybertrust for SSP and managed
services
• Smart cards purchased from GSA
• To support the Smart Card Program
• To take advantage of Smart Buy from GSA
• Smart cards met the technical requirements of the IAB
• Registration per the requirements of VA and the Federal Common Policy
• VA as the Registration Agent (RA) in accordance with VA policies
• Registration Practice Statement (RPS) written and approved to meet the
requirements of the Federal Common Policy, Cybertrust CPS, and VA
registration policies
• Dedicated SSP CA to support the requirements of the VA as well as SSP
program, Federal Common Policy with Actividentity Card Management
System hosted at Cybertrust.
©2006 Cybertrust. All rights reserved. www.cybertrust.com
Pre-HSPD-12 & FIPS 201
•What did this mean?
• No CHUID
• No fingerprints stored on the card or on the chip
• No digital photo stored in the card container
• No HSPD-12
• No FIPS 201
• No SP800-96, PIV Card to Reader Interoperability
• No SP800-76-1, Biometric Data Specification for Personal Identity Verification
• No SP800-104, A Scheme for PIV Visual Card Topography
• No SP800-73-1, Interfaces for Personal Identity Verification
• No SP800-78-1, Cryptographic Standards and Key Sizes for Personal Identity
Verification
• No SP800-79, Guidelines for the Certification and Accreditation of PIV Card Issuing
Organizations
• No mandated Federal deadlines to meet
Life seemed to be easier for VA!
©2006 Cybertrust. All rights reserved. www.cybertrust.com
Changes required for VA to meet HSPD-12
• Update the VA smart cards and CMS
• Former smart cards purchased per the GSA Smart Buy did not meet the new HSPD-
12 and NIST requirements
• The Actividentity CMS 3.6 did not meet the new HSPD-12 and NIST requirements
• Updates to meet the following NIST requirements:
• FIPS 201, Parts 1 and 2
• SP800-96, PIV Card to Reader Interoperability
• SP800-76-1, Biometric Data Specification for Personal Identity Verification
• SP800-104, A Scheme for PIV Visual Card Topography
• SP800-73-1, Interfaces for Personal Identity Verification
• SP800-78-1, Cryptographic Standards and Key Sizes for Personal Identity
Verification
• Update the VA registration system and practices
• RPS had to be updated to reflect new HSPD-12 and FIPS-201,Part 1 requirements
• The VA PIV registration system had to meet criterion for NIST SP800-79, Guidelines
for the Certification and Accreditation of PIV Card Issuing Organizations in addition
to meeting required C&A and FISMA requirements
• Personnel roles had to be filled and job descriptions enhanced to meet the
requirements for the Local Registration Agents (LRAs) and Privacy Officer
©2006 Cybertrust. All rights reserved. www.cybertrust.com
Current Status
• Approximately 1000 smart cards issued since October, 2007
• VA has updated and changed the following:
• Registration system to meet FIPS-201, Part 1
• Issuing stations, smart cards, and CMS to meet FIPS-201, Part 2
• Three data centers (1 primary, 2 backup) to support 225 local registration
offices
• Registration Practice Statement (RPS) and Key Recovery Practice
Statement (KRPS) to meet requirements of the Federal Common Policy
and FIPS 201
• Updated the smart card to meet FIPS 201 and NIST SP requirements
• Updated Actividentity CMS from 3.6 to 3.8 (done) to 4.0 (in process)
• Issue full PIV compliant cards June, 2007
• Ability to create and issue PIV and non-PIV credentials
©2006 Cybertrust. All rights reserved. www.cybertrust.com
Future Plans
• September, 2009 – complete issuance to 400,000 VA employees and
contractors
• Centralize how the agency performs employee and contractor background
investigations
• Integrate these cards with a standard physical-access control system
• Revamping all control systems to use RFID proximity readers
• Provide single sign-on capabilities for applications and having one,
department-wide identity and access management system
• Currently VA has 12 identity systems nationwide
• Goal is to link them together and with the Defense Department’s Common
Access Card (CAC)
• VA seeking to ensure full DoD CAC interoperability and data feeds from
DoD CAC enrollment
• Ensure PIV 3.0 is integrated with the VA’s enterprise architecture
• Planning this now as part of the future
• HSPD-12 is foundation and part of larger enterprise initiative to larger
access controls
©2006 Cybertrust. All rights reserved. www.cybertrust.com
Contact
Mr. Brian Epley, VA PIV PM Ms. Deborah “Debb” Blanchard
Email: Brian.Epley@va.gov Email: deborah.blanchard@cybertrust.com
Office: 202-273-6240 Office: 443-367-7011
Mr. Steven Roberts, VA PIV Advisor Mr. Tom Greco
Email: sroberts@ls3-inc.com Email: tom.greco@cybertrust.com
Office: 301-352-4194 Office: 443-367-7052
©2006 Cybertrust. All rights reserved. www.cybertrust.com
From Authentication to Privilege Management to the
Attribute Eco-System:
Marketing runs amok…
Topics
• Coupling identity and privilege management –
• Isn’t that putting authn and authz back together?
• An almost whole view of identity and attributes
• The creation and consumption of attributes
• From the enterprise view
• From the VO view
• From the user view
• The unexplored regions of the ecosystem
Identities, Attributes and Privileges
• (Avoid rathole of identity and identifiers)
• Identities have attributes for privacy
(secrecy) and scale
• Many attributes reflect privileges; they are
used by relying parties to make access
control decisions
• Privileges have a small subset of useful
/qualifiers
• Delegation, constraints, prerequisites,
expirations, and a few more…
Unified IdM
• A very, very common activity in much of
life, and many of its computer applications
• Select a set of people
• Form them into a group (managed)
• Assign the members of the group privileges
• Happens in enterprises, VO’s and the p2p
world.
• The ecosystems view
• …the p2p unknowns
Inviting Attributes into your life…
• For privacy and secrecy
• Albeit for a refined view of privacy
• For better security
• Federated identity allows for stronger
security where needed in a manner scalable
for both RP and the user.
• For efficiency
• Reduced sign-ons, reduced second-factors
Attributes in the enterprise
• Designated sources of authority for
systems and applications
• Authority tree allows sources of authority
to flow permissions and privileges to
others in the enterprise
• May need to be coupled with local
conditions
Corporate Authority Tree
Alternative Authority Tree
Academic Authority Tree
Attributes in the VO
• PI or subcommittee of management
defines a set of roles for VO use
• Individual PI’s assign the roles to people
in their local workgroups
• Attributes currently carried in the VO
identity credential but can be stored in
other locations, such as enterprise or local
directories
• Or everyone uses the PI’s cert to do
everything
But together…the Attribute Ecosystem
• We now understand, we think, an overall
“attribute ecosystem”
• Shibboleth is the real-time transport of
attributes from an IdP to an SP for an
authorization decision
• Other, “compile-time” means are used to
ship attributes from sources of authority to
IdP
• Or to the SP, or to the various middlemen
(portals, proxies, etc.)
• And a user needs to be manage all of this
User attribute management
• As a user
• Select an identity and authenticate
• Release attributes
• As a manager of privilege (attribute assignment)
• Authentication
• People picking
• Group management
• Privilege management
A Simple Life
Application access controls
(including network devices)
Shib
User
IdP
Source of Source of Source of
p2p Authority Authority Authority
A Simple Life GUI
Application access controls
(including network devices)
Autograph
Shib
Authn
User
IdP
Source of Source of Source of
p2p Authority Authority Authority
A Full IdM Life
Application access controls
(including network devices)
Shib
User
IdP Local apps
Source of Source of Source of
p2p Authority Authority Authority
A Full Life GUI
Application access controls
(including network devices)
Autograph
Shib
Authn
User
IdP Local apps
p2p Signet/ Source of Source of
Authority Authority
Source of
Authority
Grouper
Real Life
Source of
Source of Authority
Authority Application access controls
(including network devices)
IdP Portal
Source of
Authority
Gateway Shib
Source of Proxy
Authority
Source of
Authority
User IdP
Source of
Authority Source of Source of Source of
p2p Authority Authority Authority
Example Flows in the Attribute
Ecosystem
Source of
Authority
Application access controls
(including network devices)
VO Service
Center
IdP
Gateway Shib
Source of
Authority
User IdP
Source of
Authority Source of Source of Source of
p2p Authority Authority Authority
Application access controls
(including network devices)
Portal
Shib
Autograph
User Authn IdP
S/G S/G
Source of
p2p Source of
Authority
Authority
A VO Service Center Flow
VO
Service Center
Application access controls
(including network devices)
Source of
Authority
S/G
Shib
Autograph
User Authn IdP
S/G S/G
Source of
p2p Source of
Authority
Authority
The Unexplored regions
• Identity linking
• Batch and real-time attribute flows
• Metadata services
• Federation support of VO’s
• The “middlemen issues”
• Constrained delegation
• Science gateways
• P2P integration issues
Characteristics of Attribute Flows
• Context of a session
• Attributes hang off an authn context
• Meaning of a logout
• Source of authority versus immediate
provider of assertion
• Quality of original attribute assignment
• Identifier to identifier across autonomous
Example issues
• Intermediaries making assertions that are
not verifiable by the federated trust fabric.
• Users not being able to manage their
privacy on information passed to
intermediaries
• LoA on attributes
• The IEEE distributing membership
attributes
• When to use multiple IdP’s versus send
attributes
VOs plumbed to federations
Rump Session
(Scott Rea – Dartmouth College)
PKI 2007
NIST
Rump Session, 4:30-5:30
• RFID Passports and PKI
– Bill Russell, Mount Airey Group
• Using PIV Smart Cards on Linux for Authentication to
Windows Active Directory
– Douglas Engert, Argonne National Lab
• Implementing PKINIT
– Olga Kornievskaia, CITI, University of Michigan
• Dartmouth PKI Census
– Geetha Wunnava and Scout Sinclair
• Simple Authentication for the Web Using Personal-
Messaging Identifiers
– Kent Seamons, BYU
2
Using PIV Smart Cards on Linux for
Authentication to Windows Active Directory
Douglas E. Engert
Computing and Information Systems
April 26, 2006
DOE Cyber Security Group Training Conference
Dayton, Ohio
Updated for:
6th Annual PKI R&D Workshop
NIST
April 18, 2007
Driving Force
Homeland Security Presidential Directive/Hspd-12
– “and logical access to Federally controlled information systems.”
FIPS-201 “Personal Identity Verification (PIV) of Federal Employees and
Contractors.”
– Response to HSPD-12
NIST 800-73 “Interfaces for Personal Identity Verification”
– Defines the PIV card
NIST 800-73-1
– Updated version
2
Logical Access
“NIST believes PIV smartcard login is essential to protecting logical
access to Federally controlled information systems. … promote
compatibility of PIV cards with COTS smart card login mechanisms and
common applications with minimal negative impact on privacy. ”
NIST 800-73-1 Appendix F-Errata
Login
– To local workstation
• Standalone
• Part of a domain
– To network applications
• Part of a domain
Web authentication
– Another login to network application
3
The Project Goal
Add PIV support for logical access to some open source smart card package
such that it can be used by other common applications. Get the
modifications added to the open source distribution so it will be generally
available when PIV cards are generally available.
OpenSC was chosen
– Open source libraries for accessing smartcards
– Many different smart cards
– ISO 7816-4 routines
– Can use PC/SC
– Provides a PKCS #11 interface to applications
– Was easy to add PIV
– Modifications accepted and expected to be in 0.11.0 release
– Can run on Windows and Mac too!
7
Update for PKI R&D Workshop
• http://www.opensc-project.org
– OpenSC 0.11.1 has basic PIV code
– OpenSC 0.11.2-rc2 has gzip’ed cert support
thanks to Identity Alliance
– SCA – Mac OS X Installer
– SCB – Windows Smart Card Bundle
• Pkcs#11 for Fire Fox, needs ID Ally CSP for login
– http://www.opensc-project.org/opensc/wiki/UnitedStatesPIV
• http://packages.debian.org/unstable/utils/opensc
8
NIST 800-73-1
Part 1 - PIV data model, and objects on card
Part 2.1 – PIV Application Programming Interface
Part 2.3 – Card Edge Commands
We chose to implement at the card edge command level as this is a
natural separation between the card and the software. Thus any PIV card
can be used, without any vendor drivers or middleware.
9
Smartcard Applications
Web browsers
– Netscape, Mozilla, Firefox – Security plug-in is a PKCS #11 shared
library or DLL.
OpenSSH
– Modifications available on mailing list to use PKCS #11
– Could just use keys, without the certificates
Kerberos
– Use PKINIT to get initial Kerberos Ticket
– Can be done at login using pam_krb5
Globus
– Needs a way to call PKCS #11
10
Our Test Environment
Ubuntu/Debian Linux
OpenSC daily snapshots and libp11 and engine_pkcs11
– http://www.opensc-project.org
Pcsc-lite-1.3.0 and ccid-1.0.0 or newer
– http://pcsclite.alioth.debian.org
Heimdal Kerberos 0.8.1 or snapshots
– http://www.pdc.kth.se/heimdal
Pam_krb5-3.5
– http://www.eyrie.org/~eagle/software/pam-krb5/readme.html
Windows 2003 Active Directory with Enterprise CA
Other test environments
– Mac OS 10.4
– Solaris 9 and 10
16
PIV Test Cards
Beta cards from Obethur, Mobile Mind and GemPlus
Some protect the certificate with the PIN
– NIST 800-73-1 is lifting this restriction
OpenSC used to initialize the test cards
– Every vendor’s cards are a little different
– Piv-tool used to generate key pair and save public key
– OpenSSL used to create certificate request
– Windows enterprise CA to issue enterprise certificate
• Cut-and-paste request on Web form
• Save certificate as file
– Piv-tool used to load certificate on card
– Piv-tool used to change PIN
17
What can you do with existing environments
Use Windows AD with enterprise certificates
– Argonne has a site wide Windows Active Directory with all employees
– We have a smart card project with people around the site using cards
Use Windows AD with cross-realm to existing Kerberos infrastructure
Use the Heimdal KDC, but it is still under development
Wait for MIT and Apple to add KDC support for PKINIT
In any case, the full PKI infrastructure is not available today
So start testing so you are ready
18
Conclusion
Commercial vendors will take care of 95% of the market
– Both client and server side
Open source operating systems can use PIV cards
Code has been developed that will be widely distributed
– OpenSC is packaged for Debian and Red Hat
Open source clients can use commercial servers
– Standards
For web users, that’s all that is needed
For Kerberos authentication, PKINIT client code is still under development
You can state testing today
19
Questions
deengert@anl.gov
20
Implementing PKINIT
Olga Kornievskaia
CITI, University of Michigan
PKINIT: Public Key based initial
authentication in Kerberos
●
Authentication protocol where both parties are
authenticated via X509 certificates
– Provides two key establishment mechanisms (DH-
based, RSA-based)
– AS_REQ (PA_DATA) contains Alice’ s signature
– AS_REP (PA_DATA) contains KDC’ s signature
●
Standards Track IETF RFC4556 (Kerberos
working group)
PKINIT implementation history
●
Earlier draft implemented by Microsoft (Win2K)
and Apple
●
Last week Heimdal released version 0.8 which
includes PKINIT support
●
Microsoft is working toward an RFC-based
implementation (Vista)
●
RedHat is working on a PKINIT implementation
using MIT’ s preauthentication plug-in
CITI’ s PKINIT efforts
●
Sponsored by Sandia National Labs, CITI has
implemented PKINIT and working toward
having it included in MIT’ s Kerberos distribution
●
MIT plans to include CITI’ s PKINIT in their 1.7
release
●
Code is currently available in MIT’ s subversion
CITI’ s PKINIT implementation
●
Support RFC-based PKINIT and Windows-
compatible version
●
Uses MIT’ s preauthentication plug-in interface
●
Provides modular cryptographic interface
– CITI’ s implementation uses OpenSSL crypto
●
Provides configurable and modular credential
storage
PKINIT interoperability
●
Preliminary testing
– CITI, Heimdal, RedHat implementations
interoperate
– All unux clients interoperate with Win2K KDC
– Vista (PKINIT client) and Longhorn (PKINIT server)
are broken
– CITI and Heimdal KDCs support Win2K clients but
we were unable to test Win2K client against a unix
KDC
●
CITI is hosting an interoperability event in May
PKINIT w/ smartcards
●
Window’ s PKINIT only supports smartcards-
based PKINIT
●
Heimdal and CITI’ s PKINIT support various
credential storage locations and modular
interface to retrieving them
– PKCS11 (Smartcards, soft tokens)
– File system
PKINIT testing
●
ActivCard, Cryptoflex, Coolkey, CAC (any
open-sc supported cards)
– Buggy ActivCard
●
Platforms tested (includes 32&64-bit):
– Linux, Solaris, MacOS (Ken Renard)
Naming in PKINIT
●
Client identity
– Kerberos principal name encoded in an X509 SAN
– Mapping facility at the KDC (ie, file, ldap)
– MUST have X509 EKU fields
●
KDC identity (win2k)
– KDC’ s hostname is encoded in an dnsName SAN
●
Implementation needs a modular name
mapping design
PKNIT Summary
●
http://www.citi.umich.edu/projects/pkinit
●
PKINIT interoperability event May 30th&31th
NFSv4 PKi GSS mechanism
●
SPKM3 is out
●
Public key user-to-user authentication (PK2U)
might be in
– It’ s “ PKINIT without KDC”
– IETF draft (Larry Zhu, Microsoft)
●
http://www.ietf.org/internet-drafts/draft-zhu-pku2u-01.txt
●
Microsoft is working on an implementation
We do research in PKI.
Why are you "inventing new technology?"
Why are you "using outdated technology?"
"No one uses PKI except in SSL."
PKI/Trust Laboratory
Dartmouth College
We do research in PKI.
Why are you "inventing new technology?"
Why are you "using outdated technology?"
"No one uses PKI except in SSL."
(Um . . .)
PKI/Trust Laboratory
Dartmouth College
There are at least 150
people who use PKI.
(Or at least who really like NIST coffee.)
We need some numbers: a PKI census.
OASIS International PKI Survey
Qualitative: what are the barriers to PKI adoption?
We want to know about PKI as it is today.
Quantitative: who's using what technology, and how?
Helps us make the research case for PKI.
Helps you make the business case for specific technologies.
PKI/Trust Laboratory
Dartmouth College
Sample questions....
How many end-entity certs have you issued?
Do you know how many are being used?
What do you use them for? (Functions & apps)
What tech/policies for issuance? Revocation?
How does the enterprise use/structure PKI?
Code-signing?
Server-side SSL?
Federation/cross certification?
PKI/Trust Laboratory
Dartmouth College
Sample questions....
Custom components?
Software?
Extensions?
...?
Non X.509-based?
Embedded systems?
Smartcards?
Other "hidden" PKI implementations?
PKI/Trust Laboratory
Dartmouth College
What We Want From You
Feedback
What else do you want to know?
Contacts
Whom can we talk to?
Participation
We'll be in touch.
geetha.wunnava@dartmouth.edu
scout.sinclair@dartmouth.edu
PKI/Trust Laboratory
Dartmouth College
ISRL
Internet Security
Research Lab
Simple Authentication
for the Web using
Personal-Messaging Identifiers
Tim van der Horst
Kent Seamons
Internet Security Research Lab
Brigham Young University
6th Annual PKI R&D Workshop, April 2007 1
Introduction
ISRL
Internet Security
Research Lab
• Research Area: Authentication and
Authorization in Open Systems
– How to identify and grant access to those outside
my local security domain
– Desire for something more flexible and scalable
than creating a local account
• Goals
– Easy to use
– Secure
• Approaches we have explored
– Trust negotiation
– Simple Authentication for the Web (SAW)
2
Trust Negotiation
ISRL
Internet Security
Research Lab
• Attribute certificates contain properties
of the participants in a transaction
• Policies govern access control and
certificate disclosure to protect privacy
• Negotiation includes the gradual, bi-
lateral release of credentials until
access is granted
• Broad deployment hindered by a lack of
client certificates on the Web
3
Simple Authentication
ISRL for the Web (SAW)
Internet Security
Research Lab
• Personal Messaging-Based
Authentication
• Use personal-messaging identifiers as
the basis for authentication and
authorization
– Email - Email-based access control(EBAC)
– Cell phones
– Instant messaging
4
Example Scenario 1
ISRL
Internet Security
Research Lab
• A secure wiki for the PKI 2007 program
committee
• Decided to “eat our own dog food”
– Use OpenID identity management
– Requested that PC members obtain an OpenID
• Establish an account with an identity provider
• Email username to sys admin at Internet2 to be added
to the access control list for the wiki
– Only three people completed the steps to obtain
an account (Me, Neal, Von)
5
Example Scenario 2
ISRL
Internet Security
Research Lab
• Course blog at BYU (WordPress)
• Old approach
– TA creates an account for each student and
distributes username/pw
• New approach
– Cut and paste email addresses into server admin
interface
– Students can manually log in using existing
browser and email tools
– Toolbar allows single-click, single sign-on access
for students in the class
6
Forgotten Passwords
ISRL
Internet Security
Research Lab
• Email-based password
reestablishment
Web Site
Our Approach
• is not subject to passive attacks
• raises the bar for active attacks
Authentication • does not rely on:
Provider - The security of email message
delivery or
Email Provider - The active participation of email
7
providers
Core Protocol
ISRL
Internet Security
Research Lab
Service PM
Provider Provider
User
1. Authentication Request
8
Core Protocol
ISRL
Internet Security
Research Lab
Service PM
Provider Provider
2. Authentication Response User
1. Authentication Request
9
Core Protocol
ISRL
Internet Security
Research Lab 3b. AuthTokenpm
Service PM
Provider Provider
AuthTokens are:
• Short-lived
• Can only be used once
3a. AuthTokenuser
2. Authentication Response User
1. Authentication Request
10
Core Protocol
ISRL
Internet Security
Research Lab 3b. AuthTokenpm
Service PM
Provider Provider
AuthTokens are:
• Short-lived
• Can only be used once
3a. AuthTokenuser
2. Authentication Response User 4. Poll for Token
1. Authentication Request
11
Core Protocol
ISRL
Internet Security
Research Lab 3b. AuthTokenpm
Service PM
Provider Provider
3a. AuthTokenuser
2. Authentication Response User 4. Poll for Token
1. Authentication Request 5. AuthTokenpm
12
Core Protocol
ISRL
Internet Security
Research Lab 3b. AuthTokenpm
Service PM
Provider Provider
6. Token Response
3a. AuthTokenuser
2. Authentication Response User 4. Poll for Token
1. Authentication Request 5. AuthTokenpm
13
Core Protocol
ISRL
Internet Security
Research Lab 3b. AuthTokenpm
Service PM
Provider Provider
6. Token Response
7. Resource
3a. AuthTokenuser
2. Authentication Response User 4. Poll for Token
1. Authentication Request 5. AuthTokenpm
14
Demo
ISRL
Internet Security
Research Lab
15
SAW Properties
ISRL
Internet Security
Research Lab
• Web Single Sign-On
• Thwarts passive attacks
• Raises the bar on active attacks
– Require multiple identifiers (cell phone and email)
• Easy way to specify data sharing policies
using existing, familiar identifiers
• Supports delegation using email forwarding
rules
16
Implementation Status
ISRL
Internet Security
Research Lab
• Client side
– Firefox extension
– IE browser helper object
• Server side
– WordPress blog extension
– MediaWiki extension
– Apache .htaccess module
17
Relationship to PKI
ISRL
Internet Security
Research Lab
• Use PKI to support strong authentication to
the email provider
• SAW is a new approach for logging into an
identity provider
• SAW as an additional factor for n-factor
authentication
• Use SAW when a certificate contains an
email address as a proof of ownership
• Use SAW to automatically distribute
certificates or keys to outsiders
18
Further Information
ISRL
Internet Security
Research Lab
• Technical report available at
http://isrl.cs.byu.edu/
• Web single sign-on birds-of-a-feather
session tonight at 8 PM
19
ISRL
Internet Security
Research Lab
20
A Scalable PKI for a National Grid Service
Jens Jensen, David Spence, Matthew Viljoen
Rutherford Appleton Laboratory
The National Grid Service for the United Kingdom
February, 2007
Abstract
In this paper we describe work to expand the PKI for the UK National Grid Service (NGS), to
integrate it with site authentication and improve usability. This work is complementary to the UK
Shibboleth deployment. As the NGS grows to support wider and larger scientific communities, we
investigate how we can improve usability by tying in Virtual Organisation management into the PKI
framework.
1 Introduction leth federation [25], and is complementary to it, but
is still entirely independent of it. We explain how
1.1 General Introduction they will interoperate.
Deploying a PKI for academic institutions is of
The UK National Grid Service (NGS) [13] runs course not a new idea. The innovation presented
Globus-based Grid middleware which depends on in this paper lies mainly in deploying it specifically
X.509 certificates for user authentication (Globus for a national Grid, so we can tie in attribute and
Security Infrastructure, GSI [31]). The UK Grid account management, and in deploying the
e-Science Certification Authority [24] provides PKI alongside, and interoperating with, the Shib-
medium assurance [6] certificates for Grid users boleth federation. We will also briefly discuss other
and e-Science projects in the UK, including the usability issues.
NGS. This Certification Authority (CA) must pro-
vide medium assurance certificates (section 2.4.1) 1.2 Related Work in this Area
because it is approved internationally (section 1.3)
to identify users and hosts in the UK to interna- From a high-level view, the architecture of the
tional Grid collaborations. Conversely, although it work presented in this paper is similar to that of
primarily serves the UK, scientists using the NGS SWITCHaai [21], partly because this work aims to
have collaborators across the world, and the NGS solve some of the same problems. The principal dif-
trusts certificates from other internationally ap- ference is that SWITCHaai is entirely Shibboleth
proved CAs in order to facilitate these collabora- based.
tions. In particular, interoperability between NGS From a more practical point of view, this work
and TeraGrid [22] is considered important. is similar to USHER, the US Higher Education
Medium assurance, among other things, implies Root[26]. We will look closer at this similarity in
that users will have shown photo id to a Regis- section 2.6.
tration Authority (RA) operator, and that certifi- The work presented here depends on technol-
cates have a maximal lifetime of 395 days (one ogy developed in other similar projects, namely,
year, plus 30 days within which users should request MyProxy [14], SHEBANGS [17], and ShibGrid [18],
rekeying). Furthermore, many relying parties that as well as other related single sign-on work [7, 9].
use these credentials insist on having “meaningful”
commonNames (i.e., bearing a reasonable resem-
1.3 International Accreditation
blance to the person’s authenticated identity). For
many purposes, this is too strong an authentica- Although not fundamental to this paper, it will
tion and doesn’t scale well to a large number of be helpful to briefly mention as explanatory back-
users ( 104 certificates), so we are deploying a ground information that international Grid CAs are
scalable hierarchy primarily for NGS to expand the accredited by so-called Policy Management Author-
user base, with features to ease the account man- ities (PMAs). The Grid world is currently covered
agement. It is deployed alongside the UK Shibbo- by three such, who together form the International
Root
e−Science NGS Institution NGS Training
CA TopLevel and Monitoring
RAL Oxford Leeds Manchester
Figure 1: The UK e-Science Hierarchy
Grid Trust Federation, IGTF. Accredited CAs are 2.1 The UK PKI Hierarchy
then trusted by national and multinational Relying
Parties (RPs), including the NGS, but the RPs are In July 2006 the UK e-Science CA deployed a new
of course free to trust unaccredited CAs—indeed, PKI based on a hierarchical model. This hierarchy
this is often necessary to enable certain communi- was introduced at the same time as rolling over the
ties to access the Grids. Loosely speaking, it is certificate of the UK e-Science medium assurance
the PMAs who impose upon their members that CA. The new certificate for this CA is now subor-
they operate to what we have called “medium as- dinate to a root. Other CAs offering different ser-
surance” in this paper, as a condition for accredi- vices or providing other assurance levels have been
tation. deployed as part of this hierarchy. An example is a
low-assurance training CA used for people new to
the NGS.
2 Deployment Figure 1 on this page shows the UK hierarchy: a
root CA ties together the internationally approved
This paper discusses deployment of a hierarchy of
(medium assurance) CA, as well as the specialised
credential conversion CAs, where each institution
hierarchy for NGS: the institutional credential con-
effectively runs its own CA which converts the insti-
version hierarchy and the training and monitoring
tutions’ site authentication to a short-lived X.509
CA.
credential (in the Grid CA context, such a CA is of-
ten referred to as a SLCS, a Short-Lived Credentials The institutional credential conversion CAs, the
Service [8] (pronounced “slicks”)). “Short-lived” SLCS, are anchored by a common SLCS trust an-
usually means 12 hours, but is allowed to be “any- chor which itself is subordinate to the root. This
thing up to 106 seconds.” [8]. One core difference anchor CA represents a single point of trust for any
is that although a SLCS acts as a CA, it does not relying party (RP) that wishes to trust all creden-
need to issue CRLs. tial conversion services in the UK, at least in prin-
This deployment brings us a wide user base, ciple. Its policy also ensures that a minimum set
where essentially anyone from any such institution of requirements or level of assurance can be en-
can get a certificate, but we lose the right to manage forced between all credential conversion services,
and control the user data that originally identified because it can impose specific policy and practices
the user. constraints upon its subordinates. These, of course,
Indeed, our principal challenge was to widen the should not be set too high, or we would lose partic-
user base for the NGS, enabling also students and ipant institutions.
visiting scientists to obtain accounts via the authen- Since a SLCS needs to be an online service in
tication framework. order to function, it is imperative that the private
A secondary challenge was to improve the us- key be adequately protected to prevent it from be-
ability of the PKI. Usability is often seen as an ob- ing compromised. The SLCS anchor’s policy states
stacle to widespread Grid use; in some scientific that subordinate certificates can only be issued
communities users are unable or unwilling to learn when they are requested by a security device con-
basic PKI. The security required by a medium as- forming to the FIPS 140-2 level 2 standard and the
surance CA will prevent these communities from private key must not be exportable in any unen-
engaging with Grid work. crypted form from that device (such devices can
be obtained as USB tokens and are relatively inex- for this project we wanted to simplify the selection,
pensive). Although no recovery is possible in case so the client does not even need to select a home
of hardware failure, the extra assurance won by so institution.
securing the key far outweighs the risks. Indeed, The easiest way to accomplish this is to config-
should the key be lost, a new certificate can quickly ure a lookup mechanism which notices which ad-
be issued by the parent CA. dress the client is coming from, and uses it to con-
Security concerns are also addressed in the tact the right credential conversion server. We do
SLCS anchor’s policy by imposing the requirement indeed lose the ability to support “roaming” clients
upon the SLCSes that communication channels be- with such a simple scheme, but gain the simplifi-
tween them and their local authentication service, cation of not asking the user for redirection. For
as well as the NGS authorisation services, are se- central portals, the conversion service must also be
cure. In addition to this, each SLCS is required to reachable through the site firewall which compli-
log all credential conversion so that NGS traceabil- cates site deployment slightly.
ity and accountability requirements of access mech- On the server side, a trusted repository of the
anisms are satisfied. SLCS sub-CA certificates will have to be provided,
along with the repository provided by the PMAs
2.2 Architecture for traditional CAs.
Figure 2 on the next page gives an overview of the
architecture described so far and how this fits in to
the wider NGS and site infrastructures.
2.3 Implementation
As we are seeking to lower the barriers for users While there is no requirement to do so, the “ob-
to user the NGS, we assume that the user will be vious” way to implement a site SLCS is via
using some easy-to-user User Interface software to MyProxy [14].
manage their access to the Grid, to which we can
We discuss the MyProxy solution further in this
make minor changes to support the SSO infrastruc-
section, but it is also worth mentioning Microsoft’s
ture (although we do not preclude the use of com-
Windows Server 2003 which also contains features
mon command line tools).
to run a CA, but will not, as far as the authors are
The key component of the infrastructure is the
aware, be able to contact an external VO attribute
Credential Translation Service or SLCS. There is
server to add attributes to the certificates.
one of these per site and its main function is to val-
idate the user’s site identity by calling out to the By using MyProxy we can bridge many of the
site’s authentication infrastructure and then gener- site authentication infrastructures in use to the
ates a Grid credential (a short-lived X.509 certifi- GSI/PKI world. MyProxy can be configured to
cate) for the user. In this respect, it is similar to provide certificates generated by an internal or ex-
the Shibboleth IdP—see section 2.7. ternal CA. We can also support advanced users who
The Credential Translation Service can also call have long-term certificates by enabling them to up-
out to a VOMS server to obtain a VOMS attribute load proxies generated from their certificates (they
certificate for the user. This would normally be to are not permitted to upload the certificates and pri-
the NGS VOMS server, but others could be imag- vate keys themselves, by the CA’s policy). This was
ined, such as a site VOMS server. the approach taken in the ShibGrid project [18]; see
also Shibboleth discussion in section 2.7. For users
who do not have long-term certificates, the service
2.2.1 Where Are You From? generates short term certificates and keys.
Most of the work described in this paper applies to MyProxy can also support SASL [12] (allow-
local clients, running within the site. However, we ing Kerberos [19] authentication), PAM (allowing
have also thought about central interfaces (shared LDAP [29], RADIUS[16] and many other authenti-
between sites). cation systems) and PubCookie.
Such interfaces could also run on the user’s ma- Although it is simple to use the MyProxy
chine (e.g. an applet), but would typically be on command-line tools to leverage this functionality,
an NGS server (e.g. the NGS portal), or a third this could potentially present users with quite a
party server (e.g. a project portal). Unlike local barrier to overcome. Many of the target audience
clients which “know” which credential conversion traditionally balk at security in general, certificates
service to contact, a discovery mechanism is needed in particular, and anything that cannot be clicked
for non-local services, and, worse yet, potentially a with a mouse. Therefore, we aim to simplify the
different mechanisms for each one. Any such ser- process as much as possible, and hide the certifi-
vice would of course play a role of the WAYF in cate/proxy process. For our own site’s authenti-
a Shibboleth Federation where each client selects cation infrastructure, Microsoft Active Directory
his or her home institution and is redirected, but (which happily, for the purposes of this work, is
User
User Interface Head WN
Node
WN
Anywhere
User’s home site The NGS Key
X.509 Certificate/Proxy
X509 proxy delegation
Site Credential
Authentication NGS VOMS Site authentication token
Translation
Infrastructure Server
Service (SLCS) VOMS attribute certificate
Figure 2: The architecture for credential conversion in the NGS
User’s PC Portal webserver
Apache + Portal −
User 2 ’mod auth tomcat/
1 10 Head WN
kerb’ glassfish
Web Node
3 6
browser
WN
4
Anywhere 5 7 Key
User’s home The NGS
site X.509 Certificate/Proxy
X509 proxy delegation
Kerberos Ticket Granting Ticket
Site Credential (From Windows logon/Linux kinit)
8 9 NGS VOMS
Authentication Translation Server Kerberos MyProxy Service token
Infrastructure Service (SLCS)
VOMS attribute certificate
Figure 3: Authentication process from a portal.
equivalent to Kerberos 5), we have integrated sup- for the user to delegate its TGT to the portal.
port for Kerberos authentication to MyProxy into
• GSISSH Terminal (Figure 4 on the next
two easy to use Grid access methods:
page.) We have also developed additions to
• Portal access (Figure 3.) Normally, users a Java-based Grid Security Infrastructure en-
who wish to use a Grid portal would have to abled secure shell (GSI-SSH) terminal, GSI-
upload a proxy of their Grid certificate to a SSHTerm [20], which runs in a user’s web-
MyProxy server before logging on to the por- browser or as a standalone Java applica-
tal. At the portal they would then have to tion and provides terminal access to Grid re-
provide the hostname of the MyProxy server sources. These additions automatically call
along with the username and passphrase they out to the Kerberos-enabled MyProxy with
used to store their proxy. The portal would CA to attempt a conversion of the user’s lo-
then contact that MyProxy server with the cal Kerberos credential to a Grid credential,
given detail to obtain a certificate. In our when a user tries to log on to a remote re-
set-up they instead simply visit the por- source.
tal which picks up their Kerberos Ticket
Granting Ticket (TGT) and it uses this to Both of these methods rely on a specially
contact the Kerberos-enabled MyProxy-with- patched version of the Java Commodity Grid (CoG)
CA, which generates a certificate for the user. Kit [28] which allows SASL+Kerberos authentica-
The portal has to be trusted for delegation by tion to MyProxy servers. In choosing to start with
the Kerberos Key Distribution Centre (KDC) Kerberos infrastructure support we hope to support
User’s PC
User 2
1 Head WN
> GSI−SSH 8 Node
Term
WN
3 4 7
Anywhere Key
User’s home The NGS
site X.509 Certificate/Proxy
X509 proxy delegation
Kerberos Ticket Granting Ticket
Site Credential (From Windows logon/Linux kinit)
Authentication 5 6 NGS VOMS
Translation
Infrastructure Server Kerberos MyProxy Service token
Service (SLCS)
VOMS attribute certificate
Figure 4: Authentication process from the GSISSH Terminal.
many institutions as this also encompasses systems tent over time for that user. For some institutions
built on Active Directory. Both these methods fall- it may simply be that they append /CN=
back to username/password authentication (but us- to the CA’s namespace, for others they will call
ing site passwords) to the MyProxy with CA if Ker- out via LDAP to obtain more user information to
beros tokens are absent. generate a DN that is closer to those currently in
In the case of Portal access we have had expe- use the UK e-Science CA. Within our own Active
rience with both the Tomcat and Glassfish servlet Directory domain, for example, we chose to use
engines. In both cases these would run behind an /UID=/CN= .
Apache instance running on the same machine and
utilising mod auth kerb. 2.4 Scalability, Policy, and Assur-
On the server side each institution must install ance
their own dedicated MyProxy server which is con-
figured to work correctly with their site authentica- 2.4.1 Levels of Assurance
tion infrastructure. Although the configuration will
The Level of Assurance (LoA) of a CA or of a
be different depending on the site authentication in-
certificate issued by that CA is an indication of
frastructure there should be enough commonality
the extent to which an entity has been identified
within the same technology to make the provision
as the owner of a credential issued by that CA.
of example configurations useful.
Whereas the US government has proposed using
The policy for the MyProxy’s CA certificate four LoAs [15], Grid CAs have traditionally em-
means that it must be stored on a hardware token, ployed two LoAs. These map approximately to
for example a USB key-token. We have already the US governments LoA levels 1 and 2 (ibid, sec-
undertaken the necessary changes to the MyProxy tions 2.1, 2.3) with only level 2 being accepted
server code to allow it to connect to any hard- internationally, level 1 is usually for internal use.
ware token supported through the openssl “engine” This government-proposed mapping policy was ex-
mechanism1 . This set includes nCipher products, panded to recommended practice by the US Na-
CryptoSwift and key-tokens supporting PKCS#11 tional Institute of Standards and Technology in
and PKCS#15 (through components from the NIST-800-63 [5], which may well be indirectly be-
OpenSC project2 ). We selected to use the Aladdin hind the Grid requirements for “medium assur-
eToken, through the PKCS#15/PKCS#11 inter- ance” described below.
face. We have of course contributed these changes
to MyProxy. 1. Low LoA Little or no identity verification
Another issue is which Distinguished Name has taken place during the issuance of the cer-
(DN) to give to users. The policy for the CA cer- tificate. Such CAs are typically used to issue
tificate requires that the MyProxy CA will sign its training or test certificates to access resources.
certificate in a particular namespace. Further to 2. Medium LoA The certificate applicant is re-
this we only require that each user’s DN is unique quired to meet a representative of the CA, the
to that user, traceable to that user and consis- Registration Authority (RA) in person during
1 http://www.openssl.org
2 http://www.opensc-project.org/
the certificate application process. Further- day per operator, assuming it is distributed evenly
more, the applicant is required to present an (even though the RA need not verify the user’s
original photo id document as proof of iden- identity, they must still perform a simple check that
tity, while the RA is required to retain a copy the user is still associated with the project or or-
of the document for a specified period of time ganisation).
(at least as long as the lifetime of the certifi-
cate). The RA may stipulate the accepted Moreover, a new requirement is being added by
forms of documents, typically an id card of the internal Grid CA community, that users must
the institution where the RA is situated, a reauthenticate with their RA every N years, where
driving license or passport. The Classic Au- N depends on how the private key is stored, as well
thentication Profile of the IGTF requires all as other factors; N = 5 is typical. That means on
Grid CAs to be at least Medium LoA to be average 200000 reauthentications every year.
accredited to the IGTF.
Even if people didn’t have to reauthenticate, a
3. High LoA If a Medium LoA CA is con- medium level Grid CA still requires them to gen-
sidered inadequate for particularly high risk erate their own key pairs, and on relatively secure
relying parties then additional requirements systems, e.g. their own desktop machine, not a
may be stipulated covering identity verifica- shared service. Thus, people have to manage and
tion or how certificates may be issued. For ex- convert their own keys and certificates, and the sup-
ample, resources protecting particularly high- port load required to support 106 PKI-novice users
risk data may choose only to accept certifi- managing their own keys would be beyond the ca-
cates from a CA which includes biometric ver- pacity of NGS support.
ification of applicants and who only issues cer-
tificates protected by secure cryptographic de- One of the aims of this project is to be scalable
vices which can prevent the private key of the to a million users distributed over 103 institutions,
certificate being exported. increasing the usability at the cost of the assurance
that the CA can guarantee.
It is worth noting that the Grid’s medium as-
surance falls short of meeting NIST’s Level 3. For Another aspect of a medium assurance CA, as
example, most CAs make “best efforts” to revoke mentioned above, is that people have to show photo
(issue a new CRL) within “one working day” (of the id during the identification process. People may ar-
revocation request being approved) rather than 24 gue that site authentication is typically at least as
hours. Globus proxies and delegations permit cre- good as that: your employer probably saw your
dentials to be passed around and may live longer passport, birth certificate, etc. However, there are
than 24 hours (“freshly issued”, [5] 8.2.3.1.) “Pic- two problems with this approach: firstly, the CA
ture id” is required for all, but many CAs accept has no access to this information, so cannot, for ex-
photo id issued with a site account in addition to ample, rely on it to ensure that the distinguished
driver’s licence or passport. Indeed, the emerg- name (DN) in the certificate is never reallocated to
ing MICS profile (work in progress, mainly led by another person. Secondly, the CA cannot guaran-
TAGPMA) enables a CA to skip the RA step and tee that this process has taken place: many sites
issue certificates directly for site accounts. On the have visitors or contractors who are also in the site
other hand, no Grid CA except the project catch-all database, and may not be managed as strictly as
CAs accepts remote verification. A full comparison those in the payroll database.
is interesting but beyond the scope of this paper.
HEBCA has started looking at the Grid assur- The other aspect of scalability is that of the
ance levels, to evaluate the feasibility of bridging number of CAs. In this model, we have one CA
the Grid PKI to the US Higher Education. Al- per institution. However, current Grid middleware
though in progress, we describe this work further must have each CA installed, whether it is an end
in section 2.6. entity issuing CA or not. This is fine for the “stan-
dard model” with one per country [4], but not with
2.4.2 Scalability N 1 per country for a global collaboration. It
should be feasible for NGS to trust M countries and
Consider a medium assurance CA issuing certifi- N institutes, though—the number of certificates is
cates to 106 users (the estimated number of higher M + N , rather than M N . A similar situation is
and further education users in the UK is of this found in TeraGrid which is itself served by more
order of magnitude). Even assuming that no new than one CA. Furthermore, several related middle-
users are added, the Registration Authorities (RAs) ware problems have been found where the software
must process 106 renewal requests per year, which has “mysteriously” failed once the number of CAs
translates to over 2500 per day (if every day is a has reached a certain limit (usually around 60), but
working day). With 250 operators, that is 10 per these are mostly fixed.
2.4.3 Account management It is thus clear that, unlike other applications
of PKI such as smart cards where the mechanics
Another scalability problem is that of authorisa- of PKI are shielded from the end user, Grid users
tion, which has traditionally been done by the Sub- are required to have a basic grasp of using digital
ject DN, in the gridmap files. certificates. Whilst this may be reasonable for the
To get around this problem, NGS will, like many majority of Grid users at present who come from a
other Grids, be using VOMS to manage its user scientific computing background, there are increas-
authorisation. VOMS [2] provides a central Vir- ing trends, not only in the UK but worldwide, for
tual Organisations (VOs) service that manages VO Grid computing to be used in multidisciplinary re-
membership and roles. Ordinarily the user, us- search, and particularly so for the NGS.
ing either their certificates, or more commonly a The authors of this paper, who not only manage
Globus proxy [23], accesses the VOMS server and and run the UK e-Science CA but also work with
gets another proxy, this time with attributes de- the helpdesk which deals with user queries related
scribing their VO membership and optional roles. to the CA, frequently encounter frustration from
One of the advantages of generating the certifi- end users who view digital certificates and their us-
cates specifically for the NGS Grid, and the fact ability issues as a barrier to using the Grid. This
that they are short-lived, is that we can embed au- may be partly alleviated with a CA that is easy to
thorisation attributes in them, without requiring use and well documented; work has been done to
the user to perform the second step of contacting address these issues [10]. However, the overhead
a VOMS server. This is particularly important be- of learning about digital certificates remains, and
cause we aim to simplify or even hide the process if the current authentication methods continue to
from the user, so if the attributes can be embed- be used, these usability problems will be encoun-
ded in the proxy generation step, that simplifies tered by the increasing number Grid users from
the process for us and improves usability for the non-computing domains.
user. In the work described in this paper, usability
Such work was done in the Manchester “SHE- is improved because basic certificate management
BANGS” [17] (“Shibboleth Enabled Bridge to Ac- can be done by portals and other tools on behalf
cess the NGS”) project, where a MyProxy server is of the user, and locally at the user’s site. It en-
contacted for user attributes which are then embed- ables sites to provide the “single sign-on,” i.e., sin-
ded in a certificate (independently of VOMS, but gle password, mechanism by integrating the site’s
compatible). We can leverage this work to provide credential conversion MyProxy with the site’s au-
attributes for NGS. thentication system; this is also one of the advan-
The site service needs to call out to, or cache in- tages of Shibboleth. Moreover, we can improve us-
formation from, the NGS VOMS server, but should ability further by removing the need for the user to
of course be able to fall back to “plain” (non- call out separately to a VOMS server.
attribute) certificates in case the VOMS server is For certain types of client tools, we can even
unreachable. This attribute management will have hide the certificate/proxy generation from the user
to be independent of the site (Shibboleth) Attribute completely—every single step is performed trans-
Authorities, because they pertain to NGS work, not parently by the tool on the user’s desktop, con-
to site databases; nevertheless, there may be cases tacting the local conversion service using the user’s
where NGS software will need to authorise based cached desktop login credential, and the conver-
on both types of attributes. Combining these at- sion service in turn contacts the global NGS VOMS
tributes is future work, but may be able to use the server. Thus, the user need not even know that the
work from GridShib [30] which aims to make site client tool has generated a certificate on behalf of
attributes available to Grid resources. the user.
As discussed in section 2.3 we can do this
2.5 Usability with Microsoft Active Directory—and equally Ker-
beros V—but the account management step is cur-
X.509 digital certificates are the most widely used rently missing. We have the account request step in
method of authenticating users to Grids. Prior to ShibGrid, but of course it requires Shibboleth. The
using the Grid, users are often required to request obvious solution is to build a desktop registration
certificates using some form of a user agent, typ- client which the user can use to request a personal
ically a web browser. Once issued, the certificate account. A smarter solution would see the user
typically needs to be converted to a form that is us- registering with GridShib-exported site attributes,
able by Grid middleware, stored in an adequately being joined to an NGS VO by a site-local admin-
secured manner. New Grid users therefore need to istrator, and would access NGS resources on the
learn the fundamentals of key management as well basis of attributes alone. However, as discussed in
as the processes of revocation and renewal and un- section 3 this requires a greater trust in the site’s
der which circumstances these must be done. operations.
2.6 The USHER Hierarchy and though profiles are often not directly comparable
Levels of Assurance revisited even when they both claim to follow RFC 3647. In
this case, the exercise (ibid, p. 9) showed the IGTF
In this section, we briefly cover the USHER work “classic” authentication profile (the first implemen-
since it is similar to the PKI-aspect of the work tation of what we have referred to as “medium as-
described in this paper. surance” in this paper for Grid CAs), being equiv-
The US Higher Education Root [26] is operated alent or slightly worse to HEBCA level “Rudimen-
by Internet2 to establish a PKI for educational in- tary” and the Federal PKI level C-4.
stitutions. It consists of a root which issues certifi- Although interesting from an academic point of
cates to institutional CAs, and it imposes require- view, this work should not yet be relied upon for
ments on the institutional CAs. USHER imposes mappings. Usually clarifications and policy adjust-
the requirement that certificates are issued by sub- ments bring partner policies closer together.
ordinates From our (NGS’) perspective, the importanta-
“using a process that is at least as strong nce lies in establishing the policy mappings, even
as its existing practice for managing ac- just tentatively. NGS has in the past been required
counts for central services such as elec- to “interoperate” with TeraGrid, and this has so
tronic mail, calendaring, and access to far been accomplished between the IGTF-approved
central file storage[27]” CAs, with lengthy separate reviews for those pend-
ing such accreditation. For example, the UK e-
This is equivalent to the assurance provided in Science CA is trusted by TeraGrid for this reason.
Shibboleth, and to what we have in our project— Experience has shown, however, that the US is a
with the important difference that we do not have large country with many diverse PKIs, and usu-
an explicit commitment from the site. In fact, we ally the NGS has to trust one or more non-IGTF-
do not know the exact practices implemented by accredited CAs. We have had requests from users
the site to meet these requirements, nor do we have in the US with no “obvious” CA for NGS access,
the ability to audit the site’s practices. and in the future it would be convenient if their
The principal difference between USHER and institutions could get CAs via USHER, at least if
our PKI deployment is that our PKI deployment they have a need for more than a few certificates
is much simpler, partly because we have no need (otherwise a project-related “catch-all” CA could
for the institutions to trust each other’s creden- do the job). Mapping the USHER policies with
tials. Only the resource providers need to trust the known Grid policies (namely, medium assurance)
credentials of all the institutions, and the resource will greatly help the NGS evaluate the trust of those
providers, although individually members of partic- CAs.
ipant institutions, are all part of the NGS. There is As regards the UK and the PKI described in this
a world of difference between asking the University paper with the institutions participating in NGS,
of Oxford, say, to trust a CA, or to ask the NGS there is in general not much we can do about get-
administrator at Oxford to trust the same CA. In ting the institution to commit to a certain level of
a sense, we achieve the same result as USHER via assurance. As we described above and discuss in
the back door—via the project, not via the institu- more detail in section 3 we are not exposed to the
tion. The drawback is that our CAs are not widely institution’s user identity process, nor can we de-
trusted, but we can live with that because we need mand legally binding documents to this effect, since
them only for the NGS. this was supposed to be a lightweight PKI to com-
Another simplifying fact is that we have no need plement the Shibboleth deployment.
for long-term credentials, so can rely on the institu-
tional CAs to perform the conversion as and when
it is needed. 2.7 Shibboleth Interoperability
Of course, our work is more than a PKI deploy- 2.7.1 Credential Conversion with Shib-
ment: we are helping sites deploy MyProxy-based boleth
credential conversion servers, along with client tools
and NGS-specific software such as portals that use One could create a central CA portal to which each
it. Thus, our PKI deployment is tailored to fit the user connects to obtain a certificate. To ensure that
project rather than being a general purpose PKI. the home site database is queried, users must use
HEBCA/USHER started work [3] to map Grid Shibboleth to access this CA. Indeed, this is more or
(more precisely, IGTF) authentication profiles to less the model SWITCH used for one of their CAs.
their own assurance levels (HEBCA is the EDU- In the UK, we chose the approach of distributing
CAUSE US Higher Education Bridge CA)—note the subordinate credential conversion CAs to sites,
that Grid authentication profiles are all roughly for three primary reasons:
“medium assurance.” This sort of policy mapping Firstly, the practical reason, because there isn’t
exercise is commonly done for bridge CAs [11], al- yet a widespread Shibboleth deployment in the UK.
Secondly, because of the personal data; we can- there will be more than one portal, and not all NGS
not rely on sites being able (or willing) to release work will be done via portals. Nevertheless, using
sufficient personal data from their Attribute Au- portals that call out to a central high-availability
thorities to uniquely identify the user and map MyProxy is an option we may use in the future,
them to the same DN every time: at the time of when we are sure that all of the NGS is covered by
writing (Oct 06) it is not clear whether sites in the Shibboleth federation. This, too, would allevi-
the UK Federation are required to publish anything ate the lack of support for roaming users, since they
other than eduPersonScopedAffiliation (for an ex- could use the site credential conversion when on-
planation of the eduPerson schema please see [1]). site, and Shibboleth as a more complex alternative
We would need at least eduPersonTargetedID but when off-site. In that case, a Shibboleth federation
that in turn will not be sufficient to satisfy those covering the NGS userbase adds value to the work
Grid resources that require “meaningful” common- described in this paper—or vice versa—although
Name (CN). Even if NGS itself chooses to accept there is a danger, with more than one issuing au-
pseudonymous identities, which could be imposed, thority, that the user will have more than one DN.
if at all, only on the core sites, some affiliated re- This is discussed further in section 2.7.2 below.
sources have already that pseudonymous identities In the distributed model the certificates are gen-
will not be accepted. erated locally (within the user’s home institution)
In fact, the base UK Shibboleth Federation and can be used locally, on the user’s desktop, as
aims to be pseudonymous, with explicit agree- we mentioned above, and the service does not need
ment between Identity Providers (IdPs) and Ser- to be exposed to the outside world. The credential
vice Providers (SPs) whenever extra attributes are conversion service can pick up attributes that the
required. This means the institutions have to worry institution’s Shibboleth IdP may not publish, such
about data protection issues. For some, the provi- as the commonName (CN). Whether the service is
sion of an institution’s IdP may even be out-sourced allowed to expose this to the NGS is a question
with no link back to the institutions user database, of site data protection policy. The local credential
which implies that these attributes cannot be pro- conversion services also allow more robust trace-
vided. Finally, some sites with NGS users may just ability if pseudonymous DNs are used.
not join the Shibboleth federation. Moreover, an institution providing user account
Thirdly, using “smart clients” we can lever- management with higher assurance can use that, in-
age the sites’ internal authentication infrastruc- ternally or externally, without having to live with
ture without compromising site security. Unlike certificates created with a Shibboleth federation’s
the Shibboleth portals where users need to select lowest common denominator level of assurance.
their home site and then log in again to their home Finally, it is relatively easy to add a new insti-
site, our smart clients can pick up the user’s site tution to the NGS framework whereas joining the
authentication token and transparently generate a UK Shibboleth federation is more work—the latter
VOMS-proxy with which the clients can access the requires a legally binding commitment on behalf of
NGS Grid on behalf of the user. Not all clients are the institution as well as setting up and running a
“smart” enough to do that, but as mentioned ear- high-availability IdP.
lier (sections 2.2 and 2.5) for parts of the userbase
we aim to even hide that the proxy exists. As men-
2.7.2 Accessing the Grid via Shibboleth
tioned in section 2.2, compared to Shibboleth, we
Portals
lose the ability to support roaming (off-site) users
with the work described in this paper. Some version of the central Shibboleth-portal
It is worth looking at other aspects of the dis- model, as discussed in the previous section, is likely
tributed vs. central issues in more detail: to be implemented in the long term, via an NGS
For the central model, running a central high- portal. Work is already being done to “Shib-
availability CA is a big commitment. The dis- enable” one NGS portal [18], and it will be feasible
tributed model distributes the burden: a site’s to integrate certificate generation into the portals.
server can still go down, but at least only that site In this central model, the private key will be gen-
is affected, not the whole Grid. Another advantage erated remotely (by the portal), and the certificate
of the model proposed in this paper is that not even by a central service accessed by the portal. The
the VOMS server needs to be high availability: if challenge here is to ensure that both views are con-
it is unavailable, sites can fall back to cached infor- sistent: the portal views — there may be more than
mation. Information that is potentially slightly out one portal — and that of the site’s credential con-
of date is better than none at all. version service.
Furthermore, if there is a central CA portal cre- Within this world a user may have many DN-
ating credentials for the users, then users need to based identities: a DN from the UK e-Science
use that credential either wholly within that por- medium assurance CA or one of its international
tal, or export it from the portal. For NGS, though, peers, a DN from the Shibboleth credential con-
version service (usually from a central Shibboleth single CD image, similar to the NAREGI CA-on-a-
portal), a DN from her institution’s local credential CD or Scott Rea’s (Dartmouth College) OpenCA-
conversion service and maybe even DNs from other on-a-CD (but of course using MyProxy instead of
institutions where she may have accounts. How OpenCA).
does a Grid resource know that all these DNs are
the same user?
Maybe it doesn’t have to know. As long as 3 Security Issues
authorisation only depends on the VO attributes
(neither site attributes, nor the identity), the user No CRLs are published. It is common practice that
will have the same access rights, assuming of course proxies [23] live about 12 hours, but as we men-
that the user gets the same VO attributes for each tioned, they could be valid for anything up to 106
identity. However, current middleware deployed seconds. This leaves a window in which a compro-
on NGS sites still depends on gridmap files, i.e., mised credential could be misused, but the same
identity-based authentication. problem is found in general with long lived X.509
Tying the same VOMS attributes to several certificate where the user must first notice that the
identities, or more generally run a database that credential has been compromised, must then re-
knows about the identity mappings, is a problem quest revocation, under some circumstances that
we cannot currently solve. It relies on the user’s request will have to be approved (usually when it
collaboration, but even honest users may be put off hasn’t been signed with the user’s private key), then
by the work required to register DNs centrally—as the CRL has to be issued, and finally, the RPs will
we explained (section 2.5), many target users don’t have to download the CRL. We thus do not consider
want to know about certificates. We could go some the lack of CRL a particular security risk, although
way towards this goal by comparing commonNames the architecture should encourage users to protect
(CNs); for the less common names (less common their private keys, since, as mentioned above, we
commonNames if you will) it would give us an in- cannot expect users to be experts. Hiding the key
dication of when two different DNs represent the from the user helps as long as the local client is
same user, and this task could even be automated careful to store it on local disk. Backups are not
but would still need human review. necessary because the client will be downloadable
Meanwhile, our assumption is that this will not and the identity can be easily regenerated by the
be a problem as most users will, in general, stick user.
with the same identity. Users might make changes The quality of site identification has been a
to which way they log on, but they probably will contentious issue for many years, particularly for
not keep changing between different methods, espe- credential conversion CAs seeking to be accepted
cially if their institution only supports one form of by international Grid projects. It is hard to per-
credential conversion service. This behaviour will suade collaborators that your identification process
be enhanced by allowing the same set of resources, is good enough when the CA manager is not re-
services and access methods through all types of sponsible for the user data, and in general has no
identity. access to it. It is all the more difficult when the
site database contains external users, contractors,
2.8 Status or temporary staff. In the few cases where Grid
projects have accepted such a CA, the credential
We finally get to the status of the deployment. conversion has been at the same site as the CA
The hierarchy has been set up, but the access has (FNAL, CERN), and the CAs have been able to
only been tested locally within two of the core sites enforce a security level necessary for medium as-
(namely, University of Oxford and Rutherford Ap- surance by using existing assurance level flagging
pleton Laboratory). Independently, we have tested in the site database (or very occasionally the Grid
the attribute services with both VOMS and SHE- project has pragmatically decided to trust the CA
BANGS, but this work has so far only been in the until a problem occurs). Indeed, most sites would
test phase because the NGS does not yet use VOMS be reluctant to share their user data with a CA au-
for VO management in production. ditor, because it would violate data protection poli-
Furthermore, we already provide both “normal” cies. However, although the sites provide no such
and single sign-on MyProxy services for the NGS. assertion to the NGS in this framework, they do in
Ongoing work over the next months will see wider general use their site databases also for access to
deployments to core sites and further integration more “precious” resources, e.g., internal financial
of the independent components, primarily combin- information. We have thus decided that we can
ing the SHEBANGS work with the site credential reasonably expect sites to operate the databases
conversion service at University of Manchester. to a “satisfactory” level, even if we have neither
Deployment will be further enhanced by deploy- documentation for what this level is, nor a binding
ing the required software—all but the keys—on a commitment to operate to it. This trust is par-
ticularly important with pseudonymous credentials large number of users, and to improve usability for
where we rely on the site to maintain the mapping non-technical users by making—for certain types
to the user’s real world identity, but also for sites of client tools—the entire certificate and proxy is-
where access is potentially granted to the site us- suance process hidden from the user. We have de-
ing site affiliation such as the Shibboleth site at- scribed how the deployment is lightweight, requir-
tribute (scopedAffiliation), i.e., access is granted to ing no legally binding commitment on behalf of the
all users on site at the site’s discretion. A site found institutions. We have described scenarios where we
to abuse this access privilege can be revoked from grant access to the NGS based on site or Virtual
accessing the NGS, and the embarrassment factor Organisation membership attributes. We have dis-
will most likely fall upon the site rather than the cussed how we weigh the associated security con-
NGS itself. cerns, improving them where possible and accept-
The scalability issue, as described in sec- ing them where not.
tion 2.4.2 means that, for the purposes of this NGS
deployment, medium assurance is too strong. How-
ever, there may well be cases where the NGS will References
require a higher level of assurance. People requiring
such access will either have to get a certificate from [1] Internet 2. Eduperson specification. Iden-
the UK e-Science CA (for example, this is required tifier: Internet2-mace-dir-eduPerson-200312,
to access TeraGrid), or will have to prove indepen- December 2003. Version 200312. Available
dently that their site authentication was sufficiently at http://www.nmi-edit.org/eduPerson/
strong. This assurance level can subsequently be internet2-mace-dir-eduperson-200312.p%
managed as a VO attribute. CERN has taken this df.
approach with their internationally approved MICS
CA: it issues certificates only to users in the site [2] R. Alfieri, R. Cecchini, V. Ciaschini,
database with one of fourteen different status, and L. dell’Agnello, Á. Frohner, A. Gianoli,
one type of external contractors. Each of those sta- K. Lrentey, and F. Spataro. VOMS, an
tus flags ensures that the user has shown appropri- authorization system for virtual organiza-
ate photo id to the CERN user office. tions. Lecture notes in Computer Science,
(2970):33–40, 2004. Grid Computing, First
Finally, for access to, e.g., certain medical im-
European Across Grids Conference, Santiago
ages (non-anonymised), or financial data, it may
de Compostela, Spain, February 13-14, 2003.
be that medium assurance is not strong enough.
High assurance cannot be provided within this PKI, [3] P Alterman and S Rea. Policy Mapping Grid
partly because we have no explicit commitment CAs. http://indico.na-df.rnp.br/indico/
from the institutions. Rather, it would have to be materialDisplay.py?contribId=10\&
provided by either a separate CA, or with special %sessionId=1\&materialId=slides\
certificates issued by the e-Science CA with flags &confId=15, Nov 2006. 3rd TAGPMA
(e.g., policy OID) to mark it as high assurance. meeting, TACC, Austin Texas (URL checked
Feb 07).
[4] J. Astalos, R. Cecchini, B.A. Coghlan,
4 Acknowledgments R.D. Cowles, U. Epting, T.J. Genovese,
J. Gomes, D. Groep, M. Gug, A.B. Hanu-
This work is funded by the National Grid Service
shevsky, M. Helm, J.G. Jensen, C. Kanel-
in line with its provision of a national Grid CA
lopoulos, D.P. Kelsey, R. Marco, I. Neil-
and Grid support; the closely related work in Shib-
son, S. Nicoud, D. O’Callaghan, D. Quesnel,
Grid and SHEBANGS is funded by the UK Joint
I. Schaeffner, L. Shamardin, D. Skow, M. Sova,
Information Systems Committee (JISC) under the
A. Wäänänen, P. Wolniewicz, and W. Xing.
current (Apr ’04-Apr ’07) core middleware develop-
International grid CA interworking, peer re-
ment programme.
view and policy management through the Eu-
This document typeset with LATEX.
ropean DataGrid certification authority coor-
dination group. In P. Sloot, A. Hoekstra,
T. Priol, A. Reinefeld, and M. Bubak, editors,
5 Conclusion Advances in Grid Computing — EGC 2005,
LNCS3470, pages 285–295, Amsterdam, The
In this paper, we have described an architecture
Netherlands, February 2005. Springer.
for a Grid PKI for the UK National Grid Service,
NGS, deployed alongside and interoperating with [5] William Burr, Tim Polk, and Donna Dod-
the national Shibboleth deployment, as well as the son. Electronic authentication guideline. NIST
existing global Grid PKI. The work aims to provide Special Publication 800-63 Version 1.0.2, April
“NGS access for the masses” and be scalable to a 2006.
[6] R Butler and T Genovese. Global grid fo- M. Viljoen, and D. Wallom. Shibgrid: Shib-
rum certificate policy model. http://www. boleth Access for the National Grid Service. In
ggf.org/documents/GFD.16.pdf, June 2003. Proc. IEEE 2nd Int’l Conf. on e-Science and
[7] D. Byard and J. Jensen. Single sign-on to the Grid computing, 2006.
grid. In Proceedings of the 2005 UK e-Science [19] J. Steiner, C. Neuman, and J. Schiller. Ker-
All Hands Meeting, September 2005. beros: An authentication service for open
[8] TAGPMA. Editor T. Genovese. Profile for network systems. In Proceedings of the
short lived credential services X.509 public USENIX Winter Conference, Dallas, Texas,
key certification authorities with secured in- USA, pages 191–202, February 1988.
frastructure. Reference: IGTF-AP-SLCS- [20] NGS Grid Support. GSI-SSH Terminal.
20051115-1-1, November 2005. Version 1.1. http://www.grid-support.ac.uk/content/
Available at http://www.tagpma.org/files/ view/81/61/.
IGTF-AP-SLCS-20051115-1-1.pdf.
[21] SWITCHaai. http://www.switch.ch/aai/.
[9] J. Jensen, D. Spence, and M. Viljoen. Grid sin-
[22] TeraGrid. http://www.teragrid.org/.
gle sign-on in CCLRC. In to appear in the pro-
ceedings of the 2006 UK e-Science All Hands [23] S. Tuecke, D. Engert, I. Foster, M. Thomp-
Meeting, September 2006. son, L. Pearlman, and C. Kesselman. Inter-
net X.509 public key infrastructure proxy cer-
[10] J. Jensen and M. Viljoen. Usability of the
tificate profile. Request for Comments (RFC)
UK e-Science Certification Authority. UK e-
3820, June 2004.
Science All-Hands meeting, 2005.
[11] Mark Luker. A bridge for trusted electronic [24] UK e-Science Certification Authority. http:
communications in higher education and fed- //www.grid-support.ac.uk/ca/, Oct 06.
eral government. http://www.educause.edu/ [25] UK Shibboleth Federation. http://www.
ir/library/pdf/ERM0203.pdf. ukfederation.org.uk/, Oct 06.
[12] J. Myers. Simple authentication and security [26] Us Higher Education Root pki. http://
layer (SASL). Request for Comments (RFC) usher.internet2.edu/.
2222, October 1997.
[27] Usher Subscriber Expected Practices.
[13] National Grid Service. http://www.ngs.ac. http://usher.internet2.edu/docs/
uk/, Oct 2006. USHER-Expected-Practices-final.htm,
[14] J. Novotny, S. Tuecke, and V. Welch. An Nov 2006.
online credential repository for the Grid: [28] G. von Laszewski, J. Gawor, P. Lane, N. Rehn,
MyProxy. In 10th IEEE International Sympo- M. Russell, and K. Jackson. Features of
sium on High Performance Distributed Com- the Java commodity Grid kit. Concurrency
puting (HPDC-10), San Francisco, California, and Computation: Practice and Experience,
USA, pages 104–114, August 2001. 14:1045–1055, 2002.
[15] US office of management and budget. [29] M. Wahl, T. Howes, and S. Kille. Lightweight
E-authentication guidance for federal agen- directory access protocol (v3). Request for
cies. http://www.whitehouse.gov/omb/ Comments (RFC) 2251, December 1997.
memoranda/fy04/m04-04.pdf, December
2003. [30] V. Welch, T. Barton, K. Keahey, and
F. Siebenlist. Attributes, anonymity, and ac-
[16] C. Rigney, S. Willens, A. Rubens, and cess: Shibboleth and Globus integration to fa-
W. Simpson. Remote authentication dial in cilitate Grid collaboration. In Proceedings of
user service (radius). Request for Comments the 4th Annual PKI R&D Workshop, April
(RFC) 2865, June 2000. 2005.
[17] SHEBANGS (Shibboleth Enabled Bridge to [31] V. Welch, F. Siebenlist, I. Foster, J. Bresna-
Access the National Grid Service). Details at han, K. Czajkowski, J. Gawor, C. Kesselman,
http://www.sve.man.ac.uk/Research/AtoZ/ S. Meder, L. Pearlman, and S. Tuecke. Secu-
SHEBANGS, June 2006. rity for Grid services. In 12th International
[18] D. Spence, K. Tang, R. Allan, M. Dovey, Symposium on High-Performance Distributed
N. Geddes, J. Jensen, A. Martin, D. Mered- Computing (HPDC-12), Seattle, Washington,
ith, M. Norman, A. Richards, A. Trefethen, USA, pages 48–57, 2003.
Developing a National PKI for
a National Grid
6th PKI Workshop, NIST, Apr 07
Jens Jensen, David Spence, Matt Viljoen
STFC Rutherford Appleton Laboratory
Background
National Grid Service
• The “Grid for the United Kingdom”
– Other national Grid is GridPP, the Grid for particle physics
• Consists of four core sites
– Universities of Oxford, Leeds, Manchester
– Rutherford Appleton Laboratory
• And a large number of “partner” sites
• Currently ~500 users (who all have Grid certificates
from the global Grid PKI)
The UK e-Science CA
• Second largest Grid CA in the world
– The DoE Grids CA is larger
• Currently ~1200 valid users and 2200 hosts
• About 60 RAs distributed throughout UK
• In production for 4.5 years
• Certs for people, hosts, services, robots
Why X.509
• Works with the Grid • Standardised
• Works with other stuff – Mostly
– Web and browsers – Some special Grid issues
• Good for hosts • Using proxies for “single
• Grid does have single sign-on”
X.500 namespace
Security vs Usability
• People perceive certificates as difficult
– PKCS#12 <-> PKCS#8
– Passphrases
• Goal: improve usability
– without compromising security
– can even improve security
Scalability
• Medium assurance
– Each renewal requires RA approval (~1yr)
– Re-check identity after N renewals (~5 yr)
• For 106 certs (and 200 working days)
– 5000 renewals/day
– 1000 re-checks/day
What is single sign-on anyway
1. Account management: each user has a
single registration
2. Single password: a single password is used
to unlock all resource accounts
3. Single authentication – each user must type
the password only once
• Per day, per week, per login
What is single sign-on anyway
4. Credential gymnastics
• Credential conversion
• GT2 delegated proxies
5. Delegation
• (beyond scope of this talk)
Using Institution IdP
• Puts identity management in institution
– That’s good – they do it anyway
– That’s bad – the CA has no control
• Associate DN with identity
• Institute does not (usually) release information
• Institute does not describe vetting policy
– So lower assurance
Using Institution IdP
• Solves scalability problem
• Shibboleth does this too!
– Why not use Shibboleth then?
Comparing to Shibboleth
• Complementary – coexist with Shib
• Simpler – no need for attributes (at this level)
• Simpler – used only to access Grid
• Simpler – no WAYF but on site only
• Joining is infinitely cheaper
– Driven by the NGS Grid, not institution
– Some similar data protection issues
Two Models
Institute A Central Institute C
CA
Institute B The Grid Institute D
Two Models
Institute A Institute C
Local Local
CA CA
The Grid
Local Local
CA CA
Institute B Institute D
Two Models
The SWITCHaai
Central
Institute A
CA
Institute C model
Institute B The Grid Institute D
Institute A Institute C
This one (NGS) Local Local
CA CA
The Grid
Local Local
CA CA
Institute B Institute D
Two Models
• Institution using local SSO to local CA
– Institutional goodies not leaving institution
– Can use SSO: single login
– But need to build for each institution
– But many institutions have much the same
– Active Directory / Kerberos V
Overview
Institutional
CA
User (MyProxy
based)
Institution DB
It’s the apps, stupid
• Thin ones (browser), applet or portal
• Thick ones – user client
• Portal – calls directly to MyProxy
• Killer app: Java GSISSH terminal
– Modified from upstream
• Tie with SSO: users don’t know they have
certs
Killer App
SSO Terminal
User (on desktop) Head Node
or
User Interface
Institutional
CA
Technology
• MyProxy based contributed modifications
– …to use keys on tokens (increase seucirty)
– …to integrate with portal
• Potential to use Microsoft Server 2003
– Built-in CA, used by CERN
– We haven’t tried this
Technology
• Compare to KCA (Kerberos CA)
– KCA converts Kerberos ticket to short-lived
cert
– So does this
– MyProxy can proxy off existing cert
Technology
• GSISSHTerm can run stand-alone or as
applet
• With Java 1.6, can automatically pick up
ActiveDirectory/Kerberos ticket
Trusted CA
(Explicit Trust)
e-Science
Accredited ROOT
CA
Credential
e-Science NGS Training
conversion
CA and Monitoring
top level
Institutional Institutional Institutional
CC CA CC CA CC CA
Splitting
• Different CAs can have different
assurance levels – or not
• Conversely, users may have more than
one identity (two different certs)
Conclusions
• “Grid Interoperability Now”
– Or, “It’s the glue, stupid”
– Convert existing tokens – SSO
– To something the Grid uses
– Constrained to institutions on a specific Grid via
CA hierarchy
– Generate short-lived certs or proxy existing cert
• Complementary to Grid PKI and Shib
• http://www.ngs.ac.uk/ -> Grid Utilities
A Certificate-Free Grid Security Infrastructure
Supporting Password-Based User Authentication∗
Jason Crampton, Hoon Wei Lim, Kenneth G. Paterson, and Geraint Price
Information Security Group
Royal Holloway, University of London
Egham, Surrey TW20 0EX, UK
{jason.crampton, h.lim, kenny.paterson, geraint.price}@rhul.ac.uk
Abstract petabytes2 of online data storage. Despite the promising
signs, many believe that a lot still needs to be done in order
Password-based authentication is still the most widely- to realise computational grids analogous to the pervasive
used authentication mechanism, largely because of the ease electrical power grid. In particular, as commercial interest
with which it can be understood by end users and imple- grows in grid computing, grid security is an issue that will
mented. In this paper, we propose a security infrastructure become increasingly important.
for grid applications, in which users are authenticated us- Currently, the grid security infrastructure (GSI) of the
ing passwords. Our infrastructure allows users to perform Globus Toolkit (GT) [16], proposed by Foster et al. [18],
single sign-on based only on passwords, without requiring plays an essential role in supporting various grid secu-
a public key infrastructure. Nevertheless, our infrastructure rity services, such as single sign-on, mutual authentication
supports essential grid security services, such as mutual au- and delegation. Being based on public key infrastructure
thentication and delegation, using public key cryptographic (PKI),3 GSI users are required to possess and manage long-
techniques. Moreover, hosting servers in our infrastructure term credentials (typically RSA public/private key pairs),
are not required to have public key certificates, meaning which are usually renewed yearly. Inevitably, some ma-
mutual authentication and delegation of proxy credentials chines within the scope of a grid community may lack
can be performed in a lightweight and efficient manner. up-to-date protection in the form of the latest vulnerabil-
ity patches and virus definitions. This may lead to such
machines falling under the partial or complete control of
attackers who are able to remotely exploit vulnerabilities
1 Introduction
and hence obtain long-term user credentials. To minimise
the risk of compromise, many recent grid implementations
The vision of grid computing [17, 19] is to provide easy make use of the MyProxy system [8, 37] to securely store
access to “unlimited” resources, thereby enabling computa- and protect long-term user credentials. MyProxy also offers
tionally complex tasks to be performed and huge amounts the benefit of “credential mobility”, enabling users to access
of data to be stored and shared. There has been some suspi- their credentials from any machine through, for example, a
cion, since the term grid was first used about a decade ago, web browser.
that grid computing might be another technological vision
that turns out to be more hype than substance. Despite that,
the vision prevails and the gap between vision and reality is Motivations. It is desirable that remote computing re-
narrowing quickly. This is evident from the large and grow- sources be accessible from various platforms, including
ing number of grid projects and testbeds worldwide [25]. handheld devices, such as personal digital assistants (PDAs)
TeraGrid [47], one of the pioneering grid projects, which and mobile phones, as well as desktop and laptop machines.
was completed in 2004, is currently capable of provid- In fact, due to the increasing availability of wireless devices
ing 102 teraflops1 of computing power and more than 15 in recent years, wireless grids [2, 34, 41] can offer addi-
tional untapped resources to existing wired computing re-
∗ The research in this paper was supported by the UK Engineer-
ing and Physical Sciences Research Council (EPSRC) through Grant 21petabyte = 103 terabytes = 106 gigabytes.
EP/D051878/1. 3 Here, we assume that existing PKIs make use of certificates. However,
1 A teraflop is one trillion floating-point operations per second. we will later show that a PKI can be certificate-free.
sources. In particular, wireless devices can offer different However, its architecture has a subtle but crucial drawback.
types of resources through their embedded objects, such as In the MyProxy protocol [8], although users are authen-
cameras, microphones, sensors and global positioning sys- ticated to their respective MyProxy servers using conven-
tem (GPS) receivers. More importantly, wireless devices tional username/password techniques, server authentication
can supply information – on temperature, health, pollution is achieved using the server-authenticated version of the
levels, etc. – from geographic locations and social settings TLS handshake protocol [15]. This implies the need to pro-
that are difficult to access through conventional wired net- tect the root Certificate Authority’s public key certificates
works [34]. on the users’ machines. There are ways for an attacker to
The PKI-based GSI is a rather heavyweight apparatus, install a bogus root key in the user’s browser [5, 27]. Hence,
mainly because of the extensive use of public key certifi- if a desktop is vulnerable to stealing of a private key, then
cates [28] and proxy certificates [48]. Generation, certifi- the desktop may also be at risk from replacement of the as-
cation and verification of public keys, distribution of cer- sociated Certificate Authority’s certificate by the attacker.
tificates, and other aspects of traditional public key man- The above issues and observations have led us to our in-
agement using PKIs incur non-trivial overheads. Wireless vestigation of a grid security infrastructure which is not only
devices are often battery-powered and the energy required certificate-free, but also “PKI-free” from the user perspec-
for transmission of a single bit of data is over 1000 times tive.
greater than that required by a single 32-bit computation [6].
Therefore, it is necessary to minimise the communication Contributions. In this paper, we propose a password-
overheads of any grid security infrastructure if we are to ex- enabled and certificate-free grid security infrastructure
ploit the full potential of wireless grids. In short, the emer- (PECF-GSI). Briefly, our proposal enhances the earlier
gence of wireless grids has prompted the need for a more work of Lim and Paterson [32] so that users are only au-
lightweight architecture. thenticated using passwords, with the authentication taking
Lim and Paterson recently proposed a fully identity- place between users and a centralised authentication server.
based security infrastructure for grid applications [32] using This server plays a similar, but not identical, role to the
identity-based public key cryptography (ID-PKC) [14, 44]. MyProxy server in the PKI-based GSI. Our approach has
Key management in this approach is simpler than in the the benefit that neither client nor server certificates are re-
PKI-based GSI because it does not use certificates and key quired during user authentication. Our proposal also com-
sizes are relatively small. For instance, the communication pletely removes the need for long-term user public keys, and
bandwidth requirement for mutual authentication and dele- hence the need for a revocation mechanism for these pub-
gation between two entities can be reduced by up to 90%, lic keys too.4 Instead, users are given short-lived, identity-
when appropriately chosen elliptic curves and system pa- based credentials by the authentication server upon success-
rameters are used [32]. ful authentication. All subsequent security services are car-
Nevertheless, key revocation in the identity-based setting ried out using these credentials on behalf of users, without
can be complicated. Boneh and Franklin [14] proposed the requiring direct user intervention. Thus our proposal sep-
use of a date concatenated with a user’s identifier (the con- arates security functions into two “zones”: a user-friendly
struction of a public key from an identifier will be explained zone, where only passwords are involved, and a certificate-
in Section 2.1.1) to achieve automated key expiry. However, free zone, which is hidden from the users’ view, and makes
this approach has the disadvantage of increasing the work- use of full-strength public key techniques. In addition, we
load of a Private Key Generator (PKG), since the PKG is show how to solve the key escrow issue by adopting certifi-
required to regularly issue private keys to its users. Alterna- cateless public key cryptography (CL-PKC) [3]. Our con-
tively, the PKG could issue private keys less frequently, for tributions can be summarised as follows:
example monthly or yearly. In this case, however, it would
be necessary to adapt conventional key revocation mech- • We design a lightweight and user-friendly grid security
anisms, such as Certificate Revocation Lists (CRLs) and infrastructure. Our proposal inherits attractive proper-
Online Certificate Status Protocol (OCSP), to the identity- ties of the identity-based approach, in particular being
based setting, in order to provide timely revocation of an certificate-free and using small key sizes. Mutual au-
identifier and its associated public key. thentication of a user and a server is based only on a
Moreover, key escrow is inevitable in the identity-based provably secure password-based authentication proto-
setting because the PKG uses a master secret to extract pri- col. Yet, our architecture still supports various grid
vate keys of its users. This may not be desirable in some security services, such as single sign-on, mutual au-
grid applications. thentication and delegation.
MyProxy continues to play a major role in the GSI by of- 4 We still require mechanisms for handling revocation of server public
fering better credential protection and mobility to grid users. keys, however.
• Key revocation in the identity-based setting is a well- lic key cryptography (CL-PKC). We then describe a prov-
known issue [14, 40]. We employ “just-in-time” is- ably secure password-based authentication protocol due to
suance of short-lived keys to avoid any complications Abdalla et al. [1]. We also give a brief overview of the exist-
related to revoking users’ long-term public keys. Our ing grid security infrastructure (GSI) of the Globus Toolkit
approach is rather similar to the use of short-lived (GT), and review some related work.
symmetric keys in Kerberos [36]. This, and the fact
that system parameters of the identity-based primitives 2.1 Cryptographic Preliminaries
do not necessarily need to be pre-distributed or boot-
strapped, gives rise to easy, flexible and user-friendly Let G1 and G2 be two groups of order q for some large
deployment of ID-PKC. We also show how timely re- prime q, where G1 is an additive group and G2 denotes a
vocation for hosting servers’ long-term public keys can related multiplicative group.
be carried out very simply in our architecture, by push- An admissible pairing in the context of identity-based
ing up-to-date revocation information to users during and certificateless public key cryptography is a function ê :
authentication. G1 × G1 → G2 with the following properties:
• We develop an escrow-free grid security infrastruc-
ture using CL-PKC. Key escrow is inevitable in the • Bilinear: Given P, Q, R ∈ G1 , we have
identity-based setting because the PKG extracts pri-
vate keys on behalf of its users, and is a feature of ê(P, Q + R) = ê(P, Q) · ê(P, R) and
the identity-based grid security architecture of Lim and ê(P + Q, R) = ê(P, R) · ê(Q, R).
Paterson [32]. In applications where high-value or
commercially sensitive resources are to be shared, an Hence, for any a, b ∈ Z∗q , we have
escrow capability at the Certificate Authority (CA) or
MyProxy level is unlikely to be acceptable. ê(aP, bQ) = ê(abP, Q) = ê(P, abQ)
• We devise a more efficient and natural delegation pro- = ê(aP, Q)b = ê(P, Q)ab .
tocol than the current technique used in the GSI [49]
and the original approach of Lim and Paterson [32]. • Non-degenerate: There exists a P ∈ G1 such that
This can be achieved by exploiting the properties of ê(P, P ) 6= 1.
hierarchical ID-PKC [24] and CL-PKC [4]. The math-
ematical properties of hierarchical ID-PKC and CL- • Computable: If P, Q ∈ G1 , ê(P, Q) can be efficiently
computed.
PKC allow very efficient credential verification of a
delegatee for a particular delegation. A verifier needs Typically, G1 is a subgroup of the group of points on
only to check the credential of the delegatee, instead a suitable elliptic curve over a finite field, G2 is obtained
of having to verify the credentials of the delegatee and from a related finite field, and ê is obtained from the Weil
all of his ancestors along the delegation chain, as in or Tate pairing on the curve. Given P, Q ∈ G1 and a ∈ Z∗q ,
existing proposals [32, 49]. P + Q denotes elliptic curve point addition, and aP denotes
elliptic curve point (or scalar) multiplication. Note that aP
Organisation. The remainder of this paper is organised can be computed very efficiently. However, the problem of
as follows. In Section 2, we introduce background material finding a given aP is believed to be intractable, when the
relevant to this paper. In Section 3, we present our proposal curve is appropriately chosen. This problem is known as
for a password-enabled and certificate-free grid security in- the elliptic curve discrete logarithm (ECDL) problem. The
frastructure. This includes a description of the architecture reader is referred to [21] for more mathematical background
and its underlying protocols. In Section 4, we explain how on pairings.
key escrow can be removed from the security architecture
proposed in the previous section. Section 5 discusses some 2.1.1 Identity-Based Public Key Cryptography
performance issues of our proposal. Finally, we conclude in
Section 6. In 1984, Shamir [44] proposed the idea of identity-based
public key cryptography (ID-PKC). Instead of generating
and using a random public/private key pair in a public key
2 Background cryptosystem such as RSA or ElGamal, Shamir proposed
using a user’s name or other unique identifier (such as an
In this section, we first give a brief introduction to pair- email address) as a public key, with the corresponding pri-
ings, which are bilinear maps fundamental to identity-based vate component being generated by a trusted Private Key
public key cryptography (ID-PKC) and certificateless pub- Generator (PKG). Since a user’s public key is based on
some publicly available information that uniquely identi- D ECRYPT: Given a ciphertext hU0 , U2 , . . . , Ut , V, W i, this
fies the user, an identity-based cryptosystem does not re- algorithm takes as input the associated private key St
quire a mechanism for authenticating public keys. However, and recovers m. It also checks if U0 , U2 , . . . , Ut have
Shamir was only able to develop an identity-based signature the correct structure. Otherwise, the recovered m is
(IBS) scheme based on the RSA primitive. rejected.
Only in the early 2000s did the emergence of cryp- S IGN: Given a private key St and a message m ∈ {0, 1}∗,
tographic schemes based on pairings on elliptic curves the signer with ID-tuple hID1 , . . . , IDt i computes h =
result in the construction of a feasible and secure IBE H3 (ID1 , . . . , IDt , m) ∈ G1 and σ = St + st h. The al-
scheme [14, 29, 42]. Further details can be found in [39]. gorithm outputs the signature hσ, Q1 , . . . , Qt i, where
Gentry and Silverberg [24] proposed hierarchical each component is in G1 .
identity-based encryption (HIBE) and hierarchical identity- V ERIFY: Given a signature hσ, Q1 , . . . , Qt i of a message
based signature (HIBS) schemes with total collusion resis- m, this algorithm takes as input the associated public
tance, regardless of the number of levels in the hierarchy. In key, computed from ID-tuple hID1 , . . . , IDt i, and re-
the hierarchical setting, a root PKG produces private keys turns a message indicating the success or failure of the
for PKGs in the next level of the tree, who in turn generate verification.
private keys for PKGs or users in the next level (and so on).
It is this scheme on which our proposal is based.5 We now
sketch Gentry and Silverberg’s HIBE and HIBS schemes 2.1.2 Certificateless Public Key Cryptography
(see [24] for full details).
There are applications which do not tolerate key escrow,
which is a feature of identity-based cryptosystems. This has
ROOT S ETUP: The root PKG chooses a generator P0 ∈ led to the development of escrow-free variants of pairing-
G1 , picks a random s0 ∈ Z∗q , and sets Q0 = s0 P0 . based public key cryptography, including Al-Riyami and
It also selects cryptographic hash functions Paterson’s certificateless public key cryptography (CL-
H1 : {0, 1}∗ → G1 , H2 : G2 → {0, 1}n for some PKC) [3] and the certificate-based encryption (CBE) con-
n, H3 : {0, 1}∗ → G1 , H4 : {0, 1}n × {0, 1}n → Z∗q cept of Gentry [23]. It is the former approach that we use in
and H5 : {0, 1}n → {0, 1}n. The root PKG’s this paper.
master secret is s0 and the system parameters are
A user’s private key in the certificateless setting con-
hG1 , G2 , ê, P0 , Q0 , H1 , H2 , H3 , H4 , H5 i.
sists of two components: (i) an identity-dependent partial
L OWER - LEVEL S ETUP: A lower-level entity (lower-level private key (generated in the same way as in the normal
PKG or user) at level t picks a random st ∈ Z∗q which identity-based approach); and (ii) a full private key which
will be kept secret. can be produced using the partial private key and some se-
E XTRACT: For an entity at level t with ID-tuple cret known only to the user. Succinctly, this approach uses
hID1 , . . . , IDt i, where hID1 , . . . , IDi i is the ID-tuple input from the PKG and the user to generate a private key,
of the entity’s ancestor at level i (1 6 i 6 t−1), the en- thereby eliminating key escrow. We now briefly describe a
tity’s parent computes Pt = H hierarchical certificateless encryption (HCLE) scheme and
P1 (ID1 , . . . , IDt ) ∈ G1 ,
sets the secret point St to be ti=1 si−1 Pi = St−1 + a hierarchical certificateless signature (HCLS) scheme [4].
st−1 Pt (note that St−1 is the parent’s secret point
given by the parent’s ancestor and st−1 is a secret value ROOT S ETUP: As in Section 2.1.1.
only known to the parent), and defines Q-values by set- L OWER - LEVEL S ETUP: As in Section 2.1.1.
ting Qi = si P0 for 1 6 i 6 t − 1. The entity at level
PARTIAL - PRIVATE - KEY E XTRACT: As with the E X -
t is given both St , as his private key, and the Q-values
TRACT algorithm in Section 2.1.1, except that this
by its parent.
algorithm
Pt sets the entity’s partial private key Dt to be
E NCRYPT: Given a message m and ID-tuple i=1 si−1 Pi = Dt−1 + st−1 Pt , where Dt−1 is the
hID1 , . . . , IDt i, this algorithm computes the ciphertext parent’s partial private key and st−1 is a secret value
hrP0 , rP2 , . . . , rPt , z ⊕ H2 (ê(Q0 , P1 )r ), m ⊕ H5 (z)i, only known to the parent. The entity’s parent also de-
where z ∈ {0, 1}n and r = H4 (z, m). Note that fines Q-values by setting hQXi , QYi i = hsi P0 , si Q0 i
rP0 , rP2 , . . . , rPt are all elements of G1 and the for 1 6 i 6 t − 1.
sizes of the last two components of the ciphertext are S ET- PRIVATE - KEY: This algorithm transforms a partial
dependent on n. private key Dt of an entity at level t with ID-tuple
5 It is worth noting that other HIBE and HIBS schemes are available. hID1 , . . . , IDt i into a private key St = st Dt , where
We chose the Gentry/Silverberg schemes because they are efficient and st is the secret value that the entity has chosen in
their security is based on reasonable computational assumptions. L OWER - LEVEL S ETUP.
S ET- PUBLIC - KEY: This algorithm sets a public key of unique identity or distinguished name and given a public
an entity at level t with ID-tuple hID1 , . . . , IDt i as key certificate signed by a Grid CA. Public key certificates
hst P0 , st Q0 i. are used to support authentication and key agreement proto-
E NCRYPT: This algorithm first checks if the Q-values cols, such as the TLS protocol. Proxy certificates are used
have the correct structure. It then performs similar for single sign-on and delegation.
steps to the E NCRYPT algorithm in Section 2.1.1, ex- Before a user submits a job request, he must create
cept that this algorithm takes as input the ID-tuple a proxy certificate which includes generating a new pub-
hID1 , . . . , IDt i, the public key hst P0 , st Q0 i and the re- lic/private key pair and signing the proxy certificate with
lated Q-values to compute the ciphertext. his long-term private key. This newly created proxy cer-
D ECRYPT: As with the D ECRYPT algorithm in Sec- tificate can then be used for repeated authentication with
tion 2.1.1, except that this algorithm takes as input a other grid entities. The user’s long-term private key does
different set of Q-values. not need to be accessed again until the expiry of the proxy
certificate. For rights delegation from a user A to a target
S IGN: As with the S IGN algorithm in Section 2.1.1, except
service provider X, three steps are required [49]:
that this algorithm uses different Q-values.
V ERIFY: This algorithm first validates the format of the Q- 1. X generates a new public/private key pair and sends a
values. It then performs the similar steps as with the request (that is signed with the new private key) to A;
V ERIFY algorithm in Section 2.1.1, except that this al- 2. A verifies the request using the new public key, creates
gorithm uses a different public key and Q-values. a new proxy certificate, and signs it with her current
proxy credential (short-lived private key);
We remark that the above schemes do not have for-
3. A forwards the new proxy certificate to X.
mal security models and proofs. Nevertheless, they are
straightforward adaptations of the provably secure HIBE Note that A can impose some constraints on what X can
and HIBS schemes of Gentry and Silverberg described in and can’t do, using the ProxyPolicy field of the proxy
Section 2.1.1. certificate. A has to trust that an entity to which X presents
this proxy certificate will impose the constraints specified.
2.1.3 A Password-Based TLS Protocol The GSI has been built on the Generic Security
Service Application Program Interface (GSS-API) [33]
Abdalla et al. [1] recently proposed a provably secure and incorporates GSI-enabled OpenSSL [38] to sup-
password-based TLS protocol, based on earlier work of port proxy certificates. Examples of the RSA-based ci-
Steiner et al. [46]. The protocol makes use of a discrete pher suites include TLS_RSA_WITH_RC4_128_MD5 and
logarithm based mask generation function to instantiate a TLS_RSA_WITH_DES_CBC_SHA.
symmetric encryption primitive, as suggested by Bellare et In the GSI setting, each user has a long-term RSA pub-
al. [10, 11]. The protocol also makes use of a hash func- lic/private key pair with a 1024-bit modulus. The short-
tion H, mapping onto a Diffie-Hellman group generated term keys for the user’s proxy credential have only 512-bit
by g. Then, A with password P WA encrypts a Diffie- moduli. This substantial reduction of key sizes is driven by
Hellman component g a by calculating {g a }πA , where πA = the fact that generating an RSA key pair is a computation-
H(P WA ) and {g a }πA = g a · πA . Thus the result of the en- ally expensive operation. It has been shown that generating
cryption is a group element. To decrypt and recover g a , one a key pair with 512-bit moduli can reduce the processing
can simply divide the ciphertext by πA . We describe a mod- time by approximately 77% of the time required for a 1024-
ified version of this protocol and explain how it is used to bit key pair [49]. Since the proxy credential has a relatively
support single sign-on in Section 3.3.1. short lifetime, it is currently believed that the reduction in
The important point about this protocol is that dictionary security implied by using only 512-bit moduli poses an ac-
attacks are of little value to an adversary. If the adversary ceptably low risk in grid systems.
guesses a password and uses it to decrypt g a · πA , he simply There are a small number of grid projects that use Ker-
obtains a group element. In effect, the group element g a beros [36] as the backbone of their security infrastructures.
masks the (hash of the) password. It is generally believed that Kerberos, being based on sym-
metric key cryptography, is more efficient than PKI-based
2.2 The Grid Security Infrastructure approaches. However, Kerberos is unlikely to be a suit-
able long-term solution because many computational grids
The PKI-based GSI focuses on authentication, message have a dynamic entity population, and the establishment
protection, and the use of proxy credentials to support sin- and management of shared symmetric keys will be imprac-
gle sign-on and credential delegation [18, 49, 50]. In grid tical. Furthermore, it is not clear how the dynamic del-
applications that employ the GSI, each entity is assigned a egation mechanism of [49] can be supported using Ker-
beros. Therefore, PKI is preferred for grid applications, can eliminate the difficult tasks involved in correctly estab-
while Kerberos seems to be best suited for intra-domain lishing trust roots of CAs from the user side. It can also
security. In order to achieve inter-operability with PKI- minimise the user’s direct involvement in certificate man-
based systems, some Kerberos-based grid projects make use agement. Our proposal for a user-friendly and certificate-
of a Kerberised client-side program, called KX.509, to ac- free security architecture is influenced by Beckles et al.’s
quire X.509 certificates using a client’s existing Kerberos work.
ticket [30, 35]. Although the plug-and-play PKI concept seems to make
PKI more usable for the users, there are still many aspects
2.3 Related Work of PKI that need to be addressed. For example, how can we
improve the effectiveness of current key revocation mecha-
MyProxy [8, 37] is an online credential repository that nisms, such as CRLs, by exploiting the advantages that the
implements the virtual smart card concept [43]. As with plug-and-play PKI concept could bring? Furthermore, the
storing keys in a smart card, a MyProxy server is expected application of the plug-and-play PKI to the GSI does not
to provide better protection for long-term user private keys reduce the extensive use of certificates, and certificate chain
than desktop computing environments. verification is still required for all the grid security services
To create a proxy credential, a user authenticates him- which involve certificates.
self to the MyProxy server using a password which he
shares with the MyProxy server by performing the follow- 3 Our Proposal
ing steps [8].
Here, we propose a password-enabled and certificate-
1. The user establishes a TCP connection to the server free GSI (PECF-GSI). We begin by giving a conceptual
and initiates a server-authenticated TLS handshake view of the PECF-GSI design. We explain how PECF-GSI
protocol. can support various grid security services. Then, we pro-
2. Once the TLS handshake is complete and a secure vide details of the protocols which underpin PECF-GSI.
channel is established, the user sends a request mes-
sage to the server. The request contains information, 3.1 Architectural Overview
such as a username, a password and a lifetime.
3. If all checks succeed, the server will return ‘0’ to in- PECF-GSI employs a Trusted Authority (TA), instead
dicate success or ‘1’ with an error text that suggests of a CA, as the root of trust within a grid environment.
otherwise. The TA’s roles include acting as the PKG in the identity-
4. The user then generates a new public/private key pair based setting and providing a key management service. In
and forwards the public key to the server through the PECF-GSI, a user’s long-term credential is simply a pass-
established secure channel. word, which he shares with an authentication server. We
5. Subsequently, the server creates a new proxy certificate assume that the user delivers his password to the authenti-
signed with the user’s stored private key and returns it cation server during a one-off user registration phase.6
to the user. The authentication server is assumed to be accredited by
the TA and hosting servers (or resource providers) within
This approach relies on a certificate-based PKI and the grid environment. Unlike the user, who only has to re-
the user must ensure that the associated certificates boot- member a password, the authentication and hosting servers
strapped in his machine are trustworthy and have not been must obtain the TA’s authenticated parameter set through
replaced. out-of-band mechanisms. This hybrid approach divides our
Recently, Beckles et al. [9] considered issues related architecture into two zones: (i) a user-centric zone which
to the usability of the PKI-based GSI, noting that man- employs password-based authentication, and (ii) a server-
aging certificates can be burdensome and tedious for gen- centric zone which makes use of identity-based PKI (non-
eral grid users. In an effort to improve the usability of the certificate-based PKI). This is illustrated in Figure 1.
PKI-based GSI, they adopted Gutmann’s plug-and-play PKI As with the current GSI, we make use of proxy creden-
concept [26], which emphasises automated and transparent tials when providing security services such as mutual au-
setup of PKI for the end user. In so doing, Beckles et al. thentication and delegation. In Figure 1, a user proxy is
make use of the PKIBoot service of [26] to allow a user a short-lived agent created by the user to perform security
to authenticate himself to a PKIBoot server with the stan- services on the user’s behalf. Similarly, a resource proxy is
dard username/password method. Subsequently, the user 6 Note that user registration in PECF-GSI setting may well be much
can securely retrieve his public key certificate (and option- simpler than applying for an X.509 certificate in the GSI setting. This is
ally his private key) and/or CAs’ certificates. This approach because the user does not have to obtain a certified public key from a CA.
Password zone Certificate-free PKI zone
TA
Password-based
authentication
Authentication
User Resource
Proxy
server
credential
Mutual authentication
User Resource
proxy Delegation
proxy
User machine Hosting server
Figure 1. A conceptual view of PECF-GSI.
created by a resource provider to help manage a job submis- PECF-GSI can be used to support essential security services
sion from a user. for grid applications. Further details of the underlying pro-
We map the entities in Figure 1, each of which will re- tocols will be provided in Section 3.3.
quire some form of credentials to interact with another en- Before user A submits a job to resource X, for exam-
tity, into the hierarchical setting of the Gentry–Silverberg ple, through the Grid Resource Allocation and Management
HIBE and HIBS schemes (as introduced in Section 2.1.1). (GRAM) module of the GT [50], she authenticates herself
Let R be an authentication server, A be a user, and X and to R using a secure username/password mechanism. When
Y be hosting servers. We write Ā and X̄ to denote proxies the password-based authentication is successful and a se-
for A and X, respectively. Then, the TA is a level 0 entity cure channel between A and R is established, R extracts a
in the hierarchy, and issues private keys to R, X and Y at proxy credential for use by Ā. The proxy credential, which
level 1. These entities, in turn, issue private keys to their re- comprises a short-term public/private key pair, is transmit-
spective children at level 2, as shown in Figure 2. Note that ted to A, along with other required information, such as the
A does not possess any long-term credential issued by the TA’s system parameters, through the secure channel.
TA; instead she obtains proxy credentials from R. Hence, Subsequently, Ā signs her job request (with the new
Ā, a user proxy for A, becomes a child of R. proxy private key), which is then submitted to X. X verifies
Ā’s signed request and checks if A is an authorized user. If
the checks are successful, X creates X̄ and the associated
TA managed job service [50]. This is followed by the mutual
Level 0 H
s
authentication of Ā and X̄ through an identity-based and
@HH
@ H certificate-free TLS handshake protocol.
@ HH
Level 1 R s. . . @s
X HsY . . . A may, at her discretion, delegate her credential through
Ā to X̄ for later use [50]. Ā can achieve this in PECF-GSI
by simply issuing a new proxy private key to X̄ through
Level 2 Ā s X̄ s sȲ the established TLS channel. This short-lived private key
.. .. .. .. is generated based on the relevant delegation information.
. . . .
Now the delegatee X̄ effectively becomes a child of the del-
Figure 2. The hierarchical relationships be- egator Ā in the hierarchy depicted in Figure 2. Similarly, if
tween entities in PECF-GSI. X̄ further delegates some rights to Y , then Ȳ will become a
child of X̄. The resulting delegation chain rooted at the TA
is TA → R → Ā → X̄ → Ȳ .
Using the above notation, we now briefly explain how In this paper, we use a hierarchy with a single TA for ease
of exposition. In actual implementations, we can expand the 3.2.3 Key Revocation
hierarchy of Figure 2 to support multiple TAs. This can be
achieved by adding a root TA at the top of the hierarchy with Our proposed design deals with revocation of user keys and
the TAs becoming level 1 entities. Similarly, lower-level of hosting server keys in different ways. The users are never
entities are moved down to the next level in the hierarchy. given long-term public keys, instead they are only ever pro-
vided with proxy keys. As with proxy certificates [48] and
Kerberos tickets [36], these proxy credentials in our PECF-
3.2 On System Parameters and Keys
GSI setting have a short lifetime, typically less than 12
hours. As the window of exposure to compromise is min-
We now describe the system parameters and keys that imised, there is no need for an explicit revocation mech-
will be used in our protocols, which are described in Sec- anism for user keys. In this case, the hosting servers are
tion 3.3. trusting R to only distribute fresh keys to the users if the
users’ privileges are still valid.
3.2.1 Parameter Generation and Distribution Conversely, hosting servers are issued with long term
public keys. In this case, there is a requirement for an ex-
During the system setup phase, the TA runs a Bilin- plicit revocation mechanism. To allow for the revocation of
ear Diffie-Hellman (BDH) parameter generator to obtain servers’ public keys, we introduce the notion of an Identity
groups G1 , G2 of large prime order q and an admissible Revocation List (IRL), where an IRL is analogous to a CRL
pairing ê : G1 × G1 → G2 . It then performs the ROOT in a certificate-based environment. The IRL includes the
S ETUP of the Gentry–Silverberg HIBE and HIBS schemes identity of any server whose key has been revoked. This
to produce a master secret s0 . The system parameters are allows users to verify the validity of a particular hosting
hG1 , G2 , ê, P0 , Q0 , H1 , H2 , H3 , H4 , H5 i. We remark that server’s public key prior to submitting a job to that server.
an authentic set of the TA parameters must be made avail- IRLs are distributed to users by R via the secure channel
able to the authentication and hosting servers. One way to established at authentication time. From the user’s perspec-
achieve this is by bootstrapping these parameters into the tive, this “push” method of distribution simplifies the pro-
grid system. Alternatively, distribution of the parameters is cess of verifying whether a hosting server has had its public
also possible through the use of a certificate obtained from key revoked. We discuss this issue in more detail in Sec-
a conventional CA that certifies the parameters. We will tion 3.3.1.
discuss concrete parameter choices in Section 5.
3.3 Protocols
3.2.2 Key Generation
Once the system parameters have been set up, the TA can is- We now describe the protocols that we employ in PECF-
sue private keys to its subordinates at level 1 (see Figure 2) GSI to provide single sign-on, mutual authentication and
using its master secret s0 computed by the ROOT S ETUP delegation for grid applications.
algorithm. For example, authentication server R’s long-
term private key is SR = s0 PR , where PR = H1 (IDR ) 3.3.1 Single Sign-on
is the matching public key. Hosting servers’ long-term pub-
lic/private private keys are generated in a similar way. A The MyProxy system makes use of the existing standard
proxy’s public key at level 2 can be computed based on its TLS protocol [15] to provide mutual authentication between
ancestor’s identifier and its own identifier concatenated with a user and a MyProxy server. This is typically based on
a lifetime LT in some fixed format. For example, user A’s the MyProxy server’s public key certificate and a password
proxy public key would be PĀ = H1 (IDR , IDA kLTA ), and shared by the server and the user. However, in such a set-
the corresponding private key can be obtained from R, who up, where the user enters his password only after the se-
will run the E XTRACT algorithm of the Gentry–Silverberg cure channel is established, the authentication of the user
HIBE (or HIBS) scheme to generate SĀ = SR + sR PĀ . (through his password) is not directly tied to the secure
Here, sR is a secret value chosen by R when it performs the channel [46]. This may give a false sense of security if
L OWER - LEVEL S ETUP algorithm. The upper part of Ta- management of certificates of the relevant parties (e.g. the
ble 1 summarises the credentials possessed by the authenti- server and its CA) are not handled properly. This prompted
cation server R, user A and hosting server X. the study of password-based TLS protocols [1, 46].
It is worth noting that A does not possess any long- We use a modified version of the protocol described in
term credential, except a password which she shares with Section 2.1.3 for mutual authentication between a user and
R. In fact, R’s proxies are proxies of the users with whom the authentication server in our PECF-GSI setting. This is
it shares passwords. because the protocol is provably secure and it can be im-
Table 1. Credentials and keys in PECF-GSI.
Scheme Entity Long-term Credential Proxy Credential
Public Key Private Key Public Key Private Key
Gentry–Silverberg R PR = H1 (IDR ) SR = s0 PR − −
(HIBE/HIBS) A − − PĀ = H1 (IDR , IDA kLTA ) SĀ = SR + sR PĀ
X PX = H1 (IDX ) SX = s0 PX PX̄ = H1 (IDX , IDX kLTX ) SX̄ = SX + sX PX̄
Al-Riyami–Paterson R hsR P0 , sR Q0 i SR = sR s0 PR − −
(HCLE/HCLS) A − − hsĀ P0 , sĀ Q0 i SĀ = sĀ (SR + sR PĀ )
X hsX P0 , sX Q0 i SX = sX s0 PX hsX̄ P0 , sX̄ Q0 i SX̄ = sX̄ (SX + sX PX̄ )
plemented by modifying existing implementations of the schemes when performing mutual authentication and dele-
widespread standard TLS protocol. gation (see Sections 3.3.2 and 3.3.3).
In PECF-GSI, we translate the discrete logarithm based The IRL is used by Ā to check the continuing validity
approach of Abdalla et al. to the elliptic curve setting. We of the identifier of the hosting server to which Ā is going to
make use of the hash function H1 : {0, 1}∗ → G∗1 from the submit her job. It is worth noting that this approach “forces”
HIBE scheme. A’s password P WA is mapped to πA = the user into receiving an up-to-date IRL. Additionally, the
H1 (P WA ) ∈ G∗1 . The Diffie-Hellman component g a is user does not have to check the authenticity of the IRL, as-
replaced by aP0 , where P0 generates G1 , and {aP0 }πA is suming R behaves in an honest manner. Upon expiry of the
defined to be aP0 + πA . To recover aP0 , we simply subtract proxy credential, all the information that Ā obtained from
πA from {aP0 }πA . Based on this mask generation function, R can be destroyed.
which makes use of the system parameters in our PECF- We remark that the whole process of single sign-on does
GSI setting, we can derive a password-based TLS protocol not involve any kind of certificate or parameter verifica-
analogous to the protocol of [1].7 Further details of this tion from the user’s perspective (recall that users are in a
protocol are given in Appendix A. password-based zone in our PECF-GSI setting). Here, we
Steiner et al. and Abdalla et al. suggest that parameters regard verification of parameters as checking the authen-
such as G1 , P0 and H1 should be fixed or form part of a ticity of the parameters and not validating their number-
standardised ciphersuite. This obviates the need for the user theoretic structure.
A to verify the number-theoretic appropriateness of these
parameters.
3.3.2 Mutual Authentication and Key Agreement
Once A and R have been mutually authenticated and
established a secure session, R extracts a short-lived pub- While a password-based TLS protocol is a convenient
lic/private key pair (PĀ , SĀ ), shown in Table 1. Subse- mechanism for the authentication server and its (known)
quently, R sends the following information to A through users, the standard PKI-based TLS protocol is clearly more
the secure channel: suitable for mutual authentication and key agreement be-
tween two entities who have not previously communi-
1. the newly created proxy credential (PĀ , SĀ ); cated. We now leave the password-based zone and enter the
2. an authenticated copy of the TA system parameters certificate-free PKI zone, where we explain how two enti-
hG1 , G2 , ê, P0 , Q0 , H1 , H2 , H3 , H4 , H5 i;8 ties within a grid environment can authenticate each other
3. an up-to-date IRL. and share a session key.
Figure 3 shows a certificate-free authenticated key agree-
Upon receiving the proxy credential, A stores the pri- ment protocol, adapted from Lim and Paterson’s identity-
vate key SĀ in a local file system accessible by her proxy Ā based TLS protocol [32], with minor modifications to the
when necessary. This completes the process of single sign- ServerIdentifier and ClientIdentifier mes-
on by A. The system parameters that A receives from R sages. The protocol employs the Gentry–Silverberg HIBE
are needed to run the Gentry–Silverberg HIBE and HIBS and HIBS schemes.
7 In order to optimise the efficiency of our proposal, we In the first message of the protocol, nĀ denotes a
re-use some of the components of the system parameters nonce chosen by Ā, session_id is self-explanatory,
hG1 , G2 , ê, P0 , Q0 , H1 , H2 , H3 , H4 , H5 i that R obtained from and cipher_suite contains a cipher specifica-
the TA.
8 We note that the parameters G , P and H are already in use by A to tion that handles the HIBE and HIBS schemes, e.g.
1 0 1
run the password-based TLS protocol. Hence, in an actual implementation, TLS_HIBE_HIBS_WITH_DES_CBC_SHA. Here,
R only needs to transmit the remaining system parameters to A. EncX̄ (.) denotes an encryption using the HIBE scheme
(1) Ā → X̄ : ClientHello = nĀ , session id, cipher suite
(2) X̄ → Ā : ServerHello = nX̄ , session id, cipher suite,
ServerIdentifier = IDX , IDX kLTX ,
ServerHelloDone
(3) Ā → X̄ : ClientIdentifier = IDR , IDA kLTA ,
ClientKeyExchange = EncX̄ (pre master secret),
IdentityVerify = SigĀ (handshake messages),
ClientFinished
(4) X̄ → Ā : ServerFinished
Figure 3. A certificate-free authenticated key agreement protocol
with X’s proxy public key PX̄ , while SigĀ (.) represents certificate-free and is a one-pass protocol message, but also
a signing operation in the HIBS scheme using A’s proxy has a very efficient verification mechanism in the sense that
private key SĀ . a delegatee’s delegated credential can be checked by per-
When Ā (playing the role of client) performs mutual au- forming only one signature verification, regardless of the
thentication with X̄ (playing the role of server), she needs length of the delegation chain. This is a significant improve-
to forward her public key information, i.e. IDR , IDA kLTA ment on the two aforementioned delegation methods.
to X̄ as part of the protocol handshake, and vice versa. We now explain the details of the delegation technique
Note that since X̄ includes its long-term identifier in the that we employ in PECF-GSI by using an example between
ServerIdentifier message, Ā must check if the iden- the delegator A (through her proxy Ā) and the delegatee X̄.
tifier is still valid using the IRL that she received from R. In the delegation process, Ā performs the following steps:
Similarly, since Ā uses R’s long-term public key informa-
1. compute a proxy public key PĀ/X̄ of the form
tion, X̄ must validate R’s public key before using it.
Space constraints preclude a more detailed description H1 (IDR , IDA kLTA , IDX kLTX̄ kJobX̄ kPolicyX̄ ),
of the TLS protocol and the above protocol. The inter-
ested reader is referred to the literature for further de- where LTX̄ is the lifetime that Ā decides for X̄, JobX̄
tails [15, 32]. We also note that our certificate-free authen- describes A’s job request, and PolicyX̄ indicates the
ticated key agreement protocol can be adapted straightfor- policy that A wishes to enforce on X̄;
wardly to support user-to-user authentication. 2. extract a proxy private key SĀ/X̄ = SĀ + sĀ PĀ/X̄
with her secret value sĀ ;
3.3.3 Delegation 3. transmit hIDX kLTX̄ kJobX̄ kPolicyX̄ , SĀ/X̄ i to X̄
through a secrecy and integrity protected TLS chan-
The current delegation technique used in the GSI requires a nel.9
round-trip interaction between a delegator (typically a grid
user) and a delegatee (typically a hosting server or resource In this case, Ā actually acts as a PKG and issues a private
provider), as described in Section 2.2. Also, verification of key to X̄, which becomes the entity below Ā at level 3 in
a delegatee’s credential requires validating both long-term Figure 2. This can be seen in the ID-tuple used to construct
and proxy certificates of all the parties involved along the PĀ/X̄ , in which the first two parts are identifiers of X̄’s
delegation chain. ancestors, i.e. R and Ā.
Lim and Paterson proposed an identity-based one-pass It is worth noting that here, X̄’s delegated proxy creden-
delegation protocol [32], in which the delegator signs a del- tial is different from X̄’s proxy credential shown in Table 1.
egation token and forwards it to the delegatee. One advan- The latter is usually used when X̄ performs mutual authen-
tage of this approach is that the delegator can bind the dele- tication with users.
gatee’s public key information to the delegation token with- If a third party, for example Ȳ , wants to verify that X̄
out acquiring the delegatee’s proxy public key, thus requir- indeed is acting on Ā’s behalf, then Ȳ must: (i) authenticate
ing only one-pass protocol message. However, verification 9 It might be thought that the need for the secure channel to transport
of a delegatee’s status as the delegation target requires vali- the proxy private key from Ā to X̄ is a limitation of this approach. In
dation of all the signed delegation tokens (analogous to vali- fact, the secure channel between these two parties will exist anyway; the
dation of certificates in the GSI) issued by all the delegators parties have to authenticate each other using the TLS handshake protocol,
before the delegation can take place. This is to ensure that the delegation
along the delegation chain. is targeted at the right entity and that the delegation target is convinced of
Here, we propose a delegation protocol which is not only the identity of the delegator.
X̄ and (ii) check that X̄ is in possession of SĀ/X̄ . These an adversary E, who is also a valid user under the same
two checks will be carried out as part of the TLS handshake TA, intercepts the proxy private key SĀ/X̄ that Ā created
that takes place between X̄ and Ȳ . for X̄, and replaces it with E’s self-computed private key
When X̄ further delegates Ā’s credential to another host- ′
SĀ/ X̄
= SĒ + sĒ PĀ/X̄ . Superficially, this appears to be a
ing server Y , X̄ can construct a new proxy public key feasible attack, since PĀ/X̄ is public and E knows the sys-
tem parameters. However, the HIBE and HIBS schemes
PĀ/X̄/Ȳ = H1 (IDR , IDA kLTA , IDX kLTX̄ kJobX̄ kPolicyX̄ , have the property that the private key corresponding to
IDY kLTȲ kJobȲ kPolicyȲ ), PĀ/X̄ can only be computed by the owner of the identity
“IDA kLTA ”, which is the immediate ancestor of the next
where JobȲ refers to the job (potentially sub-tasks of JobX̄ ) level identity “IDX kLTX̄ kJobX̄ kPolicyX̄ ” in the same hier-
that X̄ wants Ȳ to execute and PolicyȲ refers to the policy archy. Gentry and Silverberg’s security model does model
that X̄ imposes on Ȳ , respectively. The matching private an adversary that obtains identifiers to which it is not enti-
key is SĀ/X̄/Ȳ = SĀ/X̄ + sX̄ PĀ/X̄/Ȳ . This private key tled, and their HIBE and HIBS schemes are provably secure
and the relevant information can then be forwarded to Ȳ , in such an attack model [24].
which subsequently becomes subordinate to X̄ at level 4 of
the hierarchy. 4 Removing Key Escrow
To verify Ȳ ’s delegated proxy credential, the verifier
only needs to authenticate Ȳ and check whether Ȳ knows Key escrow is a feature of the HIBE and HIBS schemes
the private key corresponding to PĀ/X̄/Ȳ , even though the used in PECF-GSI, as with other standard identity-based
delegation chain now has two delegatees (X̄ and Ȳ ). This cryptographic schemes. This may not be acceptable for
can be done, in principle, by verifying a signature produced certain grid applications. One way of solving the key es-
by Ȳ using SĀ/X̄/Ȳ . crow problem is to apply the Al-Riyami–Paterson HCLE
We remark that the use of the Gentry–Silverberg HIBS and HCLS schemes to PECF-GSI.
scheme for this purpose would result in the size of the signa- In order to use the Al-Riyami–Paterson HCLE and
ture increasing as the delegation chain grows and verifica- HCLS schemes (see Section 2.1.2), we need to modify the
tion of the signature becoming slower. Nevertheless, there keys used in the HIBE/HIBS schemes. An entity’s pri-
exist improved HIBE schemes in the literature, from which vate key in the HCLE and HCLS schemes is the product
we can derive a more efficient HIBS scheme. Boneh et al., of the entity’s private key and its chosen secret value for the
for example, recently proposed a HIBE scheme in which Gentry–Silverberg HIBE and HIBS schemes. For instance,
the size of the ciphertext is constant and decryption requires R’s long-term private key in the HIBE/HIBS schemes is
only two pairing computations, regardless of the hierarchy s0 PR ; hence R’s new private key for the HCLE/HCLS
depth [13]. schemes would be sR s0 PR , where sR is a secret value that
R uses to extract private keys for its immediate lower-level
3.4 Security Considerations entities. The public key of R, which comprises two compo-
nents, is now hsR P0 , sR Q0 i. The lower section of Table 1
In our single sign-on approach, we assume that R is a summarises the new key sets required for the Al-Riyami–
party trusted to issue the correct system parameters, most Paterson HCLE and HCLS schemes.
importantly Q0 , and up-to-date IRLs to its users through se-
cure channels. Therefore, no additional infrastructure is re- 4.1 Single Sign-on Without Key Escrow
quired to verify the authenticity of the parameters and IRLs.
Note that most of the components of the system parameters The changes that we have to make to PECF-GSI in order
discussed in Section 3.2 can be fixed and made public, ex- to remove the key escrow issue are rather trivial. When A
cept Q0 = s0 P0 , where s0 is the TA’s master secret. A performs a single sign-on, she and her authentication server
failure to obtain Q0 from a trusted source would allow a R first perform mutual authentication using a shared pass-
trivial man-in-the-middle attack. Our single sign-on proto- word, and then establish a secure channel (as before). Sub-
col is secure against such an attack, assuming R behaves sequently, R runs the PARTIAL - PRIVATE - KEY E XTRACT
honestly. Also, we assume that hosting servers always trust algorithm and issues a partial private key (SR +sR PĀ ) to A,
R in issuing proxy credentials to the correct users. These along with other information such as the system parameters
assumptions are essential for the protocol in Figure 3 and and an updated IRL.
our delegation protocol to work as intended. When A receives the partial private key, she runs the
We now consider the possibility of an adversary attack- L OWER - LEVEL S ETUP algorithm to randomly pick a se-
ing the delegation protocol. Using our example from the cret value sĀ . This secret value, in turn, is used to compute
previous section, we need to consider the possibility that her proxy public/private key pair. Ā can then use the proxy
credential to perform mutual authentication and delegation choice results in a corresponding group of prime order q
with a hosting server. Since the value sĀ is unknown to R, approximately equal to 2252 , and gives roughly the same
A’s new proxy private key is kept secret from R, which is security level as 1024-bit RSA. Using the point compres-
not the case in the protocols described in Section 3.3. sion technique, elements of this group can be represented
using 272 bits. Since all arithmetic is carried out in fields of
4.2 Security Concerns characteristic 2, group operations and pairing computations
can be implemented efficiently [7].
The cryptographic set-up in CL-PKC allows users to cre- In addition to the curve and group selections, we re-
ate more than one public key for the same partial private quire hash functions for the Gentry–Silverberg HIBE and
key [3]. For example, A can randomly select two differ- HIBS schemes. The outputs of H1 and H3 are elements
ent secret values sĀ and s′Ā , and compute two sets of dis- of G1 , while H4 gives an output with approximately 252
tinct public/private key pairs. However, we believe that this bits. Note that the size of outputs of H2 and H5 are de-
property would not cause any major issues within a grid en- pendent on n, the bit length of plaintexts. We assume that
vironment. This is because partial private keys produced by n = 256, since this is sufficient for our protocol mes-
the authentication server are short-lived. In fact, the users sages (see Section 3.3.2). Hence, the size of ciphertexts
can take advantage of this property by extracting different and signatures produced by the Gentry–Silverberg HIBE
proxy key pairs for different job submissions to increase key and HIBS schemes (or the Al-Riyami–Paterson HCLE and
freshness, before the expiry of their respective partial pri- HCLS schemes) can be computed, and are 1056 bits and
vate keys. 816 bits, respectively.
In the context of CL-PKC, we must trust the authen- The estimated communication costs for the protocols
tication server not to mount active impersonation attacks that underpin the GSI and PECF-GSI are summarised in
against its users. Such attacks are possible because the Table 2. The architecture based on the Gentry–Silverberg
authentication server can always select a secret value (for schemes is denoted by PECF-GSI-I, while the architecture
some “victim”) and calculate a private key based on the vic- based on the Al-Riyami–Paterson schemes is denoted by
tim’s partial private key to which it necessarily has access. PECF-GSI-II. Actual computational costs in milliseconds
However, these attacks would leave behind cryptographic are also summarized in this table. These timings were ob-
evidence which may reveal the authentication server’s ac- tained by implementing the key generation algorithms in
tions. We also note that traditional PKIs have an analogous RSA and the Gentry–Silverberg HIBE/HIBS schemes us-
problem: we have to trust a CA not to illegally sign user ing the MIRACL library [45]. The experiments were per-
certificates, enabling the CA to impersonate these users to formed on a Pentium IV 2.4 GHz processor. For simplicity,
other parties. we limit the length of the delegation chain to one. Compu-
tational costs are not currently available for PECF-GSI-II.
5 Performance
5.1 Communication Costs
In this section, we compare the communication costs of
the protocols used in GSI and PECF-GSI for key agreement In the GSI, the communication cost of the key agree-
and delegation. We then compare the computational costs ment protocol through the standard TLS handshake is ap-
of long-term and proxy key generation, key agreement and proximately 37.8 kilobits; the corresponding cost in PECF-
delegation. GSI-I (with key escrow) is approximately 1.9 kilobits.
In the GSI, we assume the size of a 1024-bit RSA public Note that for simplicity, we ignore small components in
key certificate is 1.5 kilobytes (ignoring small fields, such both the TLS protocols, such as the ClientHello and
as subject and validity period). Similarly, a 512-bit RSA ClientFinished messages. Key agreement in PECF-
proxy certificate is 0.8 kilobytes.10 Ciphertexts and signa- GSI-II, which does not have key escrow and so makes use
tures generated using a short-term RSA key are 512 bits. of additional public key components, has a slightly higher
For PECF-GSI, we work with a supersingular elliptic communication cost compared to key agreement in PECF-
curve of embedding degree 4 over F2271 [20, 22] to ob- GSI-I.
tain the system parameters described in Section 3.2.11 This The communication costs for delegation in the GSI
10 It is worth mentioning that RSA keys can be replaced by much shorter can be estimated straightforwardly from the protocol de-
keys, which are based on elliptic curve cryptography (ECC) [12]. How- scribed in Section 2.2. Delegation in PECF-GSI-I is very
ever, this does not eliminate the fact that certificates will still be in use, and lightweight because it only involves issuance of a private
hence, the associated limitations of certificated-based architectures.
11 We note that this curve is only chosen so that concrete timings and bit key. In PECF-GSI-II, additional public key components are
counts can be given. A wide variety of other choice of curves and their included as well, and hence extra bandwidth is required.
associated parameters are available. It is obvious that our certificate-free approach suits wire-
Table 2. A comparison of performance characteristics.
Type of Cost (units) Operation GSI PECF-GSI-I PECF-GSI-II
Communication (KB) Key agreement 37.8 1.9 2.4
Delegation 7.8 0.3 0.8
Computation time (ms) Long-term key generation 149.90 1.69
Proxy key generation 34.85 1.74
Key agreement 5.34 28.95
Delegation 38.33 10.16
less environments well, in which transmission of data us- 6 Conclusions and Future Work
ing battery-powered mobile devices is a relatively expensive
operation. We have proposed a grid security infrastructure which
is password-enabled and certificate-free. Our infrastructure
offers three distinct advantages.
5.2 Computational Costs
• The only long-term secret required by users is a pass-
word. This is likely to improve usability and accessi-
Key generation in PECF-GSI is far more efficient than bility of grid applications considerably. Moreover, we
RSA key generation in the GSI. This may have a big impact do not need to worry about revocation of users’ public
on password-enabled architectures such as the GSI incorpo- keys, a considerable problem in certificate-based ar-
rating MyProxy and PECF-GSI. chitectures.
• Key agreement and delegation in our approach requires
We can see from Table 2 that proxy key generation in
much less bandwidth than the GSI. In addition, our
PECF-GSI is almost 20 times faster than MyProxy in the
delegation technique requires only a single verifica-
GSI.12 This is, to some extent, an unfair comparison, be-
tion.
cause of the completely different mathematical properties
• The computational effort required by the key genera-
behind these two approaches, but it does suggest that the
authentication server in our proposal will scale better and tion algorithms that we employ is considerably lower
support a larger number of users than the MyProxy server. than in the GSI.
The figures for key agreement (including mutual authen- Our lightweight security architecture is more suitable
tication) are obtained by summing the times taken for the than the GSI for use by devices with limited resources,
user and authentication server to perform their respective thereby significantly extending the number of devices that
parts of the protocol. A similar method is used to obtain a can interact with computational grids and going some way
single figure for the computational costs of delegation [31, to realising the potential of wireless grids. That said,
Table 4.3]. Key agreement in the GSI (using the standard identity-based and certificateless public key cryptography
TLS protocol) is computationally less expensive than the are relatively new, and thus lack support from standardisa-
corresponding operations in PECF-GSI (using the modi- tion bodies. This may hinder early adoption of our proposal.
fied identity-based TLS protocol). In contrast, delegation To meet the requirement of grid applications which do
in PECF-GSI is almost four times faster than in the GSI. not tolerate key escrow, we proposed the use of certificate-
less public key cryptography, which enables users to select
It is unfortunate that key agreement is slower in PECF-
their own private components. This only resulted in minor
GSI, but we note that the cumulative time for key agreement
changes, in terms of key set-up, to our original architecture.
and delegation is still lower in PECF-GSI. Overall, we be-
An important security aspect of grid applications which
lieve that the computational costs of PECF-GSI make it an
we have not considered in this paper is authorization. A nat-
attractive alternative to the GSI.
ural extension of this work is to develop novel authorization
techniques using properties of identity-based cryptography.
12 Note that we only compare private key extraction in PECF-GSI to We are also aware that there are other aspects of per-
RSA public/private key pair generation in the GSI, because the time taken formance that ought to be considered, such as fault toler-
to compute a public key using the hash function H1 in PECF-GSI is neg-
ligible given the parameters we have chosen. Furthermore, construction
ance and availability of our architecture in comparison with
of a public key by hashing an identifier occurs as part of the associated MyProxy. Since MyProxy still continues to evolve, it will
encryption/decryption scheme. be appropriate to make such comparisons in the near future.
References [15] T. Dierks and C. Allen. The TLS protocol version 1.0. The
Internet Engineering Task Force (IETF), RFC 2246, January
[1] M. Abdalla, E. Bresson, O. Chevassut, B. Möller, and 1999.
D. Pointcheval. Provably secure password-based authentica- [16] I. Foster and C. Kesselman. Globus: A metacomputing in-
tion in TLS. In Proceedings of the 1st ACM Symposium on frastructure toolkit. International Journal of Supercomput-
InformAtion, Computer and Communications Security (ASI- ing Applications, 11(2):115–128, 1997.
ACCS 2006), pages 35–45. ACM Press, March 2006. [17] I. Foster and C. Kesselman, editors. The Grid 2: Blueprint
[2] S.P. Ahuja and J.R. Myers. A survey on wireless grid com- for a New Computing Infrastructure. Elsevier, San Fran-
puting. The Journal of Supercomputing, 37(1):3–21, 2006. cisco, 2004.
[18] I. Foster, C. Kesselman, G. Tsudik, and S. Tuecke. A secu-
[3] S.S. Al-Riyami and K.G. Paterson. Certificateless public key
cryptography. In C.S. Laih, editor, Advances in Cryptology - rity architecture for computational Grids. In Proceedings
of the 5th ACM Computer and Communications Security
Proceedings of ASIACRYPT 2003, pages 452–473. Springer-
Conference (CCS ’98), pages 83–92. ACM Press, Novem-
Verlag LNCS 2894, November 2003.
ber 1998.
[4] S.S. Al-Riyami and K.G. Paterson. Certificate-
[19] I. Foster, C. Kesselman, and S. Tuecke. The anatomy of
less Public Key Cryptography. Cryptology ePrint
the Grid: Enabling scalable virtual organizations. Inter-
Archive, Report 2003/126, October 2003. Available at
national Journal of High Performance Computing Applica-
http://eprint.iacr.org/2003/126.
tions, 15(3):200–222, 2001.
[5] A. Alsaid and C.J. Mitchell. Installing fake root keys in a
[20] S.D. Galbraith. Supersingular curves in cryptography. In
PC. In D. Chadwick and G. Zhao, editors, Proceedings of
C. Boyd, editor, Advances in Cryptology - Proceedings of
the 2nd European Public Key Infrastructure Workshop (Eu-
ASIACRYPT 2001, pages 495–513. Springer-Verlag LNCS
roPKI 2005), pages 227–239. Springer-Verlag LNCS 3545,
2248, 2001.
2005.
[21] S.D. Galbraith. Pairings. In I.F. Blake, G. Seroussi,
[6] K. Barr and K. Asanović. Energy aware lossless data
and N.P. Smart, editors, Chapter 9 of Advances in Ellip-
compression. ACM Transactions on Computer Systems,
tic Curve Cryptography, pages 183–213, Cambridge, 2005.
24(3):250–291, August 2006.
Cambridge University Press, LMS 317.
[7] P.S.L.M. Barreto, H.Y. Kim, B. Lynn, and M. Scott. Efficient [22] S.D. Galbraith, K. Harrison, and D. Soldera. Implementing
algorithms for pairing-based cryptosystems. In M. Yung, the Tate pairing. In C. Fieker and D.R. Kohel, editors, Pro-
editor, Advances in Cryptology - Proceedings of CRYPTO ceedings of the 5th International Symposium on Algorithmic
2002, pages 354–368. Springer-Verlag LNCS 2442, 2002. Number Theory (ANTS-V), pages 324–337. Springer-Verlag
[8] J. Basney, M. Humphrey, and V. Welch. The MyProxy on- LNCS 2369, 2002.
line credential repository. Journal of Software: Practice and [23] C. Gentry. Certificate-based encryption and the certificate
Experience, 35(9):817–826, July 2005. revocation problem. In E. Biham, editor, Advances in Cryp-
[9] B. Beckles, V. Welch, and J. Basney. Mechanisms for in- tology - Proceedings of EUROCRYPT 2003, pages 272–293.
creasing the usability of grid security. International Journal Springer-Verlag LNCS 2656, May 2003.
of Human-Computer Studies, 63(1-2):74–101, July 2005. [24] C. Gentry and A. Silverberg. Hierarchical ID-Based cryp-
[10] M. Bellare, D. Pointcheval, and P. Rogaway. Authenti- tography. In Y. Zheng, editor, Advances in Cryptology -
cated key exchange secure against dictionary attacks. In Proceedings of ASIACRYPT 2002, pages 548–566. Springer-
B. Preneel, editor, Advances in Cryptology - Proceedings of Verlag LNCS 2501, December 2002.
EUROCRYPT 2000, pages 139–155. Springer-Verlag LNCS [25] GridCafé. Grid Projects in the World. Available at
1807, 2000. http://gridcafe.web.cern.ch/, last accessed in January 2007.
[11] M. Bellare and P. Rogaway. The AuthA Protocol for [26] P. Gutmann. Plug-and-play PKI: A PKI your mother can
Password-Based Authenticated Key Exchange. Contribution use. In Proceedings of 12th USENIX Security Symposium,
to IEEE P1363, March 2000. pages 45–58, 2003.
[12] S. Blake-Wilson, N. Bolyard, V. Gupta, C. Hawk, and [27] J.M. Hayes. The problem with multiple roots in web
B. Möller. Elliptic curve cryptography (ECC) cipher suites browsers - certificate masquerading. In Proceedings of
for transport layer security (TLS). The Internet Engineering the IEEE 7th International Workshop on Enabling Tech-
Task Force (IETF), RFC 4492, May 2006. nologies: Infrastructure for Collaborative Enterprise, pages
[13] D. Boneh, X. Boyen, and E. Goh. Hierarchical iden- 306–311. IEEE Computer Society Press, 1998.
tity based encryption with constant size ciphertext. In [28] R. Housley, W. Polk, W. Ford, and D. Solo. Internet X.509
R. Cramer, editor, Advances in Cryptology - Proceedings of public key infrastructure certificate and certificate revoca-
EUROCRYPT 2005, pages 440–456. Springer-Verlag LNCS tion list (CRL) profile. The Internet Engineering Task Force
3494, 2005. (IETF), RFC 3280, April 2002.
[14] D. Boneh and M. Franklin. Identity-based encryption from [29] A. Joux. A one round protocol for tripartite Diffie-
the Weil pairing. In J. Kilian, editor, Advances in Cryptology Hellman. In W. Bosma, editor, Proceedings of 4th Algorith-
- Proceedings of CRYPTO 2001, pages 213–229. Springer- mic Number Theory Symposium (ANTS-IV), pages 385–394.
Verlag LNCS 2139, August 2001. Springer-Verlag LNCS 1838, 2000.
[30] O. Kornievskaia, P. Honeyman, B. Doster, and K. Coffman. in Cryptology - Proceedings of CRYPTO ’84, pages 47–53.
Kerberized credential translation: A solution to web access Springer-Verlag LNCS 196, August 1985.
control. In Proceedings of 10th USENIX Security Sympo- [45] Shamus Software Ltd. MIRACL. Available at
sium, pages 235–250, August 2001. http://indigo.ie/∼mscott/, last accessed in January 2007.
[31] H.W. Lim. On the Application of Identity-Based Cryptog- [46] M. Steiner, P. Buhler, T. Eirich, and M. Waidner. Secure
raphy in Grid Security. Ph.D thesis, University of London, password-based cipher suite for TLS. ACM Transactions on
2006. Information and System Security, 4(2):134–157, May 2001.
[32] H.W. Lim and K.G. Paterson. Identity-based cryptography [47] The TeraGrid Project. TeraGrid. Available at
for grid security. In H. Stockinger, R. Buyya, and R. Perrott, http://www.teragrid.org/, last accessed in January 2007.
editors, Proceedings of the 1st IEEE International Confer- [48] S. Tuecke, V. Welch, D. Engert, L. Pearlman, and M.R.
ence on e-Science and Grid Computing (e-Science 2005), Thompson. Internet X.509 public key infrastructure proxy
pages 395–404. IEEE Computer Society Press, 2005. certificate profile. The Internet Engineering Task Force
[33] J. Linn. Generic security service application program in- (IETF), RFC 3820, June 2004.
terface version 2, update1. The Internet Engineering Task [49] V. Welch, I. Foster, C. Kesselman, O. Mulmo, L. Pearlman,
Force (IETF), RFC 2743, January 2000. S. Tuecke, J. Gawor, S. Meder, and F. Siebenlist. X.509
[34] L.W. McKnight, J. Howison, and S. Bradner. Wireless grids: proxy certificates for dynamic delegation. In Proceedings
Distributed resource sharing by mobile, nomadic, and fixed of the 3rd Annual PKI R&D Workshop, pages 42–58, April
devices. IEEE Internet Computing, 8(4):24–31, July/August 2004.
2004. [50] V. Welch, F. Siebenlist, I. Foster, J. Bresnahan, K. Cza-
[35] P.C. Moore, W.R. Johnson, and R.J. Detry. Adapting Globus jkowski, J. Gawor, C. Kesselman, S. Meder, L. Pearlman,
and Kerberos for a secure ASCI Grid. In Proceedings of the and S. Tuecke. Security for Grid services. In Proceedings
2001 ACM/IEEE Conference on Supercomputing (SC2001), of the 12th IEEE International Symposium on High Perfor-
CD-ROM, page 21. ACM Press, November 2001. mance Distributed Computing (HPDC-12 2003), pages 48–
[36] B.C. Neuman and T. Ts’o. Kerberos: An authentication 61. IEEE Computer Society Press, June 2003.
service for computer networks. IEEE Communications,
32(9):33–38, September 1994.
[37] J. Novotny, S. Tuecke, and V. Welch. An online credential
repository for the Grid: MyProxy. In Proceedings of the
10th IEEE International Symposium on High Performance
Distributed Computing (HPDC-10 2001), pages 104 –111.
IEEE Computer Society Press, August 2001.
[38] The OpenSSL Project. OpenSSL: The Open Source Toolkit
for SSL/TLS, 2006. Available at http://www.openssl.org/,
last accessed in September 2006.
[39] K.G. Paterson. Cryptography from pairings. In I.F. Blake,
G. Seroussi, and N.P. Smart, editors, Chapter 10 of Ad-
vances in Elliptic Curve Cryptography, pages 215–251,
Cambridge, 2005. Cambridge University Press, LMS 317.
[40] K.G. Paterson and G. Price. A comparison between tradi-
tional public key infrastructures and identity-based cryptog-
raphy. Information Security Technical Report, 8(3):57–72,
2003.
[41] T. Phan, L. Huang, and C. Dulan. Challenge: Integrating
mobile wireless devices into the computational grid. In Pro-
ceedings of the 8th ACM International Conference on Mo-
bile Computing and Networking (MOBICOM 2002), pages
271–278. ACM Press, 2002.
[42] R. Sakai, K. Ohgishi, and M. Kasahara. Cryptosystems
based on pairing. In Proceedings of the 2000 Symposium on
Cryptography and Information Security (SCIS 2000), Jan-
uary 2000.
[43] R.S. Sandhu, M. Bellare, and R. Ganesan. Password-
enabled PKI: Virtual smartcards versus virtual soft tokens.
In Proceedings of the 1st Annual PKI R&D Workshop, pages
89–96, 2002.
[44] A. Shamir. Identity-based cryptosystems and signature
schemes. In G.R. Blakley and D. Chaum, editors, Advances
A A Password-Based TLS Protocol where PRF is a pseudo-random function specified for the
standard TLS protocol [15].
Figure 4 shows the EC-SOKE-TLS protocol, an adapta- Note that R can compute pms if and only if it can
tion of the Simple Open Key Exchange for TLS (SOKE- recover aP from A and compute the composite Diffie-
TLS) [1] to the elliptic curve setting. Hellman value ayP0 . On the other hand, A must know the
value a of aP that R would recover from her password πA .
(1) A→R: ClientHello = nA , This is to prevent an adversary from impersonating A to
′
session id, R using a guessed password πA by computing {a′ P0 }πA′ ,
′
cipher suite where a is a value which is known to the adversary. This
impersonation would fail unless the adversary could predict
(2) R→A: ServerHello = nR ,
the value a′′ of a′′ P0 that R recovers using the correct pass-
session id,
word πA from {a′ P0 }πA′ . The difficulty of finding a′′ is
cipher suite, believed to be as hard as solving the ECDL problem.
ServerKeyExchange = IDR , In step (4), R produces the ServerFinished mes-
rP0 , sage, which contains the verification value:
ServerHelloDone
(3) A→R: ClientKeyExchange = IDA , PRF(ms, “server finished”, h1 , h2 )
{aP0 }πA
where h1 and h2 represent hash values of all handshake
(4) R→A: ServerFinished
messages up to but not including this message, using dif-
(5) A→R: ClientFinished
ferent hash functions.
Figure 4. EC-SOKE-TLS protocol Note that A must verify if R has computed the cor-
rect value in the ServerFinished message before
We assume user A (playing the role of client) and au- calculating her corresponding verification value in the
thentication server R (playing the role of server) share a ClientFinished message in the last step. This is to
password πA and some parameters required for the proto- prevent a bogus server from impersonating R to A and
col, such as G1 , P0 and H1 . We use {·}π to denote a mask mounting an offline dictionary attack. If A sends the
generation function which maps an element of G1 into an- ClientFinished message immediately after sending
other element of G1 by using the password π. In our case, the ClientKeyExchange message, the bogus server R′
′
the mask generation function is defined to be the addition can test if a candidate password πA is correct by performing
of a group element and a password (as described in Sec- the following steps:
tion 3.3.1). 1. decrypt {aP0 }πA from A using its guessed password
In step (1), A sends R a standard ClientHello mes- πA′
and obtain a′ P ;
sage as in the standard TLS protocol. Here, nA is a random 2. compute the corresponding pre-master secret pms′ and
number generated by A. master secret ms′ using {aP0 }πA , yP0 , a′ yP , assum-
In step (2), R responds with a ServerHello mes- ing R′ knows the value y;
sage which contains a different random number nR and
3. compute the verification value of the
other associated information. R also randomly picks
ClientFinished message using pms′ and
r ∈ Z∗q , calculates its Diffie-Hellman value as rP0 and for-
ms′ ;
wards the ServerKeyExchange message to A. The
ServerHelloDone message is sent to indicate the end 4. compare the verification value obtained in step (3) with
of step (2). the value that R′ received from A. A match between
In step (3), A randomly selects a ∈ Z∗q and com- these two values indicates a correct guess. Otherwise,
putes aP0 . This Diffie-Hellman value is then encrypted (or R′ repeats steps (1) to (4) using a different candidate
′′
masked) using A’s password πA and forwarded to R, along password πA .
with her identity. A is authenticated to R if the last message from A con-
A and R compute a pre-master secret tains the correct verification value. The master_secret
is subsequently used to derive further keys for the TLS
pms = H0 (IDA , IDR , πA , {aP0 }πA , yP0 , ayP0 ),
record layer.
where H0 is a secure hash function; the associated master
secret is
ms = PRF(pms, “master secret”, nA , nX ),
A Certificate-free Grid Security
Infrastructure Supporting Password-
based User Authentication
Hoon Wei Lim
(with Jason Crampton, Kenny Paterson and Geraint Price)
Information Security Group
Royal Holloway, University of London
Outline
1. Background
2. Password-enabled and certificate-free Grid
Security Infrastructure (PECF-GSI)
3. Security Concerns
4. Conclusions
6th Annual PKI R&D Workshop, 17-19 April, 2007 2
Terminology
Certificate-based PKI
X.509-based PKI (PKIX)
Certificate-free PKI
Using identity-based cryptography
Standard TLS (or SSL) protocol
Requires certificate-based PKI
Certificate-free TLS protocol
Makes use of certificate-free PKI
Password-based TLS protocol
Non-PKI-based
Makes use of password-based key exchange
6th Annual PKI R&D Workshop, 17-19 April, 2007 3
1. Background
Grid scenario:
Users submit jobs to through a grid middleware.
Resource brokers find suitable computing
resources to execute jobs.
Jobs are executed on the identified resources
and the results are returned to the users.
6th Annual PKI R&D Workshop, 17-19 April, 2007 4
Grid security requirements
Entity authentication
E.g. individual users, resource/service providers.
Single sign-on
Logon once but authenticate to multiple resources.
Delegation
Achieve unattended authentication, allowing an intermediate
party to act on user’s behalf.
Credential life-span and renewal
Short-term (proxy) credentials are used to limit the exposure of
long-term credentials (private keys)
Authorisation
Grant resource access only to users who comply with policies
enforced by virtual organisations and resource owners.
Others: integration and inter-operability, auditing, trust
relationships, usability, etc.
6th Annual PKI R&D Workshop, 17-19 April, 2007 5
Grid Security Infrastructure (GSI)
First proposed by Foster et al.
(1998) for the Globus Toolkit.
Based on certificate-based PKI.
The usage of proxy certificates:
to limit exposure of long-term Year Version
credentials; 1998 – GT 1.0
to enable single sign-on and
delegation services. 2002 – GT 2.0
Uses the standard TLS protocol for 2003 – GT 3.0
mutual authentication and secure 2005 – GT 4.0
communications.
Provides a basic access control
mechanism through gridmap files.
6th Annual PKI R&D Workshop, 17-19 April, 2007 6
GSI: MyProxy & single sign-on
MyProxy – an online credential repository system:
protects long-term user private keys;
provides credential mobility.
1. Authenticate using username/password via TLS
3. Transmit signed request and proxy public key
5. Return proxy certificate
2. Generate proxy key pair
4. Sign proxy certificate
The user stores his proxy private key in a local file system accessible
by his proxy client – i.e. single sign-on.
Note it is important for the user to check the validity of the MyProxy
Server’s certificate chain back to a trusted root.
6th Annual PKI R&D Workshop, 17-19 April, 2007 7
GSI: Authentication & key agreement
Mutual authentication based on the standard TLS
handshake protocol.
Needed during job submission and before delegation.
Uses RSA encryption/signature schemes.
(1) Client to Server: ClientHello
(2) Server to Client: ServerHello,
ServerCertificate,
SeverHelloDone
(3) Client to Server: ClientCertificate,
ClientKeyExchange,
CertificateVerify,
Finished
(4) Server to Client: Finished
6th Annual PKI R&D Workshop, 17-19 April, 2007 8
GSI: Delegation
Delegation of credentials from one party to another.
E.g. resource X may need to access additional resources on
behalf of user A, without user intervention.
1. Establish secure TLS channel
3. Transmit signed request and proxy public key
5. Return proxy certificate
4. Sign proxy certificate 2. Generate proxy key pair
A round-trip delegation protocol.
Delegation chain verification involves verification of all certificates
along the chain.
6th Annual PKI R&D Workshop, 17-19 April, 2007 9
Identity-Based Cryptography
Original idea due to Shamir (1984):
Public keys derived directly from system
identities
E.g. an e-mail address or IP address.
Private keys generated and distributed to users
by a trusted authority (TA) who has a master
secret.
Bob can safely encrypt to Alice without
consulting a directory and without checking a
certificate, provided:
Bob knows Alice’s identity;
The TA has given the private key to the right entity.
6th Annual PKI R&D Workshop, 17-19 April, 2007 10
IBC: A short history
Shamir devised only an identity-based signature
scheme.
Construction of a truly practical and secure identity-
based encryption scheme an open problem until 2001.
Sakai, Ohgishi and Kasahara (SCIS, Jan. 2001).
Boneh and Franklin (CRYPTO, Aug. 2001).
Practical and provably secure.
Uses elliptic curve cryptography and pairings on elliptic curves.
Cocks (IMA C&C, Dec. 2001).
Scheme based on quadratic residuosity, not bandwidth
efficient.
Research done in mid 1990’s at UK government agency.
6th Annual PKI R&D Workshop, 17-19 April, 2007 11
IBC: Basic idea
TA
Private Key
Alice’s
ID
Public Key
6th Annual PKI R&D Workshop, 17-19 April, 2007 12
IBC: The reality
TA
Authentic system
parameters
Secure channel Alice’s
ID
6th Annual PKI R&D Workshop, 17-19 April, 2007 13
IBC: A closer look
Benefits:
Certificate-free – no processing, management or
distribution of certificates.
Indeed, Alice need not have her private key when
she receives Bob’s encryption.
Automated key revocation – extend the identifier
to include a validity period.
Limitations:
Automated key expiry implies Alice needs to
obtain her private key for current period, hence
extra workload for the TA.
Key revocation may not be fine-grained.
6th Annual PKI R&D Workshop, 17-19 April, 2007 14
Hierarchical IBC
Proposed by Gentry and
Silverberg (2002) to:
ease the private key
distribution problem and Level 0
improves scalability of the
Boneh-Franklin IBE scheme.
Level 1
mimic the hierarchy of CAs
often seen in PKI.
dynamic key issuance. Level 2
Hierarchical identity-based
…
…
encryption/signature
(HIBE/HIBS) schemes.
6th Annual PKI R&D Workshop, 17-19 April, 2007 15
2. PECF-GSI
Motivations:
Make use of attractive properties of hierarchical
identity-based cryptography.
Use of meaningful identifiers reflecting natural grid
hierarchy
Clean way of constructing short-term credentials
Simplified delegation by exploiting hierarchy
Design a lightweight and user-friendly
architecture.
Certificate-free
Password-enabled
6th Annual PKI R&D Workshop, 17-19 April, 2007 16
PECF-GSI: Main idea
We employ HIBE and HIBS schemes – well-matched
with the hierarchical nature of a virtual organisation.
Our architecture is divided into two zones:
Password
Certificate-free PKI
Make use of local/domain authentication servers, which
issue short-lived credentials to users.
User proxies perform single sign-on by using only
passwords.
User proxies perform mutual authentication and
delegation with resource providers using only short-
lived credentials.
6th Annual PKI R&D Workshop, 17-19 April, 2007 17
PECF-GSI: Architectural overview
Certificate-free PKI Zone
Password Zone
Password-based
authentication
Proxy credential
Mutual authentication
User Resource
Delegation Proxy
Proxy
6th Annual PKI R&D Workshop, 17-19 April, 2007 18
PECF-GSI: Key management
Cryptographic system parameters are available
to entities within the certificate-free PKI zone.
Key issuance:
The authentication server and hosting servers obtain
their respective private keys from the TA.
Users use only proxy public/private key pairs
obtained from the authentication server.
Key revocation:
Automated user proxy key expiry.
Public keys of hosting servers can be revoked
through an Identity Revocation List (IRL).
6th Annual PKI R&D Workshop, 17-19 April, 2007 19
PECF-GSI: Single sign-on
Users log-on to the authentication server using
a password-based TLS protocol.
Once a secure channel has been established,
the authentication server sends to the user:
new proxy credential
system parameters
up-to-date IRL
Note that:
the whole single sign-on does not rely on PKI;
users never need to check certificates.
6th Annual PKI R&D Workshop, 17-19 April, 2007 20
PECF-GSI: Authentication & key agreement
In the certificate-free PKI zone, mutual authentication
and secure communications can be achieved using a
certificate-free TLS protocol.
Based on HIBE/HIBS schemes.
(1) Client to Server: ClientHello
(2) Server to Client: ServerHello,
ServerIdentifier,
SeverHelloDone
(3) Client to Server: ClientIdentifier,
ClientKeyExchange,
IdentityVerify,
Finished
(4) Server to Client: Finished
6th Annual PKI R&D Workshop, 17-19 April, 2007 21
PECF-GSI: Delegation
We propose a one-message delegation
protocol.
The delegator encodes delegation information
within the identifier.
E.g. ID =
1. Establish secure TLS channel
3. Transmit proxy credential
(including private key)
(Proxy A) (Proxy X)
2. Construct proxy credential
6th Annual PKI R&D Workshop, 17-19 April, 2007 22
PECF-GSI: Delegation
Efficient verification mechanism
Only one signature verification regardless of the
length of the delegation chain.
(Before delegation)
(After delegation)
6th Annual PKI R&D Workshop, 17-19 April, 2007 23
3. Security Concerns
We assume authentication servers behave
honestly in distributing:
Authentic system parameters;
Up-to-date IRLs.
Our certificate-free TLS and one-message
delegation protocols are as secure as the
standard TLS and the GSI delegation protocol.
Key escrow
Can be fixed by applying certificateless public key
cryptography proposed by Al-Riyami and Paterson
(2003).
Active impersonation attacks by a dishonest TA
are unavoidable.
6th Annual PKI R&D Workshop, 17-19 April, 2007 24
4. Conclusions
Summary:
Proposed a password-enabled and certificate-free
grid security infrastructure.
Emphasised user-friendliness.
Addressed key revocation which is a common issue
for identity-based cryptosystems.
Explored attractive properties of hierarchical identity-
based cryptography.
Future work:
Develop new authorisation techniques using identity-
based cryptography that suit grid environments.
6th Annual PKI R&D Workshop, 17-19 April, 2007 25
Thank you!
Email: h.lim@rhul.ac.uk
6th Annual PKI R&D Workshop, 17-19 April, 2007 26
Enabling the Provisioning and Management of a Federated Grid Trust Fabric
Stephen Langella1, Scott Oster1, Shannon Hastings1, Frank Siebenlist2, Tahsin Kurc1, Joel Saltz1
1 2
Department of Biomedical Informatics Mathematics and Computer Science Division
Ohio State University Argonne National Laboratory
Columbus, OH 43210 Argonne, IL 60439
{langella,oster,hastings,kurc,jsaltz}@bmi.osu.edu franks@mcs.anl.gov
Abstract collaborate in some fashion, they will have services
with varying security policy enforcement requirements.
In order to authenticate and authorize users and other The interconnections, between clients and services that
peer-services, Grid services need to maintain a list of are able to securely communicate in the larger Grid,
authorities that they trust as a source for issuing form conceptual overlays of trust, which we herein
credentials. Grids inherently span multiple refer to as the “trust fabric” of the Grid. Figure 1shows
institutional administration domains and aim to an example trust fabric composed of four trust groups
support the sharing of applications, data, and (Trust Groups A-D), over a worldwide Grid. The
computational resources in a collaborative establishment, provisioning, and management of the
environment. In this environment there may exist trust fabric are critical to the scalability, maintenance
hundreds of certificate authorities, each issuing and security of the Grid and other web service
hundreds if not thousands of certificates. In such a environments. This paper is concerned with the design
dynamic multi-institutional environment with tens of and implementation of the Grid Trust Service (GTS)
thousands of users, credentials will be issued and framework to facilitate the provisioning and
revoked frequently, and new authorities will be added management of a Grid trust fabric.
regularly. Clearly a Grid-wide mechanism is needed
Trust Group B
for maintaining and provisioning trusted certificate Trust Group A Trust Group C
authorities, such that Grid services and users may
make authentication and authorizations decisions
against the most up-to-date trust information. In this
paper we present the design and implementation of the Trust Group D
Grid Trust Service (GTS), a federated framework for
creating and managing a Grid trust fabric, enabling
the provisioning of certificate authority information.
1. Introduction
As Grid computing technologies gain acceptance and
adoption, the transition from highly specialized Grids
with only a few institutional participants to a Grid Figure 1 Conceptual Trust Fabric example with
environment with hundreds of institutions is becoming different trust groups
a reality. Security is of primary importance in the Grid
and the support for secure communication, Many components of the Grid rely on having trust
authentication, and authorization is a critical agreements in place. For example, when a user wants to
requirement, specifically in settings where sensitive access a service, she is authenticated based on an
data (e.g., patient medical information) must be identity assigned to her. In the Grid, clients and
accessed and exchanged. Also needed are mechanisms services authenticate with one another using X.509
to establish and manage “trust” in the Grid so that identity certificates. Grid Identities are assigned to
asserted identities and privileges can be verified and users by authorities. When a grid-identity is asserted by
validated with the required level of confidence. Within an authority in the form of an X.509 identity certificate,
a collaboration, it is clear that the different institutions it is digitally signed by that authority. Relying parties
will have tiered levels of confidence in the users and make authentication decisions based on whether or not
service management policies of the various other the certificate presented is signed by a trusted
institutions. While generally all institutions want to certificate authority. Thus, authentication requires a
trust agreement between the consumers of X.509 • It allows the definition and management of trust
identity certificates and the certificate authorities that levels, such that certificate authorities may be
issue them. grouped and discovered by the level of trust that is
acceptable to the consumer.
In a Grid environment, there may exist tens or even • The federated nature of the GTS, coupled with its
hundreds of certificate authorities, each issuing ability to create and manage arbitrary
hundreds if not thousands of certificates. To make arrangements of authorities into trust levels, allows
matter worse, in a dynamic multi-institutional it to facilitate the curation of numerous
environment, the status of identities may be updated independent trust overlays across the same
frequently. Identities and credentials can be revoked; physical Grid.
suspended, reinstated, or new identities can be created. • The GTS can also perform validation for a client,
In addition, the list of trusted authorities may change. allowing a client to submit a certificate and trust
In such settings, certificate authorities will frequently requirements in exchange for a validation decision,
publish Certificate Revocation Lists (CRL), which which allows for a centralized certificate
specify “black listed” certificates that the authority verification and validation.
once issued but no longer accredits. For the security
and integrity of the Grid, it is critical to be able to 2. Motivation
perform authentication and validate a given identity
against the most up-to-date information about the list of Our work is driven mainly by the requirements that are
trusted certificate authorities and their corresponding derived from the Grid security usage scenarios
CRLs. gathered from the Cancer Biomedical Informatics Grid
(caBIGTM) [1] program. This program, funded by the
Each institution normally manages its own security National Cancer Institute (NCI), was launched to
infrastructure with its own CAs, and all client and provide a coordinated approach to the informatics
services within such an administrative domain needs to requirements of basic and clinical cancer research and
be configured to trust the local trust roots. If multi-institutional studies. The goal is to accelerate the
collaborations span administrative domains, then delivery of innovative approaches for the prevention
participating entities have to be configured to trust the and treatment of cancer by facilitating sharing,
trust roots defined in the different organizations within discovery, and integration of distributed information
the limits of their own local policies. The required trust and analytic resources. Although the caBIG effort
root configurations to participate in such Virtual started relatively recently, it is expected that the caBIG
Organizations (VO) are complex, error prone and community will grow to comprise of hundreds of
security policy sensitive. By centralizing the organizations and many thousands of cancer-research
configuration management and provisioning participants from geographically dispersed medical
collaborating clients and services “on demand”, one centers, universities, government agencies, and
can ensure that the correct and up-to-date trust-root commercial companies.
information is made available. In this scenario, the
central provisioning server becomes a trusted entity Given the sensitivity of the medically related data and
itself, and clients need to be configured to trust its the number of institutions involved, security has
provisioning information. In order to facilitate the trust quickly become a high priority issue in caBIG. In order
in the provisioning servers, they should be locally to articulate the security requirements of caBIG and
known to the clients, which requires local provision evaluate existing technologies, a Security Technology
servers to aggregate and to front-end remote ones. Evaluation White Paper [8] has been developed. This
white paper serves as one of the motivating influences
The Grid Trust Service (GTS) is a Web Services for the GTS work. A key security issue is to implement
Resource Framework (WSRF) [9] compliant federated an effective mechanism of managing the Grid-wide
infrastructure enabling the provisioning and identities and privileges of large numbers of users
management of a grid trust fabric. The salient features across multiple organizations. Another key issue is to
of the GTS can be summarized as follows: be able to authenticate and authorize users to caBIG
• It provides a complete Grid enabled federated services based on this information, such that access to
solution for registering and managing certificate resources can be restricted to individual users or a
authority certificates and CRLs, facilitating the group of users. Considering the scale of caBIG, these
enforcement of the most recent trust agreements. issues become challenging.
The GTS framework has been implemented in the Tier 0, also referred to here as the Locally Stored,
context of the caGrid [2, 30], which is the Grid Locally Validated (LSLV) profile, specifies that CA
software infrastructure of caBIG. caGrid is a service- certificates are stored and accessed locally; certificate
oriented architecture and implementation that provides validation is done against the locally stored CA
core services, toolkits and wizards for the development certificates. Although the deployment and maintenance
and deployment of community provided services. One of the LSLV profile seems simple, the realization of
of the primary design principles of caGrid is to such a profile in a large and dynamic Grid environment
leverage the open Grid standards [3, 4]. The caGrid faces several problems. First, the LSLV profile makes
infrastructure is built on top of the Globus Toolkit [5], it difficult to provision CA certificates and their
the most widely used reference implementation of the corresponding CRLs. Under the LSLV approach, every
Grid standards. The Globus Toolkit implements local environment is required to update its local trust
support for security via its Grid Security Infrastructure store each time a new CA certificate becomes available
(GSI) [6, 7]. GSI requires the use of X.509 Identity or each time a CA publishes a new CRL. Moreover, the
Certificates for identifying a user. An X.509 certificate LSLV profile could pose a potentially serious security
with its corresponding private key constitutes a unique risk because it requires users to maintain their own trust
credential or so-called “Grid credential” that is used to fabric. A simple error by an inexperienced user could
authenticate both users and services within the Grid. easily introduce a security hole in the environment.
Under the current Globus release (4.0.3), the
authentication process ensures that the X.509 Identity Tier 1, also referred to here as the Remotely Retrieved,
Certificate provided by the peer was issued by a trusted Locally Validated (RRLV) profile, specifies that CA
certificate authority. However, one limiting issue with certificates are retrieved remotely from a Trust Service;
the current mechanisms is that trusted certificate certificate validation is done locally against the
authorities (CAs) and their CRLs are maintained remotely retrieved CA certificates. When deployed in a
locally on the file system of each Globus installation. large Grid environment, the RRLV profile significantly
When a client authenticates with a service, Globus improves upon the LSLV profile. Retrieving the latest
locates the root CA and CRL of the client’s Identity CA certificates and corresponding CRLs remotely
Certificate on the local file system. Once located, the allows Grid services to perform validation against the
Globus runtime validates the Identity Certificate latest trust fabric. It also moves the management of the
against the CA certificate and CRLs. Although this trust fabric from the hands of users to the hands of
approach is effective, it is difficult to provision CA administrators, who have more expertise and
certificates and CRLs in a large multi-institutional experience in managing trust. Performing the validation
environment, as one has to ensure that all CA and CRL locally also allows services and applications to enforce
information must be copied to every installation and local validation policies that may go beyond those
kept current with the dynamically changing specified in X.509 certificate validation. At the same
environment. Given the sensitivity of the data in time local validation can be a potential security risk, if
caBIG, it is critical that services authenticate clients the local validation process is not effectively enforced.
against the most up-to-date list of CA certificates and
CRLs. This requirement is one of the primary Tier 2, also referred to as the Remotely Stored,
motivations behind the design and development of the Remotely Validated (RSRV) profile, specifies that CA
Grid Trust Service (GTS). certificates are stored remotely; certificate validation is
done remotely against the remotely stored CA
3. Background and Trust Fabric Profiles certificates. The RRLV profile and the RSRV profile
are similar in that validation is done against the latest
The XML Key Management Specification (XKMS) trust fabric. They differ in where the validation is done.
[10] specifies models and protocols for distributing and Under the RSRV profile validation is done remotely,
managing public key credentials. XKMS specifies a which removes the validation from the hands of the
tiered service model allowing applications to leverage local providers minimizing potential security exposure
the level of functionality that meets their requirements. when validation is not strongly enforced locally.
The design of the GTS mimics this tiered service However, it introduces a potential performance
model, and for the purpose of this paper we will problem in that a local service is required to contact a
describe the relevant tiers in terms of the locations of remote validation service every time validation is
CA certificates and where certificate validation occurs. required.
4. Grid Trust Service (GTS) GTS instance. Installations in the Grid are then
bootstrapped to trust this authority or small set of
The Grid Trust Service (GTS) is a WSRF compliant authorities. Note that even if the clients are pre-
Grid Service framework for creating, managing, and configured with the trusted CAs, the GTS infrastructure
provisioning of a federated Grid trust fabric. can be used as a distribution mechanism of the CA’s
Establishing trust in the Grid is rooted in the problem CRLs.
of determining whether or not to trust a given
certificate authority. Through its service interface, the An advantage of the deployment with self-signed GTS
GTS provides the ability to register and manage certificates is that it does not require a root-CA to exist.
certificate authorities. Using the GTS, Grid entities If clients and services will only interact with a few GTS
(services and clients) can discover the certificate instance, this could be a preferred way of deployment.
authorities in the environment, decide whether or not to However, GTS certificates cannot be revoked in such a
trust a certificate authority, and determine the levels of deployment. An advantage of the deployment with
trust assigned to a certificate authority. root-CA is that if the root-CA monitors integrity of
GTSs, it can revoke GTS certificates and publish
In implementing a trust fabric in a Grid environment, CRLs, which will include the revoked GTS certificates,
we envision that the trust fabric will consist of Grid in case of a security breach (with the acknowledged
users and administrators, Grid services, multiple CAs, issue of communicating the revoked GTS-certificate to
and multiple GTS instances. The flexibility of GTS the GTS-clients when the distribution mechanism relies
allows many possible deployment scenarios. For on the GTS).
example, an institution can set up a local CA and GTS
instance. Alternately, a group of organizations may all While GTS facilitates management of certificate
share a common CA for certificates and a GTS to authority lists, the trust establishment with a CA and
maintain the list of trusted external CAs. In any setting its trust level is a manual process. That is, the
deployment, each Grid user will be given a certificate, administrator of a GTS instance is expected to
signed by a CA that can be used by services to exchange correspondence with the owner of the CA to
authenticate the user. Similarly, each Grid service will be added to the list of CAs managed by the GTS
be given a certificate, also signed by a CA, so that a instance. Once a trust level, or set of trust levels, has
client application, user, or other service can check the been established, the CA can be added to the list of
integrity of the service. Since GTS instances are Grid CAs so that it can be discovered by users and services.
Services, they should be assigned certificates as well. The trust levels of the CA can be used by a client or
service to determine whether or not to trust the CA.
As deployments leveraging the GTS to maintain the (We will describe the management of trust levels in
trust fabric are effectively delegating this responsibility greater detail in Section 4.2.) In the trust fabric setting,
to the GTS, it is imperative the GTS instance(s) can be a CA is responsible for publishing its CRL so that local
trusted. Traditionally a trust “bootstrapping” approach CRLs and CRLs maintained by GTS instances can be
is adopted wherein clients and services communicating updated. In addition to the level of trust, each GTS
with the GTS are manually configured to trust its CA. maintains a status value for each CA in its list of CAs.
Additionally, by default, the GTS clients perform host By changing the status of a CA (e.g. from “trusted” to
authorization against the specific GTS with which they “suspended”), the GTS can quickly invalidate all the
are communicating. This ensures the service providing certificates signed by the CA, for example if there is a
the information about the trust fabric (the GTS) has a security breach.
certificate signed by a trust authority, and that it is
provably the specific instance the client intended to In a large Grid environment, it is desirable to have a
communicate with. There are multiple possible federated trust fabric for redundancy and scalability,
deployment options for assigning certificates to GTS and for the integration of multiple trust overlays. A
instances. A possible way is that each GTS instance has possible way of federating GTS instances is to create a
a self-signed certificate (i.e., serving as its own CA). In hierarchical structure, in which there are authority GTS
such a deployment, clients and services are manually instances and subordinate GTS instances. The
configured to trust the self-signed certificates of the authority GTS instances maintain lists of trusted CAs
GTS instances they intent to interact with. and CRLs and synchronize with CAs for updates. The
Alternatively, there can be one (or a few) trusted root- subordinate GTS instances can be designed to
CA, which will be used to assign the certificates to each synchronize with one or more authority GTS instances.
In this way, when the state of the trust fabric changes “no” answer. If the response is “no”, the service
(e.g., because of publishing a new CRL), the updates prevents the user from accessing its resources. If the
need not be broadcast to all GTS instances response is “yes”, the service can take additional steps
individually. The approach for federation of GTS to authorize the user and control his access to the
instances is discussed in Section 4.5. service’s functionality based on the authenticated user’s
privileges.
4.1. Profiles Supported by GTS
Grid Trust Service (GTS)
Out of the box, the Globus Toolkit supports the LSLV
1. Username/
profile, and the GTS adds the support for both the Password
L
2. SAM
RSRV profile and the RRLV profile. Our use cases for Asserti
on
OSU User
enabling trust between identity providers and
5. Grid Proxy
IdP
consumers of identities and between attribute
n
Ohio State University
o
ox rti
Pr sse
Authentication System
authorities and consumers of attributes call for the use
y
A
L
AM
of Remotely Stored Remotely Validated (RSRV)
id
S
Gr
3.
4.
profile. It is also anticipated that future releases of 6.
Is
Pr
Globus will support callouts to remote validation 7.
ox
Ye
yV
a li
s/N d?
services. The GTS supports this profile by providing a o
validation operation through its service interface. In Grid Service
this manner, the GTS is a validation service allowing Trust Agreement
Grid
clients to submit validation criteria and an X.509 Dorian
Grid Trust Service
certificate chain for validation.
Figure 2 illustrates an example usage scenario of the
RSRV profile. In this example, a GTS instance is used
Grid Service
to manage and validate client certificates in caGrid.
This example has a Dorian [11] instance serving as a Figure 2 Trust Service (GTS) RSRV Profile
CA and proxy certificate generator. Dorian is a Grid
service infrastructure for the management of Grid user The GTS also supports the RRLV profile for accessing
accounts. Dorian provides an integration point the trust fabric. This is because the current release of
between external security domains and the Grid Globus Toolkit (Globus 4.0.3) does not provide a
security domain, enabling users to obtain Grid means of supporting remote validation of credentials;
credentials using their locally provided authentication rather validation must be done against a locally
mechanism. In Figure 2, an Ohio State University maintained trust fabric. To enable Globus to
(OSU) user authenticates to the OSU authentication authenticate users by validating their credentials
system using her local user name and password. Upon against the trust fabric maintained in the GTS, the
successfully authenticating, the user is given a signed RRLV profile is employed. The GTS provides a
SAML assertion, which can be given to Dorian in framework called SyncGTS, which is embedded in the
exchange for a Grid proxy or Grid credentials. In the Globus runtime to automatically synchronize the local
example, a trust agreement has been established trust certificate store with the latest trust fabric
between the GTS instance and the Dorian instance maintained in the GTS. The SyncGTS functionality is
wherein the Dorian instance’s CA is listed as a trusted presented in more detail in Section 5.
authority in the GTS instance. Trust and the trust level
between the GTS and Dorian instances can be Figure 3 illustrates how authentication and certificate
established by the administrator of Dorian and the validation can be performed with the RRLV profile in
administrator of GTS through the exchange of GTS. When a Grid service is invoked, Globus
information such as certificate policy and certification authenticates the client by validating that the Grid
process statements. When the user presents the Grid proxy provided is signed by a trusted certificate
proxy certificate to a Grid service, the grid service authority. The certificate is validated against the local
validates that the user is the owner of the proxy’s trusted certificates directory as is seen in the figure. In
private key, the certificate is then sent to the GTS the example in Figure 3, the Dorian certificate
instance for validation (Step 6 in the figure). The GTS authority has been registered with the GTS as a trusted
instance can respond back to the service with a “yes” or certificate authority and Globus has been configured to
synchronize its local trusted certificate store with the their real identity. The CA issues a certificate to the
GTS. Thus when the OSU user invokes a Grid service applicant after these documents are reviewed by the
using her Dorian-obtained proxy, she will be CA staff. Another certificate authority may
successfully authenticated by Globus. Future versions automatically issue certificates based on an online
of Globus will support a credential-validation callout, application submitted by the applicant -- the applicant
at which time the RSRV GTS profile, illustrated in may have been requested to log on to the system using
Figure 2 can be employed. a user id and password. In these cases, the first
certificate authority has a stricter policy for issuing
Grid Trust Service (GTS) certificates; thus, it is reasonable to expect that the first
certificate authority should be trusted more than the
1. Username/
Password second certificate authority .
L
2. SAM n
io Local Globus
Assert OSU User
Trusted
Certificates
In order to model different levels of trust in the trust
5. Grid Proxy
IdP Directoy fabric, the GTS provides a mechanism for its
?
on
lid
Ohio State University
ox rti
Va
Pr sse
Authentication System administrators to define and manage trust levels. When
y
ox
y
A
Pr
No
L
s/
M
Is
certificate authorities are registered into the trust fabric
SA
Ye
id
6.
7.
Auto
Gr
3.
Synchronize
4.
Local
With GTS they are assigned one or more trust levels. Clients can
File
System
specify the level of trust that they require when
discovering trusted CAs or when requesting validation.
Grid Service Trust levels in the GTS each consist of a unique name
Trust Agreement (value) and description. The unique name is used to
Grid
Dorian implicitly bind a certificate authority to a trust level.
Grid Trust Service
The description is used as a human readable method of
understanding what a specific trust level represents.
Through its Grid service interface, the GTS provides
several operations for accessing and administrating
Grid Service
trust levels. The getTrustLevels() operation is a
publicly accessible operation which provides a list of
Figure 3 Grid Trust Service (GTS) RRLV Profile all the trust levels existing in a GTS. The
addTrustLevel(), updateTrustLevel(), and
removeTrustLevel() operations are accessible to GTS
4.2. Managing Trust Levels in GTS administrators, providing them with a method of
administering trust levels. Figure 4 illustrates the trust
The trust level specifies the level of confidence with level management interface in the GTS administrative
which a given certificate authority is trusted in the user interface (admin UI).
fabric in which it is deployed. In the Grid, one can
assume that certificate authorities will be trusted with On initial deployment, the GTS does not come pre-
different levels of confidence.1 There will be multiple configured with a set of trust levels, at the time of
types and instances of certificate authorities. Some development it was determined that it was desirable to
authorities may be used to assert identities; other allow Grid administrators to define trust levels based
authorities may be used to assert digitally signed on the security policy defined by their Grid. The GTS
documents. Even certificate authorities asserting the provides the tools for administrators to assign and
same thing may have differing levels of trust associated manage trust levels to CAs. The system is flexible in
with them, as they may employ different policies for that each GTS instance can have its own trust levels. It
issuing and validating identities. For example, a may be desirable to have a common set of trust levels
certificate authority may require that anyone applying across multiple institutions, however, so that a client or
for a certificate present official documentation about a service can interpret the trust level associated with a
CA correctly. In that case, a standard for trust levels
should be accepted by the community and made
1
The trust level concept in the Grid is similar to obtaining an available in a common repository or distributed to each
identity card from different institutions. Obtaining a passport will GTS instance. Note that having a common set of trust
require that the application provide more documentation and a more
thorough background check be performed. On the other hand, levels does not require each GTS instance to assign the
getting a library card will require a less strict background check and same trust level to the same CA. A GTS instance may
less documentation
Figure 4 Admin UI for trust level management
assign a higher level of trust to a CA than another GTS trusted certificate authority, the GTS maintains a
instance. However, a common set of trust levels allows Certificate Revocation List (CRL). The CRL contains a
a client to interpret the trust level assigned by each list of certificates that have been revoked by the CA.
GTS instance correctly and determine whether or not to
trust the corresponding CA. The GTS makes several operations available to
administrators for managing trusted certificate
4.3. Managing Certificate Authorities authorities, these include addTrustedAuthority(),
updateTrustedAuthority(), removeTrustedAuthority(),
The GTS service interface provides several operations and updateCRL(). The updateCRL() operation provides
for registering and managing trusted certificate a mechanism for CAs to publish their CRL immediately
authorities. Registration of a certificate authority after it is locally updated. For example, Dorian revokes
requires the specification of the CA’s root certificate, a a user’s certificate and adds an entry to its CRL, every
set of trust levels, a status, and an optional CRL. The time a user’s account is suspended. Upon updating its
CA’s root certificate is required for validating CRL, Dorian immediate publishes it to the GTS. The
certificates. The set of trust levels specifies the level of updateCRL() operation can be invoked by GTS
trust associated with the CA. The status specifies the administrators and individual trusted certificate
current state of the certificate authority; the status can authority administrators. The GTS provides a
be set to “trusted” or “suspended”. Setting the status of mechanism of assigning and maintaining a list of
a certificate authority allows it to be temporarily added individual trusted certificate authority administrators.
and removed from the trust fabric. For instance, if the Figure 5 illustrates the trusted certificate authority
security of a CA has been compromised, its status can management interface in the GTS admin UI.
be set to “suspended” to quickly invalidate all
certificates issued and signed by the CA. For each
Figure 5 Admin UI for managing a trusted CA
4.4. Managing Administrators uniform resource identifier (URI), priority, whether or
not to synchronize the trust levels, time to live, whether
Many of the operations provided by the GTS provide a or not to perform authorization, and the authority
means of administrating the trust fabric and are service’s identity. The priority property is used for
therefore restricted to GTS administrators. The GTS resolving conflicts between authority GTSs, for
provides three operations for managing the assignment example if two authority GTSs have a listing for the
of administrative roles to users: addPermission(), same certificate authority, the authority GTS with the
revokePermission(), and findPermissions(). These highest priority will be used for obtaining that
operations are, themselves, obviously restricted to GTS certificate authority, and its corresponding information
administrators. (e.g. its CRL). If contact to an authoritative GTS is lost
for a significant amount of time, the trust fabric within
The GTS allows for the assignment of two types of the subordinate GTS may become significantly out of
permissions; GTS Administrators, and Trusted CA date; this could be a potential security risk. The time to
Administrators. GTS Administrators are “super users” live property specifies how long certificate authorities
and can perform any operation on a GTS (i.e. manage obtained from authoritative GTSs will be valid for in
certificate authorities, manage trust levels, manage the subordinate GTS. The time to live on a given
permissions, etc). A Trusted CA Administrator certificate authority record is reset after each
permission corresponds to a specific CA, giving a user synchronization with the authority GTS. If contact with
the ability to update the CRL for the corresponding an authority GTS is lost, the time to live will expire and
CA. the certificate authority will be removed from the
subordinate’s trust fabric.
4.5. Federation
Figure 6 illustrates an example of how multiple GTSs
Redundancy and scalability are critical properties of a can be deployed to create and manage a federated trust
federated trust fabric. Serious performance implications fabric. In the example there are five GTSs: caGrid
will occur if all entities in the Grid are discovering and GTS, TeraGrid GTS, OSU GTS, caGrid/TeraGrid
performing validation against a trust fabric maintained GTS, and UT GTS. The caGrid GTS has no authority
in a central GTS. In order to enable a federated trust GTSs, it manages the certificate authorities A and S.
fabric, each GTS can be administered to synchronize The TeraGrid GTS has no authority GTSs, and it
with a set of authoritative GTSs. GTSs can inherit both manages the certificate authorities X and S. The OSU
trust levels and trusted certificate authorities from its GTS has one authority GTS, the caGrid GTS. The
authority GTSs. Registering an authority GTS requires OSU GTS inherits the certificate authorities A and S
the specification of the following properties: service’s from its authority the caGrid GTS. The OSU GTS
manages an additional certificate authority B. The OSU Through its service interface, the GTS provides
GTS is an example of how the global trust fabric can administrative operations for managing the federation.
be extended to include local trusted certificate The trust fabric is managed by specifying authority
authorities, in this case and the additional certificate GTSs for a given GTS. To support this, the GTS
authority CA B, which is trusted by OSU. The service interface provides the following operations:
caGrid/TeraGrid GTS has two authority GTSs, the addAuthority(), updateAuthority(), removeAuthority(),
caGrid GTS and the TeraGrid GTS. The TeraGrid and updateAuthorityPriorities(). Figure 7 illustrates the
GTS inherits CA A from the caGrid GTS and CA X authority GTS management interface in the GTS admin
from the TeraGrid GTS, since the caGrid GTS has a UI.
higher priority then the TeraGrid GTS, it inherits CA S
from the caGrid GTS. The caGrid/TeraGrid GTS is an
example of how two existing trust fabrics from two
different Grids can be joined together. Finally the UT
GTS has one authority GTS, the TeraGrid GTS. The
UT GTS inherits CA X and CA S from the TeraGrid
GTS. The UT GTS is an example of standing up a GTS
for better redundancy and scalability.
Federated Trust Fabric
caGrid TeraGrid
GTS GTS
A X
S S
Figure 7 Admin UI for GTS Authority Management
Priority Priority Priority Priority
1 1 2 1
4.6. Discovery and Remote Validation
caGrid/ UT GTS
OSU GTS
TeraGrid
A (caGrid) A (caGrid) X (TeraGrid) In order to support the RRLV profile, local validation
S (caGrid) S (caGrid)
B X (TeraGrid)
S (TeraGrid) processes will need a method of discovering and
obtaining trusted CAs from the pre-configured GTS.
Figure 6 Example federated GTS deployment The GTS provides a publicly available operation,
findTrustedAuthorities() through its service interface.
Supporting a federated trust fabric across GTSs In discovering trusted certificate authorities the GTS
introduces additional metadata to be associated with allows the specification of search criteria. The search
trust levels and certificate authorities. This metadata criteria include the name of the certificate authority, the
includes the “Source GTS”, “Authority GTS”, and trust level, the status, the lifetime, the source GTS, and
“Time to Live”. The “Source GTS” specifies the the authority GTS. Using this operation, validators
service URI of the GTS in which the trust level or implementing the RRLV profile can discover a list of
certificate authority was inherited from. The “Authority trusted certificate authorities based on the trust level.
GTS” specifies the service URI of the GTS that is the Additionally, trust fabric administrators may leverage
authority of trust level or certificate authority. “Time to this operation for discovering the trust fabric such that
Live” specifies the date until which the certificate they may administer it. Figure 8 illustrates the
authority entry is valid. discovery interface in the GTS admin UI.
Figure 8 Admin UI for Trust Fabric Discovery
To support the Remotely Stored, Remotely Validated directory on the local file system. SyncGTS, shown in
(RSRV) model, the GTS takes on the role of a Figure 9 maintains the local trusted certificates
validation service. The GTS validate() operation directory for Globus. When SyncGTS synchronizes
enables clients to submit, for validation, a certificate with a set of GTS instances, it copies the CA
chain and validation criteria. The GTS uses the X.509 certificates and CRLs to the local trusted certificates
validation specifications for validating the certificate directory using proper Globus naming conventions,
chain. Additionally, it enforces the X.509 Proxy purging all certificate and CRLs that existed from the
extensions for validating the certificate chain, if an previous synchronizations. SyncGTS is configured with
X.509 proxy certificate exists in the chain. The GTS a synchronization description, which describes the
uses the validation criteria to identify a set of certificate synchronization criteria. Each synchronization criterion
authorities to validate the specified certificate chain specifies a GTS to synchronize with and a set of search
against. The validation criteria are similar to discovery criteria for enforcing restrictions (trust levels, etc.) on
criteria, optionally allowing the set of certificate the resulting certificate authority set. When SyncGTS
authorities to validate against to be limited based on the is executed, it connects to all the GTS instances
following: the name of the certificate authority, the specified in the synchronization description and obtains
trust level, the status, the lifetime, the source GTS, and a list of trusted certificate authorities and
the authority GTS. corresponding CRLs matching the specified search
criteria.
5. SyncGTS
For auditing purposes SyncGTS maintains a reporting
As mentioned, the current Globus Toolkit release model, SyncReport, describing each synchronization
(version 4.0.3) supports the LSLV profile for point. A report is generated and written to the local file
certificate validation. To meet the security system, each time SyncGTS synchronizes with a set of
requirements of caBIG, we needed to ensure that GTSs. The report describes when the synchronization
certificate validation is performed against the latest occurred, the synchronization description executed, and
trust fabric. To this end, without having to modify the the outcome of the synchronization. The outcome
Globus Toolkit we created SyncGTS. SyncGTS is a details which GTS a certificate authority and CRL
plugin for the Globus Toolkit enabling it to support the came from and where on the file system the CA
RRLV profile. Globus performs authentication, or information and CRL were written. It also describes
certificate validation, against a trusted certificates any certificate authorities and CRLs that were removed,
because they were remnants of a previous provisioning is C-based, and does not deploy
synchronization. webservice compliant protocols. Furthermore, it lacks
automatic synchronization capabilities and possible
SyncGTS can support several deployment options. It aggregation mechanisms of provisioning information.
can be embedded directly into a Globus container as a
Grid service, enabling all services running in that The Portal-based User Registration System (PURSe)
container to perform authentication against the GTS [24] implements a user interface for users to register
maintained trust fabric. SyncGTS can also be and access their Grid credentials. It uses SimpleCA and
embedded directly in client-side applications by MyProxy as the backend system for management of
leveraging the SyncGTS Java API. In addition, Grid credentials. GAMA [25] is a GSI-based
SyncGTS provides command line utilities, which can infrastructure that provides a backend server for
be leveraged on both the client and service sides. creating and managing X.509 credentials for users and
a suite of portals that serve as interfaces for users and
SyncGTS administrators to access GAMA’s functionality. Dorian
[11] provides a Grid service infrastructure, based on
Globus the use of public key certificates and SAML assertions,
Trusted for managing and federating user identities in the Grid.
Certificates
Directoy It facilitates combined use of SAML and Grid
certificates to authenticate users to the Grid
Trusted
Authorities
environment through their institution’s authentication
mechanism. The GTS differs from these systems in that
it addresses the complementary problem of federating
Sync GTS
GTS
Query List
trusted identity authorities (i.e., Certificate Authorities)
with different trust levels and validation of user
certificates against this federated environment.
Trusted
Authorities
Management of trust is recognized as an important
Query
Trusted
Authorities
Query component of security in distributed environments [6,
12-21]. Manchala [12] describes trust models and
metrics in e-commerce applications and discusses how
risk can be analyzed under different models. Azzedin
and Maheswaran [13] present a trust model for a Grid
environment. Their approach models trust based on
Grid Trust Service Grid Trust Service
behavior and reputation of entities that interact with
Figure 9 Conceptual View of SyncGTS others. They describe techniques for computing this
type of behavior trust, how it evolves in an
6. Related Work environment, and how it can be managed in a Grid
setting. GridAdmin, proposed by Quillinan, Clayton,
Grid-wide management of security related information Foley, [14] is a system that provides support for
(such as certificates, credentials, user accounts, and automatic handling of requests for administrative
authorization information) is a critical and challenging actions and resource allocations. The system
issue. The challenge stems from the fact that the Grid incorporates trust metrics in responding to and ranking
consists of autonomous end-points with their own such requests. Weaver et. al. [17] discuss trust-sharing
security policies and infrastructure and it is a dynamic agreements and an IT infrastructure for federated
environment. A number of toolkits and service security in distributed healthcare applications. Hwang
architectures have been developed, for example, to and Tanachaiwiwat [18] propose a trust model and
manage user credentials and user accounts. The systems using this trust model for dynamic resource
MyProxy Credential Management Service [22, 23] is allocations. Grandison and Sloman [26] present a
an open source project for managing X.509 Public Key toolkit that provides support for specifying and
Infrastructure. MyProxy provides the ability to manage monitoring trust relationships for Internet applications.
private keys and certificates for Grid users, and also Ahsant et. al. [27] discuss how business trust
has an option to provision the trusted CAs and CRLs to relationships can be propagated to the Grid
the users. The current client implementation for the environment and how these relationships can be
federated dynamically. Li, Zhu, and Lam [28] propose defined protocols and interfaces in the GTS
a two-level trust model, in which the first level defines infrastructure. We plan to incorporate this into GTS in
trust relationships between virtual organizations and a future release. Moreover, we plan to extend GTS
the second level (lower level) specifies trust such that it can provision On-line Certificate Status
relationships within a domain. Park, Moon, and Sohn Protocol (OCSP) responder information. We expect the
[20] propose an approach and a service for validation Globus Toolkit to support OCSP in its future release
of certificates in the Grid using XKMS. Their system and will ensure that GTS can provide a mechanism for
implements support for realizing trust relationships in a OCSP-enabled clients and services to contact and trust
dynamic environment. Basney et. al. [29] describe the right authorities. Another planned future extension
extensions to the basic Grid security architecture in to GTS is the support for the provisioning of attribute
order to support negotiation and dynamic establishment and authorization authorities. With the latter
trust relationships between entities in the Grid. information, client and service will be configured to
Thompson et. al. [21] discuss trust and trust models allow them to query the relevant and trusted attribute
based on CAs for the Grid environment. Our work and authorization services.
complements the previous work on trust management
in that earlier work focused on specification of trust
and establishment and management of trust between
entities. The GTS, on the other hand, enables Grid- Acknowledgements:
wide management of trusted Certificate Authorities
with different trust levels. This work was supported in part by the National
Cancer Institute’s Center for Biomedical Informatics,
under the caBIGTM program (#79077CBS10), by the
7. Conclusions and Future Work National Science Foundation Grant ANI-0330612, by
the Ohio Board of Regents BRTTC program
We have shown the need for secure multi-institutional (#BRTT02-0003 and ODOD AGMT TECH 04-049),
Grids and have demonstrated current approaches for and by the Mathematical, Information, and
enabling access to trusted CA certificates as well as Computational Sciences Division subprogram of the
CRLs. We have outlined and analyzed the problems Office of Advanced Scientific Computing Research,
that are incurred when attempting to scale Grid security Office of Science, U.S. Dept. of Energy, under
across multiple institutions, which each has its own set Contract DE-AC02-06CH11357.
of authorized users as well as local security constraints.
We have presented GTS, a design and implementation References
for providing a Gridwide trust fabric that solves issues
in curating a Gridwide trust network. The GTS’ ability [1] Cancer Biomedical Informatics Grid (caBIGTM),
to store and manage large networks of trusted CA https://cabig.nci.nih.gov.
certificates and their CRLs will enable simple and safe
[2] The caGrid infrastructure,
scalability in leveraging secure and trusted certificates https://cabig.nci.nih.gov/workspaces/Architecture/caGrid/
in a Grid. This CA certificate trust network and
corresponding CRLs provided by GTS as a Grid [3] I. Foster, C. Kesselman, and S. Tuecke., “The Anatomy
service will enable validating users and services from of the Grid: Enabling Scalable Virtual Organizations”,
any institution against a known set of trusted certificate International J. Supercomputer Applications, 15(3), 2001.
authorities. In conjunction with SyncGTS, GTS will
enable the local caching of the trust network so that [4] I. Foster, C. Kesselman, J. Nick, and S. Tuecke, “The
local user validation can occur. The combination of Physiology of the Grid: An Open Grid Services Architecture
for Distributed Systems Integration”, Technical Report,
these tools, along with other Grid security measures
Globus Project; http://www.globus.org/research/papers/ogsa.pdf,
such as federated identity management, not only will June 2002.
enable Grid security to be less cumbersome to manage
for administrators but also will increase the ability to [5] The Globus Toolkit, http://www.globus.org.
create much larger, more secure, and disparate multi-
institutional Grids. [6] V. Welch, F. Siebenlist, I. Foster, J. Bresnahan, K.
Czajkowski, J. Gawor, C. Kesselman, S. Meder, L. Pearlman,
Although we use the tiered approach of the XKMS, our and S. Tuecke, “Security for Grid Services”, Twelfth
International Symposium on High Performance Distributed
current implementation does not employ the XKMS
Computing (HPDC-12), IEEE Press, June 2003.
[7] I. Foster, C. Kesselman, S. Tuecke, J. Volmer, V. Welch, [20] N. Park, K. Moon, and S. Sohn, “Certificate validation
R. Butler, and D. Engert, “A National-Scale Authentication service using XKMS for computational grid”. In Proceedings
Infrastructure.”, IEEE Computer, 33(12):60-66, 2000. of the 2003 ACM Workshop on XML Security (XMLSEC
'03), ACM Press, New York, NY, Oct 2003.
[8] Ken Lin and Gary Daemer “caBIG™ Security
Technology Evaluation White Paper”. [21] M.R. Thompson, D. Olson, R. Cowles, S. Mullen, and
https://cabig.nci.nih.gov/workspaces/Architecture/Security_T M. Helm. “CA-based Trust Model for Grid Authentication
ech_Eval_White_Paper_Provisional, January 2006. and Identity Delegation”, Grid Certificate Policy Working
Group, Global Grid Forum, Oct, 2002.
[9] Web Services Resource Framework (WSRF),
http://www.oasis-open.org/committees/wsrf, 2006. [22] J. Novotny, S. Tuecke, and V. Welch., “An Online
Credential Repository for the Grid: MyProxy”. Proceedings
[10] XML Key Management Specification (XKMS) of the Tenth International Symposium on High Performance
http://www.w3.org/TR/xkms/ Distributed Computing (HPDC-10), pp. 104-111, IEEE
Press, Aug 2001.
[11] S. Langella, S. Oster, S. Hastings, F. Siebenlist, T. Kurc,
and J. Saltz, "Dorian: Grid Service Infrastructure for Identity [23] J. Basney, M. Humphrey, and V. Welch., “The
Management and Federation," The 19th IEEE Symposium on MyProxy Online Credential Repository”. Software: Practice
Computer-Based Medical Systems, Special Track: Grids for and Experience, Volume 35, Issue 9, July 2005
Biomedical Informatics, Salt Lake City, Utah., 2006.
[24] PURSe: Portal-Based User Registration Service,
[12] D.W. Manchala, “E-Commerce Trust Metrics and http://www.grids-center.org/solutions/purse/
Models”. IEEE Internet Computing 4(2): 36-44, 2000.
[25] K. Bhatia, S. Chandra, and K. Mueller, "GAMA: Grid
[13] F. Azzedin and M. Maheswaran, "Evolving and Account Management Architecture," E-Science ‘05, pp. 413-
managing trust in grid computing systems," In the 420, 2005.
Proceedings of Canadian Conference on Electrical and
Computer Engineering, vol.3, pp. 1424- 1429, 2002. [26] T. Grandison and M. Sloman, "Trust Management Tools
for Internet Applications". The First International Conference
[14] T.B. Quillinan, B.C. Clayton, and S.N, Foley, on Trust Management. Springer Verlag, 2003.
"GridAdmin: Decentralising Grid administration using trust
management". Third International Symposium on [27] M. Ahsant, M. Surridge, T.A. Leonard, A. Krishna, and
Algorithms, Models and Tools for Parallel Computing on O. Mulmo, "Dynamic Trust Federation in Grids". In
Heterogeneous Networks, pp. 184- 192, July 2004. Proceedings of the 4th International Conference on Trust
Management, Pisa, Tuscany, Italy, 2006.
[15] M.H. Hanif Durad and C. Yuanda, "A vision for the
trust managed grid”. The Sixth IEEE International [28] T.-Y. Li, H. Zhu, and K.-Y. Lam, “A Novel Two-Level
Symposium on Cluster Computing and the Grid Workshops, Trust Model for Grid”. International Conference on
2006. Information and Communications Security (ICICS 2003), pp.
214-225, 2003.
[16] Y. Demchenko, C. de Laat, and V. Ciaschini, "VO-
based Dynamic Security Associations in Collaborative Grid [29] J. Basney, W. Nejdl, D. Olmedilla, V. Welch, and M.
Environment," International Symposium on Collaborative Winslett, “Negotiating trust on the Grid”. The 2nd Workshop
Technologies and Systems (CTS 2006), pp. 38- 47, May on Semantics in P2P and Grid Computing, New York, 2004.
2006.
[30] Joel H. Saltz, Scott Oster, Shannon L. Hastings, Stephen
[17] A.C. Weaver, S.J. Dwyer, A.M. Snyder, J. Van Dyke, J. Langella, William Sanchez, Manav Kher, Peter A. Covitz,
Hu, X. Chen, T. Mulholland, and A. Marshall, "Federated, "caGrid: design and implementation of the core architecture
secure trust networks for distributed healthcare IT services," of the cancer biomedical informatics grid", Ed. Alvis
In Proceedings of IEEE International Conference on Brazma, Bioinformatics, Vol. 22, No. 15, 2006, pp. 1910-
Industrial Informatics (INDIN 2003), pp. 162- 169, Aug. 1916.
2003.
[18] K. Hwang and S. Tanachaiwiwat, “Trust Models and
NetShield Architecture for Securing Grid Computing”.
Journal of Grid Computing, 2003.
[19] N. Nagaratnam et. al., “Security Architecture for Open
Grid Services”. Global Grid Forum Working Draft. 2003.
Government License (to be removed before publication)
The submitted manuscript has been created in part by
UChicago Argonne, LLC, Operator of Argonne National
Laboratory ("Argonne"). Argonne, a U.S. Department of
Energy Office of Science laboratory, is operated under
Contract No. DE-AC02-06CH11357. The U.S. Government
retains for itself, and others acting on its behalf, a paid-up
nonexclusive, irrevocable worldwide license in said article to
reproduce, prepare derivative works, distribute copies to the
public, and perform publicly and display publicly, by or on
behalf of the Government.
Enabling the Provisioning and Management
of a Federated Grid Trust Fabric
6th Annual PKI R&D Workshop
Gaithersburg, MD
April 19, 2007
Stephen Langella
Ohio State University
langella@bmi.osu.edu
Cancer Biomedical Informatics Grid (caBIGTM)
• Need: Enable investigators and research teams
nationwide to combine and leverage their findings and
expertise in order to meet NCI 2015 Goal.
• Strategy: Create scalable, actively managed organization
that will connect members of the NCI-supported cancer
enterprise by building a biomedical informatics network
• National Cancer Institute Initiative
• Over 800 Participants
• Over 80 Organizations
• Over 70 Projects
caGrid
• Grid Infrastructure for caBIG
• Enterprise Level Grid Components
• caGrid Components
• Grid Service Graphical Development Toolkit (Introduce)
• Metadata
• Advertisement and Discovery
• Semantic Services
• Data Service Infrastructure
• Analytical Service Infrastructure
• Identifiers
• Workflow
• Security
Grid Security Authentication
• Based on X.509 End Entity Certificates
and X.509 Proxy Certificates
•User Credentials
• Long term X.509 Certificate and
Private Key.
• Clients authenticate to the grid using
a grid proxy.
• Grid Proxy consists of a private key
and proxy certificate signed by the
user’s long term private key.
• Extension of X.509 Identity Certificates
• Short Lifetime
• Asserts Identity of users and services.
• Enables single sign-on
• Delegation
• Service Credentials
• Long term X.509 Certificate and
Private Key.
Problem
•How does the grid clients/services know which CA certificates to trust?
Should I trust
this CA? Should I trust
this CA?
Traditional Approach
•Traditional Approach (Globus, caGrid 0.5)
• Service Container and or Service can be configured by specifying a
trusted ca certificates directory in the server/service configuration directory
• Credentials are accepted if they are signed by a ca certificate in the
trusted ca directory.
• Drawbacks
• Hard for grid administrators to manage
• Difficult to provision trusted authorities
• Every time a new trusted authority comes on line, all the services in the grid
must re-configured to trust that authorities.
• Difficult to provision CRLs
• Impossible to keep trusted CA list current
• Trust is configured at the container level, not at the service level
• Trust Fabric in the hands of users
• Potential Serious Security Risk
Certificate Validation Profiles
•Locally Stored Locally Validated Profile (LSLV)
• Trusted Certificates are locally stored.
• Revocation Lists Store Locally
• Certificates received are validated against locally stored trusted
certificates.
• Pros
• Almost no infrastructure required
• Cons
• Impossible to keep trusted CA list current
• Trust Fabric in the hands of users
• Potential Serious Security Risk
Certificate Validation Profiles
•Remotely Retrieved Locally Validated Profile (RRLV)
• Trusted Certificates exist and are managed by a Trust Service
• Certificates received are validated against trusted certificates retrieved
from a trust service
• Pros
• Authentication performed against the current trust fabric
• Validation done locally, specialized validation requirements can be enforced.
• Cons
• Validation done locally, poor enforcement could lead to a potential security risk.
• Relies on bootstrapping from the Trust Service
Certificate Validation Profiles
• Remotely Stored Remotely Validated Profile (RSRV)
• Trusted Certificates exist and are managed by a Trust Service
• Certificates received are sent to a Trust Service to be validated
• Pros
• Authentication performed against the current trust fabric
• Validation done remotely and enforced globally.
• Local deployment no longer responsible for validation
• Certificate Path Discovery Managed.
• Enforcement of CA Signing Policies
• Cons
• Network Overhead
Certificate Validation Profile Support
• Locally Stored Locally Validated Profile (LSLV)
• Supported by Globus 4.0.3
• Directory of Trusted Certificates
• Certificate Validation against certificates in directory of Trusted Certificates
• Remotely Retrieved Locally Validated Profile (RRLV)
• Use trust service to obtain trusted CA certificates and CRLS and store them in the
Globus Trusted Certificate directory.
• Trust Service client manages the Globus Trusted Certificate directory for Globus,
keeping it up to date.
• Only minor changes to Globus required.
• Supporting Remotely Stored Remotely Validated Profile (RSRV)
• Globus contacts Trust Service during authentication to determine if the credentials in
question are signed by a Trusted CA
• Trust Service performs all validation and enforces revocation lists.
• Support requires SIGNIFICANT changes to the Globus Toolkit
Grid Trust Service Approach
• Design and Implement a Grid Trust Service
• Support for the Remotely Retrieved Locally Validated Profile (RRLV).
• Provide plug-in for the existing Globus Toolkit
• Supporting the Retrieved Remotely Validated Profile (RRRV)
• Work with Globus team to develop a validation interface abstracting validation
in Globus.
• Future versions of Globus can be configured with a custom validation interface
Grid Trust Service (GTS)
•Grid Trust Service (GTS)
• WSRF Grid Service
• Define and manage levels of assurance.
• Provides Support for Managing Trusted
Certificate Authorities
• Administrator register/manage certificate
authorities and CRLS with GTS
• Client tools synchronize Globus Trust
Framework with GTS
• Remotely Retrieved Locally Validated
Profile (RRLV)
• Globus is authenticating against the
current trust fabric
• Distributed GTS, Enabling the creation of a
scalable trust fabric.
Grid Trust Service (GTS)
•Levels of Assurance
• ex. Passport vs. Library Card
• GTS provides a mechanism for
defining and managing Levels of
Assurance or Trust Levels.
• GTS Administrators can
Add/Update/Remove Trust
Levels
• Requires grid credentials
(GTS Administrator)
• Each Trusted Authority can be
associated with a set of trust
levels.
• Certificate Authorities can be
queried by level of assurance.
Grid Trust Service (GTS)
•Trusted Authorities
• GTS manages a set of certificate authorities that are trusted in the grid to sign
grid credentials.
• Trusted Authority – A certificate authority trusted by the GTS.
• Name (Subject of the CA Certificate)
• Trust Level (s) – The level(s) of Trust associated with the CA.
• Status – The current status of the CA (Trusted or Suspended)
• Certificate – The ca certificate that corresponds to the private key that is used by the
ca to sign certificates. (credentials).
• Certificate Revocation List (CRL) – CA signed list of revoked credentials.
• Is Authority – Specifies whether or not the GTS listing this Trusted Authority is the
authority for it.
• Authority GTS – The authoritative GTS for the Trusted Authority
• Source GTS – The GTS from where the current GTS obtained the Trusted Authority
from.
• Expiration – The date at which after this Trusted Authority should no longer be
trusted.
Grid Trust Service (GTS)
•Querying for Trusted Authorities
• GTS provides a public mechanism for
discovering/querying the Trusted
Certificate Authorities.
• Query interface enables synchronization
tools to be built to synchronize
authorities trusted be Globus with those
trusted by the GTS
• GTS Provides a Java Search Client API
• GTS Provides a GUI built on top of the
Search Client API.
• Query Criteria
• Name
• Trust Level (s)
• Status (Trusted, Suspended)
• Lifetime (Valid, Expired)
• Is Authority
• Authority GTS
• Source GTS
Grid Trust Service (GTS)
•Managing Trusted Authorities
• GTS provides support for
adding/updating /removing Trusted
Authorities through its Grid Service
Interface.
• Requires Grid Credentials or Proxy
Certificate of a GTS Administrator
• GTS Provides an administrative Java
Client API
• GTS Provides an administrative GUI.
SyncGTS
•Toolkit used for synchronizing client and
service containers with the GTS
•Takes a set of GTS Queries and executes
them on a GTS, synchronizing the results of
the queries with the Globus Trusted
Certificates Directory.
•Supports multiple execution mechanisms.
• Grid Service in a grid service container
• Embedded in a client or service
• Command Line
Grid Trust Service (GTS) Federation
•GTS Federation
• A GTS can inherit Trusted
Authorities and Trust Levels
from other Grid Trust
Services
• Allows one to build a scalable
Trust Fabric.
• Allows institutions to stand up
their own GTS, inheriting all
the trusted authorities in the
wider grid, yet being to add
their own authorities that
might not yet be trusted by
the wider grid.
• A GTS can also be used to
join the trust fabrics of two or
more grids.
Grid Trust Service (GTS) Federation
•Each GTS has a set of Authoritative GTSs
•The GTS can be configured how often to sync
with its authorities.
•On syncing a GTS will obtain all valid Trusted
Authorities and Trust Levels (if specified) from
each authority GTS and organize them locally
base on priority.
•Managing GTS Authorities for a GTS
• GTS provides support for adding/updating
/removing GTS Authorities through its Grid
Service Interface.
• Requires Grid Credentials or Proxy Certificate
of a GTS Administrator
• GTS Provides an administrative Java Client
• GTS Provides an administrative GUI.
Project Resources and Communication
• www.cagrid.org
• Download Software
• Documentation
• Tutorials
• Technical Paper and Presentations
• caGrid 1.0 GForge Home
• Feature Requests
• Bug Reports
• Downloads / Source Repository
• http://gforge.nci.nih.gov/projects/cagrid-1-0/
• caGrid Users Mailing List
• https://list.nih.gov/archives/cagrid_users-l.html
• cagrid_users-l@list.nih.gov
GTS Team
• Ohio State University
• Stephen Langella
• Shannon Hastings
• Scott Oster
• David Ervin
• Tahsin Kurc
• Joel Saltz
• Argonne National Labs
• Frank Siebenlist
• NCICB
• Avinash Shanbhag
• Booze Allen Hamilton
• Arumani Manisundaram
Federation Experiences
NIST PKI R&D Workshop #6,
April 19 2007, Gaithersburg MD
Some Questions
• We are building "Trust Federations" - have we figured out what exactly
we are trusting?
• There seems to be a range of depth here from very in-depth CP/CPSs to
less-detailed Shib federations. What's the right level?
• How are the different technologies affecting the process?
– How is the mix of SAML/PKI/other working out - what are the translation
issues?
– Are the newer technologies making this easier or harder?
– Is this fostering PKI, making it obsolete or changing its roll?
• What are the sticks to go along with the carrots?
– How hard to do we have to work to ensure people play by the rules and
what happens when they don't?
2
Agenda
• Georgia Marsh - eAuthentication
• Jens Jensen – UK Federation/Shib-Grid
• Ken Klingenstein - InCommon
• Q&A
3
Authentication Panel Session
Framework
• Technological
• Political
• Practical
• Identity accounts
• Using standards (whenever possible)
• Need for implementations
UK Federation
• “Section 6” (accountability)
– ePPN not reissued within 24 months
– ePTI not reissued within 24 months
– Is it easier to not reuse ePTI?
– How to store the eXXX to prevent reuse
– Advisory – only 35% guarantee section 6
• But these are typically institution IdPs
– Cf. CP/CPS: Trust based on policy
UK Federation
• Migration issues
– SPs require personal information
• Dual sign-on (once only)…? Email linking it?
– With Shib-to-Athens gateway, SP doesn’t
always recognise user (anonymised)
• Confusingly called the Athens Shib gateway
• IdP uid -> Athens PUID
– With Athens-to-Shib gateway, SPs don’t
always get the relevant attrs
• ScopedAffiliation, ePTI, SAML2PersistentID
UK Federation
• Users should be aware of attrs
– release/block individually
• How to ensure “due diligence”
– Auditing process?
Technology in AUC
• Always (almost) pass UUID, for logging
• Along with magic bits for AUZ
• Standards are good, but
– Need licence to allow us to use it
– And convince us it remains usable
– “Free” implementations help, too
– Open Source best – we can help (sometimes)
– Preferably in languages we use
Technology
• Different things are good but,
– Need interop – and conversions
– Technical, assurance, political, practical,…
• It’s all very well until something goes
wrong
– Intruder alert
– The people factor against us
– Boss’ demo stops working
– Your nation stops working…
AUC tokens
• What are we authenticating
– Who I am (e.g. person or host certs)
– What I am (e.g. affiliation attrs, VOMS roles)
– What I do (service certs)
– Robots should say what they are, not what
they do
• Usability vs Security
– Very occasionally, there is a win-win
– SSO, hardware tokens over software
People
• Make it usable
– People sharing tokens
• Try to make it legally binding…
– And pray it doesn’t go to court, ever
– Particularly not in another country
– Insurance? Liability?
– Prohibit difficult stuff (financial)?
Policies
• Policies are good
• Early implementers feedback req’d
• IdPs and SPs shortcut via appropriate
policies
– UK (Shib) Federation rules of membership
– IGTF for Grid CAs
• Commit institutions to policies?
• Update IdPs when policies change!?
Fed Up
Topics
• Federation Basics
• Drivers
• Components
• International and pulic sector developments
• InCommon and its uses
• Next steps for federations
• Peering, confederation, and similar issues
• Support for collaboration and virtual organizations
• Development of other aspects of the attribute
ecosystem
Middleware vision in one slide
• Build a campus/enterprise core middleware
infrastructure that
• Serves the overall enterprise IT environment, providing business
drivers and institutional investment for sustainability and scalability
• Is designed from the start to support the research and instructional
missions
• Implies consistent approaches and common practices across campuses
and internationally
• Build, plumb, and replumb the tools of research on top of
that emergent infrastructure
• Domain-specific middleware (grids, sensor nets, etc)
• Common collaboration tools (video, protected wikis, shared
calendaring, audioconferencing, etc.)
Federated identity
• Leveraging enterprise identity management
beyond the enterprise
• Creates general purpose interrealm trust fabrics
• Standards (SAML) and open source
(Shibboleth) well aligned and gaining broad
adoption
• Persistent and broad R&E federations in many
countries now
Drivers
• Campuses want to allow their community to use
their local credentials to access external partners
in academia, government, businesses, etc.
• Relying Parties want to use campus authn
• For economies
• Not another sso to incorporate into the app
• Avoid much of the costs of account management
• For scaling in users
• Interest is tempered by legal considerations,
policy considerations, and unintended disruptive
economic consequences
Uses - Content
• To protect IPR (the JSTOR incident…)
• To open up markets
• Popular content – Ruckus, CDigix, etc
• MS
• Scholarly content – Google, OCLC
WorldCat
• Scope of IdM may be an issue
Services
• Student travel, charitable giving, web
learning and testing, plagiarism testing
service, etc.
• Allure for alumni services and other
internal businesses
• Student loans, student testing, graduate
school admissions, etc.
• The Teragrid
Government
• NSF Fastlane Grant Submission
• Dept of Agriculture Permits
• Social Security
• NIH
• Dept of Ed
Components of Federation
• Federating Software
• Federation operator and metadata
• Participants
• Policies on identity management
• Policies on privacy
• Shared set of attributes, including LOA
• Legal agreements among participants
• Management and governance
• (Peering, economics,…)
International Federations
• Widespread in Europe (over 15 countries),
emergent in Australia, nascent in Asia.
• The UK federation
(http://www.ukfederation.org.uk/) already has
over five million active users and intends to grow
to all of higher ed, K-12 and further education.
• Used for academic content access, research
support, national level services, etc
• Clear needs for peering; some need for
confederation or dynamic relationships.
Public sector federations
• http://www.public-cio.com/story.php?
id=2007.02.02-103751
• State-based among health agencies (NY),
presenting a SSO to citizens (Washington),
etc.
• GSA EAuthentication
• NSF, NIH, and the Dept of Ed…
• State university federations - Texas,
California, Maryland, etc
• InCommon
UTexas Federation Apps
• Legal Tracking (OGC)
• Parking Management (APS)
• Project Tracking (CHA) • Signature Authority (APS)
• Monthly Financial Reporting (BUD) • Bid Specification (OFPC)
• TIXX (GOV) • Project Time Reporting (OFPC)
• UT Plane (ADM) • Student Couponing (UT Austin)
• Compliance Training (ADM) • Online Education via Blackboard
• Research Projects Tracking (ACA) (UTHSCH)
• Academic Affairs Jobs (ACA) • Board of Regents Agenda (BOR)
12/06
• Degree Programs (ACA)
• Budget Change Request (BUD)
• Grad Registration (ACA) 12/06
• System Administration Wireless • UTANOP (BUD) 12/06
(OTIS)
InCommon
• US R&E Federation
• www.incommon.org
• Members join a 501(c)3
• Addresses legal, LOA, shared attributes,
business proposition, etc issues
• Approximately 50 members and growing
• A low percentage of national Shib use…
InCommon Members 2/27/07
• Case Western Reserve University • University of Maryland
• Clemson University • University of Maryland Baltimore County
• Cornell University • University of Maryland, Baltimore
• Dartmouth • University of Rochester
• Duke University • University of Southern California
• Florida State University • University of Virginia
• Georgetown University • University of Washington
• Miami University • University of Wisconsin - Madison
• New York University • Cdigix
• Ohio University • EBSCO Publishing
• Penn State • Elsevier ScienceDirect
• Stanford University • Houston Academy of Medicine - Texas Medical Center
• Stony Brook University Library
• SUNY Buffalo • Internet2
• The Ohio State University • JSTOR
• The University of Chicago • Napster, LLC
• University of Alabama at Birmingham • OCLC
• University of California, Irvine • OhioLink - The Ohio Library & Information Network
• University of California, Los Angeles • ProtectNetwork
• University of California, Merced • Symplicity Corporation
• University of California, Office of the President • Thomson Learning, Inc.
• University of California, Riverside • Turnitin
• University of California, San Diego • WebAssign
Key aspects of InCommon
• Federating software
• Shib 1.2+ (other possibilities in the future)
• Shared attributes and schema
• eduPerson right now
• Levels of authentication
• POP (participant operational practices)
• InCommon Bronze and Silver will map to LOA 1 & 2
• Management
• Steering committee of members IT executives
• Operations staffed by Internet2
Shibboleth
• Shib 1.3 widely deployed; 1.2 still common
• Along the way, other capabilities added:
• ADFS compatibility for WS-Fed, (MS $)
• Eauthentication certification (with waiver form:))
• Shib 2.0 completes the SAML+Shib integration
• More compatible with COTS SAML 2.0 products than they
are with each other
• A Shib/SAML to TCP/IP analogy isn’t bad; Shib adds multi-
party federation support through metadata, ARPS, etc.
• Also eases support for n-tier, non-web and other
capabilities
• Alpha in April
The Shibboleth 2.0 Sidebar
• Support for the attribute ecosystem
• attribute handling, including policy, in both SP and IdP
• designed to be reusable for other protocols (eg CardSpace)
• sets stage for further work on multiple attribute sources,
reputation management, etc.
• All Java SP (in addition to current Java/Apache), easing
integration for some applications
• Trust management
• PKI still seems too hard, even at the simpler enterprise level
• Supports a broad set of trust choices – CA’s, certs, plain
keys, managing site metadata (naming, acquisition,
validating)
• A product of years of painful experience
InCommon Management/Governance
• Steering Committee of campus/vendor
CIO’s and policy people – sets policies for
membership, business model, etc.
• Technical advisory committee - Sets
common member standards for attributes
(eduPerson 2.0) , identity management
good practices, etc.
InCommon Uses
• Access control to content
• Popular content – Ruckus, CDigix, etc
• Scholarly content – Google, OCLC WorldCat
• Downloads – Microsoft
• Access to external services
• Student travel, charitable giving, web learning and testing,
plagiarism testing service, etc.
• Allure for alumni services and other internal businesses
• Student loans, student testing, graduate school admissions,
etc.
• Access to national services
• The National Science Digital Library
• The Teragrid pilot
Inter-federation key issues
• Peering, peering, peering
• At what size of the globe?
• Confederation, overlapping, leveraged
• Tightly coupled autonomous federations
• How do vertical sectors relate? How to relate to a government
federation?
• On what policy issues to peer and how?
• Legal framework
• Treaties? Indemnification? Adjudication
• How to technically implement
• Wide variety of scale issues
• WAYF functionality
• Virtual organization support
Peering
Parameters:
•LOA
•Attribute mapping
•Legal structures
• Liability
• Adjudication
•Metadata
•VO Support
•Economics
•Privacy
Privacy
• There is a document within the UK
Federation specifically on this issue:
• http://www.ukfederation.org.uk/library/uplo
ads/Documents/recommendations-for-
use-of-personal-data.pdf.
• This document is all recommendations
and theguidelines laid out do not have to
be followed, the only requirement is
thatthe 8 principles of the UK Data
Protection Act (1998) are met.
The Eight Principles
1. Personal data shall be processed fairly and lawfully;
2. Personal data shall be obtained only for one or more specified and lawful
purposes, and shall not be further processed in any manner incompatible
with that purpose or those purposes;
3. Personal data shall be adequate, relevant and not excessive in relation to the
purpose or purposes for which they are processed;
4. Personal data shall be accurate and, where necessary, kept up to date;
5. Personal data processed for any purpose or purposes shall not be kept for
longer than is necessary for that purpose or those purposes;
6. Personal data shall be processed in accordance with the rights of data
subjects under this Act;
7. Appropriate technical and organisational measures shall be taken against
unauthorised or unlawful processing of personal data and against
accidental loss or destruction of, or damage to, personal data;
8. Personal data shall not be transferred to a country or territory outside the
European Economic Area unless that country or territory ensures an
adequate level of protection for the rights and freedoms of data subjects
in relation to the processing of personal data.