1 / 33

Investigating Provably Secure and Practical Software Protection

Investigating Provably Secure and Practical Software Protection. Lt Col Todd McDonald AFIT/ENG jmcdonal@afit.edu x4639. Research Interests. Program Encryption Program protection / secure coding Obfuscation / tamperproofing Mobile agent security / mobile code

presley
Télécharger la présentation

Investigating Provably Secure and Practical Software Protection

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 ???

More Related