Software Protection: How to Crack Programs, and Defend Against Cracking Lecture 7: Tamperproofing II Minsk, Belarus, Spring 2014

Transcription

1 Software Protection: How to Crack Programs, and Defend Against Cracking Lecture 7: Tamperproofing II Minsk, Belarus, Spring 2014 Christian Collberg University of Arizona collberg c June 16, 2014 Christian Collberg

2 2 / 74 Overview 1 Distributed Software Protection Scenarios 2 R-MATE Protection Ideas 3 Algorithms 4 The Tigress System

3 R-MATE Scenarios

4 4 / 74 Scenario: Protecting networked computer games Alice P

5 4 / 74 Scenario: Protecting networked computer games Alice P Bob

6 4 / 74 Scenario: Protecting networked computer games Alice P Bob P

7 4 / 74 Scenario: Protecting networked computer games Alice P Bob Cached data P

8 4 / 74 Scenario: Protecting networked computer games Alice P Bob Cached data P

9 4 / 74 Scenario: Protecting networked computer games Alice P Bob Cached data P

10 Scenario: Protecting medical records Alice Medical records database Medical records must be protected from improper access and improper modification. Records are stored on one secure site, accessed from multiple (sometimes mobile) devices. 5 / 74

11 Scenario: Protecting medical records Alice Medical records database E k (brittney.pdf) Confidential medical data Bob Medical records must be protected from improper access and improper modification. Records are stored on one secure site, accessed from multiple (sometimes mobile) devices. 5 / 74

12 Scenario: Protecting medical records Alice Medical records database E k (brittney.pdf) Confidential medical data Bob Medical records must be protected from improper access and improper modification. Records are stored on one secure site, accessed from multiple (sometimes mobile) devices. 5 / 74

13 Scenario: Protecting medical records Alice Medical records database E k (brittney.pdf) Confidential medical data Bob Medical records must be protected from improper access and improper modification. Records are stored on one secure site, accessed from multiple (sometimes mobile) devices. 5 / 74

14 Scenario: Protecting medical records Alice Medical records database E k (brittney.pdf) Confidential medical data Bob C if (role="doctor") allow(read write) elsif (role="nurse") allow(read) elsif (role="janitor") allow(nothing) Medical records must be protected from improper access and improper modification. Records are stored on one secure site, accessed from multiple (sometimes mobile) devices. 5 / 74

15 Scenario: Protecting medical records Alice Medical records database E k (brittney.pdf) Confidential medical data Bob C if (role="doctor") allow(read write) elsif (role="nurse") allow(read) elsif (role="janitor") read allow(nothing) Medical records must be protected from improper access and improper modification. Records are stored on one secure site, accessed from multiple (sometimes mobile) devices. 5 / 74

16 Scenario: Protecting medical records Alice Medical records database E k (brittney.pdf) Confidential medical data Bob C if (role="doctor") allow(read write) elsif (role="nurse") allow(read) elsif (role="janitor") read allow(nothing) Medical records must be protected from improper access and improper modification. Records are stored on one secure site, accessed from multiple (sometimes mobile) devices. 5 / 74

17 6 / 74 Scenario: Wireless sensor networks Alice Bob Sensor networks are common in military scenarios.

18 Scenario: Wireless sensor networks Alice Radioactivity? Chemicals? Troup movements? CPU Sensor Wifi Code Bob Sensor networks are common in military scenarios. 6 / 74

19 Scenario: Wireless sensor networks Alice Radioactivity? Chemicals? Troup movements? CPU Sensor Wifi Code bad Bob bad Sensor networks are common in military scenarios. The enemy can intercept/analyze/modify sensors. 6 / 74

20 Selective black-outs, consumers can adjust usage based on current costs, small-scale energy production,... 7 / 74 Scenario: Advanced Metering Infrastructure Electrical Grid Distribution Control Center Smart Meter

21 Selective black-outs, consumers can adjust usage based on current costs, small-scale energy production,... 7 / 74 Scenario: Advanced Metering Infrastructure Electrical Grid Distribution Control Center Smart Meter

22 Selective black-outs, consumers can adjust usage based on current costs, small-scale energy production,... 7 / 74 Scenario: Advanced Metering Infrastructure Electrical Grid Distribution Control Center HACKED! Smart Meter

23 Selective black-outs, consumers can adjust usage based on current costs, small-scale energy production,... 7 / 74 Scenario: Advanced Metering Infrastructure HACKED! Electrical Grid Distribution Control Center HACKED! HACKED! Smart Meter HACKED!

24 Selective black-outs, consumers can adjust usage based on current costs, small-scale energy production,... 7 / 74 Scenario: Advanced Metering Infrastructure Electrical Grid Distribution Control Center HACKED! Disconnect HACKED! Disconnect Disconnect HACKED! Smart Meter Disconnect HACKED! Disconnect

25 8 / 74 The Remote Man-At-The-End Problem Client Trusted Server Client

26 8 / 74 The Remote Man-At-The-End Problem Client Trusted Server Client Untrusted Client

27 8 / 74 The Remote Man-At-The-End Problem Client Trusted Server Client Untrusted Client Client SW/HW

28 8 / 74 The Remote Man-At-The-End Problem Client Trusted Server Client Untrusted Client Client SW/HW Debugger Tracer Slicer Emulator Disassembler Decompiler

29 8 / 74 The Remote Man-At-The-End Problem Client Trusted Server Client Variant 1 Untrusted Client Client SW/HW Debugger Tracer Slicer Emulator Disassembler Decompiler

30 8 / 74 The Remote Man-At-The-End Problem Client Trusted Server Client Variant Variant 1 2 Untrusted Client Client SW/HW Debugger Tracer Slicer Emulator Disassembler Decompiler

31 8 / 74 The Remote Man-At-The-End Problem Client Trusted Server Client Variant Variant 1 Variant 2 3 Untrusted Client Client SW/HW Debugger Tracer Slicer Emulator Disassembler Decompiler

32 8 / 74 The Remote Man-At-The-End Problem Client Trusted Server Client Variant Variant 1 Variant 2 Variant 3 4 Untrusted Client Client SW/HW Debugger Tracer Slicer Emulator Disassembler Decompiler

33 Debugger Tracer Slicer Emulator Disassembler Decompiler Self protect against tampering! Definition (Man-At-The-End (MATE) Attacks) MATE attacks occur in any setting where an adversary has physical access to a device and compromises it by inspecting, reverse engineering, or tampering with its hardware or software.

34 Debugger Tracer Slicer Emulator Disassembler Decompiler Detect remote tampering! Self protect against tampering! Definition (Man-At-The-End (MATE) Attacks) MATE attacks occur in any setting where an adversary has physical access to a device and compromises it by inspecting, reverse engineering, or tampering with its hardware or software. Definition (Remote MATE (R-MATE) Attacks) R-MATE attacks occur in distributed systems where untrusted clients are in frequent communication with trusted servers over a network, and where a malicious user can get an advantage by compromising an untrusted device.

35 Protection Ideas

36 11 / 74 Algorithm Ideas 1 Split move functionality from untrusted to trusted site.

37 11 / 74 Algorithm Ideas 1 Split move functionality from untrusted to trusted site. 2 Measure ask untrusted site are you running the right code?

38 11 / 74 Algorithm Ideas 1 Split move functionality from untrusted to trusted site. 2 Measure ask untrusted site are you running the right code? 3 Time make untrusted site compute challenge within given time.

39 11 / 74 Algorithm Ideas 1 Split move functionality from untrusted to trusted site. 2 Measure ask untrusted site are you running the right code? 3 Time make untrusted site compute challenge within given time. 4 Monitor monitor messages to detect signs of tampering.

40 12 / 74 Algorithm Ideas... 5 Hardware make untrusted site run tamperproof hardware.

41 12 / 74 Algorithm Ideas... 5 Hardware make untrusted site run tamperproof hardware. 6 Encrypt make untrusted site compute in encrypted domain.

42 12 / 74 Algorithm Ideas... 5 Hardware make untrusted site run tamperproof hardware. 6 Encrypt make untrusted site compute in encrypted domain. 7 Update make untrusted site continuously update its code.

43 12 / 74 Algorithm Ideas... 5 Hardware make untrusted site run tamperproof hardware. 6 Encrypt make untrusted site compute in encrypted domain. 7 Update make untrusted site continuously update its code. 8 Local obfuscate/tamperproof/watermark/... code.

44 13 / 74 Protocol Monitoring Trusted site Untrusted site Application Transport Internet Link Physical f 1 ()

45 13 / 74 Protocol Monitoring OK? Trusted site Application Transport Internet Link Physical Untrusted site f 1 () HACKED! Monitor messages to detect signs of tampering

46 13 / 74 Protocol Monitoring OK? Trusted site Application Transport Internet Link Physical Untrusted site f 1 () HACKED! Monitor messages to detect signs of tampering Not all tampering will violate protocols!

47 Protocol Monitoring OK? Trusted site Application Transport Internet Link Physical Untrusted site f 1 () HACKED! Monitor messages to detect signs of tampering Not all tampering will violate protocols! Need to monitor every level of the network stack? 13 / 74

48 14 / 74 Code Splitting Trusted site Untrusted site f 1 () X f 2 () Move functionality from untrusted to trusted site.

49 14 / 74 Code Splitting Trusted site Untrusted site X f 1 () f 2 () Move functionality from untrusted to trusted site. Increases network traffic, server load.

50 14 / 74 Code Splitting Trusted site Untrusted site X f 1 () f 2 () Move functionality from untrusted to trusted site. Increases network traffic, server load.

51 14 / 74 Code Splitting Trusted site Untrusted site f 1 () X f 2 () Move functionality from untrusted to trusted site. Increases network traffic, server load. Extreme: Run all code server-side.

52 15 / 74 Trusted Hardware Trusted site Untrusted site f 1 () f 2 () Bob has a trusted hardware unit.

53 Trusted Hardware Trusted site Untrusted site f 1 () is OK! hash(f 1 ) f 2 () is OK! hash(f 2 ) Trust Bob s site! f 1 () f 2 () Bob has a trusted hardware unit. Bob proves that his site contains no untrustworthy software. Trusted hardware makes it harder for Bob to cheat. 15 / 74

54 16 / 74 Encryption Trusted site Untrusted site 6*7=? Alice wants to outsource computation to Bob

55 16 / 74 Encryption Trusted site Untrusted site 6*7=? 6,7 42 6*7=42! Alice wants to outsource computation to Bob Doesn t want him to learn her inputs and outputs!

56 Encryption Trusted site Untrusted site 6*7=? D(E(42))=42! E(6),E(7) E(42) E(6)*E(7) Alice wants to outsource computation to Bob Doesn t want him to learn her inputs and outputs! Bob performs operations on encrypted data. 16 / 74

57 17 / 74 Continuous Evolution Trusted site Untrusted site f 1 ()

58 17 / 74 Continuous Evolution Trusted site Untrusted site f 1 () HACKED!

59 17 / 74 Continuous Evolution Trusted site f 1 () Untrusted site f 1 () HACKED! f 1 () The server continously updates the client code

60 17 / 74 Continuous Evolution Trusted site f 1 () Untrusted site f 1 () HACKED! f 1 () The server continously updates the client code Gives Bob a smaller window to hack!

61 18 / 74 Challenge Timing Trusted site Untrusted site challenge compute Alice asks Bob to compute a special function

62 18 / 74 Challenge Timing Trusted site Untrusted site response OK? challenge response compute Alice asks Bob to compute a special function Does it return the right result?

63 18 / 74 Challenge Timing Trusted site Untrusted site response OK? took too long? challenge response compute Alice asks Bob to compute a special function Does it return the right result? Does Bob return the result fast enough?

64 Alice asks Bob to compute a special function Does it return the right result? Does Bob return the result fast enough? Accurate timing on the general Internet is hard / 74 Challenge Timing Trusted site Untrusted site response OK? took too long? challenge response compute

65 19 / 74 Local Defenses Trusted site Untrusted site f 1 () Local defenses don t involve the trusted site

66 19 / 74 Local Defenses Trusted site Untrusted site f 1 () Local defenses don t involve the trusted site Hash the executable...

67 19 / 74 Local Defenses Trusted site Untrusted site f 1 () Local defenses don t involve the trusted site Hash the executable... Hash the state...

68 Local Defenses Trusted site Untrusted site f 1 () Local defenses don t involve the trusted site Hash the executable... Hash the state... Obfuscate / 74

69 20 / 74 Local Defenses Hardened Processors Bob temperature radiation CPU if (tampering) destroy private data shut down R A M power clock penetration Hardware can be hardened against attack. Consequences for cost, heat, clock-rate, energy-use...

70 Slicing functions

71 22 / 74 Move all client code server-side Trusted site Untrusted site X f 1 () f 2 () High compute load for the server and high latency for the client.

72 23 / 74 Move some client code server-side Trusted site Untrusted site X f 1 () f 2 () Intermediate level solution: some computation on the server, some on the client. balance computation, network traffic, tamper-detection. Use slicing algorithms.

73 int f(int x,int y){ int a = 4*x + y; } int c; if (y < 5) c = a*x+4; else c = 2*x+4; int sum = 0; for(int i=a;i<10;i++) sum += i; return x*(sum+c); a is an important variable hide it on the server! Whenever the client needs a get it from the server! Move code that depends on a to the server better performance!

74 int f(int x,int y){ int a = 4*x + y; } int c; if (y < 5) c = a*x+4; else c = 2*x+4; int sum = 0; for(int i=a;i<10;i++) sum += i; return x*(sum+c); Compute a forward slice from a move this code to the server! Keep unimportant variable c on both the client and the server better performance! Don t move large data structures better performance! Overhead depends in how much of the program is hidden on the server. On a LAN: 3 to 58%.

75 int client(int x,int y){ f1(x,y); int Ha = 5; int Hc = 0; int Hsum = 0; } int c; if (!f2(y,x)){ c = 2*x+4; f3(c); } int sum = 0; f4(sum); f5(); return x*f6(); void f1(int x,int y){ Ha=4*x+y;} boolean f2(int y,int x){ if (y < 5){ Hc = Ha*x + 4; return true; } else return false;} void f3(int c){ Hc = c;} void f4(int sum){ Hsum = sum;} void f5(){ for(int i=ha;i<10;i++) Hsum += i;} int f6(){ return Hsum+Hc;}

76 int client(int x,int y){ f1(x,y); int Ha = 5; int Hc = 0; int Hsum = 0; } int c; if (!f2(y,x)){ c = 2*x+4; f3(c); } int sum = 0; f4(sum); f5(); return x*f6(); void f1(int x,int y){ Ha=4*x+y;} boolean f2(int y,int x){ if (y < 5){ Hc = Ha*x + 4; return true; } else return false;} void f3(int c){ Hc = c;} void f4(int sum){ Hsum = sum;} void f5(){ for(int i=ha;i<10;i++) Hsum += i;} int f6(){ return Hsum+Hc;}

77 28 / 74 Example Functionfis the original one You want to hide variablea Compute a forward slice ona(pink). You want to protect all the pink code put it on the server in functionshf1...hf6. The client accesses the hidden functions by making RPCs. c is a partially hidden variable. It resides both on the client and the server, but the code that updates it is split between the two.

78 29 / 74 Performance Runtime overhead from 3 to 58%.

79 29 / 74 Performance Runtime overhead from 3 to 58%. Depends on the amount of protection that is added: 1 how much of the program is hidden on the server? 2 how much extra communication?

80 Performance Runtime overhead from 3 to 58%. Depends on the amount of protection that is added: 1 how much of the program is hidden on the server? 2 how much extra communication? Zhang and Gupta s measurements were done over a local area network! 29 / 74

81 30 / 74 Performance Packet turnaround times: target site # hops ms rorohiko.cs.arizona.edu cse.asu.edu

82 Verification by timing

83 32 / 74 Pioneer In a very restricted environment you can measure aspects of the untrusted client to verify that it is running the correct software. Server m( C ) Client C

84 33 / 74 Assumptions 1 The the client s hardware configuration is known; 2 The client-server latency is known; 3 The client can only communicate with the server.

85 34 / 74 Applications 1 Check cell phone/pda/smartcard for viruses; 2 Check voting machine code; 3 Check for rootkits on machines on your LAN.

86 35 / 74 Algorithm Basic idea: ask client for a hash of its code. If 1 the hash is the wrong value, or 2 the computation took too long the client has cheated! The hash function is constructed such that it can t be computed quicker.

87 Server 1. t 1 currenttime() nonce random() send nonce V: Client hash6() send() SHA-1() E: executable

88 Server 1. t 1 currenttime() nonce random() send nonce V: Client 2. receive nonce c hash6(nonce, V) send c hash6() send() SHA-1() E: executable

89 Server 1. t 1 currenttime() nonce random() send nonce 3. receive c t 2 currenttime() if t 2 t 1 > t or c is wrong then FAIL V: Client 2. receive nonce c hash6(nonce, V) send c hash6() send() SHA-1() E: executable

90 Server 1. t 1 currenttime() nonce random() send nonce 3. receive c t 2 currenttime() if t 2 t 1 > t or c is wrong then FAIL V: Client 2. receive nonce c hash6(nonce, V) send c hash6() send() SHA-1() 4. h SHA-1(nonce E) send h E: executable

91 Server 1. t 1 currenttime() nonce random() send nonce 3. receive c t 2 currenttime() if t 2 t 1 > t or c is wrong then FAIL 5. receive h if h is wrong then FAIL V: Client 2. receive nonce c hash6(nonce, V) send c hash6() send() SHA-1() 4. h SHA-1(nonce E) send h E: executable

92 Server 1. t 1 currenttime() nonce random() send nonce 3. receive c t 2 currenttime() if t 2 t 1 > t or c is wrong then FAIL 5. receive h if h is wrong then FAIL E: Client 2. receive nonce c hash6(nonce, V) send c V: hash6() send() SHA-1() 4. h SHA-1(nonce E) send h 6. r execute E send r executable

93 Server 1. t 1 currenttime() nonce random() send nonce 3. receive c t 2 currenttime() if t 2 t 1 > t or c is wrong then FAIL 5. receive h if h is wrong then FAIL 7. receive r E: Client 2. receive nonce c hash6(nonce, V) send c V: hash6() send() SHA-1() 4. h SHA-1(nonce E) send h 6. r execute E send r executable

94 37 / 74 Algorithm The hash function must be time optimal, if not the client can use the time he saved to execute his own instructions without the server noticing.

95 37 / 74 Algorithm The hash function must be time optimal, if not the client can use the time he saved to execute his own instructions without the server noticing. Others have tried to extend the protocol to general scenarios highly controversial.

96 The Tigress System

97 39 / 74 Tigress and the R-MATE Problem Trusted Server RPC(...) Trusted Clients

98 39 / 74 Tigress and the R-MATE Problem Trusted Server RPC(...) Trusted Clients RPC(...) Untrusted Client

99 39 / 74 Tigress and the R-MATE Problem Trusted Server RPC(...) Trusted Clients 1) Cryptographic keys 2) Login details 3) Sensitive algorithms 4) Security checks Tamper! Asset Untrusted Client

100 39 / 74 Tigress and the R-MATE Problem Trusted Server RPC(...) Trusted Clients Detect! Respond! 1) Sever connection 2) Phone home 3) Legal remedies Untrusted Client

101 39 / 74 Tigress and the R-MATE Problem Trusted Server RPC(...) Trusted Clients 1) Overwhelm the adversary s analytical abilities 2) Facilitate the server s tamper detection 1 2 Code 3 Variant Untrusted Client

102 39 / 74 Tigress and the R-MATE Problem Trusted Server RPC(...) Trusted Clients Trade offs: Diversity vs. security vs. performance 1 2 Code 3 Variant Untrusted Client

103 40 / 74 The Tigress System Server Client Code Blocks Code Blocks Code Transformations Renewer server.c Strategies A fully generalized code diversity system for protecting against R-MATE attacks.

104 A fully generalized code diversity system for protecting against R-MATE attacks. The trusted server continuously pushes diverse code variants to the untrusted clients. 40 / 74 The Tigress System Server Client Code Blocks Code Blocks Code Transformations Renewer server.c Strategies

105 A fully generalized code diversity system for protecting against R-MATE attacks. The trusted server continuously pushes diverse code variants to the untrusted clients. 40 / 74 The Tigress System Server Client Code Blocks Code Blocks Code Transformations Renewer server.c Strategies

106 41 / 74 Attack Model 1 There is no unassailable root-of-trust: the attacker can modify local code/hardware.

107 41 / 74 Attack Model 1 There is no unassailable root-of-trust: the attacker can modify local code/hardware. 2 The attacker knows the system: primitive code transformations, strategies for combining transformations, the source code of the entire system. Similar to Kerckhoffs s principles.

108 Attack Model 1 There is no unassailable root-of-trust: the attacker can modify local code/hardware. 2 The attacker knows the system: primitive code transformations, strategies for combining transformations, the source code of the entire system. Similar to Kerckhoffs s principles. 3 The attacker doesn t know the randomization seed and can t predict the order in which transformations are applied; location in the code where they are applied. 41 / 74

109 Primitives

110 43 / 74 Primitive Transformations Primitives Blocks Server Client interpret(...) flatten(...) opaque(...) RPC_encode(...) var_encode(...) merge(...) split(...) rnd_args(...) Block scheduler Block request/ receive Code transformer Definition (Primitive) A primitive is a code transformation that 1 adds confusion to the client code, taxing the adversary s analytical abilities (obfuscation); 2 makes modifying client code more difficult ( tamperproofing); 3 makes detecting tampering easier (tamper-detect).

111 44 / 74 Preserving Protocols Protocol Preserving interpret(...) flatten(...) opaque(...) split(...) Server Code transformer Blocks foo 0,0 foo 0,1 bar 0,0 bar 1,0 Client Block Bag Protocol-preserving primitives generate confusion and hardening.

112 44 / 74 Preserving Protocols Protocol Preserving interpret(...) flatten(...) opaque(...) split(...) Non Protocol Preserving var_encode(...) merge(...) RPC_encode(...) rnd_args(...) Server Code transformer Blocks foo 0,0 foo 0,1 bar 0,0 bar 1,0 Client Block Bag Protocol-preserving primitives generate confusion and hardening. Non-protocol-preserving primitives generate incompatible block variants.

113 Protocol-preserving primitives generate confusion and hardening. Non-protocol-preserving primitives generate incompatible block variants. Randomized primitives generate many unique variants. 44 / 74 Preserving Protocols Protocol Preserving interpret(...) flatten(...) opaque(...) split(...) Non Protocol Preserving var_encode(...) merge(...) RPC_encode(...) rnd_args(...) Server SEED Code transformer SEED Blocks foo 0,0 foo 0,1 bar 0,0 bar 1,0 Client Block Bag

114 45 / 74 Protocol-Preserving Primitives Flatten flatten(f, seed) removes nested control flow.

115 45 / 74 Protocol-Preserving Primitives Flatten flatten(f, seed) removes nested control flow. Randomize Basic Block Ordering

116 46 / 74 Protocol-Preserving Primitives Interpret interpret(f,seed) turns a function into a specialized interpreter. prog={op1,op4,op9,...}; stack = [...]; pc =... op4: {push(pop()+pop()} op9: {push(pop()*pop()} op1: {push(pop()+ (pop()*pop())}

117 Protocol-Preserving Primitives Interpret interpret(f,seed) turns a function into a specialized interpreter. prog={op1,op4,op9,...}; stack = [...]; pc =... op4: {push(pop()+pop()} Randomize Dispatch Randomize op9: {push(pop()*pop()} op1: {push(pop()+ (pop()*pop())} Randomize 46 / 74

118 Protocol-Preserving Primitives Split split(f,seed) converts a function f into two functions called from f: void f1( int *a, int *x){ void f(int a){ int x; } void f(int a){ int x; } f1(&a,&x); f2(&a,&x); } void f2( int *a, int *x){ } 47 / 74

119 Protocol-Preserving Primitives Split split(f,seed) converts a function f into two functions called from f: void f(int a){ int x; } Randomize Split Point void f(int a){ int x; } f1(&a,&x); f2(&a,&x); void f1( int *a, int *x){ } void f2( int *a, int *x){ } 47 / 74

120 48 / 74 Protocol-Preserving Primitives Opaque opaque(f, seed) inserts non-functional code protected by an opaque predicate. (p q) T F T T F (p NULL) T BOGUS

121 p->p.next; q->q.next; 48 / 74 Protocol-Preserving Primitives Opaque opaque(f, seed) inserts non-functional code protected by an opaque predicate. (p q) T F T p q T F (p NULL) T BOGUS

122 Protocol-Preserving Primitives Opaque opaque(f, seed) inserts non-functional code protected by an opaque predicate. Randomize Transformation Type (p q) T F T p q Randomize Insertion Point T F (p NULL) T BOGUS Randomize Opaque Predicate p->p.next; q->q.next; 48 / 74

123 Non-Protocol-Preserving Primitives Merge merge(f 1,f 2,seed) combines functions f 1 (args 1 ) and f 2 (args 2 ) into f 1,2 (args 1 args 2,sel). void f1( int x){ } void f1( float y){ void f_1_2( int x, float y, int which){ if (which==1) else } } 49 / 74

124 Non-Protocol-Preserving Primitives rnd args rnd args(f, seed) randomly reorders f s formal parameters and adds extra, bogus, formals. void f(, ){ } void f( ){ },, 50 / 74

125 50 / 74 Non-Protocol-Preserving Primitives rnd args rnd args(f, seed) randomly reorders f s formal parameters and adds extra, bogus, formals. void f(, void f(,, Randomize Argument Order ){ } ){ } Insert Bogus Arguments

126 Non-Protocol-Preserving Primitives RPC encode RPC encode(n, seed) assigns a new random encoding of the n:th remote procedure callrpc(n,args). RPC(42,, ) RPC(93,,, ) If the adversary ignores block updates, he may execute an invalid block containing an RPC with an obsolete encoding. 51 / 74

127 Non-Protocol-Preserving Primitives RPC encode RPC encode(n, seed) assigns a new random encoding of the n:th remote procedure callrpc(n,args). RPC(42,, ) RPC(93,,, ) RPC(42,, ) RPC(93,,, ) Randomize RPC Randomize Argument Insert Bogus 51 / 74

128 52 / 74 RPC encode... RPC(42,, ) RPC(93,,, ) If the adversary ignores block updates, he may execute an invalid block containing an RPC with an obsolete encoding. This alerts the server of the tampering.

129 Mechanisms Strategies

130 54 / 74 System Overview Diversity Graph Diversity Graph main p 0 Code transformer Server Client main i 0,0 foo p 0 Diversity scheduler Overseer foo i 0,0 g p 0 foo i 0,1 Strategies temporal diversity spatial diversity semantic diversity The diversity graph represents the complex dependencies between blocks and protocols.

131 55 / 74 System Overview Diversity Graph Diversity Graph main p 0 Code transformer Server Client main i 0,0 foo p 0 Diversity scheduler Overseer foo i 0,0 g p 0 foo i 0,1 Strategies temporal diversity spatial diversity semantic diversity How does a transformation applied to one block force updates to other blocks? Initially, similar to a call graph.

132 Diversity Graph Forward Update Cycle int g; void foo(){ g++; } int main(){ foo(); }

133 Diversity Graph Forward Update Cycle int g; void foo(){ g++; } int main(){ foo(); } main p 0 main i 0,0 foo p 0 foo i 0,0 g p 0

134 Diversity Graph Forward Update Cycle int g; void foo(){ g++; } int main(){ foo(); } main p 0 main p 0 main i 0,0 main i 0,0 flatten(foo i foo p 0,0 ) 0 foo p 0 foo i 0,0 foo i 0,0 foo i 0,1 g p 0 g p 0

135 Diversity Graph Forward Update Cycle int g; void foo(){ g++; } int main(){ foo(); } main p 0 main p 0 main p 0 main i 0,0 main i 0,0 flatten(foo i foo p 0,0 ) encode var(gp 0 foo p 0 ) 0 main i 0,0 foo p 0 foo i 0,0 foo i 0,0 foo i 0,1 foo i 0,0foo i 0,1foo i 0,2 g p 0 g p 0 g p 0 g p 1

136 56 / 74 Diversity Graph Forward Update Cycle int g; void foo(){ g++; } int main(){ foo(); } main p 0 main p 0 main p 0 main p 0 main i 0,0 main i 0,0 main i 0,0 flatten(foo i foo p 0,0 ) 0 foo p 0 encode var(gp 0 ) foo p 0 rnd args(foop 0 ) main i 0,0 main i 0,1 foo p 0 foo p 1 foo i 0,0 foo i 0,0 foo i 0,1 foo i 0,0foo i 0,1foo i 0,2 foo i 0,0foo i 0,1foo i 0,2 fooi 1,0 g p 0 g p 0 g p 0 g p 1 g p 0 g p 1

137 Strategies Diversity maingraph p 0 Code transformer Server Client main i 0,0 foo p 0 Diversity scheduler Overseer foo i 0,0 g p 0 foo i 0,1 Strategies temporal diversity spatial diversity semantic diversity Temporal Diversity: program is continuously renewed. Spatial Diversity: defense-in-depth, multiple layers of primitives. Semantic Diversity: software aging, variants are not interchangeable. 57 / 74

138 58 / 74 Scheduler Operation // client.c int attribute((level(0))) g; void foo() attribute((level(9))); void foo() {g++; RPC(2,g);} int main() {foo();} Security Requirements profile foo 78% main 22% CIL Primitives interpret(...) flatten(...) opaque(...) RPC_encode(...) var_encode(...) merge(...) split(...) rnd_args(...) main 0,0 foo 0,0 Blocks g 0 foo 0,1 Server Client Diversity Graph main p 0 Code transformer main i 0,0 foo p 0 Diversity scheduler Overseer foo i 0,0 g p 0 foo i 0,1 Strategies temporal diversity spatial diversity semantic diversity

139 58 / 74 Scheduler Operation // client.c int attribute((level(0))) g; void foo() attribute((level(9))); void foo() {g++; RPC(2,g);} int main() {foo();} Security Requirements profile foo 78% main 22% Performance profile CIL Primitives interpret(...) flatten(...) opaque(...) RPC_encode(...) var_encode(...) merge(...) split(...) rnd_args(...) main 0,0 foo 0,0 Blocks g 0 foo 0,1 Server Client Diversity Graph main p 0 Code transformer main i 0,0 foo p 0 Diversity scheduler Overseer foo i 0,0 g p 0 foo i 0,1 Strategies temporal diversity spatial diversity semantic diversity

140 58 / 74 Scheduler Operation // client.c int attribute((level(0))) g; void foo() attribute((level(9))); void foo() {g++; RPC(2,g);} int main() {foo();} Security Requirements profile foo 78% main 22% Performance profile CIL Primitives interpret(...) flatten(...) opaque(...) RPC_encode(...) var_encode(...) merge(...) split(...) rnd_args(...) main 0,0 foo 0,0 Blocks g 0 foo 0,1 Server Client Diversity Graph main p 0 main i 0,0 foo p 0 Current diversity graph Code transformer Diversity scheduler Overseer foo i 0,0 g p 0 foo i 0,1 Strategies temporal diversity spatial diversity semantic diversity

141 58 / 74 Scheduler Operation // client.c int attribute((level(0))) g; void foo() attribute((level(9))); void foo() {g++; RPC(2,g);} int main() {foo();} Primitives interpret(...) flatten(...) opaque(...) RPC_encode(...) var_encode(...) merge(...) split(...) rnd_args(...) main 0,0 CIL Blocks g 0 foo 0,0 foo 0,1 Security Requirements profile foo 78% main 22% Server Current working set Performance profile Client Diversity Graph main p 0 main i 0,0 foo p 0 Current diversity graph Code transformer Diversity scheduler Overseer foo i 0,0 g p 0 foo i 0,1 Strategies temporal diversity spatial diversity semantic diversity

142 58 / 74 Scheduler Operation // client.c int attribute((level(0))) g; void foo() attribute((level(9))); void foo() {g++; RPC(2,g);} int main() {foo();} Primitives interpret(...) flatten(...) opaque(...) RPC_encode(...) var_encode(...) merge(...) split(...) rnd_args(...) Diversity Graph main p 0 main i 0,0 foo p 0 main 0,0 foo 0,0 CIL Blocks Current diversity graph g 0 foo 0,1 Code transformer Diversity scheduler Security Requirements profile foo 78% main 22% Server Current working set Primitives effect on diversity and performance Performance profile Client Overseer foo i 0,0 g p 0 foo i 0,1 Strategies temporal diversity spatial diversity semantic diversity

143 58 / 74 Scheduler Operation // client.c int attribute((level(0))) g; void foo() attribute((level(9))); void foo() {g++; RPC(2,g);} int main() {foo();} Primitives interpret(...) flatten(...) opaque(...) RPC_encode(...) var_encode(...) merge(...) split(...) rnd_args(...) Diversity Graph main p 0 main i 0,0 foo p 0 main 0,0 foo 0,0 CIL Blocks Current diversity graph g 0 foo 0,1 Code transformer Diversity scheduler Security Requirements profile foo 78% main 22% Server Current working set Primitives effect on diversity and performance Performance profile Active Set Client Functions on the client s call stack Overseer foo i 0,0 g p 0 foo i 0,1 Strategies temporal diversity spatial diversity semantic diversity

144 58 / 74 Scheduler Operation // client.c int attribute((level(0))) g; void foo() attribute((level(9))); void foo() {g++; RPC(2,g);} int main() {foo();} Primitives interpret(...) flatten(...) opaque(...) RPC_encode(...) var_encode(...) merge(...) split(...) rnd_args(...) Diversity Graph main p 0 main i 0,0 foo p 0 main 0,0 foo 0,0 CIL Blocks Current diversity graph g 0 foo 0,1 Code transformer Diversity scheduler Security Requirements profile foo 78% main 22% Server Current working set Primitives effect on diversity and performance Performance profile Active Set Client Functions on the client s call stack Overseer foo i 0,0 g p 0 foo i 0,1 Strategies temporal diversity spatial diversity semantic diversity Replacement rate

145 58 / 74 Scheduler Operation // client.c int attribute((level(0))) g; void foo() attribute((level(9))); void foo() {g++; RPC(2,g);} int main() {foo();} Primitives interpret(...) flatten(...) opaque(...) RPC_encode(...) var_encode(...) merge(...) split(...) rnd_args(...) Diversity Graph foo i 0,0 main p 0 main i 0,0 foo p 0 g p 0 foo i 0,1 main 0,0 foo 0,0 CIL Blocks Current diversity graph New diversity graph g 0 foo 0,1 Code transformer Diversity scheduler Strategies temporal diversity spatial diversity semantic diversity Security Requirements profile foo 78% main 22% Server Current working set New working set Primitives effect on diversity and performance Invalidated blocks Performance profile Active Set Client Functions on the client s call stack Overseer Replacement rate

146 59 / 74 Crime and Punishment Server Block scheduler if (!blockok()) punish(); getblock(22) Block request/ receive Client 1 Is the requested block part of the current block working set?

147 1 Is the requested block part of the current block working set? 2 Valid RPC number? Valid RPC argument types? 59 / 74 Crime and Punishment Server Block scheduler if (!blockok()) punish(); getblock(22) Block request/ receive Client if (!rpcok()) punish(); RPC(2,42)

148 1 Is the requested block part of the current block working set? 2 Valid RPC number? Valid RPC argument types? 59 / 74 Crime and Punishment Diversity Graph main p 0 Server Block scheduler if (!blockok()) punish(); getblock(22) Block request/ receive Client main i 0,0 if (!rpcok()) punish(); RPC(2,42) foo p 0 Active Set foo i 0,0 foo i 0,1 g p 0 if (!activesetok()) punish(); Overseer

149 1 Is the requested block part of the current block working set? 2 Valid RPC number? Valid RPC argument types? 59 / 74 Crime and Punishment Diversity Graph main p 0 main i 0,0 foo p 0 Server punish(){ send kill block; insert delays(); send delay block; send allocmem block; collect forensics; } Block scheduler if (!blockok()) punish(); if (!rpcok()) punish(); getblock(22) RPC(2,42) Active Set Block request/ receive Client foo i 0,0 foo i 0,1 g p 0 if (!activesetok()) punish(); Overseer

150 Security Evaluation

151 61 / 74 Crime and Punishment Server Block scheduler if (!blockok()) punish(); getblock(22) Block request/ receive Client 1 Is the requested block part of the current block working set?

152 1 Is the requested block part of the current block working set? 2 Valid RPC number? Valid RPC argument types? 61 / 74 Crime and Punishment Server Block scheduler if (!blockok()) punish(); getblock(22) Block request/ receive Client if (!rpcok()) punish(); RPC(2,42)

153 1 Is the requested block part of the current block working set? 2 Valid RPC number? Valid RPC argument types? 61 / 74 Crime and Punishment Diversity Graph main p 0 Server Block scheduler if (!blockok()) punish(); getblock(22) Block request/ receive Client main i 0,0 if (!rpcok()) punish(); RPC(2,42) foo p 0 Active Set foo i 0,0 foo i 0,1 g p 0 if (!activesetok()) punish(); Overseer

154 1 Is the requested block part of the current block working set? 2 Valid RPC number? Valid RPC argument types? 61 / 74 Crime and Punishment Diversity Graph main p 0 main i 0,0 foo p 0 Server punish(){ send kill block; insert delays(); send delay block; send allocmem block; collect forensics; } Block scheduler if (!blockok()) punish(); if (!rpcok()) punish(); getblock(22) RPC(2,42) Active Set Block request/ receive Client foo i 0,0 foo i 0,1 g p 0 if (!activesetok()) punish(); Overseer

155 Enumeration of the Attack Space Find asset blocks A Find Detect blocks asset blocks Wait for blocks to appear in block bag Probe server for all blocks Analyze block A i Is A i an asset block? Tamper with A Tamper asset without being detected Analyze A to determine that they are orphan Prevent server from replacing AReport with newa blocks active set blocks AnalyzeReport Analyze Find blocks & build call valid active set containing blocks & build call RPCs/variables A graph graph uses A Prevent server from making meaningful updates to A Report an active set that has RPCs/variables A uses Report valid active set containing blocks with RPCs/variables A Ignore updates to A Reverse engineer updates Extract Patch new A variable/rpcnew with Find ancestor N k 1 of new block Compare N kcompare en- callgraphs N k cod- against all other blocks ings & call signaures from N 0,...,N k Avoid detection encodings 62 / 74

156 Enumeration of the Attack Space Tamper asset without being detected Find asset blocks A Tamper with A Avoid detection Find blocks Detect asset blocks Analyze A to determine that they are orphan blocks Prevent server from replacing A with new blocks Prevent server from making meaningful updates to A Reverse engineer updates Root represents the asset in the client code (security check, code that updates a global variable, the integrity of a control-flow path, global data,... ). Attack steps: 1 find the asset blocks 2 tamper with these blocks 63 / 74

157 64 / 74 The Attack Space Avoiding Detection Avoid detection Analyze A to determine that they are orphan blocks Prevent server from replacing A with new blocks Prevent server from making meaningful updates to A Reverse engineer updates 1 Orphan blocks (no calls, RPCs): modify at will!

158 64 / 74 The Attack Space Avoiding Detection Avoid detection Analyze A to determine that they are orphan blocks Prevent server from replacing A with new blocks Prevent server from making meaningful updates to A Reverse engineer updates 1 Orphan blocks (no calls, RPCs): modify at will! 2 Trick the server that asset blocks are all active: server can t update!

159 The Attack Space Avoiding Detection Avoid detection Analyze A to determine that they are orphan blocks Prevent server from replacing A with new blocks Prevent server from making meaningful updates to A Reverse engineer updates 1 Orphan blocks (no calls, RPCs): modify at will! 2 Trick the server that asset blocks are all active: server can t update! 3 Trick the server to only make trivial changes to asset blocks: ignore updates! 64 / 74

160 The Attack Space Avoiding Detection Avoid detection Analyze A to determine that they are orphan blocks Prevent server from replacing A with new blocks Prevent server from making meaningful updates to A Reverse engineer updates 1 Orphan blocks (no calls, RPCs): modify at will! 2 Trick the server that asset blocks are all active: server can t update! 3 Trick the server to only make trivial changes to asset blocks: ignore updates! 4 64 / 74

161 65 / 74 The Attack Space Countermeasures Avoid detection Analyze A to determine that they are orphan blocks Prevent server from replacing A with new blocks Prevent server from making meaningful updates to A Reverse engineer updates 1 Slow down reverse engineering using protocol-preserving primitives.

162 65 / 74 The Attack Space Countermeasures Avoid detection Analyze A to determine that they are orphan blocks Prevent server from replacing A with new blocks Prevent server from making meaningful updates to A Reverse engineer updates 1 Slow down reverse engineering using protocol-preserving primitives. 2 Use opaque to connect orphan blocks to the rest of the program.

163 The Attack Space Countermeasures Avoid detection Analyze A to determine that they are orphan blocks Prevent server from replacing A with new blocks Prevent server from making meaningful updates to A Reverse engineer updates 1 Slow down reverse engineering using protocol-preserving primitives. 2 Use opaque to connect orphan blocks to the rest of the program. 3 Use opaque primitive to insert calls to non-existing functions. If the adversary 65 / 74

164 66 / 74 Security Evaluation Empirical Test #1 Protocol Preserving Server Client Blocks Block Bag Non Protocol Preserving Code transformer bar 0,0 bar 1,0 RPC_encode(...) Ignore updates! Attack: Ignore block updates!

165 66 / 74 Security Evaluation Empirical Test #1 Protocol Preserving Server Client Blocks Block Bag Non Protocol Preserving Code transformer bar 0,0 bar 1,0 RPC_encode(...) Ignore updates! Attack: Ignore block updates! Simulated Test: Turn off client updates.

166 Attack: Ignore block updates! Simulated Test: Turn off client updates. Result: RPCs are frequent in our test program, the server reliably detected the malicious behavior shortly after the first RPC encode update. 66 / 74 Security Evaluation Empirical Test #1 Protocol Preserving Server Client Blocks Block Bag Non Protocol Preserving Code transformer bar 0,0 bar 1,0 RPC_encode(...) Ignore updates!

167 67 / 74 Security Evaluation Empirical Test #2 Protocol Preserving Server Client opaque(...) Non Protocol Preserving Code transformer Blocks Block Bag if (P F ) bogus() Request complete program! Attack: Build a snapshot of the entire program, in order to analyze it off-line!

168 67 / 74 Security Evaluation Empirical Test #2 Protocol Preserving Server Client opaque(...) Non Protocol Preserving Code transformer Blocks Block Bag if (P F ) bogus() Request complete program! Attack: Build a snapshot of the entire program, in order to analyze it off-line! Simulated Test: Client disassembles its blocks, requests referenced blocks.

169 Attack: Build a snapshot of the entire program, in order to analyze it off-line! Simulated Test: Client disassembles its blocks, requests referenced blocks. Result: The malicious client quickly requested nonexistent blocks. 67 / 74 Security Evaluation Empirical Test #2 Protocol Preserving Server Client opaque(...) Non Protocol Preserving Code transformer Blocks Block Bag if (P F ) bogus() Request complete program!

170 68 / 74 Security Evaluation Empirical Test #3 main p 0 Server Client main i 0,0 Block Bag foo p 0 foo i 0,0 foo i 0,1 g p 0 All blocks are active! Attack: Prevent the server from updating blocks!

171 68 / 74 Security Evaluation Empirical Test #3 main p 0 Server Client main i 0,0 Block Bag foo p 0 foo i 0,0 foo i 0,1 g p 0 All blocks are active! Attack: Prevent the server from updating blocks! Simulated Test: Client reports the entire contents of the block bag as the active set.

172 Attack: Prevent the server from updating blocks! Simulated Test: Client reports the entire contents of the block bag as the active set. Result: Using the program call graph the server reliably identified the malicious 68 / 74 Security Evaluation Empirical Test #3 main p 0 Server Client main i 0,0 Block Bag foo p 0 foo i 0,0 foo i 0,1 g p 0 All blocks are active!

173 Security Evaluation Empirical Test #4 We re porting ChocolateDoom to Tigress. Capture-the-Flag exercises! To appear / 74

174 Discussion

175 71 / 74 Summary A system for detecting tampering of clients running on untrusted nodes in a distributed system.

176 71 / 74 Summary A system for detecting tampering of clients running on untrusted nodes in a distributed system. Assume the adversary has complete knowledge of our system no security-through-obscurity

177 72 / 74 Summary Security Protocol-preserving primitives: Gives attacker limited time-window for analysis/tampering.

178 72 / 74 Summary Security Protocol-preserving primitives: Gives attacker limited time-window for analysis/tampering. Non-protocol-preserving primitives: Harder to tamper without modifying expected behavior easier tamper-detection.

179 72 / 74 Summary Security Protocol-preserving primitives: Gives attacker limited time-window for analysis/tampering. Non-protocol-preserving primitives: Harder to tamper without modifying expected behavior easier tamper-detection. Security: Function of the frequency of code updates and the complexity and variability generated by primitives.

180 73 / 74 Summary Performance Highly tunable: Control which parts of the program to transform, which transformations to apply, update frequency.

181 73 / 74 Summary Performance Highly tunable: Control which parts of the program to transform, which transformations to apply, update frequency. Performance overhead: Infrastructure: 4% to 23%. Update delay: 2 to 3 seconds (protocol-preserving primitives), 7 to 24 seconds (non-protocol-preserving primitives).

182 74 / 74 Discussion Optimize differently for different scenarios: Client performance Server performance Network latency/bandwidth Client energy use Time-to-crack

183 Discussion Optimize differently for different scenarios: Client performance Server performance Network latency/bandwidth Client energy use Time-to-crack What about different network topologies? client-server 1 server + n untrusted clients running same code? 1 server + n untrusted clients running different code? 1 server + n trusted clients + m untrusted clients? 74 / 74