Identity-based TLS for Cloud of Chips

Gaurav Sharma, Soultana Ellinidou, Tristan Vanspouwen, Th

eo Rigas, Jean-Michel Dricot

and Olivier Markowitch

Cyber Security Research Center, Universit

e Libre de Bruxelles, Belgium

Keywords:

SDN Security, Transport Layer Security, ID-based Cryptography, ID-TLS.

Abstract:

In this work, we implement an identity-based Transport Layer Security (ID-TLS) protocol and integrate it on

scalable multiprocessor system-on-chip (MPSoC), namely Cloud-of-Chips (CoC), in order to secure the SDN

communication on this platform. We select two identity-based encryption schemes that are more likely to meet

the performance and resource constraints on the target platform. The schemes are Sakai-Kasahara’s identity-

based encryption (SK-IBE) and the optimized identity-based encryption (OIBE) for lightweight devices by

Guo et al.. The results assert that both the schemes have their computation vs storage trade-off. The SK-

IBE algorithm is signiﬁcantly more computationally efﬁcient than its OIBE counterpart while SK-IBE uses

around 30 percent more memory than OIBE. However, the performance results of ID-TLS favor SK-IBE over

OIBE. Finally, ID-TLS is integrated in the existing OpenFlow switch and controller implementations. This

brings us to a fully functional and secure ID-TLS implementation on CoC, keeping the platform constraints in

consideration.

1 INTRODUCTION

The technology landscape of today is dominated by

new paradigms, such as internet-of-things (IoT) and

internet-of-everything (IoE) which will grow expo-

nentially over the coming years. A wide variety of

applications and therefore, extremely versatile hard-

ware solutions are needed to satisfy mobile to high-

performance computing requirements. The traditional

system-on-chips (SoCs) are no longer capable to sup-

port all these applications and hence, a new solution

is needed to provide dynamic reconﬁgurability dur-

ing run-time and to support a wide variety of use

cases. In a recently presented architecture Cloud-of-

Chips (Ellinidou et al., 2018; Bousdras et al., 2018),

a combination of multiple integrated circuits (ICs)

and IC building blocks are interconnected together

with different communication speeds and hierarchy

levels. The CoC platform contains a printed circuit

board (PCB) of multiple ICs where each IC contains

scalable processing clusters (PCs). Each PC com-

prises a combination of high performance and low

power cores and thus enable a heterogeneous system

architecture. For handling on-chip data communica-

tion, network-on-chip (NoC) is installed. The ﬁgure

1 below illustrates the CoC architecture. In order to

achieve secure communication among PCs and ICs,

we propose to implement software deﬁned network-

ing (SDN) paradigm. The traditional routing mech-

anism employs NoC hardware routers to manage the

routes among PCs. However, recent SDN based strat-

egy implements a network manager/controller with

global view, which controls the routing in an adaptive

manner (Berestizshevsky et al., 2017).

The main idea of the SDN paradigm is to separate

the control plane and data plane. OpenFlow (OF) is

a common communication protocol used in SDN. OF

establishes a unicast communication channel between

each individual switch and the controller. It allows the

controller to discover OF-compatible switches, cre-

ates rules for the switching hardware and also col-

lects statistics. In CoC, the network is separated in

two levels: IC and PCB. On the IC level, the hard-

ware routers on network on chip (NoC) are treated

as SDN switches and the routing on individual IC

is managed by an IC level controller. For the inter

IC communication, an SDN switch is placed at the

boundary of each IC and is connected to a PCB level

controller (Ellinidou et al., 2018). Unfortunately,

the SDN paradigm is susceptible to several security

breaches (Samociuk, 2015). However, in this paper,

we are mainly addressing the communication secu-

rity among SDN switches (on each IC) and controller.

The SDN security requirements are listed in detail in

the next section. In addition to the switch-controller

unicast communication, multicast communication is

Sharma, G., Ellinidou, S., Vanspouwen, T., Rigas, T., Dricot, J. and Markowitch, O.

Identity-based TLS for Cloud of Chips.

DOI: 10.5220/0007252000440054

In Proceedings of the 5th International Conference on Information Systems Security and Privacy (ICISSP 2019), pages 44-54

ISBN: 978-989-758-359-9

Figure 1: CoC architecture.

also needed to address the issue of secure transfer of

routing updates to all/some of the swicthes (Sharma

et al., 2018; Sharma et al., 2017).

The existing security solution such as the Transport

Layer Security (TLS) protocol, is not well enforced

in the current version of the OF standard (Version,

2015). Indeed, the speciﬁcation reads “the switch ini-

tiates a standard TLS or TCP connection to the con-

troller” which means, using TLS is completely op-

tional. Moreover, the public key infrastructure (PKI)

overhead includes generation and signing of digital

certiﬁcates for switches and controller. This makes

PKI based solution less acceptable for CoC platform.

Therefore, we propose a more suitable solution that

ﬁts to unique characteristics of the CoC architecture.

1.1 Our Motivation and Contribution

The deployment of TLS uses complex certiﬁcate

management which includes certiﬁcate validation,

certiﬁcate lookup and its revocation (Li et al., 2011;

Gorantla et al., 2005). A switch would have to store

the certiﬁcate of controller but also the certiﬁcate of

other switches (in the case of inter-switch commu-

nication), which seems inappropriate from the com-

putation and storage perspective, especially in CoC

where these switches are lightweight embedded com-

ponents on each IC. More precisely, the cost of TLS

handshake is our major concern while the TLS Record

is very efﬁcient and interesting for our system, since

it uses an efﬁcient symmetric encryption (e.g. AES)

for communication. In order to use TLS in the CoC

context, TLS handshake needs to be modiﬁed without

compromising the security of authentication and key

exchange process. The alternative should not rely on

PKI based approach. The main contributions in this

research are following:

• We review the IBE literature and select two con-

trasting approaches well suited to CoC require-

ments.

• We also propose a practical approach to authenti-

cate the entities participating in the CoC system.

• We implement a modiﬁed version of TLS employ-

ing two identity-based encryption (IBE) schemes.

Furthermore, we compare the performance of ID-

TLS to the original TLS protocol using traditional

public key schemes and compare the performance

in the view of running time and memory con-

sumption.

• Finally, we propose a practical way of integrat-

ing this modiﬁed version of TLS in existing OF

switches and controllers, using “crypto-proxies”.

Identity-based TLS for Cloud of Chips

Rest of the paper is organized as follows: in Sec-

tion 2, we present TLS Handshake and Record proto-

col, security requirements for CoC and existing ver-

sion of modiﬁed TLS using IBE. The related work to

IBE is presented in Section 3, where it covers most

notable IBE contributions. Afterwards the implemen-

tation details are presented in Section 4, followed by

the results in Section 5. Lastly we summarize our re-

search in the Section 6.

2 BACKGROUND AND

SECURITY REQUIREMENTS

In this section, we present TLS protocol, generic

modiﬁed version of TLS and review security require-

ments for CoC.

2.1 Transport Layer Security Protocol

The beneﬁts of symmetric and public-key cryptosys-

tems are combined in the Transport Layer Security

(TLS) protocol, which can be used to establish an

authenticated secure channel between a client and a

server. TLS, successor of the well known SSL, has

been proposed in the Internet Engineering Task Force

(IETF) standard as an improvement of SSL 3.0 in

1999. Over the years, many TLS versions came out,

to arrive to the current version of TLS 1.2 in march

2011 (Dierks, 2008). TLS 1.3 is still a draft in 2018,

during the writing of this work. TLS is composed of

two protocols:

• TLS Handshake Protocol

• TLS Record Protocol

2.1.1 TLS Handshake Protocol

The TLS Handshake protocol’s ﬁrst purpose is to au-

thenticate the server and the client. To that end, PKC

schemes such as RSA or DSA can be used. The sec-

ond purpose is to negotiate different parameters, such

as the key to be used for the communication, secured

by symmetric encryption. For the key exchange, mul-

tiple algorithms are also available such as RSA and

Difﬁe-Hellman. The TLS Handshake is generally ini-

tiated by a client request to the server, where the client

proposes a list of supported ciphers and hash func-

tions. The server, having received the list, chooses

among the options the best cipher and hash function

available and sends it back to the client along with its

certiﬁcate. TLS uses a X.509 digital certiﬁcate which

implies the use of CAs and the Public Key Infrastruc-

ture (PKI). When a PKC like RSA is used to secure

the TLS Handhsake, the procedure continues as fol-

lows. After the client veriﬁes the server’s certiﬁcate,

the client and the server exchange R

and R

. R

and

are two numbers generated randomly and their pur-

pose is to add protection against replay attacks. The

client then chooses a random series of bits, called the

premaster secret (PMS). It encrypts the PMS using the

public key of the server and sends it to the server. The

server can decrypt the PMS using its private key. Fi-

nally, the client and the server, using the PMS, R

and

generate the master secret MS. This version of the

TLS Handshake can be resumed as follows (Roschke

et al., 2010):

1. Encryption and hashing functions negotiation be-

tween client and server. Generation of random

numbers R

and R

2. Transmission and veriﬁcation of the server certiﬁ-

cate including its public key K

pub

3. Exchange of R

and R

4. Client encrypts and transmits PMS:

E(PMS, K

pub)

5. Generation of the master secret MS:

genkey(R

,PMS)

2.1.2 TLS Record Protocol

The TLS Record protocol aims to provide conﬁden-

tiality through symmetric encryption, using the en-

cryption algorithm negotiated during the TLS Hand-

shake (for example AES, triple DES, etc.) and the

master secret MS as calculated during the handshake.

TLS Record also provides integrity checks of en-

crypted messages by using hash functions such as

HMAC-MD5 or HMAC-SHA.

2.2 Security Requirements

The CoC system is originally comprised of a number

of switches and the controller. In order to manage IBE

framework for secure communication, the private key

generator (PKG, a trusted party) is also a principal

component. The overall communication of the sys-

tem can be separated into two phases. During the ﬁrst

phase, all switches and the controller contact the PKG

to get their system parameters and private keys. In the

second phase, a switch establishes a secure channel

with controller via TLS, to protect the ﬂow of appli-

cation data, such as OF messages.

2.2.1 Phase 1

Most IBE descriptions specify that the private key

must be sent from the PKG to the nodes (the switches

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

and the controller) using a secure channel but they do

not specify exactly what this channel could be and its

security requirements. The possible threats and solu-

tions are:

• In order to ensure that the only legitimate nodes

can receive identity ID and private key, node au-

thentication must be performed by the PKG.

• A counterfeit PKG with different master key gen-

erates private keys and IDs for the nodes. This

PKG is able to decrypt all the trafﬁc between

nodes and controller. In this case, authentication

of the PKG by the nodes is also needed.

• An attacker can eavesdrop the response of the

PKG and steal the private key of a node. A so-

lution must be there to ensure the conﬁdentiality

of communication between a node and the PKG.

• An attacker can sniff the packets exchanged be-

tween a node and the PKG and replay them later

to obtain a private key.

• An attacker can manage to compromise the in-

tegrity of the packets between node and PKG.

2.2.2 Phase 2

This phase refers to switch controller communication

where we adopted ID-TLS protocol. The main focus

is on the SDN related threats that an ID-TLS could

protect against. Following the data ﬂow and interac-

tion among SDN components, Microsoft presents a

threat model, STRIDE to meet security requirements

CIANNA (conﬁdentiality, integrity, authentication,

non-repudiation, availability, authorization). STRIDE

stands for Spooﬁng, Tampering, Repudiation, Infor-

mation disclosure, Denial of service and Elevation of

privileges. In particular, the ID-TLS security solu-

tion will address properties such as conﬁdentiality, in-

tegrity, authentication and non-repudiation. The other

attacks are still applicable and need to counter sepa-

rately.

2.3 A Modiﬁed TLS Protocol Using IBE

A generic modiﬁed TLS Protocol for IBE se-

cured communication was introduced by Roschke et

al. (Roschke et al., 2010). In the case of a client-server

communication, the client derives the public key us-

ing server’s identity, which can be its IP address or its

URL. Then, the client could directly encrypt the pre-

master key (PMS) with the server’s public key. The

modiﬁed TLS handshake steps can be followed from

(Roschke et al., 2010). The basic steps are as follows:

1. Exchange of R

and R

and algorithm negotiation

2. Client generates the IBE public key of the server

pub based on the identity ID

of the server:

pub = genkey(ID

)

3. Encryption of the pre-master key PMS using the

public key of the server K

pub: E(PMS,K

pub)

and transmission to the server

4. Both client and server generate the master se-

cret MS using R

, R

and PMS: MS =

genkey(R

,PMS)

After the completion of this modiﬁed TLS handshake,

the client and server can securely communicate with

each other using symmetric encryption where master

secret is the encryption key.

3 RELATED WORK

The construction of ID-based encryption schemes

is generally achieved in one of three ways:

prime/composite order pairing or without pairing (re-

fer (Boneh and Franklin, 2001) for standard bilinear

pairing deﬁnition).

Some notable IBE constructions using prime-

order pairing are (Boneh and Franklin, 2001; Sakai

and Kasahara, 2003; Boneh and Boyen, 2004;

Waters, 2005) and (Gentry, 2006). The ﬁrst fully

functional prime-order pairing based IBE scheme

was introduced by Boneh and Franklin (Boneh

and Franklin, 2001). In the following text, we

will refer this construction as BF-IBE. In 2003,

Sakai and Kasahara proposed a new IBE scheme

with potentially improved performance (Sakai and

Kasahara, 2003). Their scheme SK-IBE is also based

on bilinear pairings, however unlike BF-IBE, they

use asymmetric pairing and a novel key extraction

approach. Boneh and Boyen (Boneh and Boyen,

2004) presented an IBE construction without random

oracle. In 2005, Waters (Waters, 2005) presented

the ﬁrst fully secure IBE without random oracle but

the scheme is clearly not designed for lightweight

devices, as the encryption algorithm requires one

multiplication in G

, three exponentiations (two in

and one in G

) and an average of n/2 (and at

most n) multiplications in G

where n is the length of

the plaintext. Gentry (Gentry, 2006) also proposed a

fully secure IBE without random oracle. The authors

claimed smaller system parameters and tight security

reduction but the key extraction algorithm is quite

complex.

Recently, in 2017, Guo et al. (Guo et al., 2017)

proposed an optimized IBE (OIBE) especially for

lightweight devices. Their encryption algorithm has

Identity-based TLS for Cloud of Chips

Table 1: Performance Comparison of Encryption Schemes.

Schemes Tool Required operation(s) Number of operation(s)

e MtP Hash Multiplication Expo.

Boneh-Franklin Pairing X X X X 4 1 1

Sakai-Kasahara X X X X 4 2 1

Boneh-Boyen X X X X 1 2 4

Waters X X X X 1 +- n/2 3

Gentry X X X X 1 5 6

OIBE (l=24) X X X X l × 2 l × 4 l × 7

Paterson-Srinivasan Trapdoor X X X X 2 0 2

three ﬂavors: single/k/multi bit encryption. Their

multi-bit encryption scheme is based on the single and

k-bit encryption schemes. The idea is to encrypt a L-

bit message where L = l × k, which means that if we

have a message of 48 bytes (e.g, the pre-master key

length in TLS) and k = 16 bits then we have to call the

k-bit encryption l=24 times. They compared the hard-

ware cost and computational efﬁciency of their en-

cryption with the Sakai-Kasahara scheme (Sakai and

Kasahara, 2003). The OIBE scheme is computation-

ally less efﬁcient than the SK-IBE or other IBE coun-

terparts. Typically, for the L-bit message encryption,

the OIBE algorithm is about

times slower than other

pairing-based IBE schemes. In our system, where the

size of the message to be encrypted (the PMS) is 48

bytes, the encryption would be 24-times slower.

Another way to construct an IBE is to use a

composite-order pairing. Many IBE schemes con-

structed from composite-order pairings can be found

in literature (Waters, 2009; Lewko and Waters, 2010).

However, none of them is practical for the CoC plat-

form or in general for lightweight devices.

In 2001, Cocks (Cocks, 2001) proposed a novel

IBE scheme based on the quadratic residuosity prob-

lem. This scheme is probably the less interesting one

due to its inefﬁciency. Moreover, the scheme is vul-

nerable to adaptive chosen ciphertext attack. The in-

efﬁciency of the scheme comes from the fact that it

encrypts messages bit by bit. For example, during the

TLS handshake, if we have to encrypt the PMS (384

bits) using a 1024 bit modulus, the sender would have

to send 2 × 384 × 1024 = 786 KBytes, which is quite

unreasonable for our platform. Another pairing free

variant is the construction from trapdoor discrete log

groups designed by Paterson and Srinivasan (Paterson

and Srinivasan, 2009). The major limitations of this

scheme are, the use of a particular curve with a ﬁxed

80-bit security and inefﬁcient private key extraction

(Guo et al., 2017).

This scheme is designed for applications where

the PKG has a lot of computational power (e.g.

military applications) and where the client is very

resource-constrained, such as a sensor.

Following the above discussion, two elliptic curve

cryptography (ECC) based IBE schemes (Guo et al.,

2017; Sakai and Kasahara, 2003) are chosen to mod-

ify TLS. Both the schemes have contrasting strong

points. It would be interesting to compare them for

our platform. The table 1 presents a comparison of all

interesting schemes.

3.1 ID-TLS Communication Between

Switch and Controller

The switches initialize a TLS connection to commu-

nicate securely with the controller. We propose to

use a modiﬁed version of TLS handshake that uti-

lizes an ID-based encryption scheme to encrypt the

pre-master secret (PMS), as shown in ﬁgure 2.

4 IMPLEMENTATION DETAILS

In order to implement the two chosen IBE schemes

(Guo et al., 2017; Sakai and Kasahara, 2003) and their

integration in our modiﬁed TLS protocol, the prelim-

inary phase is secure delivery of private key. The next

step is to embed the modiﬁed IBE protocols to ex-

isting TLS framework and then integrate it on CoC

platform. The subsections below describe the steps in

a more concrete manner.

4.1 Generation of Node Identity and

Private Keys

The ﬁrst step for each node in the system (includ-

ing the controller) is to contact the PKG, to obtain its

identity, its private key and the system parameters. In

contrast with common IBE schemes where the nodes

choose their identity and provide it to the PKG, in our

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

Figure 2: ID-TLS handshake.

implementation the choice of the identity is made by

the PKG itself. Unfortunately, implementing this sys-

tem without any authentication would lead to multiple

attacks as explained in section 2.2.1. In order to solve

some of the security threats highlighted before, we

implemented mutual authentication based on a shared

secret symmetric key between the nodes and the PKG.

This key is stored at all the ICs (for all switches and

controller) at the system integration time. The same

key is also used to encrypt the communications and

provide conﬁdentiality.

To obtain its identity and private key, the node

(switches and controller) encrypts the current times-

tamp using AES in Galois/Counter Mode (GCM) with

the pre-shared key (PSK) and send it to PKG. The

same PSK is stored on all ICs at the time of sys-

tem integration. The private key request to PKG in-

cludes the ciphertext, the initialization vector (IV) and

the authentication tag. The PKG decrypts the cipher-

text using the PSK and matches the authentication

tags. Also, the PKG checks whether the decrypted

timestamp is between a certain interval (depending on

the network, system conﬁguration and speed). After-

wards, the PKG randomly generates a node ID and

computes its corresponding private key, following the

appropriate IBE scheme. Finally, the PKG encrypts

the node ID and private key along with the system pa-

rameters using AES-GCM and the PSK. It then sends

the ciphertext, IV and tag to the node. The node de-

crypts the response and stores the ID and private key.

The detailed steps of the modiﬁed handshake are

as follows:

1. The switch sends a client hello request to the con-

troller containing the ciphersuites supported by

the client and a random byte string (called R

In our system, we propose two ciphersuites mak-

ing use of ID-based encryption as key-exchange

algorithm:

• TLS-SK-WITH-AES-256-GCM-SHA384

• TLS-OIBE-WITH-AES-256-GCM-SHA384

AES-256 in GCM mode is used for secure com-

munication between switch and the controller, and

SHA384 is used as a pseudo random function

(PRF) throughout the TLS protocol such as to

generate the master secret (MS) or during the FIN-

ISH request to make sure that they both have the

same MS. SHA384 is also generally used as a pa-

Identity-based TLS for Cloud of Chips

rameter of the HMAC function to protect the mes-

sage integrity which is not needed here because

the Galois/Counter Mode already provides mes-

sage integrity protection.

2. The controller responds by sending the cipher-

suite, a random byte string (called R

) and other

relevant information such as session ID

3. The controller notiﬁes the client that the hello pro-

cedure is done

4. The switch generates the PMS which is a random

48-byte string, encrypts with the ID of the con-

troller.

5. This step is common for the controller and switch,

as both have to compute the master secret (MS)

using the PMS, R

and R

MS = PRF(PMS, R

)

where PRF is a pseudo random function.

6. Finally, the controller and switch send the FIN-

ISH request which is the ﬁrst protected packet

with the newly generated master secret. They

verify that the content of the message is correct:

Veri f (PRF(MS,“ f inished”, Hash(handshake −

message))) == 1

The handshake-message is the concatenation of

all the handshake communications such as client

hello, server hello, server hello done and key

exchange messages.

7. When both parties have sent, received and val-

idated the FINISH requests of each other, they

can start sending encrypted application data using

AES-256 in GCM mode.

In order to ensure that only nodes authenticated by

the PKG can establish a secure connection with the

controller, we use token-based authentication. The

steps are as follows:

1. The PKG and the controller have a pre-shared se-

cret key K PKG C

2. During the key extraction process, the PKG gener-

ates an authToken = HMAC

K PKG C

(nodeID) and

delivers to all switches. The authToken is trans-

mitted encrypted along with the private key

3. During the TLS handshake, the node sends the

encrypted PMS, his ID and a token = authToken

⊕ PMS[2:len(authToken)+2]. Note that the ﬁrst

two bytes of the PMS are the protocol version, so

they are deterministic and cannot be used to en-

crypt the token. The controller decrypts the PMS,

XORs it again with the token to obtain the auth-

Token and then checks its validity using the node

ID and the K PKG C

4.2 ID-TLS on CoC

In order to realize the key extraction and ID-TLS, as

a proposed solution to CoC, precisely the steps are

detailed below.

1. The switch and controller encrypt a timestamp

along with PSK and send the resulting ciphertext,

IV and tag to the PKG

2. The PKG decrypts the ciphertext, checks the tag

and timestamp and then generates the node ID.

Now, PKG runs the key extract algorithm of SK

or OIBE, to get the private key corresponding to

the newly generated ID. Finally, PKG generates

the authToken for each switch ID.

3. The PKG sends encrypted the generated ID, pri-

vate key and authToken along with the parame-

ters of the SK or OIBE scheme. Depending on

the parameters of each IBE scheme, the content of

the encrypted packet can be as follows (For more

details about parameters, refer (Guo et al., 2017;

Sakai and Kasahara, 2003)):

• SK: (ID,authToken,d

pub

g = ˆe(P

))

• OIBE: (ID,authToken,d

))

4. The switch decrypts and verify the received mes-

sage. During the TLS handshake, the switch en-

crypts the PMS using chosen IBE scheme and

sends the encrypted PMS along with its identity

and a token, proving its membership of the sys-

tem

5. After the TLS handshake and the generation of the

master secret (MS), the switch and the controller

can communicate securely.

5 RESULTS

In order to analyze the running time and the mem-

ory consumption of the ID-TLS handshake, we com-

pare it with TLS handshake using RSA. We will ﬁrst

analyze the performance of ID-based encryption and

decryption compared to RSA in isolation and then

we will look at the general performance of the TLS

handshake. We implemented our solution integrating

mbed TLS (also known as PolarSSL in the past) with

PBC library. For the bilinear pairing map, we choose

type D pairing which implements MNT curves with

embedded degree 6. The order of the curve is around

170-bits (base ﬁeld) and therefore the security will be

1024-bit in the subgroup of F

, which is considered

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

Table 2: Running time comparison of encryption/decryption and key extract functions of the SK, OIBE with an average of

100 repetitions.

Scheme Encryption time (ms) Decryption time (ms) Extract time (ms)

CPU time Real time CPU time Real time CPU time Real time

SK 2.639 2.643 5.525 9.967 5.314 10.714

OIBE 57.610 136.308 264.445 443.481 11.069 21.456

RSA 0.193 0.156 3.257 3.331 - -

Table 3: Speed performance of the TLS handshake and private key extraction on an average of 100 repetitions.

Scheme Handshake client Handshake server Get private key

CPU time Real time CPU time Real time CPU time Real time

SK 2.989 93.869 6.099 59.764 30.037 78.973

OIBE 57.884 582.496 266.348 583.022 30.093 87.707

RSA 0.674 89.216 3.633 44.534 - -

good enough (Lynn, 2010). We compare the follow-

ing three ciphersuites:

• TLS-SK-WITH-AES-256-GCM-SHA384

• TLS-OIBE-WITH-AES-256-GCM-SHA384

• TLS-RSA-WITH-AES-256-GCM-SHA384

5.1 Performance Results Without TLS

Handshake

As expected, the OIBE encryption and decryption al-

gorithms are far slower than both RSA and SK. Our

experimental results show that the encryption is 22-

times slower in CPU time and 52-times slower in real

time while decryption is 48-times slower in CPU time

and 45-times slower in real time. However, in com-

parison with the RSA scheme, the performance of the

SK scheme is respectable. Also, note that the code

of the RSA scheme is fully optimized by the authors

of the mbed TLS library while our implementation of

SK is not optimized. Therefore, with a more opti-

mized SK implementation we could be closer to the

performance of the RSA scheme. Furthermore, the

key extract is also two times faster in SK as compared

to OIBE. The following table 2 describes the compar-

ative results of their timings.

5.2 Performance Results of the ID-TLS

Handshake

The running time for private key extraction and ID-

TLS handshake is presented in table 3.

Note that for SK and OIBE, the TLS handshake

also comprises the token management used for au-

thentication of the switches to the controller. The

RSA handshake does not include this mechanism.

From table 3, we see that the CPU time of the hand-

shake for all three schemes is almost the same as the

CPU time of the encryption and decryption as shown

in table 2 above. Therefore, the cost of token-based

authentication mechanism seems negligible and does

not add more computational overhead. Furthermore,

we claim that the RSA scheme seems faster than SK

but the difference is trivial. In the case of a real-

time application, the RSA handshake would have to

include the veriﬁcation of server certiﬁcate and in that

case, SK could overtake.

The real time cost of the client and server hand-

shake is very high (around 0.5 second) for OIBE,

which is due to the slow encryption and decryption

algorithm. The time of the “Get private key” column

represents the interval from the moment when a node

sends an encrypted private key request to the PKG un-

til the moment it receives its parameters (private key,

ID etc.) and initializes the elements it needs to use

IBE in TLS. The speed of the two IBE is about same,

SK being slightly faster.

5.3 Memory Usage

In comparison with the SK encryption, OIBE uses far

less memory with a memory consumption around 12

Kbytes. In order to estimate the memory usage for

a TLS secure communication, we transfer a webpage

between a client and a server. The client used ap-

proximatively the same memory, irrespective of the

encryption used in the TLS handshake. However, on

the server side, OIBE uses signiﬁcantly more heap

memory because it has to store the big hashmap used

for the decryption. The following table 4 represents

Identity-based TLS for Cloud of Chips

the peak heap memory consumption of our testing ap-

plication. The OIBE scheme uses less heap memory

Table 4: Memory usage.

Scheme Memory usage client Memory usage server

SK 3148 KB 3296 KB

OIBE 3160 KB 22752 KB

RSA 3344 KB 3332 KB

during the encryption than SK, but the memory usage

of an actual application is comparable to that of SK.

This is because OIBE has to store more cryptographic

parameters for its operation, so the initialization of

these parameters consumes additional memory. In ad-

dition, the memory usage of the server for the OIBE

scheme is much higher than that of the SK scheme.

Finally, the OIBE scheme at server requires around

7 seconds to perform the initialization of the system

before clients can contact it, while the SK initializa-

tion is much faster. So, in applications where speed

is critical, the SK scheme seems more suitable for an

ID-based version of TLS, while in applications where

lower heap memory usage can make a difference, the

OIBE scheme might offer a viable alternative.

5.4 Results on CoC

In order to investigate the integration of above mod-

iﬁed TLS, we need SDN supporting switches and

controller. The OpenVSwitch (OVS) and Ryu con-

troller are chosen to run on an SDN emulator

Mininet (Mininet, 2014). OVS is written in C, while

Ryu is mainly written in Python. Rather than follow-

ing direct integration of the secure channel in OVS

and Ryu, we opted for a solution that allows using

them more like “black-boxes”, with minimal or no

modiﬁcations to their pre-existing functionality. We

call them “crypto-proxies”. These proxies handle all

the tasks detailed above: obtaining the private key,

establishing a TLS connection and then handling the

encryption and decryption of messages accordingly.

On the CoC platform, it is easy to realize these

proxies in the network interface (NI) of the IP core.

Moreover, there are several advantages of the proxy

approach as follows:

• Our solution is independent of the chosen OF

switch or controller

• New security solution is easy to adopt as simple

as replacing the current proxy with a new one

• This approach bypasses the communication chan-

nel originally used between the switch and the

controller (TCP), which means that the data can

now be transferred over UDP or by any other

means, eventually a new protocol

We claim that there is no security compromise

while using proxies. The message generated at IP

core is encrypted and decrypted in its own NI and to

the best of our knowledge, there is no existing breach

in this situation. Using the setup described above, we

measured the ﬂow establishment time (deﬁned below)

for the default insecure version of OF as a baseline.

We then measured the secure channel setup and ﬂow

establishment time for the OF secured with the ID-

TLS proxies.

In the TLS case, secure channel setup refers to

the execution time of the TLS handshake (for one

switch). To measure the ﬂow establishment time, we

used the pingall command, which makes each host

ping all the other hosts in the network. In a fresh run

of the network emulation, the ﬁrst time pingall is

executed, the switches have to contact the controller

to create their ﬂow tables. For all subsequent exe-

cutions, the relevant ﬂow entries are already inside

the switch’s ﬂow tables and no further communica-

tion with the controller is required. We deﬁne the ﬂow

establishment time as the average execution time of

the ﬁrst pingall command minus the average execu-

tion time of subsequent pingall commands (which is

35.51ms in our test setup). Our results are displayed

in Figure 4 below:

The Sakai-based variant of TLS clocks in at about

100ms. The OIBE version of TLS is about 6 times

slower. It is important to note that in different scenar-

ios, the TLS cost will remain constant irregardless of

the number of switches. However, we calculated that

the average AES-GCM encryption-decryption times

in our testing environment is 0.0045ms (Averaged

over 1000 executions on actual OF messages, Stan-

dard deviation: 0.001ms).

6 CONCLUSION

This paper demonstrated that ID-TLS can be em-

ployed to secure the SDN communication on CoC.

We analyzed the performance of ID-TLS with tra-

ditional PKI based version of TLS in the view of

computation and storage efﬁciency. In particular, our

basis for comparison is to analyze the performance

of traditional protocols and their TLS versions. The

SK and RSA protocols have comparable performance

while OIBE is signiﬁcantly slow. However, the OIBE

protocol while slower during the encryption and de-

cryption, has signiﬁcantly lower heap memory con-

sumption during the encryption. In a client applica-

tion where speed is critical, the SK scheme seems

more suitable while in applications where lower heap

memory usage can make a difference, the OIBE

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

Figure 3: “crypto proxy” architecture.

Figure 4: Secure Channel setup and Flow Establishment

times, averaged over 10 executions.

scheme might offer a viable alternative. The integra-

tion of ID-TLS in existing OF nodes makes the so-

lution more appealing, especially for embedded sys-

tems. Moreover, the proposed solution is not lim-

ited to CoC but applicable to all such SDN instances

where certiﬁcate management is complex. The real-

ization of proposed solution on CoC hardware is in-

teresting for further exploration.

REFERENCES

Berestizshevsky, K., Even, G., Fais, Y., and Ostrometzky, J.

(2017). Sdnoc: Software deﬁned network on a chip.

Microprocessors and Microsystems, 50:138–153.

Boneh, D. and Boyen, X. (2004). Efﬁcient selective-id

secure identity-based encryption without random or-

acles. In International Conference on the Theory

and Applications of Cryptographic Techniques, pages

223–238. Springer.

Boneh, D. and Franklin, M. (2001). Identity-based encryp-

tion from the weil pairing. In Annual international

cryptology conference, pages 213–229. Springer.

Bousdras, G., Quitin, F., and Milojevic, D. (2018).

Template architectures for highly scalable, many-

core heterogeneous soc: Could-of-chips. In 2018

13th International Symposium on Reconﬁgurable

Communication-centric Systems-on-Chip (ReCoSoC),

pages 1–7. IEEE.

Cocks, C. (2001). An identity based encryption scheme

based on quadratic residues. In IMA International

Conference on Cryptography and Coding, pages 360–

363. Springer.

Dierks, T. (2008). The transport layer security (tls) protocol

version 1.2.

Ellinidou, S., Sharma, G., Dricot, J.-M., and Markow-

itch, O. (2018). A sdn solution for system-on-chip

world. In Software Deﬁned Systems (SDS), 2018 5th

Int. Conf. on, pages 14–19. IEEE.

Gentry, C. (2006). Practical identity-based encryption with-

out random oracles. In Annual Int. Conf. on the Theory

and Applications of Cryptographic Techniques, pages

445–464. Springer.

Gorantla, M. C., Gangishetti, R., and Saxena, A. (2005).

A survey on id-based cryptographic primitives. IACR

Cryptology ePrint Archive, 2005:94.

Guo, F., Mu, Y., Susilo, W., Hsing, H., Wong, D. S., and

Varadharajan, V. (2017). Optimized identity-based en-

cryption from bilinear pairing for lightweight devices.

IEEE Trans. Dependable Secur. Comput., 14(2):211–

220.

Lewko, A. and Waters, B. (2010). New techniques for dual

system encryption and fully secure hibe with short

ciphertexts. In Theory of Cryptography Conference,

pages 455–479. Springer.

Li, H., Dai, Y., and Yang, B. (2011). Identity-based cryp-

tography for cloud security. IACR Cryptology ePrint

Archive, 2011:169.

Lynn, B. (2010). The pairing-based cryptography (pbc) li-

brary. Accessed: 2018-04-25.

Mininet (2014). Mininet project. http://mininet.org/. Ac-

cessed: 2018-04-25.

Paterson, K. G. and Srinivasan, S. (2009). On the relations

between non-interactive key distribution, identity-

based encryption and trapdoor discrete log groups.

Designs, Codes and Cryptography, 52(2):219–241.

Identity-based TLS for Cloud of Chips

Roschke, S., Ibraimi, L., Cheng, F., and Meinel, C. (2010).

Secure communication using identity based encryp-

tion. In IFIP International Conference on Commu-

nications and Multimedia Security, pages 256–267.

Springer.

Sakai, R. and Kasahara, M. (2003). Id based cryptosystems

with pairing on elliptic curve. IACR Cryptology ePrint

Archive, 2003:54.

Samociuk, D. (2015). Secure communication between

openﬂow switches and controllers. AFIN 2015, 39.

Sharma, G., Kuchta, V., Sahu, R. A., Ellinidou, S., Markow-

itch, O., and Dricot, J.-M. (2018). A twofold group

key agreement protocol for noc based mpsocs. In

2018 16th Annual Conference on Privacy, Security

and Trust (PST), pages 1–2. IEEE.

Sharma, G., Sahu, R. A., Kuchta, V., Markowitch, O., and

Bala, S. (2017). Authenticated group key agreement

protocol without pairing. In International Conference

on Information and Communications Security, pages

606–618. Springer.

Version, O. S. S. (2015). 1.5. 0 (protocol version 0x06).

Open Networking Foundation.

Waters, B. (2005). Efﬁcient identity-based encryption with-

out random oracles. In Annual International Confer-

ence on the Theory and Applications of Cryptographic

Techniques, pages 114–127. Springer.

Waters, B. (2009). Dual system encryption: Realizing fully

secure ibe and hibe under simple assumptions. In Ad-

vances in Cryptology-CRYPTO 2009, pages 619–636.

Springer.

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy