Wednesday, September 6, rd International Conference on Trust, Privacy & Security in Digital Business Kraków, Poland, September 4-8, 2006 Panel Discussion: Is Security Without Trust Feasible ? Prof. Leszek Lilien (Chair) Department of Computer Science Western Michigan University Kalamazoo, Michigan, USA

Sept.. 6, 2006 Introduction Hypothesis: Feasibility of security without trust is a perception, not a reality Hypothesis: Feasibility of security without trust is a perception, not a reality Why “feasibility of security without trust” might be perceived Why “feasibility of security without trust” might be perceived Reason 1) User’s perspective (rather than computing system perspective) on security-trust relationships in computing Reason 2) Lack of trust documentation/specifications 2

Sept.. 6, 2006 Reason 1: User’s Perspective on Security- Trust Relationships in Computing System-level perspective: Security is built upon trust System-level perspective: Security is built upon trust System-level analysis should show that mechanisms providing security in computing systems rely on trust assumptions System-level analysis should show that mechanisms providing security in computing systems rely on trust assumptions User-level relationship: Trust is built upon security User-level relationship: Trust is built upon security Users of computing systems trust only systems that are (among others) secure Users of computing systems trust only systems that are (among others) secure => From users’ perspective, trust without security is not feasible in computing systems BUT From users’ perspective, trust is not perceived as a basis of system security From users’ perspective, trust is not perceived as a basis of system security => security without trust is feasible in computing systems 3

Sept.. 6, 2006 Reason 2: Lack of Trust Documentation/Specifications To analyze Reason 2 for perception of feasibility of “security without trust,” a few preliminaries must be discussed To analyze Reason 2 for perception of feasibility of “security without trust,” a few preliminaries must be discussed Trust in closed and open computing systems (or social systems) Trust in closed and open computing systems (or social systems) Closed systems (or subsystems) Closed systems (or subsystems) All components are known a priori All components are known a priori Open systems (or subsystems) Open systems (or subsystems) Components that are “strangers” (not known a priori) can join the system Components that are “strangers” (not known a priori) can join the system 4

Sept.. 6, 2006 Trust in closed and open computing systems – cont. Trust in closed and open computing systems – cont. Claim 1a: The proper level of component trustworthiness in closed systems can be assured a priori Claim 1a: The proper level of component trustworthiness in closed systems can be assured a priori Once assured, it can then be assumed by component’s users Once assured, it can then be assumed by component’s users Users are other system components, incl. humans Users are other system components, incl. humans Claim 1b: The proper level of component trustworthiness in open systems must be assured in real time Claim 1b: The proper level of component trustworthiness in open systems must be assured in real time No trust level can be assumed a priori No trust level can be assumed a priori Trust level for a stranger is unknown / uncertain Trust level for a stranger is unknown / uncertain Dynamically determined by each stranger’s partner Dynamically determined by each stranger’s partner 5

Sept.. 6, 2006 Claim 2: Trust is pervasive in computing systems (as in social systems) Claim 2: Trust is pervasive in computing systems (as in social systems) Bec. trust relationships always exist between system components Bec. trust relationships always exist between system components As they always exist among people and artifacts in a society As they always exist among people and artifacts in a society Claim 3: Too often trust relationships are not documented Claim 3: Too often trust relationships are not documented 6

Sept.. 6, 2006 Types of trust documentation Types of trust documentation 1) Embedded trust documentation - trust specifications encoded within software Software processes these trust specs Software processes these trust specs Process = collect trust data, verify data, calculate trust values, … Process = collect trust data, verify data, calculate trust values, … 2) External trust documentation – written trust specifications not within software No processing of trust specs by software No processing of trust specs by software 3) Missing trust documentation – no trust specifications exist 7

Sept.. 6, 2006 Claim 4: Claim 4: Missing trust documentation should be disallowed in any system (whether closed or open) Missing trust documentation should be disallowed in any system (whether closed or open) External trust documentation may be used in closed systems External trust documentation may be used in closed systems System components can rely on assured trust assumptions System components can rely on assured trust assumptions Software not required to process trust specs in the real time Software not required to process trust specs in the real time Embedded trust specifications must be used in open systems Embedded trust specifications must be used in open systems System components can not rely on assured trust assumptions System components can not rely on assured trust assumptions Software required to process embedded trust specs in the real time Software required to process embedded trust specs in the real time 8

Sept.. 6, 2006 >>> optional >> optional <<< Examples of externally documented trust specifications that are acceptable Examples of externally documented trust specifications that are acceptable Implicit stated trust among modules of a computing system from a single software house Implicit stated trust among modules of a computing system from a single software house A closed system A closed system Implicit stated trust among web sites administered by a single company Implicit stated trust among web sites administered by a single company A closed system A closed system 9

Sept.. 6, 2006 Effectiveness and costs of trust specifications Effectiveness and costs of trust specifications Embedded trust specifications result in best security but are most expensive Embedded trust specifications result in best security but are most expensive Must be used wherever required Must be used wherever required Required in open systems Required in open systems External trust specifications can provide acceptable security at a lower cost External trust specifications can provide acceptable security at a lower cost Should be used wherever allowed Should be used wherever allowed Allowed in closed systems Allowed in closed systems Missing trust specifications are unacceptable in terms of security Missing trust specifications are unacceptable in terms of security 10

Sept.. 6, 2006 Is security without trust feasible in computing systems? „Security without trust” might seem feasible in computing systems „Security without trust” might seem feasible in computing systems Might even seem common Might even seem common However, the reality is that … Claim 5: … Impression of „security without trust” is misleading Claim 5: … Impression of „security without trust” is misleading If no trust relationships are documented in a system, it does not mean that there are none If no trust relationships are documented in a system, it does not mean that there are none 11

Sept.. 6, 2006 Conclusions Recall my Hypothesis: Feasibility of security without trust is a perception, not a reality Recall my Hypothesis: Feasibility of security without trust is a perception, not a reality I analyzed 2 reasons why “feasibility of security without trust” might be perceived I analyzed 2 reasons why “feasibility of security without trust” might be perceived Reason 1: User’s perspective (rather than computing system perspective) on security-trust relationships in computing Reason 1: User’s perspective (rather than computing system perspective) on security-trust relationships in computing Reason 2: Lack of trust documentation/specifications Reason 2: Lack of trust documentation/specifications Based on the analysis of Reasons 1 & 2, Based on the analysis of Reasons 1 & 2, my answer to the panel question is: Security without trust is not feasible in computing systems 12

Sept.. 6, 2006 Thank you very much for your time and attention!

Sept.. 6, This page left blank intentionally.

Sept.. 6, This page left blank intentionally.

Sept.. 6, 2006 Publications on Oppnets (intensive work on oppnets started in our WiSe Lab in December 2005) 1.Leszek Lilien and Ajay Gupta, ” Opportunistic Networks for Emergency Preparedness and Response” (submitted for publication). 2.Leszek Lilien, Z. Huma Kamal, and Ajay Gupta, "Opportunistic Networks: Research Challenges in Specializing the P2P Paradigm,” Proc. 3rd International Workshop on P2P Data Management, Security and Trust (PDMST’06), Kraków, Poland, September Leszek Lilien, “Developing Specialized Ad Hoc Networks: The Case of Opportunistic Networks,” Proc. Workshop on Distributed Systems and Networks at the WWIC 2006 Conference,Bern, Switzerland, May 2006 (invited paper, proceedings to appear). 3.Leszek Lilien, “Developing Specialized Ad Hoc Networks: The Case of Opportunistic Networks,” Proc. Workshop on Distributed Systems and Networks at the WWIC 2006 Conference, Bern, Switzerland, May 2006 (invited paper, proceedings to appear). 4.Leszek Lilien, Z. Huma Kamal, Vijay Bhuse and Ajay Gupta, "Opportunistic Networks: The Concept and Research Challenges in Privacy and Security,” Proc. International Workshop on Research Challenges in Security and Privacy for Mobile and Wireless Networks (WSPWN 2006), Miami, Florida, March B. Bhargava, L. Lilien, A. Rosenthal, and M. Winslett, “Pervasive Trust,” IEEE Intelligent Systems, vol. 19(5), Sep./Oct.2004, pp (first brief mention of the oppnet idea, in the form of malevolent opportunistic sensor networks). 16

Sept.. 6, 2006 WiSe Lab Experience in Sensornets – Selected Projects Since January 2003 NOTE: Results directly useful for oppnets are marked with an asterisk (*)  Designing of WiSe Security Protocols: DSPS  Location Tracker Using Motes (*)  RHS: Remote Home Surveillance (*)  Directed Diffusion: Attacks & Countermeasures  Improving the Accuracy of Mote Measurements by Using Neural Networks  SOMS: Smart Occupancy Monitoring System Using Motes (*)  Comparative Study of Network Simulators  Collaborative Image Processing (*)  DENSe: a Development Environment for Networked Sensors  Incorporating Mobile-ware in Distributed Computations / Grids (*)  Extending the ns-2 Simulator to Satellite and WCN Simulations  Smart Antennas for WCNs  Energy Efficient MAC Protocols for IEEE x  A Wireless Security Testing System (*)  Mobile and Self-Calibrating Irrigation System  Collective Communications for Sensornets (*) 17