SECURE APPLICATION UPDATES ON POINT OF SALE DEVICES

Manuel Mendonc¸a

Faculdade de Ci

encias da Universidade de Lisboa

Bloco C6, Campo Grande, 1749-016 Lisboa - Portugal

Nuno Ferreira Neves

Faculdade de Ci

encias da Universidade de Lisboa

Bloco C6, Campo Grande, 1749-016 Lisboa - Portugal

Keywords:

Electronic payment systems, point of sale devices, secure application downloads

Abstract:

Currently, a large number of electronic transactions are performed with credit or debit cards at terminals

located in merchant stores, such as Point of Sale Devices. The success of this form of payment, however, has

an associated cost due to the management and maintenance of the many equipments from different generations

and manufacturers. In particular, there is an important cost related to the deployment of new software upgrades

for the devices, since in most cases human intervention is required. In this paper we describe a secure solution

for this problem, where Point of Sale Devices are able to automatically discover and upload new software

updates.

1 INTRODUCTION

Even though several electronic payment protocols

have been developed for the Internet in the past

years (Bellare et al., 2000; Manasse, 1995; Schoen-

makers, 1998; MasterCard and Visa Corporations,

1997), currently most of the electronic transactions

continue to go through closed banking networks. Sev-

eral reasons explain the success of these networks, but

among them, two are specially important – it is rela-

tively easy to obtain a debit or credit card from a ﬁ-

nancial institution, and there is a large number of ter-

minals, such as Point of Sale (POS) devices or Auto-

mated Teller Machines (ATM), where these cards are

accepted.

At the beginning, when these devices started to be

available, they were relatively expensive and had lim-

ited capabilities. Basically, they allowed operations

like purchase or cash withdraw. However, as the spec-

iﬁcations of the equipments employed in a transaction

went through a standardization process, many com-

panies began to offer competing terminals at cheaper

prices, which resulted in the current situation where

most stores have a POS, and ATMs have been widely

deployed. Moreover, the type of services provided by

these devices has evolved, allowing for instance the

payment of electrical or insurance bills, purchase of

train or music concert tickets, deposits of checks, or

money transfers between accounts.

The success of these networks has a cost associated

with the management and maintenance of the consid-

erable number of equipments from different genera-

tions and manufacturers. In particular, an important

cost arises from keeping the software being run in the

devices updated. Contrarily to the hardware that once

deployed it stays stable for a long period, the Elec-

tronic Funds Transfer (EFT) applications can suffer

several changes during the lifetime of the devices.

Various causes justify the need for software changes,

for example, the creation of new services, the year

two thousand (potential) bug, or recent events such

as the introduction of the euro. Besides these causes

for modiﬁcation, there are always the usual factors re-

lated to the maintenance of any software: undetected

bugs during the testing phase or security problems.

Nowadays, in most countries, software updates

continue to be performed manually. Once a new EFT

application has been certiﬁed by the entity respon-

sible for the network, the Payment Network Opera-

tor (PNO), the new version is given to a maintenance

company that will be in charge of the rest of the pro-

cess. This will require a technician to go to the lo-

cation where the equipment is placed, and then the

equipment has to be dismantled so that the chip where

the application is stored can be substituted by another.

In some occasions, just to save time, it is more cost

effective to simply exchange the terminal with a new

one.

Ferreira Neves N. and Mendonça M. (2004).

SECURE APPLICATION UPDATES ON POINT OF SALE DEVICES.

In Proceedings of the First International Conference on E-Business and Telecommunication Networks, pages 38-45

DOI: 10.5220/0001394800380045

 SciTePress

This procedure has many efﬁciency problems,

some of them related to cost and others to time.

For example, in Portugal, the POS network contains

around 140.000 devices. If each software update has

a fee of 50 euros and takes 20 minutes, then a com-

plete substitution of the network would cost 7 million

euros and would take more than 46 thousand person

hours. Moreover, from a security point of view, the

current procedure is far from the ideal because it re-

quires complete trust on the parties that will do the

actual software update and the PNO only controls the

operation in a limited way.

The speciﬁcations related to the Europay, Master

Card & Visa (EMV) (Europay, MasterCard and Visa

Corporations, 2000) suggest that a POS should have

the capability of uploading new versions of the soft-

ware. However, these speciﬁcations do not provide

any concrete solution to the problem. Furthermore,

currently available solutions are proprietary. Dur-

ing our research, we found two POS manufacturers

claiming to support remote software updates. How-

ever, when contacted by us, they did not provide any

information about their protocols.

In this paper we propose a solution for the secure

update of EFT applications in POS devices. Since we

wanted to build a solution that could be used in a real

banking environment, we decided to base our work on

the Portuguese banking network, that is called Multi-

banco. However, since the architecture and protocols

are relatively generic, we feel that our ideas can be ap-

plied to other networks (possibly with small changes).

2 BACKGROUND: MULTIBANCO

PAYMENT NETWORK

The Multibanco payment network carries most of the

electronic transactions made through POS and ATM

in Portugal (European Central Bank, 2001). The ar-

chitecture of the network is based on a client-server

conﬁguration, where on one side resides the POS (or

ATM) and on the other a server maintained by the

PNO. Currently, more than 140.000 devices are linked

using different network technologies, ranging from

public telephone connections with X.25 to wireless

networks like GSM.

The EFT protocol is organized as a request-

response transaction. The POS always has the initia-

tive of starting the communication by contacting the

PNO server, called the Payment System Server (PSS).

The message contains several ﬁelds, and among them

there is the identiﬁer of the selected service. Once

the message arrives, the PSS executes the service and

then returns a response indicating the success or fail-

ure of the operation. A Message Authentication Code

(MAC) secures both the request and response against

integrity and authenticity attacks. Each POS shares

with the PSS a number of symmetric keys that are

used to secure the communications. These keys are

stored in a secure module of the POS to ensure that

they are physically protected from tampering. If the

PSS wants to make the POS perform some action, it

has ﬁrst to wait for the contact of the POS. Then, in

the response, it can include the code of a transaction

that should be executed next.

As an example, lets look at a payment transaction

with a debit card in a store. The merchant gets the

card from the client, and uses the POS reader to input

the data saved in the magnetic stripe of the card. This

data includes information about the account number

and bank of the client. The vendor types the cash

amount using the POS keyboard and lets the user in-

sert her Personal Identiﬁcation Number (PIN). Next,

the EFT application executing in the POS constructs

a message containing the information related to the

transaction: the service code, a sequence number, the

device unique identiﬁer, date, amount, client account

data, and the PIN encrypted with a key stored in the

POS. When a message arrives, the PSS performs sev-

eral tests to verify the correctness of the received in-

formation. For instance, it validates the PIN that was

input to make sure that the client is the owner of the

card. If the PIN is wrong, the user gets two other tries

before the card becomes permanently blocked. On

every occasion a test fails, a response is returned to

the EFT application indicating the problem. Next, the

PSS contacts the client and merchant banks to process

the payment. If the client bank authorizes the debit,

then the PSS can inform the merchant bank to credit

the requested amount on the vendor’s account. The

banking information about the merchant is known to

the PSS because it is associated with the POS unique

identiﬁer, which is stored in a PNO database. If all

steps are concluded with success, then the PSS can

send an OK message to the EFT application. Other-

wise, an ERROR message is returned.

3 SECURE APPLICATION

UPDATES IN POS

The update of an EFT application requires the execu-

tion of two main tasks. First, a new version of the soft-

ware needs to be produced by some manufacturer and

certiﬁed by the organization supervising the network

(the PNO). The certiﬁcation procedure is an impor-

tant step because it not only needs to guarantee that

the upgrade satisﬁes the speciﬁcation, but also has

to ensure that all bugs and/or security problems have

been removed (at least as many as possible). As we

mentioned in the Introduction, several reasons might

contribute for the necessity of a new version of the

SECURE APPLICATION UPDATES ON POINT OF SALE DEVICES

application.

The second task comprises all activities related to

the upload of the application to the POS. Ideally, the

PNO should control this process since, in the end, it is

responsible for the good performance of the network.

Moreover, the whole procedure should be as auto-

matic as possible because this allows rapid deploy-

ment of new services, and potentially reduces costs

due to human intervention. Since electronic payment

transactions will be executed in the POS, the security

of the process is also very important.

The proposed update procedure, besides guarante-

ing the just mentioned objectives, also has some other

interesting characteristics such as: it maintains accu-

rate information about the POS and EFT applications

currently deployed, which is an attractive feature if

one wants to use the system to support managing de-

cisions.

3.1 System Architecture

The architecture of the payment system is displayed

in Figure 1. It includes both the POS in the merchant

store and the PSS located in the PNO. In order to sup-

port automatic updates of the EFT applications, the

PNO has to offer two interfaces to the outside: one to

the Software Manufacturers (SM) and another to the

POS.

The interface to the SM is provided by a new server,

called the Certiﬁcation System Server (CSS). CSS is

in charge of all exchanges with the SM, and in partic-

ular coordinates the certiﬁcation process. Whenever a

new application is developed, it should be submitted

through the CSS for validation. Then, a number of

tests are performed to ensure the quality of the soft-

ware, and a report is returned. Ideally, the analysis

would be done by machines in a controlled testing

environment, however, for the time being, one would

expect (and accept) some human intervention. The

communication between the CSS and the SM needs

to be secured to prevent attacks that could try, for in-

stance, to change the software upgrade.

At ﬁrst, one might feel tempted to re-use the PSS

as the interface to the POS for the application updates.

In practice, this solution has some problems because

it takes a reasonable interval of time to download an

application (see Section 4), which could degrade sig-

niﬁcantly the performance of the PSS (do not forget

that the main task of the PSS is to accept payment

transactions). Therefore, we introduce a new server,

called the Application Distribution Server (ADS), that

will store the code sent by the CSS and transfer the

updates to the POS.

The EMV speciﬁcation for cards with a chip uses

asymmetric cryptography to secure the electronic

payment transactions (Europay, MasterCard and Visa

Corporations, 2000). Therefore, since it is expectable

in the near future the replacement of magnetic stripe

cards with chip cards, we decided also to use asym-

metric cryptography to protect the transactions of the

update protocol. The Certiﬁcation Authority (CA)

plays an important role in the security of the whole

system because it manages the certiﬁcates with the

public keys of the various components.

The CA has to perform several functions: it needs

to reliably authenticate the entities that require the

creation of new certiﬁcates (as deﬁned by the secu-

rity policy); it generates the certiﬁcate revocation lists

(CRL) whenever a certiﬁcate needs to be cancelled

(e.g., the private key was compromised); and it also

carries out other management functions, such as the

archival of all generated data.

3.2 Update Protocol

The update procedure of the EFT applications is im-

plemented by a set of sub-protocols, each one re-

sponsible for a speciﬁc task (see Figure 1). Due to

space limitations it is not possible to provide all de-

tails about the various ﬁelds of the messages and their

validation process. However, since most messages

are protected using the same mechanism, we will

give here a generic description (the only exception

are the EFT protocol messages that are secured us-

ing the standard MAC scheme, as mentioned in Sec-

tion 2). Whenever a component A sends a message

data to a component B, it constructs a message with

< data, E(KrA, Hash(data)), CERT

KuA >,

where E(KrA, Hash(data)) is a signature and

means enciphering an hash of the data (Hash(data))

with the private key KrA of A. The message also in-

cludes all certiﬁcates with the public keys necessary

to the validation of the signature, which in this case is

CERT KuA. Once a message arrives, the receiver

makes the following veriﬁcations: CERT KuA is

validated using the public key of the CA that is stored

in CERT KuCA; the signature is veriﬁed by deci-

phering E(KrA, Hash(data)) with KuA, and com-

paring the result with the hash of the received data.

If they are equal then the message is correct.

Certiﬁcate Distribution Protocol This protocol

distributes the cryptographic keys and certiﬁcates pro-

duced by the CA. These keys and certiﬁcates are used

to ensure the authentication and non-repudiation of

the information exchanged among the components of

the architecture. The CSS, ADS and SM should exe-

cute the following actions:

• Obtain a copy of the certiﬁcate with the public key

of the CA (CERT KuCA).

• Generate a pair of asymmetric keys, public and

private key, and store them securely ((KuXXX,

KrXXX) where XXX is either CSS, ADS, or SM).

ICETE 2004 - SECURITY AND RELIABILITY IN INFORMATION SYSTEMS AND NETWORKS

• Ask the CA for the creation of a certiﬁcate contain-

ing the public key (CERT KuXXX where XXX is

either CSS, ADS, or SM).

The certiﬁcate with the public key of the CA has

to be securely distributed through the components of

the architecture because all signature validations will

depend on the correctness of this key.

The creation of a certiﬁcate will typically re-

quire human intervention due to some authentica-

tion/authorization steps. The security policy might

impose, for instance, the need for an explicit autho-

rization from the PNO before a request for the cre-

ation of a certiﬁcate can be made. This type of re-

quirement is interesting because if applied to the SM,

it would limit who can produce correctly signed soft-

ware.

POS Set-up Protocol The manufacturer of the POS

needs to execute some set-up operations before send-

ing the device to a store. These operations include the

installation of the basic run-time software, the boot-

strap code and the application loader, and the secure

storage of the following keys:

• A pair of asymmetric keys of the POS (KuPOS, Kr-

POS).

• A copy of the certiﬁcate with the public key of

the POS (CERT KuPOS). This certiﬁcate can be

signed with the private key of the SM (instead of

the CA).

• A copy of the certiﬁcate with the public key of the

manufacturer (CERT KuSM).

• A copy of the certiﬁcate with the public key of the

CA (CERT KuCA).

Each device has a distinct pair of keys which en-

sures that a POS compromise will not affect the rest

of the network. To reduce the risk of key disclosure,

the local copies of the POS private keys should be de-

stroyed by the SM after their storage in the security

module.

The SM is responsible for the generation of the

certiﬁcate with the public of the POS. This option

is interesting from an economic and efﬁciency point

of view because it is simpler to produce a certiﬁ-

cate locally (without the intervention of the CA)

with a more relaxed the security policy. How-

ever, the validation of a POS signature will re-

quire the possession of both certiﬁcates of the SM

and CA (CERT KuCA veriﬁes CERT KuSM, and

CERT KuSM veriﬁes CERT KuPOS).

The inclusion of the certiﬁcate of the manufacturer

is used to restrict who can create new versions of the

software – a POS will only accept upgrades signed by

the same manufacturer. At ﬁrst, this might look like

an unnecessary limitation of the protocol. However,

it has important security implications because it pre-

vents certain types of attacks. For example, a bad CSS

is unable to substitute a new update with a malicious

one, signed by a friendly (and also malicious) SM.

Application Transfer Protocol This protocol de-

ﬁnes how new versions of the EFT applications and

certiﬁcation reports are exchanged between the SMs

and the CSS. Whenever a new upgrade is produced,

the SM sends a signed copy of the code to the CSS

for approval. Then, the code goes through a testing

phase to guarantee that it works as expected. Next,

the CSS returns a signed report to the SM stating if

the new version of the software was accepted or not

by the certiﬁcation tests (in the last case it also in-

cludes a list with a description of the failed tests).

From a security perspective, the certiﬁcation proce-

dure is particularly important because it can constrain

the type of attacks that can be executed by an adver-

sary SM. Basically, with an exhaustive set of tests,

one can prevent bad software from being inserted in

some POS of the network.

If the CSS is controlled by an adversary, even if

momentarily, she (or he) will not be able to produce

correctly signed applications, at most she could try

to substitute the upgrade with a previous one (do not

forget that a POS only accepts updates from the its

own manufacturer). However, since we associate an

increasing version number to each upgrade, it is pos-

sible to prevent this attack with a simple rule enforced

at the POS – it only accepts updates with a larger ver-

sion number.

Internal Management Protocol This protocol

comprises all actions internal to the PNO, necessary

to support the software updates. Basically two tasks

have to be accomplished:

• Code transfer to the ADS: the CSS sends to each

ADS a signed message with a copy of the code and

a list of POS models that should be updated. Af-

ter storing the code, the ADS is ready to receive

requests from the POS.

• Notify the PSS about the upgrade: The CSS sends

a signed message to the PSS containing the list of

POS models that should updated, the version num-

ber of the code, and a signature of the code done by

the SM (i.e, based on the KrSM). This information

is then stored in the database of the PSS.

During normal operation, a POS only communi-

cates with the PSS. Therefore, it must be the PSS who

will inform the terminal that it must upload a new ver-

sion of the EFT application.

EFT Protocol In the standard EFT protocol, only

the POS can initiate the communication by sending a

SECURE APPLICATION UPDATES ON POINT OF SALE DEVICES

request to the PSS. In the response, the PSS can de-

mand the execution of an operation by indicating that

a given transaction should be carried out following the

current one. Therefore, we had to introduce four new

EFT transactions to inform the POS about new up-

dates and for some management activities. The new

EFT transactions are:

• Begin Update Transaction (BUT): indicates that

a new upgrade is available and provides the fol-

lowing information: conﬁguration data about the

ADS that should be contacted (e.g., communica-

tion ports), version number of the code, and the

signature of the code made by the SM.

• End Update Transaction (EUT): serves to main-

tain audit information at the PSS database about

which software upgrades were made in the past.

After completing the download and the application

restart, the POS contacts the PSS to indicate that

the update was a success (or that there was an er-

ror).

• Key Version Transaction (KVT): POS sends the

versions of the keys (and certiﬁcates) that are stored

in its security module.

• Update Keys Transaction (UKT): the PSS can up-

date the keys saved in the POS. This transaction has

to be performed with some caution because a bad

PSS could use it to compromise the whole network.

There are basically these types of updates:

– new POS keys: to avoid tampering, the SM

should ﬁrst encrypt the keys with the previous

public key of the POS, and then sign them. If the

cause for the keys exchange was the compromise

of the POS, then a different mechanism would

have to be used. An attack as severe as this one

would probably require the manual substitution

of the POS since it could no longer be trusted.

– renewal of CERT KuPOS: typically, certiﬁcates

are only valid during an interval of time. There-

fore, periodically a new version of the certiﬁcate

with the current POS public key must be pro-

duced and distributed by the SM (or CA).

– renewal of CERT KuSM: for the same reason, a

new version of the SM certiﬁcate has to be pe-

riodically distributed. The new certiﬁcate could

contain a different public key, however, it should

have the same SM identiﬁcation and should be

correctly signed by the CA.

– renewal of CERT KuCA: due to the same rea-

son as before. If the new version of the certiﬁ-

cate has a different public key, then it should be

accompanied with some proof demonstrating the

knowledge of the previous CA’s private key. This

scheme allows the substitution of the CA’s keys

and at the same time prevents attacks where, for

instance, the CA’s public key is replaced by a

malicious PSS.

These new transactions will be included on the

standard EFT protocol. Therefore, they will share

the regular security infrastructure where messages are

protected with a MAC based scheme.

Table 1: Fields of the ATS transaction.

Message Fields Request Response

POS → ADS ADS → POS

Message Type 304 314

Identiﬁer (MTI)

System Trace Audit X X

Number

Error Indicator X

Source POS ident ADS ident

Destination ADS ident POS ident

Signature with KrPOS X

Signature with KrADS X

Next MTI X

Data Length X

Transport Data data block

Current Data X

Block Number

Next Data X

Block Number

Download Protocol This protocol downloads the

software from an ADS to the POS. An example of an

application transfer can be observed in Figure 2 (the

message format follows the standard ISO 8583 (Inter-

national Standard Organization, 2003)). To accom-

plish this task three different types of transactions are

executed between the POS and the ADS:

• Begin Transmission Session (BTS): POS sends a

message to the assigned ADS providing informa-

tion about the wanted version of the code and its

communication requirements, such as maximum

acceptable block size (MBS) and list of supported

compression algorithms. The response returned by

the ADS includes the total size of the application,

and the total number of MBS that will be sent (the

application might have to be fragmented if its size

is larger than the acceptable MBS).

• Application Transfer Session (ATS): in each ex-

change pair, the POS requests a speciﬁc block of

the application and the ADS transmits that block.

In case of failure, the POS can always restart the

transfer process from the last correctly received

block. As an example, we provide in Table 1 a

more detailed description of the various ﬁelds that

must be included in each of the transaction’s mes-

sages.

ICETE 2004 - SECURITY AND RELIABILITY IN INFORMATION SYSTEMS AND NETWORKS

• End Transmission Session (ETS): after the arrival

of the whole application, the POS conﬁrms the cor-

rectness of the upgrade using the signature created

by the SM (that was provided by the PSS). Then,

it uses this transaction to inform the ADS about the

success (or failure) of the transfer. Next, it executes

the new software.

There are several causes for the interruption of an

application transfer session. For instance, there might

be an abnormal delay in the communications that re-

sults in a timeout either at the POS or the ADS; or

the session might be cancelled because a more recent

upgrade is received. In any case, depending on the

reason, the POS should be informed with different er-

ror codes if it can continue the transfer or it should

start from the beginning.

3.3 POS Software Architecture

This section discusses various options for the soft-

ware architecture of the POS. In general terms an ap-

plication can be compiled into one of the following

forms: executable object code or interpreted code.

The ﬁrst solution usually leads to better performance

because it takes into consideration the particularities

of the system for which it was built. But exactly be-

cause this dependency, it is not portable. Moreover,

the source code must be compiled for each speciﬁc

system prior to its deployment.

Using an interpreted code approach, the source

code of the application is translated into byte codes

of a virtual machine. A virtual machine is a theoret-

ical microprocessor with standard characteristics that

deﬁnes such things as addressing mode, registers, and

address space. Once translated, the code can be in-

terpreted by the virtual machine implemented specif-

ically for a particular system (Morrison, 2001).

Therefore, in both solutions, at some level, there

is always a system dependency, either the compiled

machine code or the virtual machine implementation.

Another important aspect that has to be taken into

consideration is the loading operation (Hall, 1990).

Prior to a program execution the machine code must

be loaded into memory. There are two types of ma-

chine code: relocatable and non-relocatable machine

code (Intel, 1998). In the ﬁrst case, every CPU in-

struction is associated with an offset address instead

of an absolute address. When the machine code is

loaded into memory a ﬁxed base memory address is

given by the operating system (OS). Consequently, it

is possible to load the code in (almost) every mem-

ory location and to support the concurrent execution

of several programs (loaded at different offsets). One

disadvantage of this approach is that it typically needs

an operating system to load and manage programs and

memory. The non-relocatable code solution can be

used without an operating system but the program will

permanently be located at the same base address.

Taking the above in mind, a correct organization of

the POS software is essential to minimize the asso-

ciated difﬁculties related to the application manage-

ment, load and execution, and to take over the full po-

tential of software upgrades minimizing, where pos-

sible, the download time (Europay, MasterCard and

Visa Corporations, 2000). Several scenarios are pos-

sible for the software organization depending on the

physical characteristics of the terminal. Let’s take a

look at two extreme examples: a PC based architec-

ture running a well known OS and an embedded sys-

tem designed from scratch.

On a PC based architecture, programs can be com-

piled into executable object code or interpreted code.

There are many software manufacturers and several

languages that can be used to program the applica-

tion. The resulting machine code (either from the

program itself or from the virtual machine) is typ-

ically relocatable and the OS can be programmati-

cally interfaced by APIs to make the memory man-

agement. In this scenario the POS software architec-

ture can be very easily organized into the following

modules/programs:

• Module that implements the Set-up Protocol;

• Module that implements the Application Transfer

Protocol;

• Module that implements the EFT Protocol;

• Common Subroutines.

Upgrades can be done separately and updating each

one of the above is almost a matter of receiving, cre-

ating, checking, substituting and deleting ﬁles.

On the other hand, embedded systems are designed

for particular solutions requiring speciﬁc software im-

plementations. In this kind of systems the number of

software manufactures is very restricted, there are few

available development languages and usually no vir-

tual machine or OS is available. Therefore, the easiest

solution for a software upgrade is to generate non-

relocatable machine code programs and to substitute

every line of machine code by the downloaded ones.

The following tasks will have to be performed:

• Store the downloaded application into non-volatile

memory without erasing the running one;

• Check the correctness of the downloaded applica-

tion;

• Copy the downloaded application into the address

space of the previous application or point to the en-

try point address of the downloaded application;

• Free unnecessary memory space for future soft-

ware download.

SECURE APPLICATION UPDATES ON POINT OF SALE DEVICES

This solution leads to longer transfer times because

the application is not divided into independent mod-

ules and must be transferred as a whole. A better

(but more expensive) solution is to build an OS for

the embedded system, divide the POS application into

the previous proposed organization and use relocat-

able machine code programs. As the modules can be

independently upgraded this solution leads to shorter

upgrade times.

4 PROTOCOL EVALUATION

The update protocol was implemented and evaluated

on a network of PCs. The POS was simulated on a

machine with a 1.4 GHz AMD Duron processor, and

both the PSS and ADS were simulated on a PC with

a 700 MHz Pentium Celeron processor. Each PC had

128 MBytes of RAM and was running Windows XP.

The network was a 10 MBits/s Ethernet. In our exper-

imental setting, several types of networks can be sim-

ulated, in particular a modem over a telephone line or

a wireless GSM connection, by artiﬁcially delaying

the rate of packet transmission to the operating sys-

tem. In all measurements, the maximum acceptable

block size of the POS was set to 2048 Bytes. The

cryptographic algorithms used in the implementation

were the SHA hash function and the RSA encryption

algorithm (for the digital signatures) with 1024 Bit

keys.

Our measurements focus on the transactions di-

rectly related to the application download. They in-

clude all transactions that need to be executed from

the moment a POS ﬁnds out that there is an update un-

til the conclusion of the whole process (transactions in

dark boxes in Figure 2). The observed elapsed times

for application downloads with different sizes, rang-

ing from 100 KBytes to 2 MBytes, are displayed in

Figure 3. This ﬁgure shows the performance of the

protocol for three types of networks. Currently, the

most common way to connect POS devices is through

a telephone line at 9,6 Kbits/s, therefore, the other two

curves provide some indication about protocol’s fu-

ture behavior as faster networks start to be utilized.

5 CONCLUSIONS

The paper describes a solution for the secure and au-

tomatic upgrade of EFT applications in POS devices.

This solution requires the introduction of a few new

components on the current architecture of the pay-

ment system, in particular a certiﬁcation server where

software manufactures can send and validate the up-

grades, and a set of application storage servers that

interact with the POS during the upload. A proto-

col was also provided to manage the various steps of

a software upgrade, from the moment it is produced

until it is installed in the POS. The solution was im-

plemented and evaluated on a network of PCs.

ACKNOWLEDGEMENTS

This work was partially supported by the FCT,

through the Large-Scale Informatic Systems Labo-

ratory (LASIGE) and project POSI/CHS/39815/2001

(COPE).

REFERENCES

Bellare, M., Garay, J., Hauser, R., Herzberg, A., Krawczyk,

H., Steiner, M., Tsudik, G., Herreveghen, E. V., and

Waidner, M. (2000). Design, implementation, and de-

ployment of the iKP secure electronic payment sys-

tem. IEEE Journal on Selected Areas in Communica-

tions, 18(4).

Europay, MasterCard and Visa Corporations (2000).

EMV2000 Integrated Circuit Card Speciﬁcation for

Payment Systems.

European Central Bank (2001). Payment and Securities Set-

tlement Systems in the European Union (Blue Book).

Hall, D. V. (1990). Microprocessors and Interfacing - Pro-

gramming and Hardware. McGraw-Hill.

Intel (1998). P6 Family of Processors. Hardware Devel-

oper’s Manual.

International Standard Organization (2003). ISO 8583 - Fi-

nancial Transaction Card Originated Messages: Inter-

change Message Speciﬁcations: Part 3 .

Manasse, M. (1995). The Millicent Protocols for Electronic

Commerce. In Proceedings of the 1st USENIX Work-

shop on Electronic Commerce.

MasterCard and Visa Corporations (1997). Secure Elec-

tronic Transaction (SET) Speciﬁcation – Book 1:

Business Description Version 1.0.

Morrison, M. (2001). Java 1.1 Unleashed. SAMS Net.

Schoenmakers, B. (1998). Security Aspects of the Ecash

Payment System. In State of the Art in Applied Cryp-

tography, Course on Computer Security and Indus-

trial Cryptography, volume 1528 of Lecture Notes in

Computer Science. Springer-Verlag.

ICETE 2004 - SECURITY AND RELIABILITY IN INFORMATION SYSTEMS AND NETWORKS

Payment Network Operator (PNO)

Point of Sale

Device (POS)

Merchant Store

PROTOCOLS:

1 – Certificate Distribution Protocol 4 – Internal Management Protocol

2 – POS Set-up Protocol 5 – EFT Protocol

3 – Application Transfer Protocol 6 – Download Protocol

Software Manufacturer (SM)

Certification Authority (CA)

Point of Sale

Device (POS)

Application Distribution

Server (ADS)

Payment System

Server (PSS)

Certification System

Server (CSS)

Figure 1: Architecture of the payment system.

ADS

POS

…….

Initiates a

BUT

There is an update,

therefore, requests the

execution of a BUT

in the response

Returns ADS configuration

data, CERT_KuADS, version

of the code,

and code signature

Sends

communication

requirements,

and version of the

code

Request a

specific

block of

application

Returns total number of

application blocks

Verifies the

authenticity and

integrity of the

application

and terminates

Informs the

outcome of

the update

Saves audit

information

Some

Transaction

OK/NOK

Request BUT

BUT

BTS

ATS ETS

OK/NOK

data

EUT

Block

update

PSS

OK/NOK

Figure 2: The update of an application.











































    



 !

"#$

"#$

%#$

Figure 3: Elapsed time for the update of an application.

SECURE APPLICATION UPDATES ON POINT OF SALE DEVICES