1. Investigating Provably Secure and Practical Software Protection
Lt Col Todd McDonald
AFIT/ENG
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

5. Program Protection Adversarial Observation: Black Box Analysis
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 I O

11. Black Box Intent Protection a.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

16. Random Programs/Circuits

17. Correlating Program and Data Encryption
Randomizing Obfuscators

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 = ;
else if (x == 2)
y = 23;
else if (x == 3)
y = ; ….
/* 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 Structural view of P: 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)
y7 = 1 …

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