Project Status Report for the

3.2.7Human-Computer Interaction

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.2.8Calculus for Trust Judgment

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.
  

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.2.9Formal Methods

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”.
  

3.2.10Privacy

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

3.2.11Trusted Hardware

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.2.12Trusted Third Party Infrastructure

Before 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 Steps

At 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.

Download 152.32 Kb.

Share with your friends: