1. TRUST, Washington, D.C. Meeting January 9–10, 2006 The TRUST Agenda: Convergence of Technical and Policy Issues Fred B. Schneider Chief Scientist

2. TRUST, Washington, D.C. Meeting January 9–10, 2006Fred B. Schneider2 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.

3. TRUST, Washington, D.C. Meeting January 9–10, 2006Fred B. Schneider3 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

4. TRUST, Washington, D.C. Meeting January 9–10, 2006Fred B. Schneider4 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?

5. TRUST, Washington, D.C. Meeting January 9–10, 2006Fred B. Schneider5 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.

6. TRUST, Washington, D.C. Meeting January 9–10, 2006Fred B. Schneider6 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

7. TRUST, Washington, D.C. Meeting January 9–10, 2006Fred B. Schneider7 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.

8. TRUST, Washington, D.C. Meeting January 9–10, 2006Fred B. Schneider8 Liability for Software? Law 101: “Negligence involves 5 elements: – Duty – Breach – Cause in fact – Proximate cause – Damages … but two can be problematic for software.

9. TRUST, Washington, D.C. Meeting January 9–10, 2006Fred B. Schneider9 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.

10. TRUST, Washington, D.C. Meeting January 9–10, 2006Fred B. Schneider10 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

11. TRUST, Washington, D.C. Meeting January 9–10, 2006Fred B. Schneider11 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.

12. TRUST, Washington, D.C. Meeting January 9–10, 2006Fred B. Schneider12 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.)

13. TRUST, Washington, D.C. Meeting January 9–10, 2006Fred B. Schneider13 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”.

14. TRUST, Washington, D.C. Meeting January 9–10, 2006Fred B. Schneider14 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.