Wednesday, September 6, 2006

3rd International Conference on3rd International Conference on Trust, Privacy & Security in Digital BusinessTrust, Privacy & Security in Digital Business

Krak Krakóów, Polandw, Poland,, September 4-8, 2006 September 4-8, 2006

Panel DiscussionPanel Discussion::Is Is SSecurity ecurity WWithout Trust Feasible ?ithout Trust Feasible ?

Prof. Prof. Leszek LilienLeszek Lilien (Chair)(Chair)Department of Computer ScienceDepartment of Computer Science

Western Michigan UniversityWestern Michigan UniversityKalamazoo, Michigan, USAKalamazoo, Michigan, USA

Sept.. 6, 2006

IntroductionIntroduction

Hypothesis: Hypothesis: Feasibility of security without trust is Feasibility of security without trust is a a perceptionperception, not a reality, not a reality

Why “feasibility of security without trust” might be Why “feasibility of security without trust” might be perceivedperceived

Reason 1)Reason 1) User’s perspective User’s perspective (rather than computing (rather than computing

system perspective)system perspective) on on security-trust relationships in security-trust relationships in computingcomputing

Reason 2)Reason 2) Lack of trust documentation/specificationsLack of trust documentation/specifications

2

Sept.. 6, 2006

Reason 1: User’s Perspective on Reason 1: User’s Perspective on Security-Trust Relationships in Security-Trust Relationships in

ComputingComputing

System-level System-level perspective: perspective: Security is built upon trustSecurity is built upon trust System-level analysis should show that mechanisms System-level analysis should show that mechanisms

providing security in computing systems rely on trust providing security in computing systems rely on trust assumptionsassumptions

User-level User-level relationship: relationship: Trust is built upon securityTrust is built upon security Users of computing systems trust only systems that are Users of computing systems trust only systems that are

(among others)(among others) secure secure

=> => From users’ perspective, From users’ perspective, trusttrust without without securitysecurity is not is not feasiblefeasible in computing systemsin computing systems

BUTBUT From users’ perspective, trust is not perceived as a basis of From users’ perspective, trust is not perceived as a basis of

system securitysystem security=> => securitysecurity without without trusttrust is is feasiblefeasible in computing systemsin computing systems

3

Sept.. 6, 2006

Reason 2: Reason 2: Lack of Trust Lack of Trust Documentation/SpecificationsDocumentation/Specifications

To analyze Reason 2To analyze Reason 2 for perception of f for perception of feasibility of easibility of “security without trust,”“security without trust,” a few preliminariesa few preliminaries must be must be discusseddiscussed

Trust inTrust in closed and open closed and open computing systems computing systems (or (or social systems)social systems) Closed Closed systemssystems (or subsystems)(or subsystems)

All All componentscomponents are are known a prioriknown a priori

Open Open systemssystems (or subsystems)(or subsystems) Components that areComponents that are “strangers” “strangers” ((notnot known a known a

priori)priori) can join can join the system the system

4

Sept.. 6, 2006

Trust inTrust in closed and open closed and open computing systems – cont.computing systems – cont.

Claim 1a:Claim 1a: The proper level of The proper level of componentcomponent trustworthiness in closed systemstrustworthiness in closed systems can be can be assuredassured a a prioripriori

Once assured, it Once assured, it can then be assumedcan then be assumed by by component’s userscomponent’s users

Users are other system components, incl. humansUsers are other system components, incl. humans

Claim 1b:Claim 1b: The proper level of The proper level of componentcomponent trustworthiness in open systemstrustworthiness in open systems must be must be assured assured in real timein real time

NoNo trust level can be assumed a priori trust level can be assumed a priori Trust level for a stranger Trust level for a stranger is unknown / uncertainis unknown / uncertain

Dynamically determined Dynamically determined by each stranger’s partnerby each stranger’s partner5

Sept.. 6, 2006

Claim 2: Trust is pervasive Claim 2: Trust is pervasive in computing systems in computing systems (as (as in social systems)in social systems) Bec. trust relationships always exist between Bec. trust relationships always exist between

system componentssystem components As they always exist among people and artifacts in a As they always exist among people and artifacts in a

societysociety

Claim 3: Too oftenClaim 3: Too often trust relationships are trust relationships are not not documenteddocumented

6

Sept.. 6, 2006

Types of trust Types of trust documentationdocumentation

1)1) Embedded Embedded trust documentationtrust documentation - trust - trust specifications encoded within softwarespecifications encoded within software

Software processes these trust specsSoftware processes these trust specs Process = collect trust data, verify data, calculate trust values, Process = collect trust data, verify data, calculate trust values,

……

2)2) External External trust documentationtrust documentation – written trust – written trust specifications not within softwarespecifications not within software

No processing of trust specs by softwareNo processing of trust specs by software

3)3) Missing Missing trust documentationtrust documentation – no trust – no trust specifications existspecifications exist

7

Sept.. 6, 2006

Claim 4:Claim 4: MissingMissing trust documentation should be trust documentation should be disalloweddisallowed

in any systemin any system (whether closed or open)(whether closed or open)

ExternalExternal trust documentation trust documentation maymay be used in be used in closedclosed systemssystems

System components can rely on assured trust assumptionsSystem components can rely on assured trust assumptions Software Software notnot required to process trust specs in the real time required to process trust specs in the real time

EmbeddedEmbedded trust specifications trust specifications mustmust be used in be used in openopen systemssystems

System components can System components can notnot rely on assured trust assumptions rely on assured trust assumptions Software required to process embedded trust specs in the real Software required to process embedded trust specs in the real

timetime

8

Sept.. 6, 2006

>>> optional <<<>>> optional <<< Examples ofExamples of externally documented externally documented trust trust

specifications that are specifications that are acceptable acceptable IImplicit mplicit stated stated trust trust among modulesamong modules of a computing of a computing

system from a single software housesystem from a single software house A A closedclosed system system

IImplicit mplicit stated stated trust trust among web sitesamong web sites administered administered by a single companyby a single company

A A closedclosed system system

9

Sept.. 6, 2006

Effectiveness and costsEffectiveness and costs of trust specifications of trust specifications Embedded Embedded trust specificationstrust specifications result in result in best best

securitysecurity but are but are most expensivemost expensive Must be used wherever requiredMust be used wherever required

Required in Required in openopen systemssystems

ExternalExternal trust trust specificationsspecifications can providecan provide acceptable securityacceptable security at a at a lowerlower costcost

Should be used wherever allowedShould be used wherever allowed Allowed in Allowed in closedclosed systemssystems

MissingMissing trust specificationstrust specifications are are unacceptable in unacceptable in terms of securityterms of security

10

Sept.. 6, 2006

Is security without trust feasibleIs security without trust feasiblein computing systemsin computing systems??

„„Security without trust”Security without trust” might seem might seem feasible feasible in in computingcomputing systems systems Might Might eveneven seem seem common common

However, the reality is that …However, the reality is that …

CClaimlaim 5 5:: … … ImpressionImpression of „security without trust” is of „security without trust” is misleadingmisleading If no trust If no trust relationships arerelationships are documented in a systemdocumented in a system,, it does it does

not mean that there are nonenot mean that there are none

11

Sept.. 6, 2006

ConclusionsConclusions

Recall myRecall my Hypothesis: Hypothesis: Feasibility of security without Feasibility of security without trust is trust is a perceptiona perception, not a reality, not a reality

I analyzed 2 reasons why “feasibility of security I analyzed 2 reasons why “feasibility of security without trust” might be perceivedwithout trust” might be perceived

Reason 1:Reason 1: User’s perspective User’s perspective (rather than computing (rather than computing

system perspective)system perspective) on on security-trust relationships in security-trust relationships in computingcomputing

Reason 2:Reason 2: Lack of trust Lack of trust documentation/specificationsdocumentation/specifications

Based on the analysis of Based on the analysis of Reasons 1 & 2,Reasons 1 & 2,my answer to the panel question is: my answer to the panel question is: SSecurity without trustecurity without trust is is notnot feasible feasible in computing in computing systemssystems 12

Sept.. 6, 2006

Thank you very muchThank you very muchfor your time and attention!for your time and attention!

Sept.. 6, 2006

14

This page left blank intentionally.

Sept.. 6, 2006

15

This page left blank intentionally.

Sept.. 6, 2006

Publications onPublications on OppnetsOppnets(intensive work on oppnets started in our WiSe Lab in December 2005)(intensive work on oppnets started in our WiSe Lab in December 2005)

1.1. Leszek Lilien and Ajay Gupta, ” Leszek Lilien and Ajay Gupta, ” Opportunistic Networks Opportunistic Networks for for Emergency Preparedness and ResponseEmergency Preparedness and Response” (” (submitted submitted for for publication).publication).

2.2. Leszek Lilien, Z. Huma Kamal, and Ajay Gupta, "Leszek Lilien, Z. Huma Kamal, and Ajay Gupta, "Opportunistic Opportunistic Networks: Networks: Research Research Challenges in Specializing the P2P Challenges in Specializing the P2P ParadigmParadigm,” ,” Proc. Proc. 3rd International Workshop on P2P Data 3rd International Workshop on P2P Data Management, Security and TrustManagement, Security and Trust ( (PDMST’06PDMST’06), ), KrakóKraków, w, Poland, Poland, September 2006.September 2006.

3.3. Leszek Lilien, “Leszek Lilien, “Developing Specialized Ad Hoc Networks: The Developing Specialized Ad Hoc Networks: The Case of Opportunistic NetworksCase of Opportunistic Networks,” ,” Proc. Workshop on Distributed Proc. Workshop on Distributed Systems and NetworksSystems and Networks at the at the WWIC 2006 ConferenceWWIC 2006 Conference,, Bern, Bern, Switzerland, May 2006 (invited paper, proceedings to appear).Switzerland, May 2006 (invited paper, proceedings to appear).

4.4. Leszek Lilien, Z. Huma Kamal, Vijay Bhuse and Ajay Gupta, Leszek Lilien, Z. Huma Kamal, Vijay Bhuse and Ajay Gupta, ""Opportunistic Networks: The Concept and Research Challenges Opportunistic Networks: The Concept and Research Challenges in Privacy and Securityin Privacy and Security,” ,” Proc. International Workshop on Proc. International Workshop on Research Challenges in Security and Privacy for Mobile and Research Challenges in Security and Privacy for Mobile and Wireless NetworksWireless Networks ( (WSPWNWSPWN 20 200606), Miami, Florida, March 2006), Miami, Florida, March 2006..

5.5. B. Bhargava, L. Lilien, A. Rosenthal, and M. Winslett, “B. Bhargava, L. Lilien, A. Rosenthal, and M. Winslett, “Pervasive Pervasive TrustTrust,” ,” IEEE Intelligent SystemsIEEE Intelligent Systems, vol. 19(5), Sep, vol. 19(5), Sep../Oct.2004, pp. /Oct.2004, pp. 74-7774-77 ( (first brief mention of the oppnet ideafirst brief mention of the oppnet idea, in the form of , in the form of malevolent opportunistic sensor networks).malevolent opportunistic sensor networks). 16

Sept.. 6, 2006

WiSe Lab Experience in Sensornets WiSe Lab Experience in Sensornets – – Selected Projects Since January 2003Selected Projects Since January 2003

NOTE: Results directly useful for oppnets are marked with an asterisk NOTE: Results directly useful for oppnets are marked with an asterisk (*)(*)

DesignDesigninging of of WiSe WiSe Security Protocols: DSPSSecurity Protocols: DSPS Location Tracker Location Tracker UUsing Motessing Motes (*) (*) RHS: RHS: Remote Home SurveillanceRemote Home Surveillance (*) (*) Directed Diffusion: Attacks & CountermeasuresDirected Diffusion: Attacks & Countermeasures Improving the Accuracy of Improving the Accuracy of Mote Mote MeasurementsMeasurements

by by UUsingsing Neural NetNeural Networkworkss SOMS: SOMS: Smart Occupancy Monitoring System Smart Occupancy Monitoring System UUsing Motessing Motes (*) (*) Comparative Study of Network SimulatorsComparative Study of Network Simulators CollaborativeCollaborative Image Processing Image Processing (*) (*) DENSe: a Development Environment for Networked SensorsDENSe: a Development Environment for Networked Sensors Incorporating Incorporating MMobile-ware in obile-ware in DDistributed istributed CComputations / omputations / GGridrids (*)s (*) ExtendExtendinging the the ns-2 ns-2 Simulator Simulator to to SSatellite and WCN atellite and WCN SSimulationimulationss Smart Smart AAntennas for WCNsntennas for WCNs Energy Energy EEfficient MAC fficient MAC PProtocols for IEEE 802.11xrotocols for IEEE 802.11x A Wireless Security Testing SystemA Wireless Security Testing System (*) (*) Mobile and Self-Mobile and Self-CCalibrating Irrigation Systemalibrating Irrigation System Collective Collective CCommunications for ommunications for SSensornetsensornets (*) (*)

17