Investigating Provably Secure and Practical Software Protection

1. Investigating Provably Secure and Practical Software Protection Lt Col Todd McDonald AFIT/ENG jmcdonal@afit.edu x4639

2. Research Interests • Program Encryption • Program protection / secure coding • Obfuscation / tamperproofing • Mobile agent security / mobile code • Information / database security • Multi-agent architectures • Trust-based computing

3. Three Focus Areas for Program Protection • Semantic Transformation • Random Program Security Model / Randomizing Obfuscators • Perfectly Secure White Box Obfuscators Goal: Characterize the aspects of program protection that can be done with some measurable degree of security

4. Program Scenario 010010010001001001001

5. Program Protection If the adversary cannot determine the function/intent of the device by input/ output analysis, we say it is black-box protected Adversarial Observation: Black Box Analysis White Box Analysis If the adversary cannot determine the function/intent of the device by analyzing the structure of the code, we say it is white-box protected Intent Protected: Combined black-box and white-box protection does not reveal the function/intent of the program

6. How to Define/Measure “Program Protection” Security • Explicitly • Define adversary task and require that it is computationally difficult • Disadvantage: lot of threats/some are difficult to formulate in terms of computational problems • Implicitly • Define ideal security model and require our case is nearly as good as ideal one • Disadvantage: Barak et al. result shows this is impossible based

7. Where are we at? • Obfuscation: somehow make something less recognizable • Known methods of obfuscation are reverse of good software engineering • None guarantee impossibility of retrieving sensitive information or algorithms (concealment is not considered strong security, only deterrent) • A determined specialist given enough time and resources is able to de-obfuscate any obfuscated program

8. Heuristic Metrics

9. Heuristic Obfuscation

10. Information Theoretic Definition of Obfuscation • Virtual black box (VBB):anything one can compute from the obfuscated program could also be computed from input-output behavior of the original program Program P Obfuscated Program P’ P’ = O(P) TTP ????? Oracle for P O I

11. Black Box Intent Protectiona.k.a Semantic Transformation

12. Semantically Secure Black Box Protection P’ = O(P)

13. White Box Protection ?? Circuit P’

14. Two “Provable” Approaches to White Box Protection • Try to hide/interleave the seem between P and E (using randomization and a random program model) • How do we/can we characterize the hiding? • Completely hide all intermediate operations (using perfect white-box protection via canonical reduction)

15. Random Programs/Circuits circuit

16. Random Programs/Circuits

17. Randomizing Obfuscators Correlating Program and Data Encryption

18. Perfect White Box Protection main (int argc, char *argv) { int x,y; /* Get input from the user */ x = argv[1]; /* Super secret algorithm */ …….. …….. /* Output the result */ cout << y; }

19. Perfect White Box Protection • What is the best we can hope for to protect the “structure” of the code that performs the secret algorithm? • We want the program to act just like an oracle would • We want the program to be a “black-box” implementation

20. Perfect White Box Protection = Black Box Implementation main (int argc, char *argv) { int x,y; /* Get input from the user */ x = argv[1]; /* Super secret algorithm */ if (x == 1) y = 281827391; else if (x == 2) y = 23; else if (x == 3) y = 1867575; …. /* Output the result */ cout << y; }

21. Perfect White Box Protection • Problems with this approach: • You have to know all inputs/outputs • Therefore, the algorithm could never be efficient for all size input n • Therefore, the algorithm could never be general for all programs • Which lends support to impossibility results…

22. Perfect White Box Protection • But: • Mobile code programs are targeted for small information exchanges • Input size might be limited • You may not care about the full range of possible inputs, only some…

23. Perfect White Box Protection • Regardless of efficiency: • We can define a methodology for perfect white box protection • We could apply that method for programs of small input size n (which is defined only by the amount of time or resources you want to apply to get the result) • Those programs would be perfectly white box protected

24. Circuits • Consider circuit P • 3 representations: • Algebraically (Boolean function) • Structurally (circuit diagram) • Truth table (input/output behavior) Structural view of P: INPUT(3) INPUT(2) INPUT(1) OUTPUT(7) OUTPUT(6) 4 = AND(3,2) 5 = OR(4,1) 6 = XOR(4,3) 7 = NAND(5,6)

25. Circuits Behavioral view of P:

26. Circuits Functional view of P: fP • Derive it from structure y6 = (x3x2(x3x2x3)’)’(((x3(x3x2x3)’)’)’ y7 = ((x3x2 + x1) (x3x2(x3x2x3)’)’(((x3(x3x2x3)’)’)’)’ • Derive it from truth table y6 = x1’x2’x3 + x1x2’x3 y7 = x1’x2’x3’ + x1’x2’x3 + x1’x2x3’ + x1’x2x3 + x1x2’x3’ + x1x2x3’ + x1x2x3

27. So what does canonical minimization do? All you need is the truth table or behavioral view to get an SOP form

28. So what does canonical minimization do for us? This is what an oracle for P would “use” when asked questions about P … Any circuit that implements this truth table would then be a “black box implementation” of P

29. The “Logic” of Canonical P if (x1 == 0) && (x2 ==0) & (x3==0) y6 = 1 y7 = 0 else if ((x1==0) && (x2==0) && (x3==1) y6 = 1 y7 = 1 … …

30. Original P Canonical P Can I ever recover the structure of the original P from canonical P?

31. Perfect White Box Protection Architecture

32. For Designing Catenation-Based Obfuscators : P’ = P + E

33. Questions ???