Investigating Provably Secure and Practical Software Protection

1
Investigating Provably Secure and Practical
Software Protection

• Lt Col Todd McDonald
• AFIT/ENG
• jmcdonal_at_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

Obfuscated Program P
Program P
P O(P)
?????
TTP
Oracle for P
I
O
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
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 argv1
• / Super secret algorithm /
• ..
• ..
• / Output the result /
• cout ltlt 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 argv1
• / Super secret algorithm /
• if (x 1)
• y 281827391
• else if (x 2)
• y 23
• else if (x 3)
• y 1867575
• .
• / Output the result /
• cout ltlt 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 x1x2x3 x1x2x3
• y7 x1x2x3 x1x2x3 x1x2x3
  x1x2x3 x1x2x3 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) (x30)
• y6 1
• y7 0
• else if ((x10) (x20) (x31)
• y6 1
• y7 1

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

• Original P

• Canonical P

31
Perfect White Box Protection Architecture
32
For Designing Catenation-Based Obfuscators P
P E
33
Questions

• ???