![](bg3.png)
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 Certification System Server (CSS). CSS is
in charge of all exchanges with the SM, and in partic-
ular coordinates the certification 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 first, 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-
nificantly 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 specification 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 Certification Authority (CA)
plays an important role in the security of the whole
system because it manages the certificates 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 certificates (as defined by the secu-
rity policy); it generates the certificate revocation lists
(CRL) whenever a certificate 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 specific task (see Figure 1). Due to
space limitations it is not possible to provide all de-
tails about the various fields 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 certificates 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 verifications: CERT KuA is
validated using the public key of the CA that is stored
in CERT KuCA; the signature is verified 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.
Certificate Distribution Protocol This protocol
distributes the cryptographic keys and certificates pro-
duced by the CA. These keys and certificates 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 certificate 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
40