LINE and intertrust security summit (c)Intertrust

1. FRONTIERS IN CRYPTOGRAPHY
May 2017
Robert E. Tarjan
Chief Scientist, Intertrust Technologies
James S. McDonnell Distinguished University Professor
of Computer Science, Princeton University
Whitebox Security

2. OUTLINE
• The Public Key Cryptography Revolution
• Blackbox vs. whitebox threat models
• Obfuscation
• Theoretical results
• Practical implementations
• Whitebox Cryptography
• A specific kind of obfuscation, specifically for cryptography
• The Future
© 2017 Intertrust Technologies Corporation. All Rights Reserved.
2

3. IN THE BEGINNING…
…there was symmetric key cryptography.
But how could the parties agree on keys?
SECURE COMMUNICATION
OUT OF BAND KEY AGREEMENT
© 2017 Intertrust Technologies Corporation. All Rights Reserved.
3

4. Proposed by Diffie and Hellman (1976)
First practical public key cryptosystem RSA (1978)
PUBLIC KEY CRYPTOGRAPY
Alice’s PRIVATE key
Alice’s PUBLIC key
Bob’s PUBLIC key
Bob’s PRIVATE key
© 2017 Intertrust Technologies Corporation. All Rights Reserved.
4
SECURE COMMUNICATION

5. Protected Environment
Managed Device
Crypto Library
Protected Environment
Managed Device
Crypto Library
The communication channel is protected with cryptography.
The cryptographic key used at the endpoints is assumed to be protected by other means.
The attacker can’t look into that crypto library. It’s a “black box”.
BLACKBOX SECURITY ASSUMPTION
© 2017 Intertrust Technologies Corporation. All Rights Reserved.
5
SECURE COMMUNICATION

6. Unprotected Environment
Unmanaged Device
Crypto Library
The attacker can look into the crypto library.
How do we secure the key?
WHITEBOX
© 2017 Intertrust Technologies Corporation. All Rights Reserved.
6
SECURE COMMUNICATION
Cloud
Services

7. Unprotected Environment
Unmanaged Device
Crypto Library
Put the key back into a Blackbox!
HARDWARE SECURITY
© 2017 Intertrust Technologies Corporation. All Rights Reserved.
7
Cloud
ServicesSECURE COMMUNICATION
Blackbox

8. PROBLEMS WITH HARDWARE SECURITY
Therefore, whitebox security solutions will continue to be important!
© 2017 Intertrust Technologies Corporation. All Rights Reserved.
8
• Attacks do exist
• Exploiting vulnerabilities
(e.g. backdoors, update mechanisms, cold boot attacks)
• Differential power analysis (Kocher, et al, CRYPTO ’99)
• Recovery
• Hardware is hard to update if compromised
• But software can be patched
• Priorities
• Users want cost savings and speed
• Security is often secondary
Source: SPA trace showing an entire DES operation /
(December 14, 2010) by Mad fab / Wikimedia Creative Commons (CC BY-SA 2.0)

9. Provable security
guarantees
Very expensive for skilled
attackers to succeed
Lots of computation
and space required
Must be fast and use
limited memory
Security
Practice
Theory
Performance
© 2017 Intertrust Technologies Corporation. All Rights Reserved.
9
THEORY VS. PRACTICE

10. Obfuscator: An algorithm O such that for any program P, O(P) is a program that:
• computes the same function as P
• is hard to analyze / reverse-engineer
• is not too big or too slow
Intuition: an obfuscator provides a “virtual blackbox” – O(P) is a blackbox that
computes P.
Why might obfuscators exist?
• All canonical hard problems are problems of reverse engineering: SAT, HALTING
• Rice’s Theorem: You can’t look at the code (Turing Machine description) of a function and find out
a non-trivial property of it.
A Virtual Blackbox
© 2017 Intertrust Technologies Corporation. All Rights Reserved.
10
WHAT IS AN OBFUSCATOR?

11. ON THE (IM)POSSIBILITY OF OBFUSCATION
© 2017 Intertrust Technologies Corporation. All Rights Reserved.
11
Barak, et al. “On the (im)possibility of obfuscating programs.”
– JACM 2002
Looks like bad news. Is obfuscation really impossible?
• There is a family of efficient programs P that are not obfuscatable in the sense that
• given any efficient program P′ that computes the same function as a program P ∈ P,
secrets from the “source code” of P can be recovered, yet
• given black box (oracle) access to a program P ∈ P, no efficient algorithm can reconstruct
the secrets of P.

12. • Definitions
• Indistinguishability obfuscation – given any two equivalent circuits C0 and C1 of similar size,
the obfuscations iO(C0) and iO(C1) are computationally indistinguishable.
• Candidate iO functions have been described that are feasible, albeit impractical.
• Apon et al (2014) – obfuscation of a 16 bit point function blows up to 31GB.
INDISTINGUISHABILITY OBFUSCATION
© 2017 Intertrust Technologies Corporation. All Rights Reserved.
12
Garg, et al. “Candidate indistinguishability obfuscation
and functional encryption for all circuits.”
– FOCS 2013
There is hope that obfuscation in some form is possible!

13. “Standard” Assumption (e.g. LWE)
“Most” of cryptography
+ OWFs
© 2017 Intertrust Technologies Corporation. All Rights Reserved.
13
Indistinguishability
Obfuscation
VISION: IO AS HUB FOR CRYPTOGRAPHY

14. IO AS A HUB FOR CRYPTOGRAPHY
iO + One Way Functions gives
Virtual Blackbox Cryptography
A great theoretical achievement,
but very far from being practical
© 2017 Intertrust Technologies Corporation. All Rights Reserved.
14

15. © 2017 Intertrust Technologies Corporation. All Rights Reserved.
15
IO AS A HUB FOR CRYPTOGRAPHY
(IMAGE FROM BARAK 2016)
Indistinguishability
Obfuscators
Deniable
Encryption
Public Key
Encryption
Short Signatures
Group Key
Exchange
Traitor Tracing
Oblivious
Transfer
Multiparty Secure
Computation
Non-interactive
Zero Knowledge
Identity-based
Encryption
Functional
Encryption
Source: Boaz Barak: Hopes, fears, and software obfuscation. Commun. ACM 59(3): 88-96 (2016)

16. • Originally done for fun
• International Obfuscated C Code Contest
• Started in 1984, still going on
• As a security mechanism
• Make it hard to understand code, so it is hard to reverse engineer.
• Reorder data
• Changing encodings
• Converting static data
to procedures
• Replacing instructions
• Opaque predicates
• Inserting dead code
• Inserting irrelevant code
© 2017 Intertrust Technologies Corporation. All Rights Reserved.
16
OBFUSCATION IN PRACTICE
• Reordering
• Loop Transformations
• Function splitting/recombination
• Aliasing
• Control flow obfuscation
• Data flow obfuscation
• Parallelized code
• Name scrambling
• Removing standard library calls
• Breaking relations
• Packing/encryption
• Dynamic code modifications
• Environmental requirements
• Virtualization
• Emulation
• Anti-debugging techniques
Source: Passport photo of Alan Turing at age 16 (circa 1928) /
Wikimedia Creative Commons (CC BY-SA 2.0)
Alan Turing (1912 – 1954)

17. • What if we wanted to obfuscate a specific algorithm instead of using generic transformations
on arbitrary algorithms? Could we provide better security?
• In particular, can we do better on cryptographic algorithms?
Cryptography is often the key to making applications secure.
• The answer is yes. This is an active area of research.
Chow, et al (2002)
Implementations of AES
and DES
Billet, et al (2004)
Cryptanalysis of
Chow’s algorithms
Bos, et al (2015)
Differential Code Analysis
Saniflex, et al (2015)
Differential Fault Analysis
CHES 2017
Challenge
© 2017 Intertrust Technologies Corporation. All Rights Reserved.
17
WHITEBOX CRYPTOGRAPHY

18. WHO USES WHITEBOX SECURITY TODAY?
Connected Car
Entertainment
Mobile Payments
Medical
IoT
© 2017 Intertrust Technologies Corporation. All Rights Reserved.
18

19. • Can any theoretical method be made practical?
• Can theoretical methods be built on stronger foundations?
• In practice, is the cat-and-mouse game winnable?
• Do we need entirely new techniques?
• How do we address the overall security problem, including prevention
of out-of-band and side-channel attacks?
• Cryptography is (still) a robust and evolving discipline, with many interesting
problems to solve.
© 2017 Intertrust Technologies Corporation. All Rights Reserved.
19
WHAT IS THE FUTURE?

20. www.intertrust.com
THANK YOU
…and my thanks to Bill Horne, Steve Mitchell, and Tomas Sander
for designing the talk and making the slides!
© 2017 Intertrust Technologies Corporation. All Rights Reserved.