Framework Implementation Based on Grid of Smartcards to

Authenticate Users and Virtual Machines

Hassane Aissaoui-Mehrez

, Pascal Urien

and Guy Pujolle

Institute of Mines-Telecom / TELECOM-ParisTech: LTCI CNRS Laboratory

Network and Computer Science Department, 46 rue Barrault, 75634 Paris, France

University of Pierre and Marie Curie, CNRS LIP6/UPMC Laboratory 4 Place Jussieu, 75005 Paris, France

Keywords: OpenID, Microcontrollers, Secure Elements, User-Centric Identity, Virtualization and Cloud Computing.

Abstract: The Security for the Future Networks (SecFuNet) project proposes to integrate the secure microcontrollers

in order to introduce, among its many services, authentication and authorization functions for Cloud and

virtual environments. One of the main goals of SecFuNet is to develop a secure infrastructure for virtualized

environments and Clouds in order to provide strong isolation among virtual infrastructures, and guarantee

that one virtual machine (VM) should not interfere with others. The goal of this paper is to describe the

implementation and the experimentation of the solution for identifying users and nodes in the SecFuNet

architecture. In this implementation, we also employ low-cost smartcards. Only authorized users are

allowed to create or instantiate virtual environments. Thus, users and hypervisors are equipped with secure

elements, used to open TLS secure channels with strong mutual authentication.

1 INTRODUCTION

The IdM system will be based on smartcards

OpenID and user-centric attribute control policies.

The authentication servers are composed by secure

microcontrollers.

The objective is to implement the framework, based

on the authentication servers and EAP-TLS

smartcard model. The proposed SecFuNet

framework provides TLS secure channels for

establishing trust relationships among Users, VMs,

XEN and Grid of Secure Elements (GoSE). The

authentication is done directly between smartcards

(owned by users or associated to VM) and a GoSE

arranged in a SecFuNet IdP.

This paper concerns a highly secure

authentication server with an array of secure

microcontrollers allowing users' or VMs' strong

mutual authentication with GoSE. It defines the

structure and the components of the authentication

server.

This paper is organized as follows. Section 2

presents a related work and a brief state‐of‐art of

EAP-TLS Smartcard Concept and Software

Architecture. The next section 3 details the use of

TLS-Id based on EAP-TLS smartcard in OpenID

platforms. In the section 4, we detail how dedicated

Service Provider may be used to download tokens in

EAP-TLS smartcard?

2 RELATED WORK

To address some of the security issues, the project

aims to explore the application of secure elements,

such as smartcards, to improve the trustworthiness

of network infrastructure services for future

networks. Two classes of secure microcontrollers

have been studied, smartcards and TPMs (Trusted

Platform Modules).

These electronics chips have different computing

capabilities, smartcards usually run a Java Virtual

Machine (JVM) and therefore are able to execute

complex procedures (such as the TLS protocol),

while TPMs are dedicated to the RSA algorithm.

However these devices may be used in order to

enforce trust for the TLS protocol or to guarantee

secure storage for cryptographic keys.

These security properties are directly provided

by smartcards (thanks to dedicated embedded

software), but require additional software

components for TPMs.

285

Aissaoui-Mehrez H., Urien P. and Pujolle G..

Framework Implementation Based on Grid of Smartcards to Authenticate Users and Virtual Machines.

DOI: 10.5220/0005046102850290

In Proceedings of the 11th International Conference on Security and Cryptography (SECRYPT-2014), pages 285-290

ISBN: 978-989-758-045-1

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

The main goal of this section is to briefly

overview the context of the virtualization platforms

and EAP-TLS smartcard model.

2.1 Extensible Authentication Protocol

(EAP) and TLS

The EAP (RFC 3748, 2004) is a flexible framework

targeting access control in various network

infrastructures such as classical LAN, wireless LAN,

or VPNs. Furthermore the EAP-TLS (RFC 5216,

2008) standard enables a transparent transport of

TLS in EAP messages; it offers a convenient way to

use TLS without TCP flavours, and provides

mechanisms for TLS packets segmentation and

reassembly. The SecFuNet TLS platform is based on

EAP-TLS smartcards, equipped with additional

facilities. These devices include a full TLS stack, an

entity managing X509 certificates, and provide a

secure environment for keys storage and

cryptographic procedures execution. The TLS

master stack forwards packets, which are thereafter

encapsulated in EAP-TLS messages “Figure 1”.

When it detects the completion of this phase (trigged

by finished messages) it uses two ISO7816

commands (APDUs) in order to retrieve CipherSuite

and KeyBlock parameters.

Figure 1: The EAP-TLS Header.

2.2 EAP-TLS Smartcard Concept

In this section we focus on EAP-TLS smartcard and

TLS Identity (TLS-Id) deployed in SecFuNet. A

smartcard (Jurgensen, 2002) is a tamper resistant

device, including CPU, RAM and non volatile

memory.

Most of the electronic chips (i.e. smartcard)

support a JVM and execute software written in this

programming language (Chen, 2002).

The use of smartcards in TLS authentication has

now a rather long history and has been largely

developed according to different models.

These devices run the JAVA open stack,

introduced in (Menon, 2006) and which comprises

four logical components. The software architecture

of the EAP-TLS smartcard (Pujolle, 2008)(Urien,

2013) is the following:

 An EAP engine, which implements four

fundamental services (EAP messages

treatment, identity management, security

functions, and personalization) and ensures

EAP routing towards authentication methods

supported by the card.

 EAP-TLS method, which manages

fragmentation and reassembly mechanisms.

 TLS stack. The Handshake protocol takes

responsibility of authentication mechanisms,

whereas the record protocol realizes the

encryption and the integrity of data securely

transported by the TLS tunnel.

 A certificates store.

The TLS-Identity (TLS-Id) is a set of five

parameters, which comprises:

 X509 certificate and its associated private key;

 Certification Authority certificate;

 EAP identity parameter (EAP-ID);

 Friendly name, used to identify and to activate

a given TLS-Id.

These parameters are embedded in the secure

microcontroller hold by SecFuNet users, during the

personalization process.

2.3 TLS Choreography with EAP-TLS

Smartcard

The TLS-Tandem card is plugged to a SecFuNet

host, such as personal computer or mobile handset.

Before opening a session with a TLS server, its

electronic identity is activated via the Set-Identity

command. The host intends to download a file,

typically through an HTTP request, which is

securely stored in a remote WEB server “Figure 2”.

The docking host manages TCP/IP operations

and opens a connection with a remote TLS server,

and then calls the connection procedure.

This latter resets the TLS-Tandem card, and

sends an EAP-TLS-Start packet concatenated to

Unix-Time; the smartcard produces a response

including the first TLS message. A software

component acts as a bridge between EAP-TLS and

TLS.

It removes EAP-TLS header (typically 10 bytes),

and sends TLS messages to remote server. It reads

incoming data, detects TLS error, and determines the

end of TLS messages such as:

 ServerHelloDone that indicates a four ways

handshake associated to a full session.

 Finished that indicates a three ways handshake

associated to a resume session.

Thereafter it packs this set of TLS messages in a

single EAP-TLS packet, appends a 6 bytes prefix,

and forwards this request to the card.

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

286

Figure 2: A TLS session dealing with EAP-TLS

smartcard.

The card generates a response which is processed

by the EAP-TLS/TLS bridge and transmits to the

server.

Upon, the docking host collects two parameters

from the smartcard: CipherSuite and Key-Block.

The procedure is over. Thereafter smartcard is not

used, and the docking host encrypts and decrypts

information, which are sent and received to/from

remote server. These operations are done via the

TLS-write and TLS-read() functions.

3 EAP-TLS SMARTCARD AND

OpenID

OpenID is a Single Sign On system made of three

entities, the consumer site requiring a user

authentication, the OpenID server performing the

user authentication, and an internet user equipped

with a terminal. The OpenID identifier is an URL

that comprises two parts the name of the OpenID

server and the user alias.

There are many ways to perform authentication

between the user and the OpenID server. The most

popular is the simple password mechanism.

In the SecuFuNet context we use a strong mutual

authentication based on a TLS session running in the

EAP-TLS device, in which all resources (i.e. client,

VM, server…) are identified by their X509

certificates and associated private keys.

3.1 Service Discovery and Shared

Secret Computing

In the OpenID context the user identity is associated

to an URL. The SecFuNet user equipped with a

secure element, logs to the Service Provider (SP)

WEB site, where he gives his identity and indicates

the solicited service. The SP deduces from the user’s

identity the OpenID server name. The consumer

starts a discovery (XRI) procedure with the provider

and collects the XRDS server address. These two

entities exchange thereafter resource descriptors

encoded according to the XRDS format.

Afterward the server and the consumer perform a

classical Diffie-Hellman key exchange (DH) of their

public keys, in order to compute a symmetric shared

secret used to enforce message integrity thanks to a

HMAC procedure.

3.2 Authentication with the SEs

The OpenID authentication server receives the

Authentication Request, as an HTML POST

message issued by the user’s terminal. It thereafter

returns an HTML form “Figure 3”.

In a classical provider implementation, the user

would be identified by a password collected by this

form, the login page being protected via a TLS

session. In the SecFuNet platform we suppress this

password, and we replace it by a TLS session with

mutual authentication (i.e. both sides hold X509

certificate and RSA private key), initiated by the

EAP-TLS secure element.

The login page is associated to an HTTP header

including a cookie whose value is the session

identifier (sid), and the associated URL also

comprises this value, i.e. looks like:

Figure 3: OpenID form used for user authentication.

FrameworkImplementationBasedonGridofSmartcardstoAuthenticateUsersandVirtualMachines

287

http://127.0.0.1:8080/~url=server.com/login.php?sid

When the user clicks on the AutoLogin button it

opens via its EAP-TLS token the

https//server.com/login.php?sid link, and is

consequently authenticated by its X509 certificate.

The HTTP response to this request will set the

cookie (sid) for the proxy address (dealing with the

loopback address such as 127.0.0.1:8080).

A second optional exchange occurs between the

provider and the browser (secured by the EAP-TLS

token), in order to confirm the association with the

consumer site. This step may be used for

downloading attributes in the EAP-TLS secure

element.

3.3 Authentication Response

After a successful authentication, the Authentication

Response is returned by the OpenID server to the

user’s terminal. It is thereafter redirected to the

consumer site, which finally delivers a welcome

page. As detailed “Figure 4” an Authentication

Response message is delivered by the SP.

It is a set of response parameters included in

location MIME header. Data integrity is enforced

by an HMAC field associated with the OpenID

secret key, computed from the previous DH

exchange.

Figure 4: OpenID Authentication Response Message.

4 LOADING CRYPTOGRAPHIC

TOKENS IN SMARTCARD

The goal of this section is to detail how dedicated SP

may be used to download tokens in EAP-TLS

smartcard. The user attributes instantiated by tokens

are stored in a secure element. Two use cases are

described in order to load cryptographic token in

smartcard: the use of a classical WEB interface to

authenticate user with its EAP-TLS Secure Element

based on the AJAX technology, and the use of GoSE

operations to authenticate VM.

4.1 User Authentication Using SE

As described in previous sections the SecFuNet user

is equipped with an EAP-TLS secure element

“Figure 5”. In order to collect tokens, it performs a

connection with the appropriate service provider. He

enters his identity and is thereafter redirected to

"adhoc" OpenID server. The server forwards a login

page and an authentication is performed by the EAP-

TLS secure element. Afterwards the OpenID server

delivers a page that interacts with the EAP-TLS

secure element. The interaction between the server

and the EAP-TLS Secure Element is based on the

Asynchronous JavaScript and XML (AJAX).

AJAX is a set of technologies for executing

applications on the browser side, triggered by user’s

interactions, typically mouse clicks associated with

HTML forms, and processed by JavaScript

procedures. AJAX pages are downloaded by the

user’s terminal. The user’s terminal is running a

TCP daemon that we call the Proxy Server (PS),

opened on the loopback address (127.0.0.1), usually

with the port 8080. Its interface is made by two

kinds of URLs, used for network exchange and

EAP-TLS secure element.

The first class of URLs (Class I), such as:

http://127.0.0.1:8080/~url=www.server/path/file.htm

l, opens an HTTPS session the remote server (i.e. is

equivalent to https://www.server/path/file.html).

The TLS session is booted from the EAP-TLS

secure element and then transferred back to the PS.

As a result the browser opens HTTP session with

remote servers that are authenticated via the USIM.

The second class of URLs (Class II), such as:

Figure 5: User token generation and downloading.

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

288

http://127.0.0.1:8080/reader/apdu.xml,

sends ISO7816 commands to the EAP-TLS secure

element. These commands are located in the body of

an HTTP POST request. There are encoded as the

content of form inputs: =CMD1&=CMD2&=CMDi.

The returned response is encoded according to the

XML format. AJAX pages returned by the OpenID

server include XMLHttpRequest objects that send

Class II HTTP requests to the proxy server.

These requests transport ISO7816 commands,

executed afterwards by the EAP-TLS secure

element. The proxy returns ISO7816 responses,

embedded in XML pages. These XML contents are

parsed and thanks to the DOM (Document Object

Model for JavaScript) the initial page is modified,

typically with a success status.

“Figure 6” illustrates AJAX interaction with the

EAP-TLS secure element. An ISO7816 command is

hidden in an HTML form; it is thereafter executed

by the proxy server.

Thanks to these mechanisms the OpenID server

pushes content in the EAP-TLS secure element.

During the authentication procedure the OpenID

server collects the certificate of the EAP-TLS secure

element, which contains a public key.

This cryptographic material may be used to build

a container, able to securely convey token to be

downloaded in the EAP-TLS secure element.

Figure 6: Interaction between EAP-TLS SE and OpenID.

A set of ISO7816 commands, embedded in

AJAX pages, realizes operations needed for

container downloading. A container is made of three

parts:

 A header, which is the encrypted value of a

symmetric AES key, with the EAP-TLS

secure element public key, according to the

PKCS#1 standard.

 A body, which is the encrypted value of the

token, according to an AES-CBC procedure.

 A trailer, which is the signature by a trusted

authority (identified by its public key) of the

header concatenated to the body, according to

the PKCS#1 standard.

Upon downloading, the signature of the

container is checked; the AES key is recovered from

the EAP-TLS private key, the token is afterwards

decrypted and stored in the smartcard.

4.2 VM Authentication Using GoSE

As previously mentioned, each VM is associated to

an identifier (VM

, i.e. a certificate), and the VM

Authorization Token (VM-Auth-Token) establishing

the link with the hypervisor (identified by its

identifier HV

) that hosts the VM. Each VM is also

associated to a secure element, plugged in a grid,

which securely stores its private key.

In order to remotely work with its private key,

the VM must interact the service provider that

interface the GoSE. The VM is authenticated by the

, and the hypervisor private key and VM-Auth-

token. This use case is illustrated by “Figure 7”.

The VM may access to the private key of the

hypervisor stored in a secure element. It establishes

a session with the grid service provider, and

provides the HV

, VM

and VM-Auth-Token

parameters. It also request cryptographic operation

with the GoSE, such as encryption or decryption

with the VM private key. It is thereafter redirected

toward the OpenID server that performs the

authentication process with the HV secure element.

Strictly speaking the OpenID authenticates the

hypervisor, and it is not aware of an existing

functional link with the VM.

At this step the service provider knows that the

remote entity has access to the HV private key and is

supplied with the appropriate credential (VM-Auth-

Token). The GoSE service provider realizes the

requested operation and returns the result.

Obviously the session between the VM and the

GoSE service provider must be secured by the TLS

protocol (i.e. HTTPS requests are used).

In order to get a greater security level, the GoSE

service provider may pack the result in a container,

which is made of three parts:

FrameworkImplementationBasedonGridofSmartcardstoAuthenticateUsersandVirtualMachines

289

Figure 7: Grid SP operations in an OpenID context.

 A header, which is the encrypted value of a

symmetric AES key, with the HV public key,

according to the PKCS#1 standard.

 A body, which is the encrypted value of the

result of the requested operation, according to

an AES-CBC procedure.

 A trailer, which is the signature by a trusted

authority (identified by its public key) of the

header concatenated to the body, according to

the PKCS#1 standard.

Some trust issue may exist between the grid SP

and the VM, because they don’t necessarily share

the same ring of confidence. In that case the

container could be directly generated by the VM

secure element, previously bound to an HV

. This

operation is performed by administrator of secure

element thanks to Global Platform mechanisms.

TLS sessions with strong mutual authentication

are mandatory for all virtual machines (VM). Thus,

we implement the TLS Application in VM-side and

the Secure Middleware in Xen-side, including a very

simple facility to access GoSE, in order to enforce a

remote VM access to secure element and to secure

connections and transactions.

5 CONCLUSION

The architecture proposed and implemented in this

deliverable presents a secure solution for user or VM

connection in the context of the SecFuNet, based on

grid of secure elements. This integration provides a

higher level of security when compared to traditional

password authentication, and establishes trust

relationships among the resources, and eliminates

the vulnerabilities like phishing attacks.

Strong authentication is done directly between

smartcards (owned by user or associated to VM) and

a GoSE.

We have seen in this paper that the use of secure

elements can make a real highlight in the certificate

management and the application of a security policy.

For large infrastructure, add our Secure

Middleware brings the real simplicity of

management. In parallel, can be very interesting

solution to access securely to a remote specific area

of GoSE.

The experimental results of the platform

developed for SecFuNet demonstrates that the

scalability performances are compatible with today

constraints.

Furthermore, the smartcard shall be a great

addition to virtual architecture and will be as well as

a key asset to securing Cloud Computing

infrastructures.

ACKNOWLEDGEMENTS

This work has had financial support from CNPQ

through process 590047/2011-6 (SecFuNet project)

and also through processes 307588/2010-6 and

384858/2012-0. We also thank CAPES for the

financial support with PhD scholarship.

REFERENCES

Jurgensen, T.M. et. al., 2002. Paper Prentice Hall PTR,

ISBN 0130937304, Smartcards: The Developer's

Toolkit.

Chen, Z., 2002. Addison-Wesley Pub Co 2002, ISBN

020170329, Java CardTM Technology for Smart

cards: Architecture and Programmer's.

Menon, A., Cox, A. L., and Zwaenepoel, W., 2006. in

Proceedings of the annual conference on USENIX ’06

Annual Technical Conference, ATEC’ 06, (Berkeley,

CA, USA), pp. 2–2, USENIX Association, Optimizing

network virtualization in xen.

Pujolle, G., Urien, P., 2008. International Journal of

Network Management, IJNM, Volume 18 Issue 2

(March/April 2008), WILEY, Security and Privacy for

the next Wireless Generation.

Urien, P., 2013. IETF draft, EAP-Support in Smartcard",

draft-urien-eap-smartcard-25.txt.

RFC 3748, 2004. Extensible Authentication Protocol,

(EAP).

RFC 5216, 2008. The EAP-TLS Authentication Protocol.

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

290