Project Status Report for the

2.2.2Trusted Third-Party Infrastructure

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

AXIS

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 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/Mouse

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

Bear

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?
  

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.

Authenticating Via Un-trusted Clients

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 Servers

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.
  

Work is continuing in many aspects here.

2.2.3PKI-Enhanced List Server

The 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.4Privacy Studies

In 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 Computer

Starting 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 Servers

In 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(N²) 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 Anonymizers

In 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 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.5Other Projects

Trusted Paths for Web Browsers

In 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-middle

The 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.
  
• 
  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.

WebALPS

PKI 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 PKI

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

Revocation

Our 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 pair revocation to use these P2P-connected platforms to allow key mobility as well as tolerance of compromised platforms.

Fair Use in Shibboleth

Sanket 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 Architectures

How 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 PKI

The 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 JSTOR

JSTOR 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.6Leveraged Funding

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

Download 152.32 Kb.

Share with your friends: