LMM

A Common Component for Software License Management on Cloud

Shinsaku Kiyomoto

, Andre Rein

, Yuto Nakano

, Carsten Rudolph

and Yutaka Miyake

KDDI R & D Laboratories Inc., Fujimino, Saitama, Japan

Fraunhofer Institute for Secure Information Technology, Darmstadt, Germany

Keywords:

Cloud Computing, Security, Software License Management, Digital Rights Management, Illegal Copy.

Abstract:

On a cloud environment, the platform that runs a program is not ﬁxed, and there is a possibility that a program

runs on several servers in a cloud environment. Transferability of the license information by a valid user should

be allowed, even though general requirements for license management have to be satisﬁed. In this paper,

we consider software license management models for cloud environments, and discuss security functions

for building secure license management schemes. We show four license management models and analyze

the security requirements for the models. Then, we design a common component referred to as the license

management module (LMM), and explain the security functions required for the LMM. Furthermore, we

discuss how to realize the security functions and evaluate their performance using a prototype implementation.

1 INTRODUCTION

1.1 Background

Platform-as-a-Service (PaaS) is the service model

of cloud computing, and it provides a program-

executable environment for users. PaaS facilitates de-

ployment of programs without the cost and complex-

ity of buying and managing the underlying hardware

and platform layers such as operating systems. How-

ever, some security risks of cloud computing services

have been identiﬁed. It is impossible for users to ver-

ify the trustworthiness of all cloud computing envi-

ronments, and there are concerns that operations in

cloud computing may be carried out in an untrust-

worthy environment. Furthermore, a malicious user

may be able to access the resources of other users,

due to an architecture whereby users share resources

on a cloud. The dynamic and ﬂuid nature of the en-

vironments makes it difﬁcult to maintain consistent

security and ensure that records can be reliably au-

dited. Thus, moving critical programs and sensitive

data such as license information to a public and shared

cloud computing environment raises major security

concerns (Popovic and Hocenski, 2010; Shaikh and

Haider, 2011; Kantarcioglu et al., 2011). In PaaS ser-

vices, the platform provider supplies a platform for

execution of user programs and users install or acti-

vate licensed programs on the platform. Users can ac-

cess the platform and programs from a user terminal

via the Internet. In this paper, we examine threats to

cloud computing and in particular threats to installed

licensed programs.

1.2 License Management on a Cloud

License checking using an activation code is a com-

mon function to protect software from being copied.

Generally, the license is issued to a user who has the

right to use the software, and the license allows the

software to be used on a PC or other devices. If the

user plans to use the software on two different en-

vironments, the user has to obtain two licenses for

the software or register both environments to a li-

cense manager. Ownership of the licenses should be

strictly managed and the transfer of the license from

the user to other users has to be prevented by using a

license management scheme. When a user executes

a licensed program, license information should be se-

curely stored and checked. On a cloud environment,

the platform that runs a program is not ﬁxed, and

the platform is selected from cloud servers. There

is a high possibility that a program runs on several

servers in a cloud. Thus, transferability of the license

information by a valid user must be allowed, even

though general requirements for license management

have to be satisﬁed. Furthermore, as the cloud servers

are managed by a third party, some speciﬁc security

284

Kiyomoto S., Rein A., Nakano Y., Rudolph C. and Miyake Y..

LMM - A Common Component for Software License Management on Cloud.

DOI: 10.5220/0004504502840295

In Proceedings of the 10th International Conference on Security and Cryptography (SECRYPT-2013), pages 284-295

ISBN: 978-989-8565-73-0

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

requirements for cloud environments should also be

considered.

Currently, four possible approaches are presented

in ISO/IEC JTC1 SC7 WG21 as for ISO/IEC 19770

- Information Standard about Software Asset Man-

agement (SAM) (Bicket, 2011). These comprise the

sourcing approach, contractual approach, structured

approach, and mash-up approach. The sourcing ap-

proach provides free and open-source software, and

the contractual approach allows license management

to be delegated to cloud operators. The structured ap-

proach is based on the development and exploitation

of a common technological architecture for software

license management. The mash-up approach is based

on a mix of different tools and approaches. The struc-

tured approach is the most efﬁcient approach. A con-

ceptual architecture for the technical mechanisms as-

sociated with asset management has been presented;

however, the actual design of the architecture is still

under consideration.

1.3 Issues Addressed in This Paper

PaaS service has a separation mechanism for each

user environment to protect user resources. How-

ever, we should consider incorrect conﬁguration of

the hypervisor and some bugs in the separation mech-

anism. Even if the hypervisors are conﬁgured cor-

rectly, the risk of data intermingling or loss is still

present (Courtney, 2012). Zhang et al. demonstrated

an attack (Zhang et al., 2012) whereby a program

on a virtual machine can steal a private key used by

another virtual machine on the same server. We as-

sume that a malicious user may access the resources

of other users, and we also have to consider the threats

posed by a malicious platform provider. In license

management, we have to consider illegal actions by a

licensed user who uses a client terminal and the cloud,

in addition to malicious users and malicious platform

providers on the cloud. The platform provider hon-

estly executes user requests and cannot avoid per-

forming any operations related to the programs. How-

ever, the platform provider may try to use the user’s

program maliciously or to obtain license information

from physical memory or data storage. This model

is a reasonable model where we consider the system

manager of the platform as an attacker. It is a ba-

sic requirement for a software license management

scheme to protect the software from illegal use and

illegal copying by malicious users.

Thus, we should consider the following threats to

secure cloud computing.

• Malicious users or malicious platform providers

may access a program and execute it on the cloud

platform without valid license information.

• Malicious users or malicious platform providers

may steal license information from data stored on

the cloud and/or the user terminal.

• External attackers try to steal license information

from communication data, or alter communica-

tion data to execute a program on the cloud.

• Malicious users or malicious platform providers

may copy a program and license information in

order to use the program in a way that violates the

scope permitted by the license.

Under the above threats model, a license manage-

ment architecture for cloud environments should be

considered.

1.4 Contribution of this Paper

To overcome the threats, we introduce a scheme us-

ing a License Management Module (LMM) which is

capable of reducing the theft or misuse of licenses in

general. Due to the application of memory protec-

tion schemes and other cryptographic methods, we

will show how to signiﬁcantly reduce threats for li-

censed programs in PaaS-environments. We present

four license management models and analyze the se-

curity requirements for the models. Then, we design

a common component LMM, and explain the secu-

rity functions required for the LMM. Furthermore, we

discuss how the security functions can be realized.

The rest of the paper organized as follows; Section

2 presents license management models, and security

analyses. The design of the license management mod-

ule and security functions is described in section 3.

Evaluation results including security analysis and per-

formance evaluation are presented in section 4, and

existing research related to this paper is outlined in

section 5. Finally, we conclude this paper in section

2 LICENSE MANAGEMENT

MODEL

In this section, we consider license management mod-

els for cloud environments. We assume a simple li-

cense management model in which a user license is

issued for each application program of the user and

only one program execution is allowed by each li-

cense information. A user cannot execute the pro-

gram on two or more environments simultaneously,

even though the user has valid license information.

Frequent license checking is required, because a ma-

licious user may move license information to another

LMM-ACommonComponentforSoftwareLicenseManagementonCloud

285

License Management

Module

Application

Client Terminal

Tamper-Resistant Module

Cloud-Based Scheme A

User Management Module

License Management

Server

Cloud Server

License Management

Module

Application

Client Terminal

Tamper-Resistant Module

Cloud-Based Scheme B

User Management Module

License Management

Server

Cloud Server

License Management

Module

Tamper-Resistant Module

Delegation

Application

Client Terminal

Cloud-Based Scheme C

User Management Module

License Management

Server

Cloud Server

Tamper-Resistant Module

License Management

Module

Client Terminal

Cloud-Based Scheme D

User Management Module

License Management

Server

Cloud Server

Tamper-Resistant Module

License Management

Module

Application

Cloud Server

License Management

Module

Tamper-Resistant Module

Delegation

Figure 1: License Management Models.

environment after the license checking. First, we in-

troduce three components for license management.

The license management models are then built using

these three components. Next, we present four license

management models and discuss the advantages and

disadvantages of the four models. Afterwards, we an-

alyze security threats to the four license management

models.

2.1 Components for License

Management

License management is an important function for pro-

tecting software and contents against their illegal use.

Generally, a user registers information to a software

provider and receives in return the license informa-

tion. We model license management schemes using

three basic components as follows:

• User Management Module. The user management

module manages the registration information of

users. Users access the user management mod-

ule to obtain license information before they start

using the software. The user management mod-

ule authenticates users, registers user information,

and provides license information to users. We do

not discuss the design of the user management

module in this paper.

• License Management Module. The license man-

agement module (LMM) holds the license of a

user. The LMM provides license information,

when an application program requests the infor-

mation from the LMM. The main issue of this pa-

per is to examine the design of the license man-

agement module.

• Application Program. The application program is

a program that a user uses with the license in-

formation. The application program is not exe-

cutable without license information. The program

accesses the LMM to obtain license information

as soon as the program is executed. The appli-

cation program may include digital contents such

as musics and videos. In such cases, the appli-

cation program is a viewer of the digital contents

and a license management scheme for the applica-

tion program is a part of a digital rights manage-

ment (DRM) system for the contents. We discuss

a general license management framework for ap-

plication programs, and do not consider speciﬁc

requirements for each program.

2.2 Cloud-based License Management

Models

Four models are considered for license management

on a cloud as shown in Figure 1. Models are separated

based on the conditions under which a license man-

agement module (LMM) is implemented. In model

A, the LMM is implemented on a user terminal, and

SECRYPT2013-InternationalConferenceonSecurityandCryptography

286

an application program communicates with the user

terminal to check license information. Model B im-

plements the LMM on both the cloud server and user

terminal, and the license information is delegated to

the LMM on the cloud. The LMMs in model C and

model D are implemented on another cloud server that

manages the license information.

We analyze the advantages and disadvantages of

the four models as follows:

• Model A. Model A is an online scheme by which

the license information is managed by the LMM

on the user terminal, and a program running on

the cloud accesses the LMM via a public network

when the program is executed.

Advantage. An advantage of model A is that no

license information is stored in the cloud.

Disadvantage. Frequent communication is re-

quired between the cloud server and the user ter-

minal, where the license information is veriﬁed.

• Model B. Two LMMs communicate before the

execution of a program in order to transfer license

information. The LMM has to manage the dele-

gated license information securely on the cloud.

Advantage. No communication with another en-

tity is required for license checking, even though

communication for delegation of license informa-

tion is needed.

Disadvantage. The LMM and license information

is on the cloud. We have to consider attacks on

the cloud.

• Model C. This model is an extension of model

A. The LMM is executed on another cloud server,

and the LMM and a program communicate via a

public network, when the program is executed.

Advantage. No communication with the user ter-

minal is required, although communication with

another cloud is needed. We do not consider

threats to the user terminal during license check-

ing.

Disadvantage. The cloud that holds the LMM

should be trusted, otherwise we have to consider

a protection mechanism for the LMM.

• Model D. This model is a combination of model

B and model C. The LMM is executed on a cloud

server, and another LMM on another cloud server

receives delegated license information from the

LMM that manages license information when the

program is executed.

Advantage. No communication with the user ter-

minal is required, even though communication for

delegation of license information is needed. We

do not consider threats to the user terminal.

Disadvantage. The cloud that holds the LMM

should be trusted, otherwise we have to consider

a protection mechanism for the LMM on both

servers.

Sufﬁciency of License Management Models. We con-

sidered several license management models based on

the LMM and selected the above four models. The

models are separated by the location of the initial stor-

age of the license information. Feasible options for

the location are on the cloud or on the user terminal.

As a consequence, there are models where the home

LMM is on the user terminal and models where the

home LMM is on the cloud server. The license infor-

mation has to be stored in a unique LMM; however, it

has to be possible to install and execute a program on

several cloud servers. Thus, we cannot directly store

license information in the cloud on which the program

is executed, before the execution of the program. We

also consider on-line or off-line license conﬁrmation

schemes for each model. We therefore examine the

four license management models for a cloud environ-

ment. It should be noted that one can assume that the

cloud server, that manages user LMMs, is trustwor-

thy. In this case, it would be a simple license manage-

ment model under a trusted license server, but this is

beyond the scope of this paper.

2.3 Threats to License Management

Models

In this section, we analyze possible threats to four li-

cense management models based on the threats dis-

cussed in 1.3. We have to consider three malicious

entities: malicious user, malicious operator, and ex-

ternal attacker. The execution of a program without

license information must be considered in all mod-

els. Illegal use of license information is another threat

which may be executed by a malicious user and/or a

malicious operator. All models except model A are

vulnerable to this threats. These malicious entities

may access the LMM and use the license informa-

tion stored in the LMM. Model A does not consider

attacks on the LMM on the cloud, even though at-

tacks on communication between a user terminal and

cloud server have to be considered. Model C does not

have an LMM on the user terminal, and only consid-

ers attacks on the cloud and communication between

cloud servers. Only local access to the LMM is used

in model B, but communication for license delegation

should be protected in this model. Threats to model D

are similar to those for model C; so we assume threats

to cloud servers. A summary of the analysis is shown

in Table 1. The ”user” includes both attackers as a

traitor and other users and ”operator” is a curious op-

erator. Online schemes (such as model A) need not

LMM-ACommonComponentforSoftwareLicenseManagementonCloud

287

Table 1: Threats to Each License Management Model.

Threats Adversary Target Model A Model B Model C Model D

Execution without User, Operator Program X X X X

License Info. on Cloud

Illegal Use of License Info. User, Operator LMM X X X

on Cloud

Theft of License Info. in Terminal User LMM X X

Cloud User, Operator LMM X X X

Attack on Communication User, Operator Communication X X X X

Ext. Attacker Data

Illegal copy of License Terminal User LMM X X

Info. in Cloud User, Operator LMM X X X

be concerned about attacks on the LMM in a cloud;

however, the drawback of the online schemes is that

frequent communication is required for license conﬁr-

mation, as discussed in 2.2. Ofﬂine schemes such as

model B do not require communication while license

conﬁrmation is requested by the application program;

however, we have to incorporate a protection mecha-

nism for locally stored license information.

3 LICENSE MANAGEMENT

MODULE

In this section, we design a common component for

the license management module (LMM). We also

present security functions for the license management

models. In this paper, a cloud service provider is un-

der a setting: honest but curious as discussed in 1.3.

Thus, security and trust of the cloud environment are

out of the scope of this paper.

3.1 Design of License Management

Module

The License Management Module (LMM) is a key

component for license management. We determined

the requirements for the LMM according to the

threats analysis in 2.3. The requirementsfor the LMM

are summarized as follows:

• The LMM enables execution of the application

program to be controlled according to license in-

formation.

• The LMM securely stores and manages license in-

formation.

• The LMM can securely transfer license informa-

tion to other LMMs.

• Illegal copying of license information and the

LMM has to be prevented.

We design the LMM based on the above require-

ments. We assume that the LMM is implemented on

all cloud servers and client terminals. Figure 2 shows

the design of the LMM. The module consists of ﬁve

security functions: secure element, memory protec-

tion, application program binding, local binding, and

delegation mechanism. The secure element stores se-

cret information such as license information. The

memory protection function protects data on physi-

cal memory against attacks such as a memory dump.

The license information is loaded from the secure

storage and stored in a physical memory using the

memory protection function. The application bind-

ing function uses license information on the physi-

cal memory through the memory protection function

and supports license conﬁrmation with an application

program. The application program does not com-

plete any operation without help from the application

binding function. That is, without a valid pair of the

application program and license information, an at-

tacker cannot execute the application program. The

local binding function is used to protect the LMM

against illegal copying. The function obtains local in-

formation that can identify an environment due to its

uniqueness, and stores it in the secure element. The

function also frequently obtains local information and

compares it with the stored local information. If the

information does not match, the LMM stops. The del-

egation mechanism is incorporated into model B and

model D. The mechanism operates a delegation pro-

tocol between LMMs in order to transfer license in-

formation. Details of the functions are explained in

the later sections. The software execution procedure

is as follows:

1. When the program starts to execute, the program

ﬁrst accesses the LMM.

2. The LMM validates the identiﬁcation information

of a local environment using the local binding

function.

3. If the identiﬁcation information matches the in-

formation stored in the secure element, the LMM

obtains the license information from the secure el-

ement, and stores it in the physical memory using

the memory protection function.

SECRYPT2013-InternationalConferenceonSecurityandCryptography

288

Secure Element

License

Information

Physical Memory

Memory Protection

Delegation Mechanism

(for Model B and D)

Cloud Environments

Application Program Binding

Application Program

Local

Binding

Local

Info.

LMM

Figure 2: License Management Module.

4. The program frequently accesses the LMM to

check license information, and the LMM provides

the result of license check according to the appli-

cation binding function.

3.2 Secure Element

The secure element is a form of secure storage that

holds the license information and related secret val-

ues. The secure element is a part of the LMM, and

can only be accessed by the LMM. The secure ele-

ment can be implemented on both software and hard-

ware. A tamper-resistant module is used for hardware

implementation, and an encryption scheme is used for

constructing a software-implemented secure element.

In software implementations, a secret key for the en-

cryption scheme needs to be securely embedded in

program code of the LMM using software obfusca-

tion. In the software implementation, encryption is

not sufﬁcient to protect license information, and how

to restrict copying of the license information should

also be considered. A status is deﬁned for each li-

cense information

to avoid double use of the license

ﬁle, and it should be protected. In consequence, an

encrypted ﬁle including the status information has to

be hidden from an operating system or it should be

made difﬁcult to ﬁnd the ﬁles. Once the secret key

is revealed, the LMM has to be replaced by a new

one; the secret key should be embedded in the LMM

securely. The hardware implementation is more se-

cure than the software implementation, but the soft-

ware implementation is widely applicable to several

cloud environments.

Encryption Key Generation. Each license informa-

tion should be encrypted by an encryption key de-

We deﬁne six types of status: normal, read, delegating,

delegated, delegated-read, and removed. Detailed explana-

tions for the status types are shown in later sections

rived from both a secret key and the user secret in

order to avoid illegal use of license information. The

user secret (for example a password) is provided by

the owner of the license information, and it is re-

quested when license information is used or dele-

gated. When license information is stored in the se-

cure element, the secure element request entry to the

user secret, and derives the encryption key EK

h(secret key||user secret), where x||y denotes a con-

catenation of data x and data y. Note that the function

h(x) is a hash value computed by a hash function h.

For a decryption of the license information, the se-

cure element requests entry to the user secret again,

and computes the encryption key in the same manner.

3.3 Memory Protection

The license information can be read from the secure

element and extracted to physical memory, where its

status is ”normal” or ”delegated”. The status of the li-

cense information is changed to ”read” or ”delegated-

read” to avoid double use of the license information,

where the license information is read from the secure

element. We assume that an adversary including a

cloud operator cannot dump and analyze the whole

physical memory, but may dump and analyze a part

of the physical memory. If an adversary dumps a

part of the physical memory, the license information

might be revealed. However, a huge computational

cost is required when we dynamically encrypt/decrypt

all data on the physical memory, during the program

execution. Thus, a lightweight memory protection

mechanism is used for the LMM. We design the mem-

ory protection function based on a memory protection

scheme (Nakano et al., 2012). Figure 3 shows the

procedure of the mechanism. The license information

is divided into small peaces and mixed with random

data. By the random data addition, the length l

data is extended to k

, where k

is a security param-

eter that is selected according to security and perfor-

mance requirements. The memory protection mech-

anism mediates memory accesses to memory area L

and generates fake accesses. It hides information on

which memory area is accessed. The scheme consid-

ers the buffer M being implemented within the se-

cure element or secure memory area. The table H is

also stored within this boundary. If we do not assume

such a secure memory area, the bufferM with the size

of m and history table H with the size of l

are kept

in the unsecured memory area as with L , and they

should be encrypted. In this case, access to M (and

H ) is made by reading and writing every data block

in the buffers (which requires decryption and encryp-

tion of data). Thus, to ﬁnd out whether ‘a’ is in M ,

LMM-ACommonComponentforSoftwareLicenseManagementonCloud

289

we read/write all values; when replacing data blocks

in M , we again read/write all values. The security

provided is the same; but the computation overhead is

obviously increased. It is expected that a huge com-

putational cost does not requires to compute it, due

to the size of M . It is dependent on buffer size M

and H , but these sizes are sufﬁciently smaller than

the size of the whole memory.

Data including both protected data and randomly

generated redundant data are loaded into memory. Af-

ter loading data, m data blocks are copied into M ; the

table H starts empty. Before the program starts to

run, the scheme can operate by accessing a number of

dummy data blocks to populate the history buffer. On

the ﬁrst access to a data block ‘a’ (either a

read

(a) or

write

(a,x)), the scheme searches for ‘a’ in M and

accesses L twice: if ‘a’ is in M , the scheme replaces

two random elements (not ‘a’) from M with two ran-

dom dummy elements from L and we access ‘a’; if

‘a’ is not in M , two random elements from M are re-

placed by ‘a’ and one random dummy element from L

(and ‘a’ is accessed). In both cases, the correspond-

ing addresses of blocks being kicked out from M are

written in H . In subsequent calls, the scheme pro-

ceeds as follows:

1. If ‘a’ is in M , we replace two random elements

(not ‘a’) from M with a random element from L

and a random element from L which had already

been accessed (as recorded in the history buffer),

and we access ‘a’.

2. If ‘a’ is not in M , and its address is in the history

table, the scheme replaces two random elements

from M with a random element from L and ‘a’

(as recorded in the history buffer). Note that H

holds only addresses and data are stored in L.

3. If ‘a’ is not in M , and its address is not in the

history table either, the scheme replaces two ran-

dom elements from M with ‘a’ and a random ele-

ment from L which had already been accessed (as

recorded in the history buffer).

Every time the data blocks are kicked out from M

to L, data blocks are written in L taking their orig-

inal position (as described by E ), and the addresses

of those blocks are registered in the history table H .

As the program continues to access data blocks, the

table may eventually become full. When this oc-

curs, at each access we select at random ℓ

elements

from among the ℓ

+ 2 elements

. The memory is re-

shufﬂed after a certain period of time. If stronger se-

curity is required, data should be encrypted, when the

data are uploaded into memory, although additional

computational cost is required.

The current history elements and two new ones

3.4 Application Binding

The application binding function enables software

protection in a way such that the program cannot run

without license information. The program frequently

requires the license information to execute the whole

operation. For that requirement, we develop a appli-

cation binding scheme based on Fukushima et al.’s

software protection scheme (Fukushima et al., 2012)

and apply it to our license checking. The scheme

transforms a target program into a protected appli-

cation program and an its license information that is

used by the application program binding function.

The application programis distributedto cloud en-

vironments and the user management module issues

the license information to users. The protected pro-

gram is executed on the platform and only handles

encoded data according to Fukushima’s scheme. The

encoded data are data sets transformed by a secret en-

coding rule in the license information. After receiving

the encoded output, the application binding function

checks the validity of the output. If it is valid, the

function returns the decoded result to the protected

program. The application program binding function

stores all the encoding rules E

, E

, ..., E

decoding

rule D

, and non-trivial relation R

. The non-trivial

relation checks the validity of the response from the

protected program, and the decoding rule decodes the

execution result

The function checks the validity of the response

in order to eliminate modiﬁed responses from an at-

tacker. Let v

be a variable in the program. The func-

tion calculates the value of R

,.. . , v

) from the

response. If R

,.. . ,v

) = 0 holds, the func-

tion decides that the response is valid. Otherwise,

it decides that the query is modiﬁed. The function

decodes the value of x

using decoding rule D

, i.e.,

= D

,.. . ,v

), if the response from the pro-

tected program is valid.

Non-trivial Relations. An m× n Boolean matrix A

with rank n and an m-dimensional vector b is selected

as non-trivial relations for license information. Each

element of the matrix must be 0 or 1, and each ele-

ment of the vector must be an l-bit constant. A rela-

tional equation using matrix A, vector b, and rotation

amounts s

, s

, ..., s

, t

, ..., t

is as follows:







≪ t







= A







≪ s







⊕ b.

There is no special reason to select R

for checking. We

can use other non-trivial relations R

, R

, .. . , R

m−n

instead

of R

SECRYPT2013-InternationalConferenceonSecurityandCryptography

290

The encoding rules (E

,.. . ,E

) are ob-

tained by solving this equation for encoded vari-

ables y

, y

, ... , y

: y

= E

,.. . ,x

= E

,.. . ,x

), . . . y

= E

,.. . ,x

Then, we solve the above equation for target vari-

ables x

, x

, ..., x

. We have decoding rules

,.. . ,D

) such as: x

= D

,.. . , y

= D

,.. . ,y

), . . . , x

= D

,.. . , y

n out of m encoded rules are used to ﬁnd the de-

coding rules. Non-trivial relations (R

,.. . ,R

m−n

)

such as: R

,.. . ,y

) = 0, R

,.. . ,y

) = 0,

... , R

m−n

,.. . ,y

) = 0, are obtained by re-

placing target variables x

with D

,.. . ,y

) in

the unused m− n rules. The LMM stores all the de-

coding rules for managing application programs and

sends decoded results to a valid application program.

3.5 Local Binding

A local binding mechanism is a security function to

protect LMMs from illegal copying. The local bind-

ing mechanism is built into the LMM, and veriﬁes the

identiﬁcation information of the local environment

that the LMM is executed on. The procedure of lo-

cal binding is as follows;

1. As an initial setting, the LMM obtains identiﬁca-

tion information from the local environment and

computes a hash value for the information using a

hash function. The LMM securely stores the hash

value in the secure element.

2. When license information is requested, the LMM

obtains identiﬁcation information and computes

its hash value. Then, the LMM compares the com-

puted value with the hash value stored in the se-

cure element. If the hash values are not identical,

the LMM terminates the provision of license in-

formation.

If an adversary copies the LMM to his/her own

device, the LMM does not provide the license in-

formation due to inconsistencies in the identiﬁ-

cation information generated from local environ-

ments. We use another method for local bind-

ing when we cannot use a secure element to store

the identiﬁcation information. In that case, we

modify the encryption key generation procedure

in 3.2. The key generation function is modiﬁed

as EK

= h(secret key||user secret||identification

information). If the identiﬁcation information is not

valid, the correct key is not obtained.

3.6 Delegation Protocol

In model B and model D, license information delega-

tion between LMMs is required. The license delega-

tion needs a secure communication channel between

LMMs, and the channel can be constructed using

an authenticated-key exchange protocol. A public-

private key pair and a public key certiﬁcate are se-

curely stored in the LMM. An LMM can verify the

public key certiﬁcate and generate a session key from

its own private key, a public key of the other entity,

and random values that have been shared in the au-

thenticated key exchange protocol. The status of li-

cense information should be managed in four stages:

normal, read, delegating and removed. We also use

an additional status ”delegated” for delegated license

information. The procedure of license delegation is as

follows;

1. An LMM (LMM-1) obtains license information

from the secure element. The status of the license

information is changed from ”normal” to ”read”.

2. LMM-1 executes an authenticated key exchange

protocol with another LMM (LMM-2) that is the

target to delegate the license information and con-

struct a secure channel between the LMMs.

3. LMM-1 transfers the license information to

LMM-2 via the secure channel, and the status

is changed to ”delegating”. Then the status is

changed to ”removed” when the transmission is

ﬁnished. The session key that LMM-1 holds is

deleted.

4. LMM-2 stores it in its secure element. The label

of the license information is ”delegated”. The ses-

sion key that LMM-2 holds is deleted.

5. LMM-2 provides ”delegated” license information

for an application programduring execution of the

program.

6. After execution of the application program,

LMM-2 computes a hash value of the ”delegated”

license information, and changes the status from

”delegated” to ”removed”.

7. LMM-2 executes the authenticated key exchange

protocol with LMM-1; then, LMM-2 sends a con-

ﬁrmation with the hash value of the license infor-

mation to LMM-1 via a secure channel. LMM-2

removes the hash value.

8. LMM-1 checks the hash value and then LMM-1

changes the status of the license information from

”removed” to ”normal”. LMM-2 removes the li-

cense information.

Note that the license information can be used

where the status is ”normal” or ”delegated”, and it

can be delegated only when the status is ”normal”.

LMM-ACommonComponentforSoftwareLicenseManagementonCloud

291

Table 2: Evaluation Results.

Function PC Cloud

Read License 43 ms 42 ms

Check License 37 ms 37 ms

Check Local Binding 36 ms 36 ms

Delegate License 83 ms 156 ms

(except AKE)

The status is changed to ”delegated-read” when dele-

gated license information is read from the secure el-

ement. We use an authenticated key exchange pro-

tocol based on Difﬁe-Hellman key agreement (Difﬁe

and Hellman, 1976) for sharing a session key such as

the ephemeral DH with RSA certiﬁcates mode (DHE-

RSA) in TLS (Dierks and Rescorla, 2008). The trust-

worthiness of LMMs is conﬁrmed based on their pub-

lic key certiﬁcates in the protocol.

4 EVALUATION

In this section, we present evaluation results for the

performance of the LMM and a security analysis of

our license management models.

4.1 Performance Evaluation

We implemented a prototype system of the LMM on

a PC

and a cloud environment

, and evaluated the

transaction time of each function. The total code

size of the LMM was 314 KByte. Table 2 shows the

evaluation results. All functions includes transaction

time for using the memory protection. The transac-

tion time of license delegation except the AKE pro-

tocol was evaluated on the PC and the Cloud. The

total transaction time of license delegation depends

on the selection of the AKE protocol. Each transac-

tion time is sufﬁciently small. The transaction time of

the memory protection linearly increases according to

increase of the parameter k

. We evaluated the trans-

action time where k

= 128 and the overhead of the

memory protection is negligibly small; thus, we can

apply the LMM to practical services.

4.2 Security Analysis

When we apply the LMM to the four license man-

agement models, we are able to protect license infor-

mation against the threats summarized in section 2.3,

and prevent illegal use of application programs. In

this subsection, we analyze the security of the license

management in relation to the threats.

Corei7-3720QM 2.6GHz, 8Gbyte Mem., CentOS 6.3

Amazon EC2, Xeon 2.66GHz

Execution without License Information. The ap-

plication binding function prevents program execu-

tion without license information because a key code

is stored and executed on the LMM. As described, the

license information is a vital part within the software

protection scheme, as it contains information that

needs to be present to successfully apply the encod-

ing / decoding procedure within the software protec-

tion scheme. This means that the computational com-

plexity of an attack on the software protection scheme

without valid license information is Ω(exp(m log l))

(Fukushima et al., 2012), where m is the number of

variables involved in the software protection mecha-

nism and l is the length of the variables.

Illegal Use of License Information. The license in-

formation is encrypted by an encryption key that is

derived from a secret key of an LMM and user secret

of the license owner. For a malicious user or oper-

ator this means that both the secret key and the user

password need to be obtained before the license infor-

mation can be used. As described, the user secret is

never used directly in the encryption process. Instead

a secure hash function is used to calculate a hash value

from the user secret. By using a collision resistant se-

cure hash function like SHA-256 or SHA-512, attacks

on the user secret can nearly be eliminated. The only

possibility would be to intercept the secret when it is

entered by the user at the terminal. This has to be

prevented by additional security mechanisms which

are not considered in this paper. Consequently, a ma-

licious user or malicious operator cannot use the li-

cense information without obtaining the user secret.

Theft of License Information. For this threat we

have to distinguish between a running and a not run-

ning application. In particular, this means that either

the license information is only available encrypted

within the secure element (this is valid as long as the

application is not executed) or the license information

is already loaded into system memory (this is valid

for an already executed application). So, as long as

the application is not executed, we assume that the

theft of license information additionally involves the

theft of the user secret and access to the secret key.

On runtime, the license information is already loaded

into memory, and it is difﬁcult for an attacker to de-

termine correct data on the memory, even if the at-

tacker can obtain δ access patterns to the physical

memory. Due to (Nakano et al., 2012), the proba-

bility ε that the attacker ﬁnds the correct memory ac-

cess is ε ≤

(m−2)

(1−p

(m−2)

(1−p

)(1−p

)

2(m−2)

, where

≥ (

m−2

)

, p

≥ (

)

Attack on Communication. The communication

channel between two LMMs must be protected us-

ing the secure delegation protocol. We assume that

SECRYPT2013-InternationalConferenceonSecurityandCryptography

292

a standardized protocol like TLS is used to generate

a secure session key during the handshake. As de-

scribed, the secure delegation protocol also includes

digital signatures, which are used to authenticate the

systems involved. This means that we assume that

an external attacker is not able to modify the trans-

ferred data undetected, and thus may misuse the li-

cense information. The only possibility for an exter-

nal attacker is to eavesdrop the encrypted communica-

tion. Assuming here that standardized encryption al-

gorithms like AES-128 are used, the security depends

only on the conﬁdentiality of the secret session key.

Illegal Copy of License Information. The local

binding mechanism provides an LLM with protection

against illegal copying by an attacker. As described,

the security here relies on the application of a secure

hash function on local environment information. As

any access to the license information also involves

the veriﬁcation of that particular information, it is not

possible to copy the LLM and use the license informa-

tion on a system different from the original system. In

the models, the license information is transferred se-

curely from one LMM to another LMM.

5 RELATED WORK

In this section, we brieﬂy introduce existing work re-

lated to software license management on cloud envi-

ronments.

License Management. License checking using an

activation code is a common function of copy protec-

tion software. Software obfuscation schemes trans-

form the original program into an obfuscated pro-

gram that is difﬁcult to analyze, while preserving its

function. Some of the obfuscation schemes focus on

obscuring the data structures in a program (Collberg

et al., 1997; Shokurov, 2004), and some focus on ob-

scuring the control ﬂow (Hohl, 1998; Wang et al.,

2001; Chow et al., 2001). Software watermarking

schemes embed auxiliary information for identiﬁca-

tion into a program (Monden et al., 2000; Collberg

and Thomborson, 2002). The drawback of water-

marking is that it cannot prevent or detect unautho-

rized copying in real time. Online schemes use an

external server to check the user license (Microsoft

Corporation, 2003; Dvir et al., 2005) or to execute es-

sential parts of a program (Zhao et al., 2009; Mumtaz

et al., 2005). The drawbacks of these schemes are that

the program manufacturer must deploy and manage a

server, and program execution requires network ac-

cess between the server and user terminal. Hardware-

based schemes execute a whole program on a special

hardware device, such as a secure processor (Gilmont

et al., 1998; Suh et al., 2003; Shi et al., 2006). These

schemes are expensive solutions since tamper-proof,

high-performance hardware is needed to execute an

entire programin a protected domain on the hardware.

Combined hardware and software schemes reduce the

deployment cost of hardware-based schemes. A pro-

gram is executed on an unprotected device and only

the important functions are executed on resource-

constrained hardware. Atallah and Li (Atallah and

Li, 2003) proposed a license management scheme for

smart cards. In this scheme, the program is unpro-

tected on the device. Mana and Pimentel (Mana and

Pimentel, 2001) and Zhang and Gupta (Zhang and

Gupta, 2003) presented schemes where only the es-

sential parts of the program are executed on secure

hardware. Their schemes require the development of

distinct functions on each piece of hardware. Ander-

son (Anderson, 2008) studied the theoretical aspects

of the combined schemes based on complexity the-

ory. A program can execute securely in conjunction

with a partnering oracle on a secure device. The or-

acle collaborates with any program by changing the

parameters, since the function of the oracle is com-

mon to all programs. Anderson proved that Turing

machines are secure under the assumption that a se-

cure device can be used. Fukushima et al. (Fukushima

et al., 2012) proposed a practical software protection

scheme that transforms a general program into a pro-

tected program. The protected program handles en-

coded data on an unprotected device; then, the TPM

decodes the execution result. Oblivious RAM is the

traditional solution for memory access pattern pro-

tection. It was ﬁrst proposed by Goldreich (Goldre-

ich, 1987), and later extended by Goldreich and Os-

trovsky (Goldreich and Ostrovsky, 1996). Oblivious

RAM constructions remain too expensiveto be imple-

mented on embedded processors. In (Zhuang et al.,

2004), Zhuang et al. proposed a practical, hardware-

assisted scheme for embedded processors, with low

computational overhead.

License Management on Cloud. Two general mod-

els have been developed in the European projects

BEinGRID and SmartLM for managing software li-

censes in distributed environments (Li et al., 2008).

The SmartLM project (The SmartLM Project, 2013)

has addressed the licensing problem by working on

a framework. The SmartLM project proposed a

model that makes licenses mobile objects. The main

approach of the SmartLM is to provide platform-

independent access and treat software licenses as ser-

vices. In the model, a license management service

is used as a central service for license administra-

tion, license storage and scheduling as well as li-

cense information distribution and usage record cre-

LMM-ACommonComponentforSoftwareLicenseManagementonCloud

293

ation. The model is similar to the cloud-based scheme

(Model C) in our paper, and it can be used for li-

cense management on the cloud, even though the li-

cense management server needs to be a trusted lo-

cal server. ElasticLM (elasticLM, 2010) is a license

management scheme based on a contribution from the

SmartLM project, and it is a novel technology for

creating and managing software licenses designed for

distributed computing environments like grids, clouds

or service-oriented architectures (SOAs). The Bein-

GRID project provides a license tunneling model for

FlexLM-based products (Simmendinger et al., 2008;

The BEinGRID Project, 2009). Our LMM will be

applicable to their architectures. GenLM (Dalheimer

and Pfreundt, 2009) is a license management frame-

work that allows software venders to manage their li-

cense usage in a distributed environment. The key

idea of the framework is to build an on-demand li-

cense for a given job. Raekow et al. presented a li-

cense management architecture (Raekow et al., 2010)

that allows the authentication of a job via a trusted

proxy server. The architecture enables pay-per-use

license management that can be deployed together

with an on-demand computing scenario. Hou et al.

designed and implemented a software license man-

agement scheme (Hou et al., 2007) for a campus

computationalgrid environment; the main approaches

are automatic license scheduling based on application

queries, dynamic and license monitoring. Goel et al.

presented a short paper (Goel and Dua, 2012) about a

framework for a license management system between

the cloud user, cloud vender, and cloud provider. All

architectures/frameworks are assumed to be forms of

online license management; thus, ofﬂine license man-

agement such as cloud-based scheme (B) and (D) in

this paper have not been considered.

6 CONCLUSIONS

In this paper, we considered license management

models for cloud environmentsand designed a license

management module (LMM) for the models. We also

considered security functions in the LMM. Evalua-

tion results showed that the performance of the LMM

is sufﬁciently feasible, and the LMM is applicable

to license management on clouds. We will consider

a license management mechanism for more complex

licenses such as group licenses and hierarchical li-

censes in our future research.

ACKNOWLEDGEMENTS

A part of this work was supported by the Japanese

Ministry of Internal Affairs and Communications

funded project, ”Study of Program Protection Mecha-

nism for Open Platform Architectures (PROPROM).”

REFERENCES

Anderson, W. E. (2008). On the secure obfuscation of

deterministic ﬁnite automata. In Cryptology ePrint

Archive, 2008/148.

Atallah, M. J. and Li, J. (2003). Enhanced smart-card based

license management. In Proc. of IEEE International

Conference on E-Commerce (CEC2003).

Bicket, D. (2011). Cloud computing and license manage-

ment. ISS-N004-v3.2.

Chow, S., Gu, Y., Johnson, H., and Zakharov, V. A. (2001).

An approach to the obfuscation of control-ﬂow of se-

quential computer programs. In Proc. of 4th Informa-

tion Security Conference (ISC2001), Lecture Notes in

Computer Science 2200, pages 144–155.

Collberg, C., Thomborson, C., and Low, D. (1997). A tax-

onomy of obfuscating transformations. Technical Re-

port 148, Computer Science, University of Auckland.

Collberg, C. S. and Thomborson, C. (2002). Watermarking,

tamper-prooﬁng, and obfuscation — tools for soft-

ware protection. IEEE Trans. on Software Engineer-

ing, 28(8):735–746.

Courtney, C. (2012). Cloud computing security risks ? hy-

pervisor and multi-tenancy. Cloud Security.

Dalheimer, M. and Pfreundt, F.-J. (2009). GenLM: license

management for grid and cloud computing environ-

ments. In Proc. of 9th ACM/IEEE International Sym-

posium on Cluster Computing and the Grid (CCGRID

’09), pages 132 –139.

Dierks, T. and Rescorla, E.(2008). The transport layer secu-

rity (TLS) protocol version 1.2. Internet Engineering

Task Force (IETF), RFC5246.

Difﬁe, W. and Hellman, M. (1976). New directions in cryp-

tography. IEEE Transactions on Information Theory,

22(6):644 – 654.

Dvir, O., Herlihy, M., and Shavit, N. N. (2005). Virtual

leashing: Internet-based software piracy protection. In

Proc. of 25th IEEE International Conference on Dis-

tributed Computing Systems (ICDCS2005).

elasticLM (2010). elasticLM - License as a Service (LaaS).

The Fraunhofer Institute for Algorithms and Scientiﬁc

Computing SCAI.

Fukushima, K., Kiyomoto, S., and Miyake, Y. (2012). Soft-

ware protection combined with tamper-proof device.

IEICE Trans. on Fundamentals, E95-A, No.1:213–

222.

Gilmont, T., Legat, J.-D., and Quisquater, J.-J. (1998).

An architecture of security management unit for safe

hosting of multiple agents. In Proc. of the Interna-

tional Workshop on Intelligent Communications and

Multimedia Terminals.

SECRYPT2013-InternationalConferenceonSecurityandCryptography

294

Goel, U. and Dua, R. L. (2012). A review paper on cryp-

tographic approach for license management system in

cloud computing. In Indian Journal of Computer Sci-

ence and Engineering (IJCSE), volume 3, No.4, pages

626–631.

Goldreich, O. (1987). Towards a theory of software pro-

tection and simulation by oblivious rams. In Proc. of

ACM STOC ’87, pages 182–194.

Goldreich, O. and Ostrovsky, R. (1996). Software protec-

tion and simulation on oblivious rams. In Journal of

ACM, volume 43(3), pages 431–473.

Hohl, F. (1998). Time limited blackbox security: Protecting

mobile agents from malicious hosts. In Lecture Notes

in Computer Science 1419, pages 92–113.

Hou, Z., Zhou, X., and Wang, Y. (2007). Software li-

cense management optimization in the campus com-

putational grid environment. In Proc of the third In-

ternational Conference on Semantics, Knowledge and

Grid, pages 604 –605.

Kantarcioglu, M., Bensoussan, A., and Hoe, S. (2011). Im-

pact of security risks on cloud computing adoption. In

2011 49th Annual Allerton Conference on Communi-

cation, Control, and Computing (Allerton), pages 670

–674.

Li, J., Weldrich, O., and Ziegler, W. (2008). Towards sla-

based software licenses and license management in

grid computing. In From Grids to Service and Per-

vasive Computing, pages 139–152.

Mana, A. and Pimentel, E. (2001). An efﬁcient software

protection scheme. In Proc. of 16th IFIP International

Conference on Information Security (ISC2001), pages

385–401.

Microsoft Corporation (2003). Technical overview of win-

dows rights management services for windows server

2003.

Monden, A., Iida, H., Matsumoto, K., Inoue, K., and

Torii, K. (2000). A practical method for watermark-

ing java programs. In Proc. of 24th Computer Soft-

ware and Applications Conference (COMPSAC2000),

pages 191–197.

Mumtaz, S., Iqbal, S., and Hameed, E. I. (2005). Develop-

ment of a methodology for piracy protection of soft-

ware installations. In Proc. of International Multi-

topic Conference (INMIC2005).

Nakano, Y., Cid, C., Kiyomoto, S., and Miyake, Y.

(2012). Memory access pattern protection for

resource-constrained devices. In Proc. of The 8th

Smart Card Research and Advanced Application Con-

ference (CARDIS2012), LNCS, volume 7771, pages

188–202.

Popovic, K. and Hocenski, Z. (2010). Cloud computing

security issues and challenges. In MIPRO, 2010 Pro-

ceedings of the 33rd International Convention, pages

344 –349.

Raekow, Y., Simmendinger, C., Grabowski, P., and Jenz,

D. (2010). License management in grid and cloud

computing. In Proc. of 2010 International Conference

on P2P, Parallel, Grid, Cloud and Internet Computing

(3PGCIC), pages 9 –15.

Shaikh, F. and Haider, S. (2011). Security threats in cloud

computing. In 2011 International Conference for

Internet Technology and Secured Transactions (IC-

ITST), pages 214 –219.

Shi, W., Hsien-Hsin, Falk, S. L. L., and Ghosh, M. (2006).

An integrated framework for dependable and reviv-

able architectures using multicore processors. In Proc.

of the 33rd International Symposium on Computer Ar-

chitecture (ISCA2006).

Shokurov, A. (2004). An approach to quantitative analy-

sis of resistance of equivalent transformations of alge-

braic circuits. Technical report, Institute for System

Programming Russian Academy of Sciences.

Simmendinger, C., Kraemer-Fuhrmann, O., and Raekow, Y.

(2008). Support for client-server based license man-

agement schemes in the grid. In Collaboration and the

Knowledge Economy: Issue, Application, Case Stud-

ies, pages 1262–1272.

Suh, G. E., Clarke, D., Gassend, B., van Dijk, M., and

Devadas, S. (2003). Aegis: Architecture for tamper-

evident and tamper-resistant processing. In Proc. the

17th annual international conference on Supercom-

puting, pages 160–171.

The BEinGRID Project (2009). BEinGRID, business exper-

iments in grid. the European Unionfs sixth research

Framework Programme (FP6).

The SmartLM Project (2013). SmartLM - grid-friendly

software licensing for location independent appli-

cation execution. the European Commission Pro-

gramme, Information and Communication Technolo-

gies.

Wang, C., Davidson, J., Hill, J., and Knight, J. (2001). Pro-

tection of software-based survivability mechanisms.

In Proc. of International Conference of Dependable

Systems and Networks (DSN2001), pages 193–202.

Zhang, X. and Gupta, R. (2003). Hiding program slices for

software security. In Proc. of the international sympo-

sium on Code generation and optimization: feedback-

directed and runtime optimization, pages 325–336.

Zhang, Y., Juels, A., Reiter, M. K., and Ristenpart, T.

(2012). Cross-vm side channels and their use to ex-

tract private keys. In Proc. of the 2012 ACM confer-

ence on Computer and communications security, CCS

’12, pages 305–316.

Zhao, J., Yao, N., and Cai, S. (2009). A new method to

protect software from cracking. In Proc. of World

Congress on Computer Science and Information En-

gineering (CSIE2009), pages 636–638.

Zhuang, X., Zhang, T., Lee, H.-H. S., and Pande, S. (2004).

Hardware assisted control ﬂow obfuscation for em-

bedded processors. In Proc. of ACM CASES 2004,

pages 292–302.

LMM-ACommonComponentforSoftwareLicenseManagementonCloud

295