Table Of Content

(cid:0) Language Issues in Mobile Program Security (cid:0) (cid:1) Dennis Volpano and Geo(cid:0)rey Smith (cid:0) Departmentof ComputerScience(cid:0) Naval Postgraduate School(cid:0) Monterey(cid:0) CA (cid:1)(cid:2)(cid:1)(cid:3)(cid:2)(cid:0) USA(cid:0) email(cid:4) volpano(cid:5)cs(cid:6)nps(cid:6)navy(cid:6)mil (cid:1) School of ComputerScience(cid:0) Florida International University(cid:0)Miami(cid:0) FL (cid:2)(cid:2)(cid:7)(cid:1)(cid:1)(cid:0) USA(cid:0) email(cid:4) smithg(cid:5)cs(cid:6)(cid:8)u(cid:6)edu Abstract(cid:0) Manyprogramminglanguages havebeendevelopedandim(cid:9) plemented for mobile code environments(cid:6) They are typically quite ex(cid:9) pressive(cid:6) But while security is an important aspect of any mobile code technology(cid:0) it is often treated after the fundamental design is complete(cid:0) in ad hoc ways(cid:6) In the end(cid:0) it is unclear what security guarantees can be made for the system(cid:6) We argue that mobile programming languages should be designed around certain security properties that hold for all well(cid:9)formed programs(cid:6) This requires a better understanding of the rela(cid:9) tionship between programming language design and security(cid:6) Appropri(cid:9) ate security properties mustbe identi(cid:8)ed(cid:6) Some of these properties and related issues are explored(cid:6) Anassortmentoflanguagesandenvironmentshavebeenproposedformobile code(cid:1) Some have been designed for use in executable content and others for use in agents (cid:2)(cid:3)(cid:4)(cid:5)(cid:6)(cid:7)(cid:8)(cid:1) Parallel e(cid:0)orts in extensible networks and operating systems havealsofocusedattentiononlanguagedesignformobility(cid:1)Thesee(cid:0)ortsinclude workonactivenetworks(cid:2)(cid:6)(cid:6)(cid:5)(cid:6)(cid:9)(cid:8)(cid:5)theSPINkernel(cid:2)(cid:10)(cid:5)(cid:3)(cid:11)(cid:8)andExokernel(cid:2)(cid:9)(cid:8)(cid:1)What these e(cid:0)orts have in common is a need for security(cid:1) We can roughly separate security concerns in this setting into code security andhost security(cid:1)Theformerisconcernedwithprotectingmobilecodefromun(cid:12) trusted hostswhile the latter is concernedwith protectinghosts fromuntrusted mobilecode(cid:1)Thismayseemabitarti(cid:13)cialsinceonemightliketomodelsecurity (cid:0) more symmetrically(cid:1) Nonetheless(cid:5) it is a useful distinction for now(cid:1) The code security problem seems quite intractable(cid:5) given that mobile code is under the control of a host(cid:1) For some proposals and a discussion(cid:5) see (cid:2)(cid:10)(cid:4)(cid:5)(cid:10)(cid:14)(cid:5)(cid:7)(cid:15)(cid:8)(cid:1) In the remainder of this paper(cid:5) we treat only the host security problem(cid:1) (cid:0) Host Security Our view of the problem is that mobile code is executed on a host which must be protected from privacy and integrity violations(cid:1) As far as privacy goes(cid:5) the (cid:0) ThismaterialisbaseduponactivitiessupportedbyDARPAandtheNationalScience FoundationunderAgreementNos(cid:6)CCR(cid:9)(cid:1)(cid:10)(cid:7)(cid:11)(cid:7)(cid:12)(cid:10) andCCR(cid:9)(cid:1)(cid:10)(cid:7)(cid:11)(cid:2)(cid:3)(cid:13)(cid:6) Toappearina special issue of LNCSon Mobile Agents andSecurity(cid:6) (cid:0) Onecanimagineamodelthatdoesnotdistinguishmobilecodefromahost(cid:0)treating both as mutuallysuspicious parties(cid:6) Report Documentation Page Form Approved OMB No. 0704-0188 Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if it does not display a currently valid OMB control number. 1. REPORT DATE 3. DATES COVERED 1998 2. REPORT TYPE 00-00-1998 to 00-00-1998 4. TITLE AND SUBTITLE 5a. CONTRACT NUMBER Language Issues in Mobile Program Security 5b. GRANT NUMBER 5c. PROGRAM ELEMENT NUMBER 6. AUTHOR(S) 5d. PROJECT NUMBER 5e. TASK NUMBER 5f. WORK UNIT NUMBER 7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION Naval Postgraduate School ,Center for Information Systems Security REPORT NUMBER Studies and Research (NPS CISR),Department of Computer Science,Monterey,CA,93943 9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S) 11. SPONSOR/MONITOR’S REPORT NUMBER(S) 12. DISTRIBUTION/AVAILABILITY STATEMENT Approved for public release; distribution unlimited 13. SUPPLEMENTARY NOTES Mobile Agents and Security, G. Vigna (Ed.), volume 1419 of Lecture Notes in Computer Science, pp. 25-43. Springer Verag, 199 14. ABSTRACT see report 15. SUBJECT TERMS 16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF 18. NUMBER 19a. NAME OF ABSTRACT OF PAGES RESPONSIBLE PERSON a. REPORT b. ABSTRACT c. THIS PAGE Same as 19 unclassified unclassified unclassified Report (SAR) Standard Form 298 (Rev. 8-98) Prescribed by ANSI Std Z39-18 host has private data that the code may need to perform some expected task(cid:1) The host wants assurance that it can trust the code not to leak the private data(cid:1) This is the classical view of privacy (cid:2)(cid:10)(cid:3)(cid:16)(cid:10)(cid:6)(cid:8)(cid:1) As for integrity(cid:5) the host has information that should not be corrupted(cid:1) Integrity(cid:5) in general(cid:5) demands total code correctness(cid:1) After all(cid:5) corrupt data can simply be the result of incorrect code(cid:1) There are(cid:5) however(cid:5) weakerforms of integrity (cid:2)(cid:6)(cid:8)(cid:1) We believe that an important characteristic of the mobile code setting is that the only observable events are those that can be observed from within a mobile program using language primitives and any host utilities(cid:1) There are no meta(cid:12)level observers of a mobile program(cid:17)sbehavior such as a person observing its execution behavior online(cid:1) Still(cid:5) depending on the language(cid:5) leaks can occur in many di(cid:0)erent ways(cid:5) some being much more di(cid:18)cult to detect than others(cid:1) (cid:0)(cid:1)(cid:0) Security Architectures A common approach to host security is to monitor the execution of mobile code(cid:1) You build an interpreter (cid:19)or virtual machine(cid:20) and slap the hands of any code that tries to touch something sensitive(cid:1) The interpreter obviously needs to know whether hand slapping is in order so it might appeal to some sort of trust framework to decide(cid:1) This arrangement is often called a (cid:21)security archi(cid:12) tecture(cid:22)(cid:1) Architecturesaregrowingquite elaborateasthe demand for lesshand slapping rises(cid:1) An example is the security architecture of the Java Developer(cid:17)s Kit JDK(cid:3)(cid:1)(cid:10) (cid:2)(cid:3)(cid:3)(cid:8)(cid:1) It blends some proven concepts(cid:5) such as protection domains(cid:5) access control(cid:5) permissions(cid:5) and code signing(cid:5) to allow applets more room to maneuver(cid:1) Netscape(cid:17)s (cid:21)Object Signing Architecture(cid:22) takes a similar approach(cid:1) One begins to wonder how much of these security architectures is really necessary(cid:1)Aretheyaresponsetoaneedforhostsecuritygivenmobileprograms written in a poorly(cid:12)designed mobile programming language(cid:23) Perhaps they can be simpli(cid:13)ed(cid:1) It would seem that this is possible if mobile code is written in a language that ensures certain security properties statically(cid:1) For example(cid:5) suppose that all well(cid:12)typed programs have a secure (cid:24)ow prop(cid:12) erty and that you know a certain program(cid:5) needing your personal identi(cid:13)cation number (cid:19)PIN(cid:20)(cid:5) is indeed well typed(cid:1) Then that program respects the privacy of your PIN and there is no need to check at runtime whether the program has permission to read it(cid:1) Our claim is not that security architectures will no longer have a role in the future(cid:1) We feel their role will simply change and be more formally justi(cid:13)ed(cid:1) For example(cid:5) they might carry out certain static analyses or proof checking(cid:5) perhaps along the lines of proof(cid:12)carrying code (cid:2)(cid:10)(cid:11)(cid:8)(cid:1) It should be possible(cid:5) for a given language(cid:5) to more clearly identify the role of the security architecture(cid:1) Certain desirable properties might be provable for all well(cid:12)formed programs in the language(cid:5) in which case some security checks can go away(cid:1) There are many di(cid:0)erent facets of mobile language design that in(cid:24)uence security in some way(cid:1) For example(cid:5) access control mechanisms (cid:19)encapsulation(cid:5) visibility rules(cid:5) etc(cid:1)(cid:20) are important(cid:1) We will limit our attention to some of the issues that impact host privacy and integrity(cid:1) On the integrity side(cid:5) we look at (cid:10) type safety(cid:1) Type safety is often said to be a key ingredient for security in Java andforsafekernelextensionswritteninModula(cid:12)(cid:6)(cid:2)(cid:10)(cid:8)(cid:1)Today(cid:5)somelanguageslike Standard ML evolve with formal treatments of the type system and semantics developed along the way(cid:1) This allows one to give formal accounts of type safety thatevolveaswell(cid:1)Otherlanguages(cid:5)likeJava(cid:5)lackthissortofformaltreatment(cid:1) Java has grown so rapidly that one quickly loses grasp of the impact of certain features on key properties like type safety(cid:1) Thenweexploretherelationshipbetweenprivacyandlanguagedesign(cid:1)There aremanywaysmobilecodecanleaksecrets(cid:1)Westartbyexamininginformation channels in a deterministic language(cid:1) We look at how they are in(cid:24)uenced by timing(cid:5) synchrony(cid:5) and nontermination(cid:1) Then we consider channels in a simple concurrent languagewith shared variables(cid:1) Some of these channels arise in very subtle ways(cid:1) For example(cid:5) they can arise from contention among processes for shared resources(cid:5)like CPU cycles(cid:1) (cid:1) Type Safety Whatistypesafety(cid:23)ConsiderthefollowingdescriptionfromaJavaperspective(cid:25) The Java language itself is designed to enforce security in the form of typesafety(cid:1)Thismeansthecompilerensuresthatmethodsandprograms donotaccessmemoryinwaysthatareinappropriate(cid:19)i(cid:1)e(cid:1)dangerous(cid:20)(cid:1)In e(cid:0)ect(cid:5) this is the most essential part of the Java security model in that it fundamentally protects the integrity of the memory map(cid:1) Secure Computing with Java(cid:0) Now and the Future(cid:1) (cid:2)(cid:3)(cid:3)(cid:4) JavaOne Conference(cid:5) InJava(cid:5)forexample(cid:5)codeshouldnotsomehowbeabletocoerceareferenceofa user(cid:12)de(cid:13)nedclassto one ofasystem classlikeSecurityManagerwhich therun(cid:12) time system (cid:19)Java Virtual Machine(cid:20) consults for access permissions(cid:1) Obviously(cid:5) this leads to trouble(cid:1) So at the heart of type safety is a guarantee against misinterpretation of data(cid:26)some sequence of bits being misinterpreted by an operation(cid:1) This has long been recognized as a serious computer security problem(cid:1) In a well(cid:12)known reportpublished twenty(cid:12)(cid:13)veyearsago(cid:5)Andersondescribesawaytopenetratea time(cid:12)sharingsystem(cid:19)HIS(cid:14)(cid:6)(cid:4)(cid:27)GCOSIII(cid:20)basedontheabilitytoexecuteauser(cid:17)s arraycontentswith an assignedGOTOstatementinFortran(cid:2)(cid:3)(cid:8)(cid:1)The statement can misinterpret its target(cid:5) the contents of an arbitrary integer variable(cid:5) as an instruction(cid:1) Today we see the same sort of problem in a di(cid:0)erent context (cid:2)(cid:10)(cid:28)(cid:8)(cid:1) (cid:2)(cid:1)(cid:0) Type Preservation An important property related to type safety is the idea of type preservation(cid:1) Type preservation is frequently confused with type soundness in the literature(cid:1) Soundness is a statement about the progressa program(cid:17)sexecution can makeif (cid:6) the programis well typed(cid:1) Typepreservation(cid:5)on the otherhand(cid:5) merelyasserts that if a well(cid:12)typed program evaluates successfully(cid:5) then it produces a value of the correcttype(cid:1) It isusually needed to provesoundness(cid:1)Forinstance(cid:5) youmay know that an expression(cid:5) with some type(cid:5) evaluates to a value(cid:5) but the value must have a speci(cid:13)c form in order for evaluation to proceed(cid:1) Type preservation gives you that the value has the same type as the expression(cid:5) and with some correctformstyping lemma(cid:5) youknow thatonly values ofthe formneededhave that type(cid:1) Thefollowing isa typicaltype preservationtheorem(cid:1) If (cid:0) isamemory(cid:5)map(cid:12) ping locations to values(cid:5) and (cid:1) is a location typing(cid:5) mapping locations to types(cid:5) then type preservation is stated as follows (cid:2)(cid:3)(cid:14)(cid:8)(cid:25) (cid:0) Theorem(cid:1) (cid:19)Type Preservation(cid:20)(cid:1) If (cid:0) (cid:0) e (cid:1) v(cid:2)(cid:0)(cid:5) (cid:1) (cid:0) e (cid:25) (cid:3)(cid:5) and (cid:0) (cid:25) (cid:1)(cid:5) then (cid:0) (cid:0) (cid:0) (cid:0) (cid:0) there exists (cid:1) such that (cid:1)(cid:2)(cid:1)(cid:5) (cid:0) (cid:25)(cid:1)(cid:5) and (cid:1) (cid:0)v (cid:25)(cid:3)(cid:1) The(cid:13)rsthypothesisofthetheoremstatesthatundermemory(cid:0)(cid:5)aclosedexpres(cid:12) (cid:0) sioneevaluatestoavaluev andamemory(cid:0)(cid:1)Nowemaycontainfreelocations(cid:5) hence e is typed with respect to a location typing (cid:1) which must be consistent with (cid:0)(cid:5) that is(cid:5) (cid:0) (cid:25) (cid:1)(cid:1) Evaluation of e can produce new locations that wind up (cid:0) in v(cid:5) so v is typed with respect to an extension (cid:1) of (cid:1)(cid:1) As one can clearly see from the theorem(cid:5) whether a language exhibits this propertydependsonthetypesystemandthesemantics(cid:1)Insomecases(cid:5)wemight expect that the type system needs to change if the property does not hold(cid:1) But the semantics itself may be to blame(cid:1) For instance(cid:5) consider the C program in Figure(cid:3)(cid:1)Whencompiledandexecuted(cid:5)(cid:0)cevaluatestoasignedintegerquantity(cid:5) char (cid:0)c(cid:1) f(cid:2)(cid:3) (cid:4)char cc (cid:5) (cid:6)a(cid:6)(cid:1) c (cid:5) (cid:7)cc(cid:1)(cid:8) g(cid:2)(cid:3) (cid:4)int i (cid:5) (cid:9)(cid:10)(cid:10)(cid:1)(cid:8) main(cid:2)(cid:3) (cid:4)f(cid:2)(cid:3)(cid:1) g(cid:2)(cid:3)(cid:1) printf(cid:2)(cid:11)(cid:12)c(cid:11)(cid:13)(cid:0)c(cid:3)(cid:1)(cid:8) Fig(cid:0)(cid:1)(cid:0)Dereferencing a dangling pointer yet it has type char(cid:1) If a C semantics prescribes this behavior(cid:5) then we cannot provetypepreservationwith respecttothat semantics(cid:29)theClanguagesaysthis program is unpredictable(cid:1) This is one place where type preservation and C col(cid:12) (cid:1) lide(cid:1) A formal C semantics should be clear about the outcome of dereferencing adanglingpointer(cid:5) if this isconsidered(cid:21)normal(cid:22)execution(cid:5) sothat typepreser(cid:12) vation can be proved(cid:1) Otherwise(cid:5) it should specify that execution gets stuck in thissituation(cid:5)againsothattypepreservationholds(cid:1)Inthelattercase(cid:5)animple(cid:12) mentationofCwould be requiredtodetectsuchanerroneousexecutionpointif thatimplementationweresafe(cid:1)Asafe(cid:19)faithful(cid:20)implementationguaranteesthat every execution is prescribed by the semantics(cid:5) so that programs cannot run in (cid:1) Thus(cid:0) perhaps(cid:0) it is not surprising that the SPIN group abandoned its attempts to de(cid:8)ne a (cid:14)safe subset of C(cid:15)(cid:0) adopting Modula(cid:9)(cid:2) instead (cid:16)(cid:11)(cid:17)(cid:6) (cid:7) ways not accounted for by the semantics(cid:1) This usually requires that an imple(cid:12) mentation do some runtime type checking unless it can be proved unnecessary by a type soundness result(cid:1) Remark(cid:1) Although a lack of pointer expressiveness is in general a good thing from a safety viewpoint(cid:5) manifest pointers (cid:19)references(cid:20) are still a substantial security risk(cid:1)A runtime system might accidentallyprovide an applicationa ref(cid:12) erencetoasystem securityobjectthat mustremaininvariant(cid:1)This wasdemon(cid:12) stratedinJavaforJDK(cid:3)(cid:1)(cid:3)(cid:1)Its entiretrust framework(cid:5)basedondigitally(cid:12)signed code(cid:5) was undermined when it was discovered that applications could obtain a (cid:2) reference to a code signers array(cid:1) (cid:2)(cid:1)(cid:2) Type Soundness Typepreservationtheoremsusuallytalkaboutsuccessfulevaluations(cid:1)Theirhy(cid:12) pothesesinvolveanassumptionaboutanevaluationproceedinginsomenumber of steps to a canonical form(cid:1) But this may not adequately address a type sys(cid:12) tem(cid:17)sintentions(cid:1)Anobjectiveofasystem mightbetoguaranteeterminationor to ensure that programs terminate only in speci(cid:13)ed ways (cid:19)e(cid:1)g(cid:1) no segmentation (cid:3) violations(cid:20)(cid:1) What is needed is a precise account of how a well(cid:12)typed program can behave when executed(cid:1) In other words(cid:5) we want a type soundness theorem that speci(cid:13)es all the possible behaviors that a well(cid:12)typed program can exhibit(cid:1) Traditional type soundness arguments based on showing that a well(cid:12)typed program does not evaluate to some special untypable value are inadequate for languages like C and Java(cid:1) There are many reasons why programs written in languages like Java and C may produce runtime errors(cid:1) Invalid class formats in Java and invalid pointer arithmetic in C are examples(cid:1) A type soundness theorem should enumerate all the errors that cause a well(cid:12)typed program to get stuck (cid:19)abort(cid:20) according to the semantics(cid:1) These are the errors that every safe implementation must detect(cid:5) One regards the type system as sound if none of these errors is an error that we expect the type system to detect(cid:1) This is essentially the traditional view of type soundness as a binary property(cid:1) But a key point to keep in mind is that whether a given type system is sound really dependsonourexpectationsofthetypesystem(cid:1)Thoughitmaybeclearwhatwe expect for languages like Standard ML(cid:5) it is less clear for lower(cid:12)level languages like C and assembler(cid:1) Forexample(cid:5)wegiveatypesystemforapolymorphicdialectofCin(cid:2)(cid:6)(cid:15)(cid:5)(cid:6)(cid:10)(cid:8)(cid:1) Thetype soundnesstheorem basicallysaysthat executing awell(cid:12)typedprogram either succeeds(cid:5)producingavalueofthe appropriatetype(cid:5) fails toterminate(cid:5)or gets stuck because of an attempt to (cid:2) Itisinterestingtoconsiderwhatsortofproofwouldhaverevealedtheproblem(cid:6)One strategy would be to try (cid:8)ndinga P(cid:9)time reduction from compromising the private key used in a digital signature to executing untrusted code(cid:6) It would also establish a computational lower boundon executinguntrustedcode using JDK(cid:7)(cid:6)(cid:7)(cid:6) (cid:3) Suchproperties are important in situations where you need guarantees against cer(cid:9) tain faults(cid:6) Anexampleis isolating execution behindtrust boundaries (cid:16)(cid:7)(cid:12)(cid:17)(cid:6) (cid:4) (cid:3) access a dead address(cid:5) (cid:3) access an address with an invalid o(cid:0)set(cid:5) (cid:3) read an uninitialized address(cid:5) or (cid:3) declare an empty or negative(cid:12)sized array(cid:1) The(cid:13)rsttwoerrorsareduetopointersinthelanguage(cid:1)Nowonemayexpectthe type system to detect the (cid:13)rst error in which case our type system is unsound(cid:1) However(cid:5)if one believes it is beyond the scope of a type system for C(cid:5) then our type system is sound(cid:1) Clearly if the list included an errorsuch asan attempt to applyanintegertoaninteger(cid:5)thenthetypesystemwouldgenerallyberegarded as unsound(cid:1) A better way to look at type soundness is merely as a property about the executions ofprogramsthat the typesystem saysareacceptable(cid:1)Thisallowsus tocomparetypesystemsforalanguagebycomparingtheirsoundnessproperties(cid:1) Some may be weakerthan others in that they requireimplementations to check typesatruntimeinordertoremainsafe(cid:1)Itisalsousefulfordeterminingwhether a particular language is suitable for some application(cid:1) Some of the errors listed in a formulation of soundness may be among those that an application cannot tolerate(cid:1) Further(cid:5) and perhaps most importantly(cid:5) it identi(cid:13)es those errors that an implementation must detect in order to safely implement the semantics(cid:1) For instance(cid:5) a safe implementation of C should trap any attempt to dereference a danglingpointer(cid:1)MostCimplementationsareunsafeinthisregard(cid:1)Oneexpects Java implementations to be safer(cid:5) but despite all the attention to typing and bytecode veri(cid:13)cation(cid:5) the current situation is unfortunately not as good as one might imagine(cid:1) (cid:4) Consider the Java class in Figure (cid:10)(cid:1) The class modi(cid:13)es itself by putting a CONSTANT Utf(cid:1) type tag for x in that part of the constant pool where a CONSTANT String type tag for x is expected by the ldc (cid:19)load from constant pool(cid:20) instruction(cid:1) Method exec gets a copy of itself in the form of a bytecode array(cid:1)Theclassiswelltyped(cid:5)yetitabortswitha(cid:21)segmentationviolation(cid:22)(cid:19)core dump(cid:20) in JDK(cid:3)(cid:1)(cid:3)(cid:1)(cid:3)(cid:5) evenwhen Java is run in (cid:21)verify(cid:22)mode(cid:1) Veri(cid:13)cation of the modi(cid:13)edbytecodesdoesfailusingtheverifyoptionoftheJavaclassdisassembler javap(cid:1)Onewouldexpectittoalsofailforthebytecodesdynamicallyconstructed in exec(cid:5) leading to a VerifyErrorwhen class SelfRefis run(cid:1) Instead we get a core dump(cid:1) So the JDK(cid:3)(cid:1)(cid:3)(cid:1)(cid:3) implementation of Java is unsafe(cid:1) Perhaps making class representations available in bytecode form needs to be reconsidered(cid:1) It becomes quite easy to dynamically construct classes that aredi(cid:18)cult toanalyzestaticallyfor securityguarantees(cid:1)Self(cid:12)modifying code(cid:5) in general(cid:5) makes enforcement of protection constraintsdi(cid:18)cult(cid:5) if not impossible(cid:1) Channel command programs in the M(cid:1)I(cid:1)T(cid:1) Compatible Time(cid:12)Sharing System (cid:19)CTSS(cid:20)(cid:5) for instance(cid:5) were years ago prohibited from being self(cid:12)modifying for this reason (cid:2)(cid:10)(cid:9)(cid:8)(cid:1) (cid:4) Abitofhistory(cid:6)Theclassstemsfromanattempttoimplementanactivenetworkin Java(cid:6) Active programs migrate among servers that invoke their exec methods(cid:6) An active program maintains state by modifying its own bytecode representation prior to being forwarded(cid:6) Yes(cid:0) it(cid:18)s a hack(cid:6) (cid:14) public class SelfRef implements ActiveProgram (cid:4) final String x (cid:5) (cid:11)aaba(cid:11)(cid:1) public void exec(cid:2)byte(cid:14)(cid:15) b(cid:13) MyLoader loader(cid:3) throws Exception (cid:4) if (cid:2)b(cid:14)(cid:16)(cid:17)(cid:15) (cid:5)(cid:5) (cid:18)x(cid:18)(cid:19)(cid:3) (cid:4) (cid:20)(cid:20) CONSTANT(cid:21)String b(cid:14)(cid:16)(cid:17)(cid:15) (cid:5) (cid:18)x(cid:18)(cid:16)(cid:1) (cid:20)(cid:20) set CONSTANT(cid:21)Utf(cid:19) b(cid:14)(cid:16)(cid:22)(cid:15) (cid:5) (cid:18)x(cid:18)(cid:18)(cid:1) b(cid:14)(cid:16)(cid:23)(cid:15) (cid:5) (cid:18)x(cid:18)(cid:18)(cid:1) Class classOf (cid:5) loader(cid:24)defineClass(cid:2)b(cid:13) (cid:18)(cid:13) b(cid:24)length(cid:3)(cid:1) ActiveProgram p (cid:5) (cid:2)ActiveProgram(cid:3) classOf(cid:24)newInstance(cid:2)(cid:3)(cid:1) p(cid:24)exec(cid:2)b(cid:13) loader(cid:3)(cid:1) (cid:8) else System(cid:24)out(cid:24)println(cid:2)x(cid:3)(cid:1) (cid:8) public static void main(cid:2)String(cid:14)(cid:15) argv(cid:3) throws Exception (cid:4) FileInputStream f (cid:5) new FileInputStream(cid:2)(cid:11)SelfRef(cid:24)class(cid:11)(cid:3)(cid:1) byte(cid:14)(cid:15) data (cid:5) new byte(cid:14)f(cid:24)available(cid:2)(cid:3)(cid:15)(cid:1) int c (cid:5) f(cid:24)read(cid:2)data(cid:3)(cid:1) MyLoader loader (cid:5) new MyLoader(cid:2)(cid:3)(cid:1) new SelfRef(cid:2)(cid:3)(cid:24)exec(cid:2)data(cid:13) loader(cid:3)(cid:1) (cid:8) (cid:8) Fig(cid:0)(cid:2)(cid:0) Typemismatchleading to segmentation violation in Java (cid:2) Privacy in a Deterministic Language Suppose we begin by considering a very simple deterministic programming lan(cid:12) guage with just variables(cid:5) integer(cid:12)valued expressions(cid:5) assignment(cid:5) conditionals(cid:5) while loops(cid:5) and sequential composition(cid:1) Programs are executed relative to a memorythat maps variables to integers(cid:1)If a programneeds I(cid:27)O(cid:5) then it simply reads from or writes to some speci(cid:13)c variables of the memory(cid:1) Further(cid:5) suppose thatsomevariablesofthememoryareconsideredprivatewhileothersarepublic(cid:1) Every program is free to use all variables of the memory and also knows which variables are public and which are private(cid:1) What concernsus is whether some program(cid:5)in this rather anemic language(cid:5) canalways produce(cid:5)inapublicvariable(cid:5)thecontentsofaprivatevariable(cid:1)There are many such programs(cid:5) some more complicated than others(cid:1) For instance(cid:5) one can simply assign a private variable to a public one(cid:5) not a terribly clever strategy for a hacker(cid:1) This is an example of an explicit channel(cid:1) Oronemighttrytodoitmoreindirectly(cid:5)onebitatatime(cid:5)asinFigure(cid:6)where PIN is private(cid:5) y is public(cid:5) and the value of mask is a power of two(cid:1) This is an example of an implicit channel(cid:1) It illustrates the kind of program we wish to reject because it does not respect the privacy of PIN(cid:1) We need to formalize the security property it violates(cid:1) (cid:11) while (cid:2)mask (cid:25)(cid:5) (cid:18)(cid:3) (cid:4) if (cid:2)PIN (cid:7) mask (cid:25)(cid:5) (cid:18)(cid:3) (cid:4) (cid:26)(cid:26) bitwise (cid:6)and(cid:6) y (cid:27)(cid:5) y (cid:28) mask (cid:26)(cid:26) bitwise (cid:6)or(cid:6) (cid:8) mask (cid:27)(cid:5) mask (cid:20) (cid:29) (cid:8) Fig(cid:0)(cid:3)(cid:0)Implicitchannel (cid:4)(cid:1)(cid:0) Privacy Properties We give a more formal statement of the privacy property we want programs to have in this simple deterministic language(cid:25) De(cid:5)nition(cid:1) (cid:19)Termination Security(cid:20)(cid:1) Suppose that c is a command and (cid:0) and (cid:0) (cid:0) (cid:4) are memories that agree on all public variables(cid:1) If (cid:0)(cid:0)c(cid:1)(cid:0) and (cid:4) (cid:0)c(cid:1)(cid:4) (cid:5) (cid:0) (cid:0) then (cid:0) and (cid:4) agree on all public variables(cid:1) (cid:0) (cid:19)The judgment (cid:0) (cid:0) c (cid:1) (cid:0) asserts that executing command c in initial mem(cid:12) (cid:0) ory(cid:0)terminatessuccessfully(cid:5)yielding(cid:13)nalmemory(cid:0)(cid:1)(cid:20)Intuitively(cid:5)Termination Security says that we can change the contents of private variables without in(cid:12) (cid:24)uencing the outcome of public variables(cid:1) In other words(cid:5) these changes cannot interferewiththe(cid:13)nalcontentsofpublicvariables(cid:1)Theaboveprogramdoesnot have this property(cid:1) Any change in the private PIN will result in a di(cid:0)erent (cid:13)nal value for the public variable y(cid:1) IstheTerminationSecuritypropertyanacceptableprivacypropertyforpro(cid:12) gramsinoursimpledeterministiclanguage(cid:23)Thatdependsonwhatisobservable(cid:1) ConsiderthesimilarprograminFigure(cid:7)(cid:1)Ifonecanrepeatedlyrunthisprogram while (cid:2)PIN (cid:7) mask (cid:5)(cid:5) (cid:18)(cid:3) (cid:4) (cid:8) y (cid:27)(cid:5) y (cid:28) mask Fig(cid:0)(cid:4)(cid:0) Channel fromnontermination with a di(cid:0)erent mask(cid:5) one for each bit of PIN(cid:5) then assuming y is initially zero(cid:5) therunswillcopyPINtoy(cid:1)OnePINbitisleakedtoyinasinglerun(cid:1)Weassume that(cid:5) after a speci(cid:13)c period of time(cid:5) if a run has not terminated then it never (cid:5) will(cid:5) and we move on to the next bit(cid:1) But although the program seems insecure(cid:5) it satis(cid:13)es Termination Security(cid:1) ChangestoPINcannotin(cid:24)uencetheoutcomeofyinasinglerunoftheprogram(cid:1) AfterchangingthePIN(cid:5)theprogrammaynolongerterminate(cid:5)butthisdoesnot violate Termination Security since it only applies to successful termination(cid:1) Consider another property(cid:25) (cid:5) The task obviously becomes mucheasier when we enrichthe language with threads and a clock(cid:6) Now each bit can be examined by an asynchronously(cid:9)running thread(cid:0) and after some timeout we can be fairly con(cid:8)dent that all nonzero bits have been properly set in y(cid:6) (cid:9) De(cid:5)nition(cid:1) (cid:19)O(cid:30)ine Security(cid:20)(cid:1) Suppose that c is a command and (cid:0) and (cid:4) are (cid:0) (cid:0) memories that agree on all public variables(cid:1) If (cid:0) (cid:0) c (cid:1) (cid:0)(cid:5) then there is a (cid:4) (cid:0) (cid:0) (cid:0) such that (cid:4) (cid:0)c(cid:1)(cid:4) (cid:5) and (cid:4) and (cid:0) agree on all public variables(cid:1) Notice that we have removed one of the two successful evaluation hypotheses from Termination Security(cid:1) The property basically says that changing private variables cannot interfere with the (cid:13)nal contents of public variables(cid:5) nor can it interfere with whether a program terminates(cid:1) We call the property O(cid:30)ine Security because it addresses only what one can observe about a program(cid:17)s behaviorif it is executed o(cid:30)ine(cid:5) orin batch mode (cid:19)one either sees the results of asuccessfulexecutionorisnoti(cid:13)edofsometimeoutthatwasreached(cid:20)(cid:1)Thetime it takesfora programtoterminateis not observed(cid:1)In adeterministic language(cid:5) O(cid:30)ineSecurityimpliesTerminationSecurity(cid:1)Actually(cid:5)theformulationofO(cid:30)ine Securityis suitablefortreatingnondeterminism asweshallsee(cid:1)Theprogramin Figure (cid:7) does not satisfy O(cid:30)ine Security(cid:1) Unfortunately(cid:5) there are other sources of channels(cid:1) Consider the program in Figure (cid:4)(cid:1) Again suppose we can repeatedly execute it with di(cid:0)erent masks(cid:1) if (cid:2)(cid:16) (cid:20) (cid:2)PIN (cid:7) mask(cid:3)(cid:3) (cid:4) (cid:8) y (cid:27)(cid:5) y (cid:28) mask Fig(cid:0)(cid:5)(cid:0) Channel frompartial operation It always terminates(cid:5) sometimes abnormally from division by zero(cid:1) The e(cid:0)ect(cid:5) however(cid:5) will be the same(cid:5) to copy PIN to y one bit at a time(cid:1) Henceifweincludepartialoperationslikedivision(cid:5)wehaveasituationwhere aprogrammighteithergetstuck(cid:19)terminateabnormally(cid:20)orrunforever(cid:5)depend(cid:12) ingonaprivatevariable(cid:1)Soweneedyetastrongero(cid:30)inesecurityproperty(cid:1)Ba(cid:12) sicallyitneedstoextendO(cid:30)ineSecuritywith thecondition thatifcterminates abnormally under (cid:0)(cid:5) then it does so under (cid:4) as well (cid:2)(cid:6)(cid:4)(cid:8)(cid:1) Noneoftheprecedingpropertiesaddressesanydi(cid:0)erenceinthetime required to run a program under two memories that can disagree on private variables(cid:1) These di(cid:0)erences can be used to deduce values of private variables in timing attacks on cryptographic algorithms(cid:1) For example(cid:5) a private key used in RSA modularexponentiationhasbeendeducedinthisfashion(cid:2)(cid:10)(cid:15)(cid:8)(cid:1)Di(cid:0)erencesintim(cid:12) ingundertwomemoriescanberuledoutbyrequiringthatexecutionsunderthe two memories proceed in lock step(cid:5) a form of strong bisimilarity(cid:1) This property(cid:5) which might be called Online Security(cid:5) is the most restrictive thus far(cid:1) But is it really necessaryfor mobile programs(cid:23) That depends on what is observable(cid:1) (cid:4)(cid:1)(cid:2) What is Observable(cid:6) Key to judging whether any of the preceding properties is necessary is deter(cid:12) mining what is observablein the model(cid:1) Whether a privacy propertyis suitable depends on how it treats observable events(cid:1) Notice that there is an observation (cid:28)