Presentation on theme: "1 Risks in Anonymous Distributed Computing Systems Michael J. Ciaraldi David Finkel Craig E. Wills Worcester Polytechnic Institute Worcester, MA 01609."— Presentation transcript:
1 Risks in Anonymous Distributed Computing Systems Michael J. Ciaraldi David Finkel Craig E. Wills Worcester Polytechnic Institute Worcester, MA USA Presented at International Network Conference 2000 Plymouth, England Copyright 2000 Michael J. Ciaraldi, David Finkel, and Craig E. Wills
2 Overview zAnonymous Distributed Computing Systems yWhat are they? zWhat are the risks? yMost are well-known yADCSs face some unique challenges. zWhich risks can be addressed, and how?
3 Anonymous Distributed Computing Systems
4 Distributed Computing Systems zTraditional vs. zAnonymous
5 Traditional Distributed Systems zAutonomous systems yStandalone machines yExplicit Services with explicit authorization xtelnet, ftp zDistributed operating systems yAppear as a single virtual machine ySingle administrative domain zNetwork file systems yShared resources ySingle administrative domain
6 Anonymous Distributed Computing Systems zTypes of Nodes zCharacteristics zApproaches
7 Types of Nodes in ADCS zDistributor nodes yDistribute pieces of a calculation. zClient nodes yExecute pieces and report back to distributor. zPortal nodes yDirect clients to distributors.
8 Characteristics of ADCS zPotentially millions of nodes. zClient nodes vary in power and architecture. zClients controlled by different administrative domains. zClients may be unaware of each other. zClients not always available for ADCS. zInternet communications unreliable and at various speeds. zClients may crash or withdraw at any time. zA client may be in several ADCSs. zClients may volunteer or be paid (micropayments).
9 Approaches in ADCS zOne-Time Download: yJust once, client downloads an executable program from a portal. yTo participate, client program contacts portal. yExamples: zEach-Time Download: yClient downloads Java applets or ActiveX controls each time. yExamples: xPOPCORN, Charlotte, distriblets
11 Risks zWhere are they? zWhat are they? zCan they be reduced or eliminated? yBy technology? yBy human diligence?
12 Types of Risks and Where They Occur zInternet Communication yInherently unreliable yPasses through others’ machines xCan be intercepted and/or altered. yAnonymous xWhat is the sender’s true IP address? xWho is the sender, anyway?
13 Types of Risks and Where They Occur II zKnowing identity of distributor yRecommended by others yConfidence that software is not harmful xTo client xTo others, e.g. DoS, cracking. yAccountability zKnowing identity of client yConfidentiality yPayment yInvalid results
14 Dealing With Risks
15 Dealing With Risks zCommunication problems zMalicious client code yAttacks the client or another machine. zCounterfeit client code
16 Accidental Communication Problems zChecksums guard against corruption. zTimestamps guard against stale data.
17 Deliberate Communication Problems zIPSec yProvides encryption and authentication end- to-end. yGuards against interception and/or modification en route. yIs only a protocol.
18 IPSec Is Not Enough zADCSs must use asymmetric (public key) encryption. zThis requires knowing the public key of the other party. yOr whoever the other party claims to be. zTo confirm the key, use a digital certificate from a Certification Authority (CA).
19 Problems with Certification Authorities zCan the CA be trusted? yCould be run by an unethical organization. yEmployees could be corrupt. zCan the CA guarantee the identity of the entity?
20 Problems with Certification Authorities II zCan the entity be trusted to be non- malicious and competent? yCan all its members? zCertificates expire and are revoked yBut not instantaneously. zThese are primarily human problems, not technological.
21 Malicious Client Code zMechanism: yScreen savers and ActiveX controls vs. yJava applets zExamining source code
22 Screen Savers and ActiveX Controls zCould be yOne-time download (screen saver) yEach-time download (ActiveX) zPrivileges yEssentially unlimited in MS-Windows. yCan be limited by careful installation in Unix.
23 Java Applets zExecute in a “sandbox” with limited privileges. zCan still: yOpen windows ySend with your return address yConsume system resources. zCan only open a network connection back to the download server. yCannot directly participate in distributed attack. yLimits parallelism.
24 Examining Source Code zWho is competent to examine it? zYou have to send the source code. yConfidentiality? yHow to guard against counterfeit code?
25 Counterfeit Client Code: Why? zMaliciousness zCompetition zDenial of service zPayment for services not rendered.
26 Counterfeit Client Code: Possible Defenses zPossibilities suggested by Popcorn: ySend the same computation to several independent clients. xWidely applicable, but expensive. yCheck the answers. xLess expensive, but not as applicable. yAre the resources spent on checking greater than those gained by parallelism?
27 Counterfeit Client Code: Other Possible Defenses zChallenge-response authentication. yIs it possible? yReverse engineering? yCould a Trojan Horse later corrupt or replace the client code? zNonces yCause authentication to expire.
28 Risks Facing Portals zConnecting through a well-known central portal is no guarantee of safety. yComputations still come from third parties. yPortal operators can identify computation sources, but not their safety. yPortal operators cannot determine what all their clients will consider ethical. yPortal operators must exercise due diligence, but this may not protect them from liability.
29 In Conclusion
30 Summary zADCSs are attractive. zThey present many risks, some unique. zSome of these risks: yHave technological solutions. yMay have human solutions. yHave no currently-known solution. zSo, keep thinking! zThe ultimate test: will users be deterred?