ASIA-PACIFIC TELECOMMUNITYThe 23rd APT Standardization Program Forum(ASTAP-23)

DocumentASTAP-23/INP-15

03 – 07 March 2014, Pattaya, Thailand 03 March 2014

ETRI, Republic of Korea

A WAY TO USE WHITEBOX CRYPTOGRAPHY IN SEPARATED DOMAIN ENVIRONMENT OF MOBILE DEVICES

1. Motivation

Because smart phones, smart pads or other mobile devices are recently used more, people just depend on electronic devices and enjoy their convenience life. However, mobile devices wired anywhere, anytime has lots of leakages by security issues. Therefore, many possible attack exists. Also, because attack methods are getting more sophisticated, general secure solution is hard to detect malicious execution codes. This paper introduces stronger security solution based on separated domain environment. Proposed method is about whitebox cryptography that hides system master key in cryptographic algorithm [6]. This key can produce session keys and protect system kernel without support of hardware. Ultimately, this paper shows efficient usage of whitebox cryptographic technology with secure execution of domain separations.

2. Proposed Secure Structure

A. Location of whitebox module in secure domain

In mobile environment based on separated domain, even though normal domain, for example android OS, is exposed to malwares, there is another operating system, that is called secure domain, totally protected by normal attack situation [2, 4]. <fig 1> shows domain separations which is described from hardware processors to application layers. Multi-OS can share single processor on hypervisor, each Operating system is totally independent.

Contact: Jong-Yeon ParkETRI, KOREASeong-yong YoonETRI, KOREAJeongNyeo KimETRI, KOREA

Email: flysohigh@etri.re.kr

syyoon@etri.re.kr

jnkim @etri.re.kr

ASTAP-23/INP-15

Virtualization Module

Android

ApplicationSecure OS

Secure Service

Certificate Secure Storage Module

Key management with root of Trust

<fig 1 > Domain separation, “normal domain and secure domain”. Although, secure domain and normal domain is separated, secure part must depend on root of trust(ROT), hardware modules are used by ROT, for example, USIM[5], TPM[3], Trust Zone[1]. Thus, this paper proposes using whitebox cryptographic solution. Whitebox cryptography(WBC) has many real world problems, however we can overcome those limitations of WBC in this environment with our usage that can give key generation and management of tamper evidence level.

Virtualization Module

Android

Middleware

Application

Secure OS

Middleware

Application

White box AES

<fig 2> Logical Location of Whtiebox key module

Fixed key white box module exist independently from operating systems. There are several reasons below.

- If cryptographic key is in the secure domain, protected object by ROT is in protected Object. That is the obviously contradiction. - Logically separated read only structure must be simple, which will be clear from leakages and safeness.

B. Usage 1: Secure Booting

Isolated cryptographic algorithm can operate integrity checking of full object. In our proposed usage <fig 3>, booting image segments were encrypted, WBC encrypts decrypted booing image segments. Unless WBC module contains wrong key, boot loader cannot operate normally due to corruption of boot segment.

Page 2 of 4

ASTAP-23/INP-15

WBC

Encrypted Booing img segment

OUT

Secure Domain

Integrity checked Obejct

Secure Booting

<fig 3> Secure booting by Whitebox Cryptography

C. Usage 2: Key generation

If we can use the structure of <fig 2>, many simple and strong scheme can be designed. The second usage is a key generator. The most important point of key generator are randomness and un-prediction. WBC key generator makes simple 128bit key token for session keys. <fig 4> shows how to make session key and encryption with session keys(A). In the scheme, whitebox AES gets the random number from PRNG (Pseudo Random Number Generator), and then WBC produces bit string output. This session key is sent to secure domain. This key is used to encrypt data directly, and saved in secure domain with (A) for decryption. Although an attacker tries to decrypt encrypted object, he cannot access WBC module. This is because whitebox module is totally isolated from operating systems (including secure domain), see <fig 2>.

Random number

PRNG

Encryption using Pre Fixed key

(secure)

WhiteBox AESe

13A$.....

DATA

Encryption using generated key

AESe

13A$.....

Encrypted data

Random number

<fig 4> Encryption scheme with Whitebox AES

Page 3 of 4

ASTAP-23/INP-15

Reference

1. ARM “ARM Security Technology”, white paper, http://infocenter.arm.com/help-/topic/com.arm.doc.prd29-genc-009492c/PRD29-GENC-009492C_trustzone_security_w-hitepaper.pdf

2. M. Hohmut, M.Peter, H.Hartig, and J.S Shapiro, “Reducing TCB size by using untrusted components – small kernels versus virtual-machine monitors. In: Proceedings fo the 11th ACM SIGOPS European Workshop 2004.

3. Trusted Computing Group, “TCG PC Client Specific TPM Interface specification (TIS)” http://trusted-computing.org, 2005.

4. Y.H. Kim, Y.K. Lee, and J.N. Kim, “TeeMo: A Generic Trusted Execution Framework for Mobile Devices”, CNSI 2012, 579-583, 2012.

5. 3rd Generation Partnership Project(3GPP), “Technical Specification Group Services and System Aspects, 3G Security, Specification of the MILENAGE Algorithm Set, An example algorithm set for the 3GPP authentication and key generation functions f1, f1*, f2, f3, f4, f5 and f5*, 2009. 12

6. M. Joye, “On White-box Cryptography”, Security of Information and Networks 2008, Tranfford Publishing, pp 7-12

Page 4 of 4