Research Statement

[ Home | CV | Research | Fun | Contact ]

Research Statement---Sean W. Smith

From Arpanet to the Internet to the Web to pervasive computing, the world is changing rapidly. Computation, increasingly complex and distributed, continually penetrates into new areas of society and life. These changes raise challenges:

What does security and privacy mean in these new settings?

What base technology is necessary to provide these properties?

What else must happen for this technology to have an effect in practice?

Since society tends to adopt new technology whether or not the security issues have been identified and addressed, these challenges become especially urgent.

I want to make a difference. This focus emerged in my early research: in graduate school, theoretical systems and security work; at Los Alamos, real-world security analysis for e-commerce and e-government.

This early work led me to three realizations:

A fundamental problem in the emerging computational world is that distribution dissociates trust from control. Alice's interests depend on the correctness of computation that occurs at Bob's machine---but Bob's interests may differ.

Secure coprocessors ---computational devices that can be trusted to execute their software correctly, despite physical attack---could systematically solve many of these threats.

However, these solutions would remain theoretical, as long such devices existed only as lab prototypes.

My subsequent work at IBM Watson eliminated this barrier:

I defined what a generic, real-world secure coprocessor platform should do;

I designed a security architecture that achieved this;

I helped implement it as a real product, the IBM 4758;

and I then led the formal modeling and validation work that earned this device the world's first FIPS 140-1 Level 4 validation (the highest possible).

My research is now being used in thousands of installations worldwide, to secure applications ranging from banking, to postal meters, to movie and music distribution.

In my future work, I want to keep making a difference. I plan to demonstrate the potential (and limits) of the secure coprocessing technology I have already created, as well as to identify and rectify new security and privacy problems that are emerging.

Carnegie Mellon

In graduate school, my thesis work under Doug Tygar focused on some theoretical aspects of time and security in distributed systems. The traditional notion of time as a linear order on events may be appropriate for a uniprocessor, although some prior work had explored using partial orders for distributed systems---since if two events could not have influenced each other, their real-time order is irrelevant. My work had theory, algorithms, and security aspects:

I showed that more general time models, such as hierarchies of partial orders, better characterize the complexities that arise in distributed computation. (For example, distinct but related partial orders describe a distributed fault tolerance algorithm and the virtual failure-free computation it implements.)

I showed how problems in distributed systems can reduce to queries about these time relations. In particular, I used this approach to distributed time to characterize and solve some long-standing fault tolerance problems. (This work defined the term "completely asynchronous recovery" and jump-started work in this field.)

However, building algorithms based on "clocks" for these more general notions of time opens up security and privacy risks---since these clocks require parties to share private and unverifiable information. My work was the first to identify these problems and the first to introduce the notion of signed vector timestamps to address some of these problems.

My work also used the technology of secure coprocessors to construct sealed vector timestamps, which addressed even more of these problems.

(In my advisor's lab, we had a handful of coprocessor prototypes from IBM, and had been considering the implications such technology could have, should it ever exist in a form that could be widely deployed.)

My formal research at CMU was complemented by my more immediate, hands-on work: with my advisor and fellow students, I assisted the U.S. Postal Inspection Service in analyzing vulnerabilities of postal franking systems---where fraud was costing the U.S. public an estimated $200 million annually.

Also, I served as a teaching assistant for three semesters, for three different levels of material---even though only one semester was required.

Los Alamos

After CMU, I received a post-doctoral appointment in the Computer Research and Applications Group (CIC-3) at Los Alamos National Laboratory (and subsequently earned conversion to permanent staff member).

In CIC-3, I joined a diverse team containing academic researchers---in security, distributed systems, and applied mathematics---as well as senior personnel directly involved in defending the Laboratory's extensive (and targeted) computing infrastructure. Besides pursuing our individual research, our team also undertook a series of consulting engagements for various government and private-sector entities who were migrating their operations into new computational and Web environments, and turned to us for education, security analysis, and design advice.

This work extended my experience about design, attack, and defense of real systems, and clarified for me the urgency of the security and privacy problems created by society's migration to e-commerce and e-government.

As part of this work:

I led analyses for five projects with regional and national scope (and made major contributions to several others);

I explored some deeper research questions suggested by this work;

I authored two security handbooks distributed by the U.S.Department of Energy and the U.S. Postal Service;

with team leader Gary Christoph and penetration specialist Mike Neumann, I developed a multi-day Internet Security course, which we taught several times for various government groups

As noted earlier, I distilled from this work that a fundamental problem in many of the e-commerce and e-government settings was the dissociation of dependency from control, and that secure coprocessors---like the IBM prototypes we had back at CMU---could provide a way to systematically address these problems. As a result, I developed a proposal to explore the use of secure coprocessors to address some security and authentication problems at the Laboratory. I promptly ran into an impasse:

My project would be funded only if a path existed taking an initial small prototype to a limited (but secure) pilot, and then to a wider installation

The state of the art did not make this path possible, since a secure coprocessor platform that enabled development and deployment of third-party secure applications did not exist.

IBM Watson

In an attempt to correct the lack of a secure coprocessor platform for real applications, I contacted IBM Watson (the source of early hand-built prototypes we had at CMU). They responded by hiring me as a Research Staff Member, and chartering me to change the state of the art:

to transform an ongoing secure cryptographic accelerator product effort (led by my research group at Watson) into the high-end secure coprocessor platform that I believed should exist.

(The team had already begun a basic hardware design: physical security; 486-class CPU; DES, RNG, and modular math hardware.)

My research work had five main parts.

The first part of my challenge was determining my constraints. ( This paper gives an overview of this design space.)
- My design must enable both development and deployment of secure coprocessor applications (whatever that meant).
- My design must enable anyone (not just IBM) to develop supervisor-level OS software for the card.
- My design must enable anyone (not just IBM, and not just the OS developer) to develop applications to run on top of this system software.
- My design must accomodate realistic vulnerability scenarios. For example, any rewritable code may turn out to be faulty or malicious---but any code that goes into ROM must be simple enough to be correct, with high assurance.
- My design must accomodate realistic trust scenarios. For example, we must assume that none of these developers will trust each other (or IBM) (or the end users) any more than necessary.
- My design must accomodate realistic manufacturing constraints. At IBM, possible routes from the factory to customer sites are unimaginably Byzantine; each new shippable variation of a product vastly increases the bureaucratic overhead; and we clearly did not want to maintain a database of entries---secret or otherwise---for each shipped device.
- My design must accomodate realistic maintenance constraints. For example, where does code get installed? How does code get fixed? What should happen to installed secrets?
- The business group must be able to transform whatever we built into an accelerator for the IBM CCA crypto API.

The second part of my challenge was developing a design that satisfies these constraints. First, I defined the end-goal:
- Any party interacting with a deployed secure coprocessor application must be able to verify that it is "the real thing, doing the right thing."
Then (interacting with Steve Weingart, the physical security lead), I designed a security architecture that achieved this goal. ( This paper gives more details.)
- From the time it leaves the factory until it is tampered, each card contains a certified keypair. The active physical tamper detection and response is continuously active.
- Each card contains foundational Miniboot security management that guards this key, and controls the configuration, retention of secrets, and authentication of this card.
I accommodated the "no database" constraint by using public-key methods. I accommodated the "unknown shipping channel" constraint by permitting installation and update of software in the hostile field. I accommodated the vulnerability constraints by putting the more complex parts of Miniboot into an (atomically) rewritable portion, and by deriving a loading and secret retention policy from the overall principle that the device (with Miniboot) retains a layer's secrets only while it can continually maintain an environment trusted by that layer's owner.
The design needed to address many subtleties (too numerous to address in this short statement). A few examples:
- If someone's OS code has a bug that permits malicious code to usurp supervisor-level privileges, how can you be sure this code gets fixed? (After all, this evil code has access to all "Ring 0" memory!)
  My solution: I changed the hardware, and helped invent a ratchet lock to hide Miniboot's private keys---and write-access to its code---from all code, even supervisor-level, that executes after Miniboot finishes.
- If IBM releases a Miniboot update that is corrupt, how can anyone be sure they're talking to a card that hasn't been corrupted? (After all, it's the corrupted Miniboot that signs statements about the device's configuration!)
  My solution: as an atomic part of each Miniboot update, the old (trusted) Miniboot generates a new device keypair, and a transition certificate attesting to this software change. A corrupt release cannot hide its presence.
- How does one authenticate what's in a card? Identity of code in each layer is not sufficient, since different owners may have different update policies; furthermore, one cannot trust a rogue application to be honest about its identity or owner.
  My solution: Miniboot, as the guardian of the configuration of the card, signs statements about configuration with its protected private key.
- How does an application, while it's running, prove who it is?
  My solution: my outbound authentication API builds an internal key structure where Miniboot creates and certifies a keypair for the OS to use---but this certification identifies the OS and application who had access to this key.

The third part of my challenge was making this design real. I was involved in every step of the implementation process: doing much of the Miniboot coding myself, supervising the rest, testing all of it (and even debugging hardware, writing user manuals, and training customers). The original product shipped in the fall of 1997; in January 2000, we announced our follow-on hardware---with much faster crypto---for general availability in 2Q2000.

The fourth part of this challenge was ensuring this design could be trusted. In my consulting engagements at Los Alamos, a mantra was "never trust the vendor---always have independent adversarial testing." The device I had now produced as a vendor had better live up to the standards I had set as an analyst.
Work on secure coprocessing had always cited Federal Information Process Standard (FIPS) 140-1 as a metric of tamper resistance. Level 4 (the highest level) was the only one that provided sufficient assurance for high sensitive applications.
However, no one had ever earned a FIPS 140-1 Level 4 validation, because the independent testing was too difficult. In particular:
- the hardware needed to withstand arbitrary physical penetration testing; and
- the software needed to be formally modelled and "proved" secure within this model.
Our hardware team felt their design could stand up to this testing. But for our secure coprocessor platform to be a trusted foundation for third-party applications, we needed to obtain this full validation: to establish that this armor, within my security architecture, was effectively and meaningfully guarded by my configuration software.
This was another problem that I decided need to be solved. With management's approval, I led the world's first (and, so far, only) successful validation of software at this highest level of FIPS 140-1. My work included:
- building a formal mathematical model (close to code) of what the software does, when executing on this hardware;
- formally defining security correctness properties in terms of this model; and
- supervising its embedding in ACL2 and mechanical proof.
As part of this work, I also identified areas where the standard fell short of high-assurance software security (for example, by not analyzing bounds checking on variables, offsets, and pointers). I then addressed these areas in my submission (to set a precedent for future validations); and have been working with NIST to try to ensure that the follow-on 140-2 standard codifies this precedent. ( This paper gives a preliminary overview of the formal modeling strategy; this paper gives more details on the whole experience.)
My work led, in the fall of 1998, to our device earning the world's first FIPS 140 validation at this highest level---and, to date, this is the only device with software to achieve this level. (The only other device is a non-programmable crypto chip for mainframes, also from IBM.)
Since then, OEM customers have been engaging in delta-validations of their code on top of this platform.

The last part of my work is seeing that this generic secure coprocessor platform is actually used as a secure coprocessor (and not just an accelerator).
This has involved porting some of my testing code to a "developer's toolkit," training OEMs, and arranging University research partners (UCSD is using our device for secure mobile agents; University of Michigan is exploring using it to secure their Kerberos servers.)
We are also currently negotiating with various IBM entities to release the developer's toolkit for free on the Web.
This platform is also generating a research and business life of its own. Many additional universities have approached me about using this secure coprocessor platform to enable their research. The Naval Postgraduate School even had a course on secure coprocessing, where my papers constituted nearly a third of the reading list. And on a business front, more than 50% of cards sold are for OEM applications!

What's Next

I joined Watson---and built and validated a generic secure coprocessor platform---because, in 1996, I believed this technology could solve many of the trust problems emerging in the Internet, e-commerce, and e-government. (This report documents the taxonomy of potential applications I perceived then.)

In 2000, I still believe this. As part of my future work, I want to finish the work I outlined in that tech report: in particular,

to characterize more precisely formally the families of problems for which this technology is useful;

and then to develop a family of applications that demonstrate this potential.

(I have several exciting applications in progress.)

However, I also want to move into new terrain, and to identify and characterize new security and privacy problems that are emerging with new technology. One area that is particularly promising is Pervasive Computing: scientists at IBM, MIT, and elsewhere are proposing visions of small portable devices that become a user's universal portal for communication and computation.

Roughly speaking, the proposed Pervasive Computing world is much like the current Web infrastructure, only more so. Consider all the daily tasks for which one currently uses a browser; Pervasive Computing proposes even more tasks, more connectivity, and more executable content, from a larger network.

Each of these amplified areas raises new security risks. For example:

PKI.
Pervasive Computing will require more machines and more interconnections than the Web. However, we have not even solved the problem of establishing a meaningful public-key infrastructure for just the servers on the Web! (How many sophisticated Web users can even describe what the server certificate on the last SSL connection they made meant?) How do we do this for the myriad machines, controlling entities, and trust environments in the pervasive world?

Privacy.
More interconnections means more opportunities for collecting information about individual's activities---perhaps in ways that are not considered acceptable. Currently, security-concerned Web users can ensure approximate data isolation by isolating machines: no Web browsing or unknown executables on the machine with the sensitive source code and build environments; no political activism or embarrassing love letters on the work machine.
However, when everything comes through a single portal, and when the portal connects and interacts without the conscious involvement of the user, how does a user ensure that the wrong categories of data don't get exposed at the wrong times? (What does this even mean?)
Addressing this threat requires a precise definition of what "correct" behavior really is---which in turn requires a language in which to express and reason about proposed definitions.

Device Integrity.
Currently, one of the major security threats in Web browsing is executable content such as applets and Word documents. However, a user generally cannot be attacked from a Web site if they don't visit it. Similarly, a major privacy threat consists of the referrer field; a user can avoid that by using conscientious surfing patterns.
However, visions of pervasive computing usually entail a personal portal continually and automatically uploading the executables it needs for an environment from that environment. How are we going to avoid the endless series of vulnerabilities that Java had?

Usable Security.
How can a user make meaningful trust judgments about services and information?
Researchers describe a vision where, while driving to a meeting, an executive's personal portal learns of traffic problems and informs its user of a detour. Because of this feature, an adversary who can penetrate (or impersonate) a machine somewhere in this data path can direct selected drivers to side-routes chosen by the adversary---potentially making it substantially easier to arrange simple robberies or even kidnappings and assassinations.
We need an infrastructure where the personal portal can know a trust level of the information it is presenting---and where its user interface can communicate this meaningfully to its user. (How many Web users know how to disable Java and JavaScript in their browsers, or how to check what level of SSL encryption their browser has been set to accept?). We haven't solved this with current browsers. Meaningful user management of an even smaller device with even broader functionality will be critical.

At Carnegie Mellon, I learned how to do research; at Los Alamos, I learned the urgency of e-commerce and e-government problems; and at IBM Watson, I was able to carry out research that, in conjunction with a product effort, did something about some of these problems. I plan to keep making a difference.