Project Status Report for theAndrew W. Mellon Foundation:

Dartmouth College PKI Lab - Phase OneMay 18, 2023

1

AbstractThis report summarizes Mellon Foundation Phase 1 work to date by the PKI Lab at Dartmouth College, describes the Lab’s vision, and presents plans for Phase 2. The “Work to Date” and “Phase 2 Plans” sections each present activities for:

Deployment Research User Studies, and Outreach

The report shows how the four complement and interact with each other and promote the PKI Lab’s vision and plans. Finally, it presents staffing and budget plans for Phase 2.

Table of ContentsAbstract........................................................................................................................................2Table of Contents.........................................................................................................................2

1 Introduction..............................................................................................................................41.1 Summary..........................................................................................................................41.2 Vision...............................................................................................................................5

2 Work to Date............................................................................................................................72.1 Deployment Team...........................................................................................................7

2.1.1 Production PKI Installation.....................................................................................82.1.2 Academic Applications..........................................................................................102.1.3 Development Expertise..........................................................................................13

2.2 Research Team...............................................................................................................142.2.1 Vulnerability Analysis and Application Migration...............................................142.2.2 Trusted Third-Party Infrastructure.........................................................................152.2.3 PKI-Enhanced List Server.....................................................................................182.2.4 Privacy Studies......................................................................................................182.2.5 Other Projects........................................................................................................192.2.6 Leveraged Funding................................................................................................21

2.3 User Studies...................................................................................................................222.3.1 Understanding User Behavior................................................................................222.3.2 Evaluate Secure Applications: User Study............................................................232.3.3 Findings: Computer Use and Security Knowledge...............................................24

2.4 Outreach.........................................................................................................................242.4.1 Papers and Presentations........................................................................................252.4.2 External Partners....................................................................................................27

2.5 Conclusions....................................................................................................................29

3 Phase 2 Plans.........................................................................................................................333.1 Phase 2 Vision...............................................................................................................33

3.1.1 Integration..............................................................................................................343.1.2 Phase 2 Themes.....................................................................................................34

3.2 Deployment Team Plan Phase 2....................................................................................353.2.1 Production Knowledge..........................................................................................353.2.2 Local Deployment.................................................................................................363.2.3 National Deployment.............................................................................................37

2

3.3 Research Plan Phase 2...................................................................................................373.3.1 S/MIME.................................................................................................................373.3.2 Wireless.................................................................................................................373.3.3 Trusted Paths.........................................................................................................383.3.4 Human-Computer Interaction................................................................................383.3.5 Calculus for Trust Judgment..................................................................................383.3.6 Formal Methods.....................................................................................................393.3.7 Privacy...................................................................................................................393.3.8 Trusted Hardware..................................................................................................403.3.9 Trusted Third Party Infrastructure.........................................................................40

3.4 User Studies...................................................................................................................423.4.1 Understanding User Security Behavior.................................................................423.4.2 JSTOR Pilot Evaluation.........................................................................................423.4.3 Understanding Users’ Conceptual Models of Security.........................................423.4.4 Estimating the Scale and Scope of Security Risk from Users in Higher Education

433.5 Outreach Plan Phase 2...................................................................................................43

3.5.1 Web Reference Information..................................................................................433.5.2 Seminars and Webinars.........................................................................................443.5.3 Public Relations (press and analysts)....................................................................443.5.4 Tools and Infrastructure Development..................................................................443.5.5 HEBCA..................................................................................................................453.5.6 Partnership Deployment Projects with Remote Campuses...................................453.5.7 External Partnerships and Vendor Influence.........................................................46

3.6 Conclusion.....................................................................................................................47

4 Budget....................................................................................................................................48

3

1 Introduction

1.1 SummaryDartmouth has been participating since 1999 in a variety of Higher Education PKI development projects, including the Early Harvest and Early Adopters projects. Dartmouth was selected as one of the two PKI Labs established by Internet2 in response to a RFP in 2000 and has worked with the second PKI Lab at the University of Wisconsin. In November 2001, the Dartmouth team submitted a successful proposal to the Mellon Foundation to support an expansion of the PKI Lab efforts.

The expanded project began in January 2002. Our original Mellon Foundation proposal began “Dartmouth College proposes to develop and deploy an end-to-end public key infrastructure (PKI) for its academic user base, that overcomes the obstacles that to date have prevented PKI from taking root, and that is easily reproducible by other universities. We want to make PKI finally ‘happen,’ and to transform academic computing.” A little more than a year later, we are well toward accomplishing our goal. This grant has allowed us to become involved in projects and activities that go beyond and could not have been specifically anticipated by the original proposal. Accordingly, what we describe in the “Phase Two” section of this report is part of a larger vision for PKI activities at Dartmouth College and for all of Higher Education.

The PKI Lab unites faculty and students (graduate and undergraduate) from Dartmouth’s Computer Science Department together with staff from the central IT organization (Peter Kiewit Computing Services). The PKI Lab also collaborates with faculty from Dartmouth’s Thayer School of Engineering and the Institute for Security and Technology Studies located at Dartmouth College. The grant from the Mellon Foundation has enabled the PKI Lab to gain national prominence among other projects and workers in this field.

The Dartmouth Mellon PKI project is addressing the issues that have slowed the adoption and use of PKI technology and applications in academic environments. The original project proposal described needs in Higher Education that PKI technology could solve. It described known problems with this technology and laid out research efforts to address them. It proposed sociological studies of actual user perceptions and behavior to investigate user behaviors. The project rapidly established integrated research and deployment teams with strong skills, and we have made excellent progress.

The deployment team built and operates a production quality PKI at Dartmouth College. As part of the developing production infrastructure, the deployment team has worked as well to develop compelling PKI enabled applications, in the process developing documentation, conducting pilot tests with end users and working with campus computer support personnel to provide a production quality infrastructure that serves as a beginning and growing base for PKI deployment at Dartmouth and at other institutions.

The research team continues to investigate a variety of PKI issues and to test fundamental assumptions. In addition, the research team’s analysis of the products and applications in use or developed by the deployment team discovered and documented unanticipated security issues.

4

Both of these areas of research have generated a number of refereed papers and have yielded several software components and applications that provide possible solutions.

1.2 Vision The need for improved cyber security is apparent. The number and efficiency of computer viruses increase at a ferocious pace, and the havoc they can wreak now includes broadcasting archived email and providing illicit remote control of the infected computer. Hacker attacks on the Internet are rampant, and are now even part of protests and international hostilities. These attacks cost billions of dollars in damage, and lost productivity and lost revenues. Email spam is so prevalent that it is inspiring legislation in attempts to curb it. Identity theft is the fastest growing white collar crime in the United States. Horror stories abound. As our society becomes more and more reliant on electronic communications and networked services, the ramifications of these security exposures become more severe for the “masses”. It is clearly time for greater security in our computing infrastructure.

PKI offers by far the most comprehensive and widely available infrastructure to address these problems. Through its foundations in asymmetric cryptography, PKI is uniquely suited to problem domains (such as higher education) where many different organizations, with distinct administrative boundaries, must interact and share information services. It is a fundamental improvement to the computing infrastructure in a systematic way to address crucial issues of:

Authentication

Digital signing

Data encryption

Point solutions exist for each category, but PKI is the only standards-based solution that coherently addresses them all well with broad support from vendors and other solutions providers. Robust services, commercial tools, and freely available tools provide a sound foundation for the infrastructure. Applications such as browsers, email readers, web servers, web services, email list servers, database servers, PDF readers, VPN appliances, WPA wireless authentication, USB keys, smart cards, and many others all have integrated PKI support. Because PKI is standards-based, these all (at least in principle) interoperate with each other. PKI attribute certificates show strong promise for implementing critical authorization services. PKI enables end-to-end security (in particular, securing both clients and servers and not just the pipe between them). Inherently secure servers are a necessary ingredient to allow e-business to evolve to the next level. An industry-wide foundation is in place for widespread deployment of PKI with significant applications already available, and the stage is set for more applications to follow so that PKI can become an all-encompassing solution for HEIs’ needs for improved security. PKI is well-tested in the research and development labs and now in trial and early deployments.

PKI has to date proven relatively difficult to deploy. This is due to its ambitious and general purpose definition, the breadth of its scope, the complexity of its technology, and difficulties with standards-based approach interoperability. Improvements in PKI tools and applications combined with increasingly urgent need for greater security are simultaneously lowering the barrier to entry and raising the motivation for organizations to enter the realm of deployed PKI.

5

Dartmouth sees the outstanding potential of PKI once it gathers critical mass on the deployment side. We plan massive deployment of PKI internally and seek to help others deploy it extensively at their own institutions.

This work will likely be as much organizational as technical.

Dartmouth’s vision for PKI adoption takes an incremental and evolutionary approach: Develop PKI infrastructure (we have accomplished the first round of this). Start small with simple and well-contained PKI applications (we need to prime the

pump). Make incremental additions and improvements to these applications over time. First add new capabilities for users (for example, the ability to authenticate to services

from off-campus or the ability to digitally sign documents). Save replacing with PKI “the old way” on existing applications until later stages. In the long run, PKI provides a comprehensive solution for all campus mainstream

authentication, signing, and encryption needs. Assist other early adopters:

o Provide both general PKI education and specific “how to” documentation.o Be opportunistic.o Help with applications that matter to them.

Dartmouth College intends to become a recognized leader in securely using computing technology in support of education, research, and administration, and PKI is an important component of our strategy. This goal starts with foundations in computer network security, secure systems, and applied cryptography. Areas of specialization include:

developing enhanced security features for software products and computer systems,

testing and vulnerability analysis of security features in software products,

implementation practices for production environments supporting production applications,

architectures and applications for secure coprocessors, and

infrastructure for trustable systems.

An overarching goal is the continued development of a laboratory to support and further develop these activities at Dartmouth and at other institutions. This direction integrates a number of activities including the Internet2-sponsored PKI Lab, this Dartmouth-Mellon PKI project, I2 Middleware efforts in general, research work supported by NSF and the US Department of Justice, as well as key participation in the EDUCAUSE-sponsored HEBCA BID. In addition, Dartmouth actively participates in OKI and is among the CSG schools investigating the Chandler project. Dartmouth is working to further expand the activities of and develop additional and self-sustaining resources for this laboratory, which will help integrate existing and originate future projects in this area.

6

2 Work to DateSection 1 of our proposal to the Mellon Foundation states four main goals. We sought to develop and deploy a PKI that:

1. "overcomes the limitations that hamper deployment of low-assurance PKI in academia",2. "lays a foundation for developing innovative new approaches to address the security,

privacy, usability, and scalability challenges that hamper the deployment of higher-assurance PKI",

3. "lays a foundation for exploring new directions in protection of intellectual property", and

4. "is easily transferable to other universities".

These goals motivated the team structure of the Lab in our first phase work. The deployment team handled goal 1, assembling a low-assurance production PKI from COTS tools and modifying legacy Dartmouth applications to interoperate with it (see section 2.1). The research/design team undertook goal 2, developing and prototyping architectures for higher-assurance PKI components, and doing vulnerability analyses of current components and tools (see section 2.2.1). Both teams shared goal 3; the development team ported legacy library applications to work with the low-assurance PKI, and the research/design teams worked on alternative authorization PKI/PMI for these applications. Both teams collaborated on goal 4 as well, producing a continuous stream of invited talks and published papers (see section 2.4.1) reporting our results.

Now as we enter into phase 2, we are ready to bring these efforts to fuller fruition. This fall, we anticipate rolling out the low-assurance PKI into a wider pilot, and integrating the more promising of the design/research tools into the production PKI. With the hire of a new staff member devoted to leading our outreach effort, we will now take these results to other universities.

2.1 Deployment TeamThe deployment team assembled Dartmouth’s initial campus PKI installation during the summer of 2002 and used it for application conversion and testing projects during the fall. This work focused on installing a commercial Certificate Authority product as quickly as possible, so application development could proceed. This product appeared to be both economical and usable from the major computing environments. We selected Sun’s commercial iPlanet offering rather than an Open Source alternative based on our judgment that the Open Source alternative’s high labor requirements would be more costly than the low purchase price of iPlanet. In addition, the Sun product is FIPS-validated, a requirement for cross-certification with the Federal Bridge.The deployment team developed during the fall and winter 2002 a second iteration of the PKI services with expanded security features and performance suitable for campus-wide use. This iteration of the design added protection for the Certificate Authority server by utilizing a hardware key module and a firewall since an online design was adopted. We enhanced the server’s reliability by incorporating a disk array and automated backup procedures. The infrastructure became available for production use in February 2003.

7

2.1.1 Production PKI InstallationWe selected the Sun/iPlanet PKI product as the certificate authority component for the Dartmouth PKI project. We started with the iPlanet Certificate Management System version 4.2 as the first instance of a PKI server. It was available for testing and development in June 2002. This proved to be a full-featured PKI with a Registration Authority, Certificate Authority and key escrow and recovery among other features. Source code is available for the entire user interface allowing easy customization of what the user sees. The product also includes excellent and easy-to-use documentation which is rare. The license fee was $1.25 per user but due to discounts for students and staff (fulltime faculty is the only category of users which pays full fare) the cost for about 25,000 users was less than $15,000. This cost was not borne by the Mellon grant.

In April 2003, Sun announced that it was planning to discontinue development of the iPlanet (by then renamed SunONE) Certificate Authority product. Support will continue to be available for three years, a very long time in this field. While this was disappointing news, the Sun product is meeting our current needs and we expect that it will continue to do so within the support timeframe. AOL continues to sell a similar Enterprise Server Certificate Manager product that originated in part from the same code base. The AOL product is a possible upgrade path and provides a similar environment for other institutions interested in duplicating these results.

For our PKI development system we used two inexpensive Sun workstations each running an instance of the iPlanet server software. These served well for initial exploration of the product and then for development and testing of configurations and later for local modifications to the user interface.

For the production PKI service we upgraded the server software to SunONE Certificate Server ver. 4.7 which, despite the name change, is a minor update of our previous iPlanet software. The upgraded software was installed on a server-class computer that had recently been displaced as the campus-wide calendar server. It is a Sun E250 with hot-swappable RAID-5 disks and large memory capacity. The E250 has an attached DLT tape drive for import/export of data, and it is backed up over the network.

The production server uses a Chrysalis Luna CA3 key module to create and hold the Certificate Authority’s private signing key. The Chrysalis key module is a peripheral device attached to the Sun E250 server by a private connection to a PCI card installed in the E250’s back plane. The Certificate Authority’s private key never leaves the Chrysalis unit. Any cryptographic operations that require use of the private key are done by shipping the data to be signed to the Chrysalis unit where the crypto operations are performed, and then the encrypted data goes back to the server. There is a provision to back up the Certificate Authority’s private key on removable media so that operation of the production server could be restored if the Chrysalis unit became inoperable. Two-factor authentication is required to access the encrypted private key on the removable media, so there is reasonable protection of the private key when it is removed from the Chrysalis unit. In future work, we are considering working with the research/design team to port open source CA software onto cheaper and more secure hardware from IBM.

A Cisco PIX 506E firewall protects the production Certificate Authority server. Since users access the Certificate Authority via the web, the firewall allows all http and https traffic to reach the CA server but any other incoming traffic is limited to specific protocols originating on specific computers at Dartmouth.

8

The deployment team documented the architecture and parameters of this installation and will share this documentation as part of our outreach program. The installation combines the RA and CA functions on one server. It uses 2048 bit CA keys with a 10 year expiration date. The installation is purposefully easy to replicate, modify, and operate elsewhere. We also gained invaluable experience about the many problems that can arise when creating a production CA, and will share this experience with others in our outreach program.

Local enrollment extensionsAfter examining the needs of our initial applications, we decided to employ a self-service online registration system for end users of the PKI. This relies on the institutional processes for adding and deleting student and staff accounts in the institutional LDAP directory. Since the web authentication systems we intended to replace with a PKI-based solution rely on the same directory, this is a feasible solution. This solution also does not require additional staff to service a registration process. The SunONE product supports online registration, but we needed to extend the SunONE code to deal with different directory objects. This provisional approach leaves the PKI only as secure as the password-based system it replaced. In Phase 2 work, we plan to explore more robust enrollment schemes.

The extensions developed for the SunONE product are likely to be useful for other institutions and are now available. For example, in the Dartmouth environment, we incorporated the fuzzy name matching functionality of the Dartmouth Name Directory to simplify local use and adoption of this new infrastructure.

Enrollment SystemThe Dartmouth CA uses a Web-based enrollment system to issue certificates over https. The most widely used of the two options for getting a client certificate is the DND Validation enrollment. This web page asks the user for a name and password to be validated against the campus LDAP directory. (At Dartmouth, the LDAP is colloquially known to end users as the Dartmouth Name Directory, or DND) We customized the enrollment code to select the recommended options automatically, for example 1024 bit keys. If the validation succeeds, the browser generates a key pair and stores the private Key, and the CA issues a client certificate.

The second option for getting a client certificate is manual enrollment. This page provides access to a variety of parameters possibly needed for special situations. Certificate requests issued here are manually reviewed and approved by the CA administrators. This page can handle requests for things like Web server certificates, or shorter key lengths and the like at the discretion of the approving administrator. It offers a variety of enrollment options, the most notable of which are Dual Key Escrow, Security Level, and anonymous or temporary enrollment.

Key escrow has been a concern of the support staff, since users losing their keys is to be expected. The dual key option LDAP validation to issue two certificates to the client and allows recovery of the encryption key. One key-pair makes up the authentication certificate, while the second creates an encryption certificate. The CMS uses a transport certificate to securely retrieve and store a copy of the private key of the encryption certificate. This key can then be recovered to the client in the event of a loss of the private key. Key recovery is covered by an M of N security policy set by the CA administrators. This method does not work with IE, but does work with Netscape and Mozilla. A lost signing key will be replaced.

9

Security level enrollment makes use of the Microsoft security level options in a certificate, allowing the user to specify that a password prompt should be given every time the certificate is used. (We note that use of this feature was developed due to interaction with the research/design team.)

Anonymous enrollment uses LDAP validation of a named user to create a certificate that merely identifies the subject as a Dartmouth College certificate holder. Temporary certificates are issued with a 4-hour validity period. These temporary certificates are meant to be used in situations where the client key store is relatively un-trusted or un-securable. As an example, a user might want to log in to a Dartmouth service from an Internet café. The temporary certificate reduces the risk of the user forgetting to delete the key after finishing with it. Any browser that can generate a key pair can use these options.

Dartmouth also uses its enrollment process to publish certificates for users in its LDAP directory. This allows users a way to exchange public keys with reduced vulnerability and inconvenience. Certificates are automatically removed from the directory when they are revoked or expired. Currently, these processes require administrator intervention or the private key used to create the certificate. We are researching a method to revoke and remove a certificate using the same level of authorization that was used to create it.

MobilityThe mobility of a private key has been raised as a principle user concern. Many people use multiple computers and/or applications, and kiosk systems are popular with students. The PKILAB has documented the procedures for exporting and importing keys between different computers or web browsers, and has investigated different options for personal key storage devices. We have identified several possible solutions, but so far none of them work on all major platforms. Some physical form factors such as ID cards are appealing.

We note that supporting mobility of users is one of the driving factors behind the research/design team’s TTP project (see Section 2.2.2).

2.1.2 Academic ApplicationsThe initial applications of the Dartmouth PKI provide personal authentication for web services. The deployment team collaborated with several service providers on campus to develop a number of web authentication applications. Access to Library resources via personal PKI certificates went into production in June. Authentication to Oracle web applications has been demonstrated on the test systems and our Administrative Computing Group is pursuing making this available for production use in August. This update will enable PKI authentication for the student information system and other staff administrative services (see section 3.2.2 for more phase 2 local deployment details).

Web Authentication ReplacementAround 1996, Dartmouth adopted and deployed Kerberos has an authentication mechanism for web based applications. This became a campus standard and is currently in wide use. The changing architecture of the Internet is however preventing its continued operation for an increasing number of users. Firewalls and Network Address Translation (NAT) cause problems for Kerberos users, and client-side X.509 PKI (e.g., client-side SSL) is providing a workable

10

alternative solution. Instead of the old Kerberos KClient and Sidecar software, appropriate Web browsers with personal certificates from the Dartmouth PKI provide similar functionality. A PKI-based solution has the additional advantages of being usable on Microsoft, Apple and UNIX machines without additional software installations.

The PKI Lab team worked with the various application groups at Dartmouth to extend their applications to also support authentication using personal PKI certificates. Applications have been converted in the Library, Research Computing, Administrative Computing and the Tuck Business School. Details of specific applications are provided in the next section.

Because PKI certificates have other uses, the mobility and time scale issues are different than the Kerberos solution. This has led to the development of alternate certificate profiles to allow the use of PKI instead of Kerberos in the special cases of working on computers the user doesn’t own, library use by guests, and protecting the identity of database users. Temporary, guest, and anonymous certificates address these needs.

In conjunction with the deployment team’s work to utilize client-side SSL, the research/design team critically examined the effectiveness of this technique (see Section 2.2.1).

Web Authentication ExamplesDartmouth Web SitesThe Dartmouth College development Web server can now use client certificates. Currently, the PKI Lab web site uses client certificate authentication to control access to the download area for software that is not available to the general public. Information on how to configure similar use for other Web sites is published on the PKI Lab Web site.

Library SystemsThe Library currently makes extensive use of the KClient/Sidecar infrastructure for access control to any local or vendor supplied web based data resources that could be made compatible with it. It is also used to authenticate to the Library proxy server. Off-campus library users have been significantly affected by the KClient/Sidecar network issues. In response, the Library systems staff worked with the deployment team to augment their access control procedures to allow use of personal PKI certificates for authentication to these resources.

We added logic to library applications can to check for the presence of certain environment variables set by the web server to indicate that the SSL (https) connection is certificate authenticated. These variables also identify the user (or at least indicate that the user is anonymous) to the application.

Oracle/Banner ApplicationsDartmouth’s Oracle IAS web servers were can now optionally request client side SSL connections which prompt the user for a personal certificate. A CUSSP authentication bottleneck already in place for KClient/Sidecar authentication now first checks for the SSL environment variables. If they are present, then the user was already authenticated with PKI and the authentication logic skips using Kerberos. The SSL environment variables provide the user’s identity as needed for authorization. TuckStreams, the business school’s intranet system, and Banner, the student records database are both example applications making use of this type of PKI authentication. Both allow access using a certificate without any modifications to the database application.

11

Secure MailSecure mail is one of the next major application areas of the campus PKI. We tested S/MIME features of currently available e-mail clients for interoperability with the SunONE PKI and each other. We wrote and published setup and usage tips. Currently, users are generally reluctant to switch e-mail clients to gain access to S/MIME features. As another possible solution we are developing add-in code to enable levels of compatibility with other, more popular, mail clients to foster the adoption of S/MIME mail, and we are exploring the possibility of an S/MIME plug-in to add this functionality to existing clients. The deployment team developed sample code using Open SSL for the signing, verification, encryption and decryption functions. We also developed sample code making using of the NSS library in order to use keys saved in the Netscape/Mozilla key store. A Key store component is an important consideration.

An additional technique we are investigating would make use of additional servers to provide add-on S/MIME capabilities. This “mail” server would, for example, check the signatures attached to incoming mail and add MIME parts to the message that report the status of the signature to the end user via a mail client that is not S/MIME-aware. The research/design team has been exploring this idea further, including incorporation with secure hardware (see section 2.2.2).

LDAP IntegrationThe PKI publishes certificates into the campus wide LDAP directory. This supports integration into the address book features of some mail clients, which will retrieve certificates needed to encrypt a message when the address list is specified.

S/MIME List ServersWhile researching methods to add PKI support into a mailing list manager we discovered that an existing product, Sympa <http://www.sympa.org> already has the required functionality. Sympa has the ability to understand S/MIME signed and encrypted messages, and is extremely flexible in how it deals with signed messages. It can require a person posting to a list to have a valid digital signature. This would keep unexpected or unwanted (SPAM) messages from ever reaching the list. Requiring valid signatures will also keep spoofed messages (user A pretending to be user B) from reaching the list. Administrators can use signed messages to control the list server, eliminating any possibility for a user to spoof an admin account.

Sympa has the unique ability to receive a message encrypted to the list, and re-encrypt it for each recipient. Sympa takes advantage of client certificates in the web browser. When a user visits the list administration web page, they are automatically authenticated using their Client Certificate. This prevents any sort of password sniffing or cookie stealing attack.

A Sympa list server installation is available for production applications at Dartmouth, and we are working to inform potential users of its benefits. Switching mailing list software does require some reconfiguration and training however to gain access to S/MIME features.

Digital Signature ApplicationsDigital Signatures on campus forms and applications for external services are another primary application area. The PKI Lab participated in the NIH-HEBCA grant application pilot project.

12

As a result, the Dartmouth PKI is cross-certified with the prototype HEBCA, and the campus LDAP directory links into the Bridge’s directory of directories.

We installed signing software from E-Lock and integrated it with the PKI. Two different staff members representing the principal investigator and campus grant officer filled out and then signed a sample Microsoft Word formatted grant application.

On campus, most blank forms are now saved as PDF formatted documents and distributed on a public file server. The deployment team is designing an electronic signature process to make use of these. This would replace the current practice of printing forms, filling them out by hand, and signing the paper copies. We have begun investigating the PKI compatibility of Acrobat software.

Other applications for digitally signed office documents of various types are apparent. For example, Microsoft Excel formatted spreadsheets are used for travel expense reports. The XP version of Office includes digital signature capabilities. Third party add-in software is also available for previous versions.

Given the interest in and importance of this application, the research/design team critically examined the effectiveness of the current COTS tools (see section 2.2.1).

Wireless Authentication We are starting investigations of wireless network authentication as enabled by a PKI. This application is of great interest at Dartmouth and many other academic and industrial institutions. Wireless authentication now includes a standard based on TLS---using X509 certificates and proof-of-possession. We will identify the certificate profile for TLS test it with current products. The Windows XP operating system supports this feature. Dartmouth is participating in a beta test of a similar feature with another vendor.

In conjunction with research into applications based on Dartmouth’s campus-wide wireless network being conducted at the Computer Science department, we have developed some contacts at Intel and Cisco. The lack of security solutions for wireless networks is significantly constraining wireless plans at many institutions, and so is seen as a severe market entry barrier by vendors like Cisco and Intel. In particular joint work at Dartmouth may be focused on developing a method to provide controlled guest access in a PKI authenticated network (see section 3.3.2).

2.1.3 Development Expertise

CA SoftwareThe PKI Lab team has first hand experience now with Entrust, Sun, Baltimore and Windows CA software. This will be useful when assisting other institutions with their PKI designs. Experience with the Netscape and RSA products would similarly be desirable. The Lab plans to become more familiar with the current Open Source projects for this same reason. In order to use open source CAs in some applications it may be necessary to address the issue of FIPS conformance, particularly for Bridge usage. (We note that the leader of research/design team, Prof Smith, has led six successful validation efforts for the highest two levels of FIPS140 security, including the first-ever at the highest level.)

13

Tool DevelopmentDeveloping new PKI based applications is complicated by the fact that there are many different supporting libraries available. They vary widely in terms of their functionality, the documentation available, ease of installation and use and platform support.

One tool we created is a cross platform certificate browser written in Java. It is able to retrieve certificates from an LDAP directory, which is a unique feature. This was useful while testing the PKI installation and directory integration. It is also useful for client testing on platforms that do not have a certificate viewer application built-in and for examining certificate extensions. We are using some of this code to develop a certificate editor for maintenance of LDAP directory entries.

2.2 Research TeamDartmouth’s PKI research team rapidly developed a strong reputation for “poking holes” in many disparate applications and security solutions. Distinguished attendees of security conferences have reported that the team is making them lose sleep at night worrying about the vulnerabilities it has brought to light. The research and development team has also made significant progress devising solutions to a number of these vulnerabilities.

2.2.1 Vulnerability Analysis and Application MigrationIn the initial proposal, we considered doing a vulnerability analysis of the paradigm of browser-based key stores. We extended this work to examine other issues that arose in the deployment track. Namely:

using SSL client-side authentication to replace passwords and other forms of user authentication for Web-based information services, and

using COTS tools to sign and verify digital signatures on electronic documents and email.

(Both of these applications were discussed in section 2.1.2 above.)

Unfortunately, our work to find vulnerabilities was successful.

We were able to demonstrate various ways that a malicious server M could, via legal but devious frameset and Javascript tricks, trick a browser A to issue requests---including both POST and GET form responses---to an arbitrary server S. In many standard configurations, if S requires client-side SSL authentication, the browser will happily use the user's personal private key for this request of which the user was neither aware nor approved. Ironically, many password-based services will become less secure if naively migrated to client-side SSL.

We were able to demonstrate numerous ways to extract private keys from standard browser key stores. In particular, we devised some new attacks to extract "medium security" and "high security" keys from IE (which previously had been regarded as secure), using only a single executable running at user privilege. One lesson of this work: the security of current public-key cryptography is woefully mismatched with the current de facto standards for desktop computing which lag far behind.

14

Looking at standard off-the-shelf digital signature tools and workflow formats, we were able to demonstrate numerous ways that a party can produce documents whose apparent contents can change in usefully malicious ways without invalidating (or, in some cases, appearing to invalidate) the digital signature. For example:

Students can submit homework in Word; a trusted authority adds a timestamp and signs it; the professor posts his solutions; and when the professor examines the homework, the timestamp will still be valid but the document will show the professor's own solutions.

Faculty can submit their expenses in a spreadsheet; the department chair will see small numbers and sign it; then accounting will see large numbers but a valid signature from the chair.

Our attacks on browser-based key stores and on SSL client-side are documented in the Marchesini-Smith-Zhao paper, which we presented at the 2nd Annual PKI Research Workshop. (Tim Polk of NIST has repeatedly said that these results have made him lose sleep.) Additionally, we have documented a short-term defense against the client-side authentication weaknesses.

We documented our attacks on digital signatures are in the Kain-Smith-Asokan paper, presented at the IFIP Security conference in Europe. We notified both Lexign (when they owned Assured Office) as well as NIH (who were using Assured Office in their PKI pilots).

We note that this work nicely demonstrated the interaction between the Design and Deployment teams in the lab: the deployment team worked with us on generating various X509-certified key pairs for our browsers, and are planning to integrate our short-term defense in their Web applications. Our signature-hacking work also started with the deployment team's survey of best-of-breed signature packages.

2.2.2 Trusted Third-Party InfrastructureAs the vulnerability analysis above showed, browser-based key stores are not a particularly good place to keep private keys, and simply providing a key service (without regard to the context in which the key is being used) can introduce serious risks. Furthermore, both issues become compounded if users are mobile. (Recall the discussion in section 2.1.1 above.)

It was in anticipation of these reasons that we originally proposed the Trusted Third Party (TTP) project.

AXISThe Alliance of Extensible Independent Servers is the current working name of for the TTP project: using a network of trustable hardware devices as a back-end for both user private keys as well as other sensitive elements. The AXIS component is the package that lives on these platforms and permits these sensitive components to migrate between platforms and work with each other.

Work on the TTP project has proceeded on several fronts.

A team led by Alex Iliev and John Marchesini designed an architecture for the AXIS platform, and coded a prototype (running on an exposed desktop Linux platform). In Fall 2002, they

15

demonstrated the basic framework and a simple application consisting of applying a user's RSA key to encipher/decipher some text.

Front-end - Alex built a number of servlets that handle some session management via short-lived user certificates and passwords. There are also servlets that issue requests to the AXIS dispatcher (i.e. the Back End) for processing, and handle the replies.

Back-end - John built the CORBA-based dispatching system, as well as some proof of concept application handlers, keys, and UI handlers.

Moose/MouseThe TTP prototype needs trusted hardware on which to run. Our undergrad intern team, with the help of IBM Watson, ported Linux onto the IBM4758 platform (to increase code portability and implementation flexibility). The small memory size of the coprocessor has been a continuing problem; however, the team has now managed to shrink a Java virtual machine and get that running inside, and is now working on the CORBA ORB.

(We initially nicknamed this hardened Linux platform “Moose,” because of the armor on the 4758. However, given the continuing challenge of the small size, we’ve renamed it “Mouse”.)

BearFor an alternative platform, Rich MacDonald has been exploring TCPA.

TCPA is an alliance and a specification for adding a small, smart-card-like Trusted Platform Module to standard computing equipment, and using this as a foundation for secure credential store.

We've been looking at TCPA for several reasons:

It's an interesting, timely topic.

Unlike Palladium, we can actually get a specification and machine.

Mellon wanted a non-4758 platform for AXIS; and a general problem with 4758s is that they are small. Can we use a TCPA platform as an alternative?

Furthermore, the current commercial support is all based on Windows. Can we do something else?

We have examined the available high-assurance UNIX variants (NSA SE Linux, HP Trusted Linux, NPS hardened OpenBSD), but rejected them for our initial prototype, due to time constraints.

Rich installed Red Hat on a TCPA box, and has been developing an open-source Linux library that will allow Linux-based desktop applications to exploit the physical security provided by the TPM (in a sense, providing a higher-performance, but lower-security "big brother" to the Linux/4758 platform.)

We are about ready to move the AXIS prototype on to this platform---nicknamed “Bear”---as well.

16

Authenticating Via Un-trusted ClientsTwo ongoing senior thesis projects also relate to the TTP project.

How can a trusted server authenticate human users via an un-trusted client machine?

Dan Kang (with some additional advice from Prof. Hany Farid) is investigating one approach.

Humans are bad at doing cryptography but good at speaking. If the trusted server authenticates humans by asking them to speak a fixed phrase, then a malicious client can record and repeat that. If we ask them to speak a random phrase, then a malicious client might record sufficient phonetic elements to splice together a virtual recording of that user saying that phrase.

However, Hany Farid's statistical analysis tools have proven successful at distinguishing between natural speech and such spliced speech.

Can we put this all together, and make a human-friendly authentication system that can distinguish in real time between a particular human and a spliced/synthesized recording inserted by a malicious client machine?

In summer of 2002, Dan selected and installed a “best-of-breed” speech and speaker recognition package. By the end of 2002, he was able to fool it with spliced speech. Currently, he is implementing Prof. Farid's analysis tools.

Hardened S/MIME Gateways and ServersSome argue that S/MIME will be the "killer app" for academic PKI. (E.g., recall the discussion in section 2.1.2 above.) Integrating PKI with Web-based mailers creates interesting challenges. Where should the private key live? How are we going to get a multi-platform mail client that uses S/MIME? How are we going to get anyone to switch to that client? (Everyone loves what they're using now.) How are we going roll AXIS into a larger, practical pilot?

In the summer of 2001, we began considering using secure coprocessors to bring security and PKI to Web-based mail. In the fall of 2002, this idea expanded to using a hardened S/MIME gateway---eventually, as a pilot for AXIS.

This approach has several advantages:

We don't change the client. Rather, we change the mail server to which the client points. (We are targeting institutions, after all!)

The server speaks ordinary mail to the legacy client. But it speaks S/MIME to the outside world.

The user manages these transformations via an auxiliary S/MIME management client, which we do via https (so all the platforms we care about already have the client software!)

The server uses AXIS to do the private key operations and appropriate sensitive computation.

Mindy Pereira has been exploring these ideas for her senior honors thesis: concurrently working out use cases and design, as well as porting the right portions of the open-source Getronics S/MIME library onto the Linux/4758 platform.

Work is continuing in many aspects here.

17

2.2.3 PKI-Enhanced List ServerThe proposal listed work on a PKI-enhanced list server as a research project; subsequent exploration of the Sympa tool (discussed in section 2.1.2 above) suggested an additional research and design effort was not necessary.

2.2.4 Privacy StudiesIn addition to preparing studies on human users' attitudes toward privacy (see Section 2.3 below), we have been exploring privacy vulnerabilities in the emerging technological infrastructure---as well as building countermeasures. (In the current environment, academia is perhaps the last bastion of socially responsible computing.)

Rights Management for Big Brother’s ComputerStarting with his senior thesis work and continuing into the beginning of 2002, Alex Iliev worked on using high-end COTS secure coprocessors to ensure that archivers of network traffic followed their announced policy (we called this "Rights Management for Big Brother's Computer"). This work was published in the 2nd Privacy-Enhancing Technology conference, and received wider press coverage in Wired and Spiegel.

Private Credential ServersIn his transition from IBM to Dartmouth, Prof Smith worked on using secure hardware for "practical private information retrieval": so a user can open an SSL session to server, request a record, and receive that record---but the server learns nothing about what record was requested. Dmitri Asonov in Berlin followed up on this work with an improved algorithm.

Alex and Sean then noticed that in our current academic infrastructure work, we were creating two significant new privacy problems:

centralized X509 certificate directories would permit unscrupulous server operators to monitor who was sending encrypted email to whom, and

institutional attribute authorities in Shibboleth would permit a user's home institution to learn the resource providers with whom he or she was working (of particular concern for a system that prides itself on privacy).

Both problems could be solved with practical private information retrieval. So, Alex began extending Asonov's algorithm and prototyping for an X509 certificate directory at Dartmouth. We learned that, in practice, Asonov's O(N2) shuffling step would be a show-stopper, so we used permutation networks to build an O(N log N) one instead. We published this work at the 2nd Annual PKI Research Workshop; it looks like, with two 4758s and 8K certificates, we can service one certificate request every three seconds. Alex is finishing the code; we plan to work with the deployment team to integrate this into a real directory pilot later this year.

Web AnonymizersIn another topic related to privacy, new PhD student Anna Shubina is studying the privacy provided by existing proxy-based Web anonymizers. She found these anonymizers were vulnerable to traffic analysis; and speculated that a proxy which regularly crawled the Web and

18

archived content would provide better anonymity. To prove this concept, she coded an anonymizer which lets the user browse the Web via the Google cache. Prof Smith presented this work in progress at the 2nd Annual PKI Workshop.

2.2.5 Other Projects

Trusted Paths for Web BrowsersIn her master's thesis, Eileen Ye demonstrated the continuing threat of Web spoofing. If the user cannot correctly perceive the existence of SSL authentication, then what's the point of the SSL PKI?

We then developed, prototyped, and tested our synchronized random dynamic (SRD) boundary countermeasure. We published the paper at Usenix (which only had a 17% acceptance rate!)

Downloads of the prototype are available now for Mozilla/Linux and Mozilla/Windows. Eileen and Denise did a follow-up user study (see section 2.3).

Once we have a trusted path from the browser to the user, the next challenge is to say true and useful things via this trusted path. Consider some motivating examples:

Until recently, if you visited the Palm Store's secure site and checked the certificate, you can confirm that you're talking to Modus Media International, in Lindon, Utah. Is Modus Media authorized to act for Palm? How does the user know?

If server operator uses our WebALPS approach of protecting Web servers against insider attack, how can the client tell?

In these and many other scenarios, for the client to make an effective trust judgment, we need more than just an SSL connection with a server with some valid certificate: in particular, we also need to know properties other than server identity.

SSH Man-in-the-middleThe SSH protocol, commonly used as the "secure" replacement for telnet, uses the public key of the server to establish a protected channel. However, until the recent release of commercial SSH tools, the only way the client could determine whether the public key belonged to the desired server was to compare it against the key used last time for that server.

This situation created the potential for man-in-the-middle attacks, particularly for users of borrowed client machines.

Yasir Ali, in his Master's thesis, has been looking at enhancing the protocol (and open-source tools) to address this weakness.

Users (or their sysadmins) set up online directories of server public keys. (This could be as simple as a personal service on the user's home page, or as complicated as an enterprise-scale LDAP.)

In addition to entering the name of the desired target machine, the traveling user (who trusts the client, but not the DNS) enters the URL of this service, a userid and a password.

19

The client sends the userid and target machine name to the directory, which responds with the key fingerprint---and an HMAC generated with the user's password.

The client uses the user's password to verify this HMAC.

The client then proceeds with SSH, and uses the key fingerprint to verify what the server sends.

The code is finished, but needs polishing before being released.

WebALPSPKI is about communication of trust across boundaries. Standard SSL PKI communicates trust about a server. Why should you trust a server that has many potential internal security holes? If we move the end of the SSL tunnel from the server into a co-server running inside a secure coprocessor, then we have grounds to trust it.

Shan defended his thesis in June 2001, and we published the paper in December 2001, at the ACM/ACSA Annual Computer Security Applications Conference. In Summer 2001, Sean prototyped the box office application on top of Shan's WebALPS code.

However, in June 2001, Shan left to work at Microsoft, and had no time until fall 2002 to update his code (particularly to reflect updates in Apache and OpenSSL). Dartmouth legal staff is trying to investigate whether he is allowed to touch it now, without Microsoft claiming all rights; the Microsoft lawyers refuse to answer.

SDSI-SPKI Shibboleth, a system for inter-organizational information services (particularly in the academic sector), has many components where cross-organizational authorization information needs to be communicated.

Sidharth, for his master's thesis, is exploring how to integrate SDSI/SPKI into these parts of Shibboleth.

Forward Security and Practical PKIIn a forward secure cryptosystem, compromise of current secrets does not compromise the semantic security of previous uses of secrets. E.g., even if the adversary learns my private key today, my signatures from last month are still meaningful.

Strongly forward secure cryptosystems extend the protection the other way as well: learning my private key today does not permit the adversary to forge my signatures next month.

PhD student Zhengyi Le has been exploring the state of the art in such cryptosystems, and is exploring integration in current PKI.

RevocationOur NSF proposal suggested building a survivable trusted third party using trusted hardware and peer-to-peer. As a potential PKI application of such a system, Gabe Vanrenen (in his senior honors thesis) has been looking at extending the Boneh-Tsudik SEM architecture for instant key

20

pair revocation to use these P2P-connected platforms to allow key mobility as well as tolerance of compromised platforms.

Fair Use in ShibbolethSanket Agrawal spent much time examining information flows and roles in organizations. He has now moved to the Master's program, and is completing his thesis looking at an open issue: how to effectively integrate fair use and DRM within Shibboleth.

Trust Path ArchitecturesHow do you connect CAs? What does a trust path mean, anyway? John Marchesini started with his virtual hierarchies work, but has been looking at a number of new directions here. John published the virtual hierarchies paper (and also gave it as PKI Lunch talk), is considering a spin-off paper on hardened Gnutella, and is looking at some ideas here for a thesis topic.

Efficient Security for BGP PKIThe BGP routing protocol is central to how the Internet works. However, it requires that a router believe what other routers tell it---and what those routers tell it about what other routers told them. Public-key cryptography seems natural to prevent lying and forgery. Kent et al proposed S-BGP, which uses PKI to address some of these issues.

However, these approaches are inefficient. Kent et al have suggested difficult-to-implement optimizations. Meiyuan and Sean developed an easy-to-implement protocol that appears to provide the same cryptographic protections. Working with David Nicol, Meiyuan has done simulations showing that S-BGP is indeed horribly inefficient, and that our new scheme is just as efficient as the difficult S-BGP optimizations.

Real-time anomaly detection in JSTORJSTOR is having a problem where adversaries are stealing material via open proxies. Solving the problem by closing the proxies and moving to stronger authentication was not feasible in the short term. However, it seemed likely that real-time anomaly detection should work---that is, applying machine learning techniques to profile “typical” usage from a particular site, and then automatically sound alarms (and trigger countermeasures, such as slowing access) when usage significantly differs from the standard profile.

Paul Seligman explored these ideas in his senior honors thesis, with additional advice from Prof Jay Aslam, an expert in machine learning.

2.2.6 Leveraged FundingProf Smith received start-up funding from Dartmouth College, and used that to fund equipment and many of the students. Eileen, Rich, and Sidharth also received support from a National Institute of Justice research grant. We have also received an NSF Trusted Computing grant to explore peer-to-peer applications of trusted hardware; that will provide additional leveraged funding.

21

2.3 User StudiesTwo main projects characterize the User Study component of the PKI Research group during year one of the Mellon grant: understanding user behavior, and evaluating secure applications.

2.3.1 Understanding User BehaviorThe first project has focused on determining and understanding user behavior and its implications for security. More specifically this component of the PKI project seeks (1) to determine the extent of “risky” behavior by typical user groups in Higher Education (e.g., undergraduate and graduate students, administrative staff, faculty, etc.), and (2) to identify the factors that affect computer users’ security behavior, including: (a) overall knowledge of security issues, and awareness of methods to decrease exposure and vulnerability; (b) the value placed on protecting private information, and making transactions and exchanges secure; (c) the barriers users’ perceive to taking steps to decrease exposure and vulnerability; and (d) perceptions of the risk of a security breach.

Initially, we sought to identify and compile data from national studies regarding what is already known about user security-related behavior. What we found, in short, is that no one knows very much. There is general information about the extent of particular types of use and transactions. For example, surveys of the national on-line population, estimated to be approximately 66% of adult population in the U.S. (Harris Poll 2002), find that 84% use email, 39% make purchases online, and 18% use online banking (http://www.ntia.doc.gov/ntiahome/dn/html/toc.htm). There is also some detailed information on the issue of privacy. For example, the Markle Foundation’s nationally representative survey (Toward a Framework of Internet Accountability, 2001) found that 54% of the public believes they have fewer protections online compared to off-line, 58% do not trust on-line businesses to regulate their own behavior, and 64% believe the government should develop rules to protect online exchanges.

On issues more closely related to security, there is little information available. Some interesting work has been conducted by the Stanford Persuasive Technology Lab, in conjunction with Consumer Webwatch (http://www.consumerwebwatch.org/news/report3_credibilityresearch/stanfordPTL_abstract.htm). They found that there is some mismatch between what users say they do, and what they actually do. For example, on-line consumers state in surveys that websites’ privacy policies are vital to evaluating credibility; 93% say it is “very important” for e-commerce sites to have a visible statement of how the site will use and protect credit card information (http://www.consumerwebwatch.org/news/1_abstract.htm). During active browsing, however, users rarely look at privacy policies when transacting with websites; only 33% say they always look at a website’s policy on protecting credit card information when transacting with a site. Instead, many users base evaluations of credibility on superficial aspects of websites, such as visual design, layout and text size. This study is worth mentioning because unlike many studies of user attitudes, it measures user behavior, i.e., what users actually evaluate when observing real websites.

Given the lack of general data on user security-behavior, and our desire to understand security issues in the HE community specifically, we have developed an on-line survey to gather data on users’ security knowledge, behavior and attitudes. (See appendix A for the survey questionnaire.) The initial survey of undergraduates will be administered this spring. A survey of staff is expected to be administered this summer, followed by a survey of faculty in the fall. See more

22

details under “Future Plans” (section 3.3.4). Using data from these surveys we expect to not only describe accurately what users do and understand (as well as what they don’t do and don’t understand); we also will begin to more fully articulate the value proposition of PKI in Higher Education.

2.3.2 Evaluate Secure Applications: User StudyThe secure systems and applications developed by the PKI design team, such as the SRD boundary for the Mozilla browser (see section 2.2.5 above), must be understandable and usable by actual users to have an effect on security. The existence of a trusted path from browser to user as is communicated by the SRD boundary, does not guarantee that users will understand what this path tells them. We therefore conducted user studies to evaluate the usability of communicating security information via the SRD boundary.

We conducted a total of nine sessions with 37 undergraduate and graduate student volunteers. Subjects first answered a brief questionnaire regarding demographic characteristics, as well as questions about their typical computer use and general knowledge of computer security. Next, we gave subjects a brief introduction to security information (e.g., what a certificate is and what it does during an SSL session). Then we introduced them to the SRD boundary approach and informed them of the two parameters (brown color and synchronized boundary changes) that would signal a trusted window. Subjects also viewed the original Mozilla user interface, in order to become familiar with the buttons and window appearance.

The scenario for the test sessions was for users to use a web server from to access their email. Before checking email, they must verify that the browser is indeed communicating with the email secure server. Users never actually accessed their email or entered any private information during the test sessions. Instead, they started our modified browser and entered an SSL session with the server.

We asked users to observe the windows for five seconds before they answered a series of questions regarding what they observed of the two parameters in the window boundaries and whether they thought the window was secure (from the trusted source). The entire test took approximately one hour. Subjects volunteered after responding to advertisements about the study in campus buildings. Subjects were paid $10 for their participation.

The 37 subjects included both undergraduate (n=21) and graduate (n=16) students, and ranged in age from 18 to 40, with a mean age of 23. Over half of the subjects were computer science (CS) or engineering majors (n=22), though these subjects performed no differently (based on statistical comparisons) than subjects from other major areas of study. Subjects self-rated their own expertise as internet users on a scale of 1=expert, 2=knowledgeable, 3=inexperienced. Twenty-seven percent rated themselves as an expert, and 73% as knowledgeable. Expert and knowledgeable subjects also did not differ in performance (according to statistical comparisons).

Across the three test sessions, subjects accurately identified the signal of a trusted window 80% of the time, and accurately identified a not-trusted window 87% of the time. Subjects were most successful in accurately identifying a trusted window in method two in which the SRD boundary is displayed in both a pop-up reference window and the pop-up security-warning window. Subjects in method two also accurately identified not-trusted windows.

23

In addition to demonstrating the effectiveness of the SRD display as a mechanism to signal website security information, the user study revealed some information about user behavior in general that has contributed to the goals of our first user project. Below are some of the findings regarding security knowledge and behavior from the participants in the SRD-display tests.

2.3.3 Findings: Computer Use and Security Knowledge 92% of subjects spend at least one hour per day on the web, in addition to email.

97% have purchased products on-line, and nearly all have done so in the last six months.

65% have heard the phrase SSL (all of the experts and half of the knowledgeable users; CS majors more likely than non-CS majors to have heard of SSL).

Half of those who have heard of SSL say they know what SSL means.

When submitting private information on-line:

Only 25% say they always check security features on their browser.

36% sometimes check security features.

39% rarely or never check the security features!

The security features typically checked by those who sometimes or always check:

51% check the URL for https.

70% check the lock icon.

35% check the certificate.

These findings have contributed to our development of the survey questionnaire for user behavior.

We will use these and future findings in our Phase 2 outreach education programs (see 3.5) so that others can benefit from the insights we have gained.

2.4 OutreachThe team has worked on a number of activities to disseminate and share current work, and we are engaged as co-workers on a number of national projects. Dartmouth continues to participate in the Internet2 HEPKI TAG, PAG, S/MIME groups and Shibboleth pilot project. Mr. Brentrup is co-chair of the S/MIME group which worked with a number of institutions to explore using S/MIME. Some of them are developing local PKI installations.

The group has published as much information as possible on the PKI lab web site http://www.dartmouth.edu/~pkilab/, and the work above is documented there. The site makes available:

end user documentation,

24

notes for support staff,

notes for application developers,

research reports, and

papers and slide presentations

There are also links to other useful sites and many PKI vendors.

Members of the lab are participating with the Chandler project, specifically regarding security. A Chandler team member, their acting head of security development, visited Dartmouth 17 March 2003 to discuss security issues, implications for trusted operations between peers, and suggested possible technologies to employ. We are continuing our advisory role directly and through CSG.

2.4.1 Papers and PresentationsPKI Lab members made presentations at the Educause and Internet2 conferences. We presented refereed papers in highly competitive security conferences, and published in the archival proceedings. Prof. Smith chaired the 1st Annual PKI Research Conference; Dartmouth hosts the archival web site at http://www.cs.dartmouth.edu/~pki02/. Prof. Smith also served on the program committee for the 2nd conference to be held in April 2003; he also is guest-editing a special issue of the ACM Transactions on Information and System Security on PKI.

Invited talks: J. Marchesini. “Keyjacking: Risks of the Current Client-side Infrastructure.” 2nd Annual PKI

Research Workshop. Gaithersburg. April 2003.

A. Iliev. “Privacy-Enhanced Credential Services.” 2nd Annual PKI Research Workshop. Gaithersburg. April 2003.

M. Zhao. “Work-in-Progress: Efficient Security for BGP Route Announcements.” 2nd Annual PKI Research Workshop. Gaithersburg. April 2003.

S.W. Smith. “Work-in-Progress: The Happy Fun Anonymizer (still legal in 46 states).” 2nd Annual PKI Research Workshop. Gaithersburg. April 2003.

S.W. Smith. “Effective PKI Requires Effective HCI.” ACM/CHI2003 Workshop on HCI and Security Systems. Fort Lauderdale, April 2003.

S.W. Smith. “Before Palladium: Building and Using Secure Coprocessors in the Real World.” Princeton University, Computer Engineering. March 2003.

R. Brentrup. “Dartmouth PKI Lab.” Fed-Ed Meeting. December 2002.

J. Marchesini. “Virtual Hierarchies: An Architecture for Building and Maintaining Efficient and Resilient Trust Chains.” NORDSEC, Stockholm. November 2002.

S.W. Smith. “Outbound Authentication for Programmable Secure Coprocessors.” European Symposium on Research in Computer Security. Zurich. October 2002.

R. Brentrup. “Developing and Deploying a PKI for Academia.” Educause. Atlanta. October 2002.

25

K. Kain. “Digital Signatures and Electronic Documents: A Cautionary Tale.” IFIP Conference on Communications and Multimedia Security. Slovenia. September 2002.

E. Ye. “Trusted Paths for Browsers.” USENIX Security, San Francisco. August 2002.

R. Brentrup. “Dartmouth College PKI Lab Update.” Net@EDU PKI Summit - Snowmass, Colorado. August 2002.

S.W. Smith. “Toward End-to-End Trust.” Sun Microsystems, Burlington MA, May 2002.

S.W. Smith. “Work-in-Progress: Way Up North.” 1st Annual PKI Research Workshop, Gaithersburg. April 2002.

A. Iliev. “Prototyping an Armored Data Vault: Rights Management on Big Brother's Computer.” PET2002, San Francisco. April 2002.

S.W. Smith. “Missing Pieces in End-to-End Trust.” George Mason University, Fairfax. March 2002.

S.W. Smith. “Information Security.” National Institute of Justice. Arlington, VA. February 2002.

Refereed Papers: J. Marchesini, S.W. Smith, M. Zhao. “Keyjacking: Risks of the Current Client-side

Infrastructure.” Proceedings of the 2nd Annual PKI Research Workshop. NIST, April 2003 (to appear).

A. Iliev, S.W. Smith. “Privacy-Enhanced Credential Services.” Proceedings of the 2nd Annual PKI Research Workshop. NIST, April 2003 (to appear).

J. Marchesini, S.W. Smith. “Virtual Hierarchies: An Architecture for Building and Maintaining Efficient and Resilient Trust Chains.” Proceedings of the 7th Nordic Workshop on Secure IT Systems---NORDSEC 2002. Karlstad University Studies. November 2002.

S.W. Smith. “Outbound Authentication for Programmable Secure Coprocessors.” Computer Security---ESORICS 2002. Springer-Verlag LNCS 2502. Pp. 72-89. October 2002.

K. Kain, S.W. Smith, R. Asokan. “Digital Signatures and Electronic Documents: A Cautionary Tale.” Advanced Communications and Multimedia Security. Kluwer Academic Publishers. Pp. 293-307. September 2002.

E. Ye, S.W. Smith. “Trusted Paths for Browsers.” Proceedings of the 11th USENIX Security Symposium. August 2002.

A. Iliev, S.W. Smith. “Prototyping an Armored Data Vault: Rights Management on Big Brother's Computer.” Privacy-Enhancing Technology 2002. Springer-Verlag LNCS 2482. April 2002.

Columns and departments: S.W. Smith. “Fairy Dust, Secrets and the Real World.” IEEE Security and Privacy. 1:89-93.

Jan/Feb 2003.

26

S.W. Smith. “Humans in the Loop: Human-computer interaction and Security” IEEE Security and Privacy. May/June 2003 (to appear).

R. Brentrup. “Public Key Cryptography Demystified.” Syllabus. May 1, 2003.

J. Boettcher, R. Brentrup, J. Douglass. “Digital Certificates: Coming of Age” Educause Review. Jan/Feb 2003.

Technical reports and theses: Y. Ali, Master's thesis. Flexible and Scalable Public Key Security for SSH. 2003. (A revised,

abridged version appears as Computer Science Technical Report TR2003-441, Dartmouth College.)

D.M. Nicol, S.W. Smith, M. Zhao. Efficient Security for BGP Route Announcements. Computer Science Technical Report TR2003-440. Dartmouth College. February 2003.

M. Barreno, senior honors thesis. The Future of Cryptography under Quantum Computers. 2002.

E. Ye, Master's thesis. Building Trusted Paths for Web Browsers. 2002.

S. Agrawal, Master's thesis. Integrating Fair-Use with Shibboleth.

K. Kain, Master's thesis. Risks of Electronic Documents and Digital Signatures.

Dan Kang, senior honors thesis. Authenticating Humans via Untrusted Clients.

S. Nazareth, Master's thesis. Using SDSI-SPKI for Distributed Attribute Release Policies in Shibboleth.

Mindy Pereira, senior honors thesis. A Hardened S/MIME Gateway: Usability and Trust.

Paul Seligman, senior honors thesis. Using Machine Learning to Detect and Suppress Fraud in JSTOR.

Gabriel Vanrenen, senior honors thesis. Keypair Revocation in Distributed Systems.

2.4.2 External Partners In March 2003 the deployment team started regular meetings with a PKI project team at the University of Wisconsin-Madison using video conferencing. We are also identifying partners from other schools with whom we can collaborate to deploy similar infrastructure and applications at their institutions. We visited Cornell to meet with members of their technical staff about Dartmouth’s experience with PKI and to provide a general presentation. Visits to the University of Wisconsin, Yale, Brown, Stanford, Columbia, and Princeton are either planned or under consideration.

JSTOR pilotDuring the summer of 2002, Dartmouth participated in the CREN/JSTOR pilot and was able to make use of the JSTOR system through PKI client certificate authentication. The PKI Lab obtained a CREN signed certificate for Dartmouth College and chaired the group of five institutions participating in the JSTOR access pilot.

27

At Dartmouth, Library staff enrolled in the PKI and used their personal certificates to obtain access to the JSTOR system. The Lab developed some step by step instructions which the participants successfully used to enroll in the PKI and use their keys to access the JSTOR system. This project was demonstrated at the Educause session from the GIT network.

HEBCAThe team has been active with the Educause Net@Edu group, which led to Dartmouth’s involvement in the HEBCA BID. Dartmouth leads the Business development sub-group and is deeply involved in the Operations planning. As part of the NIH-HEBCA signature pilot, the team worked out the procedures for cross-certifying the Sun CA with the bridge and contributed to the “cookbook” being developed for other schools to follow.

On 31 January 2002 under the auspices of EDUCAUSE, the National Institutes of Health (NIH), and the Federal Public Key Infrastructure (PKI) Steering Committee, a Higher Education Bridge Certificate Authority was successfully cross-certified with the FBCA and three schools test-submitted NIH proposals <http://www.educause.edu/news/2002/01/hebca.html>: the University of Alabama at Birmingham, the University of Wisconsin–Madison, and Dartmouth College. This project showed the viability of using campus-based PKI credentials to digitally sign grant applications using a test-mode HEBCA cross-certified with the FBCA. University participants cross-certified with the HEBCA. Electronic signatures on grant applications submitted via e-mail to NIH from the different universities were verified at NIH. This project proved quite successful and has paved the way for a broader set of applications requiring interoperable PKI environments. This project was awarded an “E-Gov Best-of-the-Best” award in 2002, and was widely discussed in the federal PKI Steering Committee, the federal CIO Council, MAGIC, and other bodies planning for middleware futures. The FBCA plans to support continued development of bridge aware applications.

Our work with the JSTOR pilot and the Shibboleth pilot have further demonstrated the need for Inter-institutional PKI. There is a need for shared trust anchors to enable these types of projects. The HEBCA may become the center of many of these projects.

In the summer of 2002 EDUCAUSE created a group charged with building a production HEBCA <http://www.educause.edu/hebca/>. Dubbed the HEBCA Board of Instantiation and Development the group consists of invited technical and administrative IT professionals from Dartmouth, Duke, EDUCAUSE/I2, U Colorado, Penn, U Texas System, U California System, U Virginia, and U Wisconsin. The BID issued an RFI to move the creation of an operational production HEBCA. Submitting a response, Dartmouth recused itself from the BID during RFI deliberations, and was selected by the BID to work with the EDUCAUSE board and management to create a HEBCA. EDUCAUSE has informally committed to provide $100K to $200K per year for three years, and we are seeking funding from other sources such as NSF and I3P for the balance of the $500K per year for the three years Dartmouth will need to bootstrap the HEBCA here.

Shibboleth PilotThe PKI Lab and the Dartmouth Library submitted a proposal to be included in the Shibboleth project pilot group which was accepted in August 2002. The Library was interested in participating because of interest by the Digital Library Federation and because they have been

28

customers of the vendors also participating in the Shibboleth pilot. Dartmouth worked with the v0.7 release and provided some feedback on setup problems. We successfully installed the v0.8 version of Shibboleth and connected to the Internet2 test target. Dartmouth paired with EBSCO to test services, but this has been on hold pending the release of v1.0. EBSCO could only run v0.7 and Dartmouth could only run v0.8. The incompatibilities are to be fixed in the new release. In March 2003, the PKI Lab set up a Handle Server that accepts authentication using X.509 PKI certificates. A subgroup of Shibboleth users interested in client-side PKI formed to explore this area. In May 2003, the Lab published a guide for PKI enabling a Shibboleth Handle Server. This documentation will be included in the next system release. The Lab also provided input for a dual PKI and LDAP authentication module developed by Wisconsin. These developments are now being shared with the entire group of Shibboleth pilot participants (originally 12 schools and 6 vendors).

Internet2 S/MIME GroupIn February 2002 Internet2 recruited a group of 15 schools interested in working on S/MIME email. The group was co-chaired by Jim Jokl at UVa and Bob Brentrup at Dartmouth. This group held a series of conference calls from February until October 2002 to explore the infrastructure needed for S/MIME installations. The group pulled together documentation on available S/MIME enabled clients and conducted some compatibility, and the participants shared information on sources of certificates and Certificate Authority systems. The group met in person at the I2 Spring meeting and developed ideas for S/MIME enabled applications. It posted information on the HEPKI web site. The S/MIME group suspended operations due the need for further progress on local CA installations and lack of available time by many participants. This group will probably be restarted in Summer 2003.

HEPKI TAGThe HEPKI TAG group has met periodically by phone conference since May 2000 with Dartmouth’s PKI Lab as an active participant. The group discusses technical issues related to PKI deployments and applications. Some of the topics have included: Open Source CA software, Interactions with directories, Client customization issues, Validity periods, Technical issues in cross-certification and Inter-institutional test beds. Documents produced by the group and minutes of the calls are posted on the HEPKI web site.

2.5 Conclusions Our research and deployment has revealed a great deal about the state of PKI today:

The learning curve for starting a PKI is steep, but should not be prohibitive for HEIs armed with the PKI lab’s documentation.

Software and hardware and application support for PKI is mixed but getting better. Glitches, user interface issues, and oversights abound in end-user applications.

The security of end-user applications is lacking in many cases, especially in feature rich applications.

Users are moderately aware of security issues and good secure computing practices, but we clearly have a lot of user education to conduct to get them computing safely with PKI.

29

Learning CurveThe learning curve for planning a PKI is steep. The vendor information available is typically a very high level overview or detailed product manuals. Practical information about the many interacting decisions one needs to make in designing and deploying a PKI is hard to find. There are so many options that it is often difficult to find the information in the detailed product documentation. We think that the “setting up a CA” information we generated will be very useful to others. We have been somewhat surprised at the number of issues we have found in presumably stable products. Almost everything we have tried has opened up new areas that need work, but we have been able to work around the issues to produce a stable CA environment. Most of the issues are not big problems once one is aware of them and how to get around them.

Commercial CA products are sufficiently complex to install and operate that specialized knowledge is required and few people have this experience yet. CA products that make use of complex databases compound this problem. Also many of the products were expensive, though the asking prices maybe moderating in the face of low sales. Product quality varies widely and it’s best not to assume components are compatible. Information about compatibility is scarce and often not useful for long because the products are changing rapidly.

Using the SunONE product was an easy way to start learning about a Certificate Authority product. Sun’s license allows free use of the product for development. Fees are required for production use. Recently Sun extended the free use provision for research work.

The PKI Lab team has learned much about the current state of PKI software and hardware (secure coprocessors, USB PKI key dongles, drivers, etc.). Many products exist although most are only available for Microsoft operating systems. Trying to find solutions that work on multiple platforms has complicated our efforts significantly. Some of the products with the most features are often the hardest to use in a secure fashion. Secure configurations are often not the default. Some existing products have serious security. For a technology that has been available for such a long time, PKI is still surprisingly immature.

PKI is as much about Policy as Technology. The policy issues, especially between organizations, are only partially understood. Defining the policy of the local PKI can be one of the most difficult aspects of getting started with the technology. It is easy to be awed by the use of cryptography and get carried away with trying to make replacement applications more secure than their non-electronic predecessors. On the other hand, if the replacements are not more secure than non-electronic (or pre-PKI versions), then what’s the point?

End-User ApplicationsWhile the availability of PKI support in applications is expanding, it is not yet universal. In some cases one has to switch applications in order to use the PKI infrastructure. This is a difficult and time-consuming barrier. This problem is especially acute for secure mail, where the application has much greater value when it is available to the widest possible universe of users. User application setup of PKI features can be complex. The meaning or interactions of the many options and preferences is often not obvious and the error messages are often confusing or misleading as well. An excellent example of this is the use and manipulation of keys and certificates in various browser key stores. Microsoft Internet Explorer and Outlook share the same key store yet provide different user interfaces for accessing them with major overlap in

30

some cases such as key import and export. These same applications often provide obscure error messages. Sometimes it is not even obvious to most users where the error originated.

Most PKI features are relatively new, and older versions of desktop applications in some cases just do not work. To take maximum advantage of PKI technology, users must maintain and upgrade their desktop software. However compatibility testing is a problem that requires significant ongoing effort. Security features and problem fixes are complex. New releases of software sometimes break features that were previously working and tested.

Debugging applications using encryption is especially complicated. The data streams visible in normal debugging tools are functionally opaque because of the encryption. Additional tools need to be incorporated into the software development environment. The open source development libraries are often not documented, examples are scarce and it takes a lot of effort to learn how they work.

Access to Web resources is a good starting application. While it does not utilize many of PKI’s capabilities, it is a common need and the security demands are not high. We think this will be a good way to get people to start using PKI and then be enabled for other applications like document signing and secure mail. Dartmouth is somewhat unusual in having deployed the Kerberos/Sidecar-infrastructure which we hope to replace with PKI. Providing digital document signatures in support of online workflow improvements seems to be a compelling next application. Secure mail will likely be heavily used eventually, but it will need to be more widely available before it will be used regularly and brings in the added complication of encryption and its accompanying need for more careful and comprehensive key and certificate management (including greater user awareness of the intricacies of key management).

Security of ApplicationsWe have found (not surprisingly) that PKI is only as secure as the applications which implement it. For example, a Microsoft Word document or a spreadsheet can be properly and securely signed and encrypted with PKI yet refer to dynamic content which appears on the screen and printer differently at different times. SSL authentication provides no value if users are not able to determine exactly what web content has been authenticated. Web spoofing can fool many users, but we have found and prototyped possible user interface features to address this threat. Key stores are still too easy to break.

End User EducationWe are working to understand how much “PKI knowledge” will be needed by the general population in order to make use of the PKI applications that have been developed. Without a driving application, it is harder to get users’ attention (although coupons for free Ben and Jerry’s ice cream have proven effective at getting surveys filled out) . Most users are aware of the need for security and some of the security features already available to them, but fewer actually use these security features on a regular basis or even at all. For example, most are aware of the purpose of secure connections in browsers, but few check the “secure” indicator regularly, and some never check it. It seems safe to conclude that it will take time and education to get users to the point where secure computing practices using PKI are second nature to them. We will use our educational activities to generate demand for PKI by making users more knowledgeable about the technology and its applications. We will also help education end users in the use of the applications which we disseminate.

31

PKI ViabilityDespite its many issues with complexity, applications support, new processes and policies required, and lack of user knowledge, PKI is technically sound for its intended purposes and making steady progress in all areas. All our findings indicate that PKI can indeed solve the problems it is intended to address. PKI is a diamond in the rough with many rough edges that need polishing. With some refinement it will make an outstanding basis for far more secure computing in the future.

32

3 Phase 2 Plans

3.1 Phase 2 Vision

The context for Phase 2 efforts is Dartmouth’s long range vision of extensive PKI integration into campus computing fabrics. PKI’s certificate based technology with flexible attributes capabilities provides an extensive, scaleable architecture for bringing authentication and authorization to an individual level. This opens up a whole new paradigm for personalizing network access and resource allocation that scales well beyond today’s traditional security schema.

Possible applications of PKI include:

PKI authentication for secured resources, including:o Wireless and wired network, access for desktop, public, portable, and handheld

computing devices. o Digital Library resources.o Student information systems.o Administrative systems.o Email, instant messaging.

PKI-enabled new administrative processes:o Digital document signing to allow us to streamline administrative operations away

from signed paper forms.o Web services for business process automation.

PKI-secured communications:o S/MIME email for all users.o SPAM free email lists.o Store personal email securely with encryption.

PKI-secured critical data with encryption:o Student medical information.o Sensitive research data.o Student academic records.o Sensitive HR data.o Financial data.o Admissions data.

PKI can become a personal electronic key plus college ID plus cyber security certificate, all in one consolidated device with embedded PKI technology.

In one possible future, students and staff carry a wireless handheld organizer/phone/browser device into which they plug their PKI-enabled ID card (and by so doing are authenticated to the wireless network). This combination can automatically authenticate the user via PKI to applications on the network with just the typing of a code for the session and a password into the handheld. Or they can plug the ID card directly into a client computer, library checkout reader, the lock on a door, a cafeteria checkout reader, etc. Depending on security requirements, these operations may or may not require a password to go along with the PKI authentication. In this

same future, users supply keys for signing and encrypting email and electronic documents easily and conveniently with their wireless or direct-plug PKI capabilities. The essential ingredient here that PKI provides is a personal device with a unique and secure personal electronic key that users carry as an “all-in-one” key for all these purposes.

3.1.1 IntegrationIn the original proposal, we envisioned intervals in which we would evaluate the work so far, and consider how ideas could cross over between the design and deployment teams.

The phase 1 work already reflected interaction between the teams: deployment application work drove research/design vulnerability analyses; research/design's work on trusted paths, WebALPS, and SSH have all been considered for deployment.

In the second phase, we plan for this interaction to continue and grow. We plan to integrate the S/MIME expertise of the development team and the hardened S/MIME gateway work; we plan to use the private credential server and the AXIS system as soon as they are ready; we plan to explore porting open-source tools onto trusted hardware; and we plan to use both research and deployment expertise in user and guest authorization for wireless networks.

Furthermore, in both phases, the user studies work and the research/design/deployment work are closely related.

3.1.2 Phase 2 ThemesPhase 2 encompasses the following main themes:

Research and development User studies Local deployment National deployment Securing wireless networks

A prominent development in phase 2 is the emergence of securing wireless networks as a compelling application of PKI, both on and off campus.

Research and User Studies will continue existing projects and undertake new ones as planned. In Deployment, we will continue to develop PKI production knowledge and experience in the context of actual “real user” deployments at Dartmouth and at other schools.

On-campus deployment will take place in the following areas: Securing our wireless network

Authentication and authorization for web applications:

Library journal applications

TuckStreams

Student admin system (Banner)

National outreach will proceed on multiple fronts with increasing emphasis placed on activities that get the best traction:

Web reference information

Web seminars

PKI summit hosted at Dartmouth

Public relations (press and analysts)

Test certificate authority

Presentations and papers

Tools and applications distributions

Open source CA and/or Turn-key HEI-PKI

Selected campus visits and direct phone/email consultation with IT leadership and technical staff deploying PKI at other HEIs

Partnership deployment projects with corporations and remote campuses

Influence on vendors as they improve PKI features in their products

3.2 Deployment Team Plan Phase 2Deployment team activities fall into the following main categories:

Production knowledge

Local deployment

National deployment

The following sections explain the PKI Lab development team’s priorities in each category.

3.2.1 Production KnowledgeFor phase two, the PKI Lab team plans to continue the general PKI awareness activities already in progress and expand their scope. More importantly we need to undertake the next steps to foster the creation of PKI applications and infrastructure deployment at other Institutions of Higher Education. Our phase 1 outreach efforts indicate that the Dartmouth PKI installation and applications can currently solve problems faced by other HEIs. The next steps are the need for other successful production deployments and the perceived need for an environment in which an expanding circle of IT people can experiment on their own campuses.

The team will continue to document extensively the knowledge and experience we gain through our deployment activities. This documentation has already proven extremely valuable internally and to our early outreach partners. It will become even more valuable as we expand our national outreach scope.

PKI Applications DevelopmentThe deployment team will continue to work on PKI applications that Dartmouth is interested in pursuing. These include:

Authentication to secure wireless network

Digital signing of documents

S/MIME secure email clients

Complete and Adapt Design Team ProjectsThe design team has developed several applications and components that are worth extending, porting, generalizing, polishing, and distributing:

The WebAlps implementation of a secure web server.

The work done on an SSH Server seems to solve a common problem with applying SSH in general.

The research team’s methods for improving the trust characteristics of Mozilla

A key shared interest for the design and deployment teams is in developing Web based secure mail services. Because of the popularity of web based mail, a server based solution for S/MIME functionality would be very useful. Even a partial solution to this problem would be useful as a transition strategy for S/MIME usage as explained earlier in this report. Solutions in this space could be significant application drivers for PKI deployments at other institutions. S/MIME functionality provides assurance of the sender’s identity and can provide a way to highlight important communications in a rising tide of e-mail “noise” (for example from junk mailings and virus infection attempts). Encryption allows e-mail to move from a technology most analogous to “post cards” towards something more closely resembling “first class” mail.

3.2.2 Local Deployment

PKI Accessibility to General UsersThe deployment team will support and enhance our production Dartmouth certificate authority and accompany registration system as they serve increasing numbers of users. Communications Services will continue to help improve and maintain our “Using PKI at Dartmouth” user web. We will continue to educate and assist our consulting team as PKI usage ramps up. We will probably need to develop a higher assurance PKI registration process for some of the applications under consideration.

Dartmouth’s general PKI infrastructure will evolve as our experience grows and as we incorporate findings from Research and User Studies. It will serve as a working example for our national outreach program.

ApplicationsWe have selected authentication and authorization for web applications as our first area for “real user” application deployment. Specifically, we will deploy authentication and authorization for: Library electronic journals

TuckStreams business school system

Banner student admin system (assuming we can provide sufficient assurance in our early PKI)

We will also focus heavily on wireless network security using PKI. We have a WPA-secured network working in the PKI Lab and are starting to investigate the issues surrounding a “real user” deployment.

Project leaders in Dartmouth’s computing services, libraries and other departments need to take over the details of supporting PKI authentication in the production systems and their ongoing operation.

3.2.3 National DeploymentThe Outreach section (see 3.5) covers the details of national deployment, but it is important to acknowledge here that PKI lab deployment team staff will contribute to the national deployment effort and to the PKI lab’s outreach program in general. The team’s collective wisdom and assistance will be crucial to the success of the outreach work.

3.3 Research Plan Phase 2

3.3.1 S/MIMEAs noted above, we plan to continue exploration of hardened S/MIME in conjunction with the deployment team.

However, for many of the problems that S/MIME is touted to solve in academic environments (e.g., proving that mail really came from Wisconsin's registrar or Yale's Dean), S/MIME is not sufficient. Knowing that Eric Norman signed the message doesn't help, unless we know that Eric can act for the registrar.

As a research project, we wish to explore the necessary authorization infrastructure to enable signed mail to achieve this goal.

3.3.2 WirelessAs noted above in Section 2.1.2, as wireless networks become ubiquitous in large organizations (such as universities), the problem of how to secure these networks---while also allowing for authorized guest access to the net at large and to internal resources---is an emerging problem.

Emerging wireless standards permit a TSL-based authentication based on PKI. Extending this to solve the above problem requires:

the ability to issue X509 identity certificates to regular institutional users (and to access points)

the ability to issue authorization certificates to permit authorized users to delegate permissions to appropriate guests

With our initial production PKI, we have the former; with our work both in SDSI-SPKI and with PERMIS, we have the latter. We plan---leveraging funding from industrial partners---to explore this with the deployment team.

We suspect that wireless authorization may be the "killer app" for PKI in academic environments. Everyone will want wireless access, and a PKI-based approach avoids the security and management weaknesses of plaintext shared SSIDs, shared passwords, and large central databases.

3.3.3 Trusted PathsEileen ended her appointment in May 2003. We hope to make her trusted-path code available via the Internet2 Middleware program. We also plan to adapt her work exploring the expression of non-identity server information for use in wireless network access control for guests.

3.3.4 Human-Computer InteractionIn many ways, our team has been continually discovering that PKI doesn't work: server-side SSL does not enable trust judgments; client-side SSL does not prove the client was there; valid digital signatures on electronic documents don't mean the documents were valid.

However, from the right perspective, these issues all stem from standard design flaws familiar to HCI researchers: a gap exists between the conceptual model that users and programmers had of what the computers were doing with the cryptography, and what the computers were really doing with it.

Sean has been increasingly interested in exploring this angle further (including bringing Dartmouth and Mellon participation to the invitational ACM/CHI2003 Workshop on HCI and Security Systems.) As a starting point, student Lin Zhong is doing an HCI-based analysis of how to fix the client-side SSL problem, and Anna Shubina is planning to do an HCI-based analysis of X509.

3.3.5 Calculus for Trust JudgmentUltimately, our secure systems need to be used by people; our PKI should enable these people to make reasonable trust judgments about the systems and services they use.

However, people do strange things when it comes to drawing conclusions about what online things they choose to trust. For one example, in PKI, two competing views are “hook things up in a hierarchy” and “hook things up in a mesh;” John Marchesini noticed that many people prefer hierarchies, even after one points out the clear technical advantages of meshes. For other examples, we might look at the often surprising findings from recent user studies regarding trust perception of Web sites.

Some recent research has looked trying to formalize the logic of making trust decisions. In particular, Maurer has looked at logics of drawing conclusions from piles of certificates; Maurer has also looked (less directly) at determining whether the conclusions reached by these formal systems match reality. (Sean Smith also looked at some of this, in his ESORICS paper from last year.)

Some folks advance the thesis that this “surprising” human behavior is only surprising because we haven't taken the time to formalize the rules. Proving this thesis would require:

compiling a catalog of surprising instances of human trust judgment, preferably in electronic settings (and which are counter-intuitive from a technologist's viewpoint), and

constructing a formal decision procedure that appears reasonable, is consistent with this data, and perhaps successfully predicts other data.

This procedure may be an extension of some existing calculus, like Maurer's, or may build on the game theory models that sociology has used. (Or on something else, of course!)

The hope is that, once such a model is constructed, we can use it to design PKI systems that better accommodate how people make judgments, and thus which more effectively achieve the goal of enabling trust judgments. Whether the systems we apply this model to are “user interfaces” or “certificate structures” or something else depends on what type of system the model-construction work examines.

Undergraduate Sam Slee, working with Denise and Sean, has begun exploring this area.

3.3.6 Formal MethodsFor some in the computer science community, the term "formal methods" refers to some specific techniques for specifying and analyzing systems, often with the automated and semi-automated tools of model checkers and theorem provers. (Clarke and Wing have some good survey papers here.)

These tools---particularly model checkers---can prove surprisingly effective in examining large spaces of reachable system states in order to determine if system properties the analyst cares about ever fail to hold.

At the ACM/CHI2003 HCI/Secure Systems workshop (and in its aftermath), some of the HCI folks asserted that “formal methods” had no role in resolving the HCI/security problem. It's not clear whether they meant “formal methods” in the specific sense above, or in a more generic sense.

However, these comments got us thinking.

Systems have state, and this state undergoes transformations based on user actions and environmental events.

A reasonable characterization of “security” is: “does the system retain critical correctness properties despite foreseeable adversarial actions?”

A problem affecting security and systems in general is that systems, in the real world, can exhibit behavior paths through this state space that were never anticipated.

A challenge from HCI is that human users of systems in the real world can also exhibit unanticipated behavior paths---not just about trust judgments, as considered above, but also even input sequences and “mistakes”.

Can we use the tool of model checkers bring light to these issues?

3.3.7 PrivacyAs noted, we plan to finish the private credential server, and pilot it both within a Dartmouth X509 directory as well as within Shibboleth installations at Dartmouth.

We'd also like to extend this work to private chain discovery and validation.

3.3.8 Trusted HardwareA major component of the research/design team's effort was using trusted hardware to secure sensitive server-side operations.

If our work is not to be vaporware, we need to actually do this using real hardware; Section 2.2.2 above discussed our work on the Mouse and Bear platforms.

On the way to fully porting AXIS onto Mouse and Bear, the expertise we have achieved already can enable some easy deliverables. To our knowledge, no one else has been using TCPA with Linux; and no one else has gone as far with embedding applications on the 4758 with Linux.

One project is TcpALPS: Like the original WebALPS project, we can harden Web servers by porting the SSL private key, session keys, and sensitive computation onto a trusted platform. However, we can use the TCPA platform to do this: using the TPM to securely store the secret key, bound to the specific software configuration of that server, and using TCPA attestation to enable the SSL CA to certify this.

Porting a standard open-source CA onto 4758/Linux seems like an obvious thing to do, but which apparently no one has done yet.

In future work, there is a rich space of interesting things to investigate which will possibly arise as a result of having the TPM and a 4758 on the same machine.

3.3.9 Trusted Third Party InfrastructureBefore we can seriously consider AXIS as a part of a next-generation PKI, we need to finish porting it into secure hardware. Our current plan is to have it ready for wider pilot by October 2003.

We plan parallel development efforts.

Thread 1 - Front-end on TCPAlps. As discussed above, the goal is to get an Apache Web Server with mod_ssl running on a TCPA-hardened machine and take advantage of the security features of the TPM. Our first run is to build a system which will allow clients to negotiate an SSL session with a specific application (via the application's key).

Sean is currently writing up some thoughts on this.

Rich is working on the TCPA library (adding features) so that we can use the library to build such a prototype.

John is looking into the Linux boot process to find out how we can hook the TPM into the boot process.

How this relates to AXIS: once TCPAlps is implemented, the AXIS servlets (i.e. the front end) can be dropped right in to TCPAlps, giving users a secure channel to the AXIS system.

Thread 2 - Back-end on a 4758. This is underway. As noted, we now have a multi-threaded Java virtual machine running inside, and are porting a CORBA ORB.

The next item on the agenda is to wrap the card's native crypto interface as a Java Crypto Provider, so that any Java code may use the native crypto. This will relax library dependencies and free up space in the card. John will tend to this as soon as the back-end is in the card (or as much of it will go in without having crypto).

Next StepsAt this stage, Rich and John will integrate the front and back ends of the system, completing the hardening of our initial prototype.

The next task in this space is to implement migrating objects. This requires at least two things to happen:

A networking interface needs to be implemented for processes in the 4758. The idea is to make a thin socket API for the sccnet communication mechanism, so that processes in the card can write to the API, and a process on the host will actually forward the request to the TCP/IP stack. (Note: this would be very useful for anyone writing Marianas applications.)

The actual object location and migration mechanisms need to be implemented, so that private keys and application handlers may migrate to other AXIS back-ends. Our thinking here is to use the JXTA toolkit to construct these mechanisms. Once the networking is in place, this becomes a very straightforward task.

(Here we see synergy with the NSF Marianas project. This is also useful to Marianas developers - in fact, this is exactly the Marianas middleware layer, unless people want to implement fancier location algorithms like Distributed Hash Tables, and the like. However, even in the case where developers would like to implement other schemes, the JXTA tools allow developers to plug-n-play these algorithms.)

When the above is complete, we want to pilot AXIS in conjunction with the Dartmouth PKI. Initially, we plan on integrating Dan's authentication work (if successful) and, as an initial application, we are planning on porting Mindy's S/MIME work.

Once AXIS is complete, we will have built a distributed crypto framework, and we hope that 3rd parties will use it to develop their own applications.

Additionally, we will have essentially built a test-bed for PKI architectures in the sense that each AXIS node contains a CA and can be connected to other CAs in a number of ways. Having such a system would lead to some natural exploration of PKI architectures without having to build real PKIs for testing while still allowing us to build and test working prototypes. At least one member's agenda is to build "PKI-on-the-fly", and AXIS is a rich environment for testing concepts related to this agenda.

3.4 User Studies

3.4.1 Understanding User Security Behavior

Current – June 2004We will complete the student user survey and in-depth interviews in the spring of 2003. We will then begin to analyze the type of security and risky behavior common among student-users, as well as their knowledge and awareness of computer security issues. Using this data we will also begin to identify the types of activities users would like to engage in, but currently must do so in an unsecure way (e.g., delegate authority and control of a specific action, such as check-in, to another actor which currently requires users to share passwords). We will make our analyses generalizable to the higher education community more generally by using national data on student computer use from the Higher Education Research Institute’s CIRP study and other national data to adjust the Dartmouth sample to be representative of the national student population.

This summer we will conduct the next phase of the user survey by sampling staff members about their security behavior and knowledge, as well as the types of activities that currently require unsecure actions. Finally, in the fall of 2003 we will survey faculty members. Combining data from the three survey populations (students, staff and faculty) will enable us to provide a comprehensive analysis of user security behavior in higher education, i.e., help us to understand what users actually do, and why they do what they do.

3.4.2 JSTOR Pilot Evaluation

September 2003 – December 2003Work with the deployment team to evaluate the usability of accessing JSTOR via PKI certificates and keys. As more users begin to access the JSTOR system via PKI, we will evaluate users’ perceptions of ease of use, and satisfaction with the method. We will also evaluate the extent and type of questions to the Help Desk for help with the method.

3.4.3 Understanding Users’ Conceptual Models of Security

June 2003 – July 2004We will work with the research team to evaluate how a variety of users (including neophyte end-users as well as knowledgeable computer “experts”) understand and conceptualize the technological systems underlying a range of digital exchanges. We seek to answer the following questions: How do users conceptualize digital exchanges and the systems through which they occur? What do they think happens when they sign an electronic document, when they send private information across an SSL connection to a website, or when they access their private information via a secure web server? Do their conceptual models lead them to over-estimate (or under-estimate) the security of the system? How do users’ conceptual models of the computer interface system affect how effectively they use the system, and what if any steps they take to increase security?

3.4.4 Estimating the Scale and Scope of Security Risk from Users in Higher Education

January 2004 – August 2004This part of the User Study project seeks to estimate the scale and scope of network security exposure resulting from user behavior. More specifically, we will estimate the overall extent of security exposure resulting from user behavior, the risk of a security breach resulting from the level of exposure, as well as the administrative costs of preventing and fixing security exposure, and any security breaches that result. Further we will attempt to estimate the potential overall cost of different types of security breaches (e.g., including a broader definition of “cost” to include items such as, “public relations” costs or liability exposure), as well as the “value” of the user behavior that causes security vulnerability and exposure, in order to assess the overall cost-benefit ratio resulting from our estimation of user-induced security vulnerability to the network.

Estimating the risk and cost of security exposure caused by user behavior will allow HE institutions to: evaluate the importance and value of system administration support of security-related activities; evaluate the need for and potential effect of various user policies (e.g., standards for passwords, forced password changes, etc); better estimate the value of new technology for limiting security exposure and security breaches resulting from user behavior; and determine alternative practices that allow valued activity while preventing network security exposure.

3.5 Outreach Plan Phase 2 We have added a Project Leader staff member specifically to address PKI Lab outreach. Mark Franklin started in this role in early May 2003. He will help deploy the PKI Lab’s applications, first at Dartmouth and then nationally. He will assume overall responsibility for our national deployment activities, but the rest of the group will be involved in this work. Effective outreach that results in real applications is going to have to be a team effort. The knowledge and contacts within an organization to make a large remote project happen are distributed within the team. It has taken many months to develop the technical expertise and transferring it is still complex. Mark and other new personnel will need to work closely with the existing team and be able to contribute to developing products that work for our partners.

The following sections describe specific activities we plan for national deployment.

3.5.1 Web Reference InformationThe PKI Lab web site has been a successful way to distribute information about the project. There is a somewhat continuous stream of new material being added. We will distribute the work to date sections of this report there. The elements of a “PKI Cookbook” have been taking shape, and we will assemble a complete version of this idea. We will add sample code derived from the existing Dartmouth web applications using PKI authentication along with an expanded section for PKI development tools and information. We will continue to put extra effort into making this information suitable for consumption outside Dartmouth.

3.5.2 Seminars and WebinarsIn the next twelve months, Dartmouth plans to host a PKI summit where we will bring together top influencers in the security community with HEI and industry CIOs to explore the state of the art in PKI technology and its application toward solving real world problems. A mix of lectures, tutorials and demonstrations of PKI solutions will provide a rich environment for evangelizing PKI.

Dartmouth will plan and execute a series of Webinars to disseminate the results of its research in PKI technology and solutions. In addition we will provide a series of tutorials to educate the community at large on PKI technology and systems/network infrastructure deployment required to support PKI, perhaps in conjunction with EDUCAUSE and I2.

3.5.3 Public Relations (press and analysts)Dartmouth plans to mount an aggressive PR campaign for dissemination of our PKI activities and to position itself as an authority on PKI technology and solutions. We will utilize campus media resources coupled with external PR professionals to develop a well balanced campaign. We will solicit analysts by positioning ourselves as an authoritative source for PKI technology expertise and system integration. We expect to generate roughly one article every other month from our research and deployment activities and plan to target popular IT press publications in addition to the more traditional research and higher education venues. In addition to spreading the word about Dartmouth’s accomplishments, we plan to help generate demand for PKI by educating users about the capabilities, potential, and current state of PKI and how Dartmouth can help them adopt it. We will continue to propagate our results by writing papers and presenting at conferences and workshops.

3.5.4 Tools and Infrastructure DevelopmentOne of the barriers to PKI deployment is the need to have the ability to generate certificates before one can even start to experiment with applications. Following up on an idea generated in discussions at the spring Internet2 middleware meetings, the PKI Lab will ensure that a suitable external test and development certificate authority exists to give potential PKI adopters in the investigation phase the ability to generate their own certificates on our system and use them with PKI Lab or other applications for evaluation and proof of concept work. Campus IT personnel will be able to enroll and obtain keys and certificates. This should lower the hurdles required to get them to the “test drive” stage and thus ease their path to PKI deployment. Certificates from this system will be for non-production purposes only and certificates generated by it are not to be trusted. We can also provide sample PKI enabled web and mail servers for testing and evaluation purposes. These services will enable demonstrating PKI enabled applications in a local deployment which seems to be crucial to helping campus administrators perceive the value of PKI enabled applications in a local deployment obtaining their support. At the same time, local IT personnel will gain first hand experienced with PKI technology. The PKI Lab will use these test and evaluation services as important components of our outreach program for educating potential PKI users at other institutions and for helping them climb the PKI learning curve.

The PKI Lab has created simple “certificate viewer” and “signer” tools which we will make available for others to use.

As we assist other institutional deployments of PKI, we will continue to refine the process needed to deploy a local PKI. A turn-key type of solution is our goal, though we may not completely achieve this in the short term. The deployment team has packaged our customizations to SunONE for example to simplify reinstalling them locally or remotely and plans to continue similar efforts. Our long-term hope is to be able to supply other HEIs with a package of documentation and/or open source CA tools which amount to “PKI in a box” to be deployed in a straightforward fashion at other schools with the possible addition of a commercial CA product. In the near term, we will continue to enhance our documentation to accompany a commercial CA product for our “PKI in a box” solution.

As mentioned previously, the Dartmouth group has experience with a number of different CA products. Depending on the interests of partners, other products may become important. The deployment team may need to develop additional expertise with other products. Traditionally there is a lot of interest in Higher Education community in Open Source software solutions. We intend to investigate and perhaps contribute to development of additional open source alternatives.

3.5.5 HEBCAAs mentioned earlier, Dartmouth has been an active participant in the prototyping and development of plans for a HEBCA. At the very least, Dartmouth will be interested in applications that work with the HEBCA. Projects to contribute to the development of necessary software modifications to support use of the HEBCA may be interesting projects in which the PKI lab could become involved. These efforts would require either additional resources or follow the previously described projects.

The deployment of bridges by Higher Education and the Federal Government however could become a very significant driver for PKI deployments within Higher Education. The Federal Government for example is proceeding with plans for a common mechanism for electronic submission of grant applications. In general a widely available infrastructure for inter-institutional PKI such as the HEBCA could significantly enhance the desirability of local PKI deployments. This will be an important area to monitor and perhaps devote effort toward in this project.

Dartmouth is presently working with EDUCAUSE to create the HEBCA.

3.5.6 Partnership Deployment Projects with Remote CampusesWe will carefully select two to four partner HEIs with which we will work in much greater depth and for longer than the consultations in the activity above.

Other successful deployments are key to demonstrating that the Dartmouth effort can be a model. The initial focus will be on production applications and supporting PKI deployments at a limited number of partners with whom we will work closely. To do this we must bring together several elements. Partners must be willing to make solving the problems that PKI can address a high priority. Currently this will be easiest with a partner that has already experimented with PKI. The local political process must be navigated to allow resources to be committed by the partner to start to implement solutions. It is crucial that this commitment be sustained for a sufficient time to demonstrate positive results. A path to production deployment must be made to complete the

process. Additional examples of successful PKI applications and the deployment of supporting infrastructure will very likely be the best way to attract the interest of more campuses.

Dartmouth’s collected and documented PKI deployment experience should significantly shorten the time needed for completion of an external deployment, and Dartmouth’s completed applications can serve as models and/or may be directly exportable to our partner HEIs.

Steps:

1. Working from our current best information, identify likely partners. We should initially seek to identify two serious partners. We can expand to others once we have substantial progress at the initial partners and personnel resources are available for more partners. Partner buy-in needs to include both the Technical and CIO levels.

2. For each partner HEI:a. Jointly select a PKI application and determine what is needed to deploy it. This

includes defining the details of the application and identifying suitable software and the support environment. Identify needed partner HEI resources such as people, equipment, and funding.

b. Determining the specifics of a suitable PKI architecture. The PKI must fit in with existing infrastructure, such as directories, be acceptably priced, and be supportable and sustainable by the partner HEI.

c. Develop the details of the Application with staff at the HEI. It must fill a perceived need. It would be easiest to choose an application that Dartmouth has already developed, e.g. Web authentication to Banner/Oracle. Otherwise we need to select something similar, such as Web authentication to PeopleSoft. Other primary possibilities are authentication to Library Resources/Shibboleth or local web services. Secure e-mail, electronically signed documents or wireless network authentication are also possible with some additional development by the Lab.

d. Develop the details of the PKI with the staff at the HEI. It would be easiest to base it on products that Dartmouth has already used, e.g. SunONE, AOL/Netscape or Entrust. Otherwise we need to find something else suitable to local needs, e.g. Microsoft CA services.

e. Develop a working relationship with Technical staff at the HEI to assist the remote project as needed, e.g. knowledge transfer, investigate alternative products, support local application development. This must include continuing interaction to catalyze progress.

Specific activities required to assist particular partners will derive from their diverse needs and environments and are therefore hard for us to detail further.

3.5.7 External Partnerships and Vendor InfluenceMany commercial products have features to support the use of PKI, but few products support it well. PKI features are typically added after the fact and are often not well integrated with the rest of the product. And they often have poorly-designed user interfaces, obscure error messages, omissions, oversights, and bugs. The PKI Lab will strive to persuade and help the vendors to improve their products.

By establishing itself as a recognized authority of PKI technology and solutions coupled with Dartmouth’s network and computing infrastructure resources, Dartmouth is well positioned to collaborate with industry on development and validation of key PKI technologies and system solutions. Over the next twelve months, Dartmouth will target and establish collaborative relationships with at least two leading industry players to integrate PKI technology in their product portfolio. .

3.6 ConclusionAll PKI Lab activities contribute to our overarching goal of making PKI really happen at Dartmouth and other Higher Education institutions. Our research and development team tests for inadequacies in existing solutions, develops solutions for problems found, and generates new and more secure techniques, tools, and platforms for PKI implementations. It reports its findings for all to use. Our deployment team focuses on the practical “nuts and bolts” matters of institutional PKI usage, implementing large-scale PKI at Dartmouth, assisting other HEIs as they deploy PKI, productizing the output of the research team, helping vendors refine PKI technology, and conducting a number of outreach activities to promote the use of PKI through: education, dissemination of working solutions with “how to” documentation, and participation in technical committees, conferences, and special interest groups. Our User Studies team studies the ways people actually use PKI solutions and their perceptions of security, providing feedback to the research and deployment teams so they can adjust their products accordingly. Our Phase 2 work will continue to orchestrate all these activities so that they compliment and build upon and amplify each other while we deliver viable and compelling PKI solutions for both Dartmouth and Higher Education in general.