TRUST, Washington, D.C. Meeting January 9–10, 2006

The TRUST Agenda:Convergence of Technical and Policy Issues

Fred B. SchneiderChief Scientist

Fred B. Schneider 2TRUST, Washington, D.C. Meeting January 9–10, 2006

Policy + Technology

Trustworthiness problems invariably involve solutions with both technical and policy dimensions.– Neither dimension can be ignored!– Neither dimension provides the whole solution!

TRUST “force field” encourages collaborations that include technical and policy expertise.

Fred B. Schneider 3TRUST, Washington, D.C. Meeting January 9–10, 2006

T+P Example 1: Identify Theft

File stolen. File contains names, ss# etc.– Better authentication / authorization system software would make

retrieval much harder.– Encryption might help too.– New California Law incentivizes business to better secure personal

information. Users whose data was accessed must be notified. ($$$$) Encourages support for audit and other forensics.

Society conflates “identification” and “authentication”– SS# or other personal details should not suffice to authenticate an

agent (yet today it often does).– Use: Something you have [card], know [pin], are [iris scan]

People need to manage large sets of names + pins– Technology for secure storage, trusted computing, …– Technology for revocation

Privacy-preserving data mining obviates need to store ss#, etc

Fred B. Schneider 4TRUST, Washington, D.C. Meeting January 9–10, 2006

T+P Example 2: E-Voting

How to have assurance in electronic voting equipment?– Paper voter-verifiable audit trails.

Recounts become a nightmare

– Small simple trusted computing base. Still need to trust programmers and auditors Still need to trust physical security

– New cryptographic protocols. Still need to trust mathematicians Subliminal channels Human unreliability

What are we prepared to trust?What level of assurance would be reasonable?

Fred B. Schneider 5TRUST, Washington, D.C. Meeting January 9–10, 2006

T+P Example 3: Metrics

Systems today are not secure.– Technology does exist to make them more secure.– (Ultimately research will be needed, too.)

To build systems with better security has costs:– Increased development time.– Fewer features.– More and/or better developers.

Incentives for investment in security are needed.

Fred B. Schneider 6TRUST, Washington, D.C. Meeting January 9–10, 2006

Investing in Security

“Ideal” incentive scheme:– economically efficient.– apportions profits according to risk.– apportions costs according to benefit.

Supply chain realities:– producers / consumers / users– “surprise” implications of software universality

Fred B. Schneider 7TRUST, Washington, D.C. Meeting January 9–10, 2006

Bridging the Gap

A gap:– Self-interests of individuals.– Interests of greater society.

A bridge:– Avoid legal costs.– Avoid fines and damages.

Agent of change: accusations by– the government.– the private sector.

Fred B. Schneider 8TRUST, Washington, D.C. Meeting January 9–10, 2006

Liability for Software?

Law 101: “Negligence involves 5 elements:– Duty– Breach– Cause in fact– Proximate cause– Damages

… but two can be problematic for software.

Fred B. Schneider 9TRUST, Washington, D.C. Meeting January 9–10, 2006

Liability versus Duty

Duty as: Expectations for performance.– Unable to specify security performance…– Unable to measure security performance…

Duty as: Extent to which best practices employed in development:– Correspondence between process and results is

tenuous.

Fred B. Schneider 10TRUST, Washington, D.C. Meeting January 9–10, 2006

Damages

Damages can be disclaimed for use in certain (all?) settings.… breach of duty becomes moot.

The “Lloyds of London” conundrum:– What if nobody is willing to produce software for a

given market? Consumers must choose: abuse existing software or don’t

build systems

Fred B. Schneider 11TRUST, Washington, D.C. Meeting January 9–10, 2006

Insurance Model

Insurance enables management of risk:– Cost of compromise.– Cost of damages from negligence judgments.– Cost of fines from violating regulations.

Insurer would have to predict risks:– Historical data non-existent due to rapid and discontinuous

evolution.– Software is different: over-provisioning fails.

Couple insurance price to defacto standards and best practices.

– If only we could measure security to know what the pay-off is.– If only we could build actuarial tables for software.

Fred B. Schneider 12TRUST, Washington, D.C. Meeting January 9–10, 2006

Trustworthiness Metrics

Absence of– Metrics for evaluating trustworthiness– Specifications for describing trustworthiness

is a significant impediment to use of traditional incentives for deploying more secure systems.

(This is a technical problem that blocks deploying non-technical solutions.)

Fred B. Schneider 13TRUST, Washington, D.C. Meeting January 9–10, 2006

T+P Example 4: DRM

The Digital Rights Management landscape:– Copyright and other IP law– Business models designed to profit– Universal yet unsubtle nature of computers

The challenges:– Identify other points in this space

Must be viable (for society, for business, and given technology)

Must be able to get “there” from “here”.

Fred B. Schneider 14TRUST, Washington, D.C. Meeting January 9–10, 2006

Concluding Remarks

Great researchers, if left alone, will do great research. Researchers collaborate when it serves their interests.

TRUST’s Grande Experiment:– P+T collaborations, which

Make solving the real problems attractive. Make the development of deployment researcher’s solutions

attractive.