Relational-based Trust Management in a Generic

Payment System

Lamia Chaffai-Sghaier

and Sihem Guemara-El Fatmi

SUPCOM, University of Carthage,2083 Tunisia

Abstract. Trust Management represents a vital component for the protection of

business transactions. This paper considers the application of a relational-based

model for Trust Management in Electronic Payment Systems. We introduce a

generic payment model that provides a good framework to validate our trust

model. We use the special features, new extensions and relational techniques pro-

vided by the Trust Management model to specify entities, actions and security

policy axioms and rules in the generic payment system. We also discuss com-

pliance correctness issues such as security policy speciﬁcation correctness and

validation, certiﬁcate chain discovery and revocation as well as performance is-

sues. Finally, we consider some implementation issues.

1 Introduction

The main issues in access control of distributed networks are authentication, authoriza-

tion and enforcement. Identiﬁcation of principals is handled by authentication. Autho-

rization answers the question: should a request r submitted by a principal K be allowed?

Enforcement addresses the problem of implementing the authorization during an exe-

cution. Trust Management (TM) systems resolve these issues by deﬁning languages for

authorizations and access control policies, and by providing a TM engine for deciding

when a request is authorized.

In [1], Boudriga and al. present a TM model which brings the novelty of using rela-

tional techniques for authentication and compliance checking processes. The model is

based on (1) a relational language allowing constructs for the description of TM entities

such as actions, certiﬁcates, requests and security policies, (2) a relational calculus for

performing proofs, verifying features, and computing systems answers,(3) a mechanism

for identifying entities requesting to perform actions based on public key certiﬁcates and

(4) a compliance engine, which provides a service to applications for determining how

an action that is requested by a principal can be granted based on relational certiﬁcates

chaining.

Electronic commerce services, which basically rely on Payment Systems (PS) and

use public-key cryptography on a mass-market scale, require sophisticated mechanisms

for managing trust. Furthermore, authorization constitutes the most important relation-

ship in a PS. In this paper, we introduce a generic payment model to demonstrate the

possible generalization of our TM model to all payment schemes and protocols.

The paper is organized as follows. Section 2 provides an overview of payment sys-

tems’ characteristics and security requirements. Section 3 introduces a generic payment

Chaffai Sghaier L. and Guemara-El Fatmi S. (2004).

Relational-based Trust Management in a Generic Payment System.

In Proceedings of the 1st International Workshop on Electronic Government and Commerce: Design, Modeling, Analysis and Security, pages 116-125

DOI: 10.5220/0001402801160125

 SciTePress

model providing an abstraction of payment services. Section 4 presents the TM model

components and new features relational compliance check processes. In section 5, we

apply the TM model to the generic payment model to demonstrate its ﬂexibility and

its capacity to encompass all types of PSs. Section 6, addresses the issues of the secu-

rity policy speciﬁcation correctness and compliance correctness. Section 7, presents an

implementation methodology. Section 8 concludes this paper.

2 Electronic Payment Systems

2.1 Models and characteristics

Commerce always involves a customer and a merchant who exchange money for goods

or services and at least one ﬁnancial institution (i.e. bank). PSs can be classiﬁed based

on the following features [2]: (a) Pre-paid vs post-paid,(b) Account based vs token

based, (c) On-line vs off-line,(d) Macropayments vs micropayments,(e) Deterministic

vs probabilistic.

2.2 Security properties and requirements

In general, PSs must exhibit the following security properties[2]: authentication, in-

tegrity of data, conﬁdentiality of information, non-repudiation, availability and reliabil-

ity (atomicity). Additional properties like anonymity and multiple-spending prevention

are sometimes required (i.e. cash-like systems). Moreover, PSs should fulﬁll mandatory

security requirements [3] (1)Bank requirements: proof of transaction authorization by

customer and by merchant, (2)Customer requirements: proof of transaction authoriza-

tion by bank, authentication and certiﬁcation of merchant and payment receipt from

merchant,(3)Merchant requirements: proof of transaction authorization by bank and

by customer. All these security properties and requirements can be achieved by using

Public-Key Cryptographic tools. While conﬁdentiality is attained by enciphering each

message, using a private key known only to the sender and recipient, the authentic-

ity features are attained via key management carried out by a certiﬁcation authority.

Anonymity is attained via blind-signature and zero-knowledge proofs.

3 Generic payment model

In this section, we describe the architecture of the generic payment model and its regis-

tration, payment, and electronic token purchase protocols. Players are the customer, the

merchant and the bank. The bank plays several roles such as issuer, acquirer, registra-

tion (RA) and certiﬁcation (CA) authority. Customer and merchant have accounts in the

bank. We use the concept of a wallet linked to a single account and supporting multiple

PSs [5]and we adopt the GPSF [4] primitive value transfer services constituting the core

of any PS.

3.1 Registration Procedure

Before issuing a name certiﬁcate, the bank’s RA may perform an in-person authenti-

cation and ask the customer/merchant to provide physical credentials. We assume that

upon receiving the required credentials, the RA provides the customer/merchant with

an authenticator that will be included in the certiﬁcate request. The customer/merchant

generates a key pair and sends a certiﬁcate request to the CA using the authenticator.

The CA generates and delivers the certiﬁcate directly to the customer/merchant.

Payer Payee Bank

Select-pay-method

Confirm-pay-method

Start-Tx

Tx-id

Tx-pay

Tx-auth-Req

Tx-auth-Resp

Tx-Receipt

Fig. 1. Generic Payment Protocol

3.2 Generic Payment Protocol

We generalize the payment protocol presented by Bolignano [6] to cover account based

and token based PSs. We also add messages for the negotiation of a payment method

(see ﬁgure 1). This protocol corresponds to the purchase and validation phases. The

customer is supposed to have already selected the products or services to purchase and

completed the order form. The customer has a valid order description (Ordd) and a valid

payment description (Payd) and is supposed to initiate the purchase. The transaction

data Tx-data, composed and signed by the customer, includes Tx-Amount, customer

and merchant identities and time of transaction. It is sent together with Ordd and Payd.

Ordd should only be known by the merchant and is encrypted with Km (merchant’s key)

while Payd (account number and PIN, credit card number or a set of tokens {e1..en})

should only be known by the bank and is encrypted with Kb (bank’s key).

3.3 Protocol for electronic token purchase (withdrawal)

The customer sends a request to the bank (issuer) to purchase/withdraw a certain value

of tokens. A generic token purchase protocol is as follows : The bank and customer

form a random transaction identiﬁer Tx-Id. The customer sends a token purchase request

including Tx-Id and the value of tokens and signs the request. The bank checks that the

customer’s account has enough provision. It debits the customer’s account and forms

the tokens e1..en, encrypts them with the customer’s public key Kc, signs the envelope

and sends it to the customer.

4 Relational-based Trust Management model

Over the last ten years, several TM systems [8,7] have been developed, some focus-

ing on authentication like X.509 and PGP, others for general purpose authorization like

SPKI and KeyNote and others based on logics. Keynote [8]uses credentials that directly

authorize actions. It requires that credentials and policies be written in a speciﬁc asser-

tion language, designed to work smoothly with its compliance checker. The Keynote

engine is provided by calling a list of credentials, policies, along with the public keys of

the requester and a list of attribute-value pairs generated by the application and deﬁning

an action environment. However, it [9]does not support revocation, external function

calls, parametrized action attribute and veriﬁcation of credential ownership.

SPKI [10]uses cryptographic keys to represent identities, local names to designate

users, and authorizations to help achieving compliance checking. Authorization certiﬁ-

cates grant authorizations, or delegate the ability to grant authorizations. Further more,

certiﬁcate chain discovery and certiﬁcate reduction mechanisms are used for proof re-

trieval and validity.

4.1 Deﬁnition and Representation of the Trust Management model

As stated in [1], our relational-based TM model is deﬁned by (a) a set X, called the

certiﬁcate/request space (requests for on-line checks and operations accompanied by

appropriate certiﬁcates), (b) a set Y, called the checking outputs (all signed responses)

and (c) a binary relation R from X

to Y (X

is the set of ﬁnite non empty chains of

elements in X).

Entities and actions. The model uses SPKI certiﬁcates but still supports other cer-

tiﬁcate formats (i.e. X.509). The certiﬁcate set includes CRLs. The authorization and

delegation expressions are extended. An action description is a pair <action (act-name

input parameters), π>, where act-name is an action identiﬁer and π is a predicate deﬁn-

ing requirements for the action execution. Delegation can include a time dependent

predicate.

Requests and on-line checks. The TM language speciﬁes and classiﬁes requests and

on-line checks in the authorization, delegation and validity checks.

Axiomatic representation of the model. The model is described as a deductive system

4= (W, Axiom, Rule) where

W is the set of well formed formula (formula of the ﬁrst order logic interpreted on

and Y and formula of the form “(C,y) ∈R”;

Axioms of the form : (C,y)∈R∧ π(c)∧ p(y) where π and p are predicates interpreted

on X

and Y,

Rules deﬁne equivalences between certiﬁcate chains.

4.2 Main features

Our relational based TM system has the following features:

(1) A relational language providing a simple and mathematically deﬁned semantics.

This language is monotonic but it still supports negative credentials. It also allows to

specify entities by naming certiﬁcates for authentication and authorization certiﬁcates

for actions and authorization delegation.

(2) A compliance engine addressing various tasks including: certiﬁcate validation,

request authorization, and enforcement of local security policies. The compliance check-

ing process is speciﬁed by a simple and compact relational calculus using ﬁx-point

approach and internal state derivation.

(3) An axiomatic representation of the security policy which helps capturing all the

properties that the security manager needs to address.

(4) A mechanism for identifying entities requesting to perform actions based on

public key certiﬁcates.

5 Trusted Generic payment model

5.1 Speciﬁcation of entities and actions

Entities in our PS are (1)the customer identiﬁed by his public key Kc and a name cer-

tiﬁcate associated to his account,(2) the merchant identiﬁed by his public key Km and

a name certiﬁcate associated to his account and the bank identiﬁed by its public key Kb

and its name certiﬁcate.

Name certiﬁcates. A name certiﬁcate is structured as follows:

<cert(issuer (name k n)(subject p), val> where k and n are the public key and the

name of the bank while p(k’ n’) and k’ is the public key of the account holder and n’

is the name of the account holder and account identiﬁer; In case of anonymous PSs,

the customer may be identiﬁed by a pseudonym. Val is the validity period {not-before,

not-after} of the certiﬁcate.

Authorization certiﬁcates. We are mostly concerned by the authorization and val-

idation tasks of the bank and its compliance engine as well as the security policy that

protects bank’s, customer’s and merchant’s assets. Authorization certiﬁcates have the

form :

<cert (issuer (name k’ n’ )(subject p) Act Del Val> where k’ and n’ are the public key

and the name (or pseudonym) of the certiﬁcate owner and subject p( k” n”) represents

the public key and name of the principal taking beneﬁt from actions in Act.

Act (action ﬁeld) has the form <action(act-name in-parameters), µ> where µ is a

predicate deﬁning requirements for the action execution. In our case, Act ∈{withdraw,

deposit, pay, multi capture}

Del = 0 which means that delegation is not allowed in our system.

Val has the form <Val (not-before, not-after, options) > where <options (online-

test)> and <online-test (online-type uris issuer(p)>. Val contains a predicate now(t) so

that the certiﬁcate becomes invalid as soon as the execution of the requested action

ends.

Certiﬁcate revocation list CRL. CRLs have the form:

<Crl(issuer (name k n)) (revoked c1 ... cn) Val> where cj=(kj,hj) for j≤n, cj repre-

sents the public key and the hash value of a revoked certiﬁcate.

Requests and on-line checks. the customer and merchant may submit requests for

naming certiﬁcate generation, renewal and revocation as well as validity and revocation

online-checks and having the form:

<Req (Checker check-type) (k p Act Del Val) opt.> where Checker corresponds

to uniform resource identiﬁers (uris) to be used for on-line check. check-type ∈ {val-

ch, aut-ch}; val-ch corresponds to validity checks aut-ch corresponds to authorization

checks.

SET X

SET Y

1˚) Customer To Bank Requests    Bank to Customer Responses

Withdraw Request Withdraw response

<Req(Bank-addr, auth-ch) (Kc pc withdraw 0 now(t)) opt (Txid, Amount, t)>  {Accept, Reject}

2˚) Mechant to Bank Requests  Merchant to Bank Responses

Deposit request   Deposit response

<Req(Bank-addr, auth-ch) (Km pm deposit 0 now(t)) opt (Tx-method, Txid, eKb(payd), Tx-data)>  {Accept, Reject}

Payment authorization request Payment authorization response

<Req(Bank-addr, auth-ch) (Kc pm pay 0 now(t)) opt (Tx-method, Txid, eKb(payd), Tx-data>   Accept, Reject}

Multicapture request  Multicapture response

<Req(Bank-addr, auth-ch)(Km pm multicapture 0 now(t)) opt(N, C1...Cn)>  {Accept,Reject}

3˚) Certificate Processing Requests Certificate Processing Responses

Issue Cert Request   Issue Cert Response

<Req(Bank-addr, auth-ch) ( Kx px issue 0 val ) opt(Registration-id)> 

 {Accept, Reject}

Renew Cert Request  Renew Cert Response

<Req(Bank-addr, auth-ch) (Kx px renew 0 val) opt(Registration-id)>

 {Accept, Reject}

Revoke Cert Request   Revoke Cert Response

<Req(Bank-addr, auth-ch ) ( Kx px revoke 0 val) opt(revocation reason)>

 {Accept, Reject}

Check Cert Validity   Validity Check Response

<Req(Directory-addr, val-ch) (Kx px Act 0 val)> 

 {True, false}l

Check Cert Revocation   Revocation Check Response

<Req(Bank-addr, val-ch) (Kx px Act 0 val) opt(hash(C)> 

 {True, False}

4˚)Naming and Authorization Certificates and CRLs

Fig. 2. Set X (certiﬁcates and requests) and Set Y(responses)

5.2 Speciﬁcation of the model

We need to deﬁne sets X and Y and the binary relation R. Set X contains name, autho-

rization and revocation certiﬁcates and requests for on-line checks and operations. Set

Y contains all signed responses returned by the bank. R contains axioms of the form

(xo..xn; y) where xn is a request received by b and y is a signed response of b based on

all messages prior to xn ( see ﬁgure 2).

5.3 Speciﬁcation of the security policy

The speciﬁcation of the security policy describes the relation R to be used in the com-

pliance check processes. Axioms and rules are deduced semi-automatically from the

PSs’ security requirements. We introduce some functions to be used in the expression

of axioms and rules:

owner (c) returns the owner of certiﬁcate c

signer (c) returns the signer of certiﬁcate c

val(c) returns the content of the validity ﬁeld of c

multi-spend(c) is a boolean function showing if the tokens have been spent

valid-tokens(c) is a boolean function indicating if the tokens are valid

Max-Tx is the maximum allowed amount for an account-based transaction

owner-key(c) returns the public key of the naming certiﬁcate c

Axioms. As deﬁned in the relational-based trust model[1], axioms have the form : (C,y)

∈R ∧ π(c) ∧p(y), where πand p are predicates interpreted on X

and Y, respectively, and

y typically deﬁnes the desired response, at time t, of the model for a trivial input chain

of certiﬁcates, denoted C. Due to space constraints, we only present a sample of axioms

and rules to demonstrate the expressiveness of our TM language.

A1-Payment axiom (c1.c2.c3; auth) ∈ R if:

Tx-method (C3) = account

∧ c1 is a valid naming certiﬁcate

∧ c1 is not revoked

∧signer(c3) = owner (c2)

∧owner(c3) = owner (c1)

∧ c2 is a valid naming certiﬁcate

∧ c2 is not revoked

∧ c3 is a payment certiﬁcate

∧ Tx-amount(c3) < Max-Tx

Where c1 is the merchant name certiﬁcate, c2 is the customer name certiﬁcate, c3

is the customer one-time payment authorization certiﬁcate.

The payment axiom states that an account-based payment transaction is authorized

if the merchant and the customer have valid and not revoked certiﬁcates at the time of

the transaction and the authorization certiﬁcate is generated and signed by the customer

to the beneﬁt of the merchant. The axiom also states that Tx-amount should not exceed

a maximum value Max-Tx ﬁxed by the bank.

A2- Deposit axiom (c1.c2.c3; auth) ∈ R if:

Tx-method (c3) = cash

∧ c1 is a valid naming certiﬁcate

∧ c1 is not revoked

∧signer(c3) = owner (c2)

∧owner(c3) = owner (c1)

∧ c2 is a valid naming certiﬁcate

∧ c2 is not revoked

∧ c3 is a deposit certiﬁcate

∧ multi-spend(c3) = false

∧ valid-tokens(c3) = true

The deposit axiom states that a deposit of electronic coins is authorized if the mer-

chant and the customer have valid and not revoked certiﬁcates at the time of the transac-

tion and the authorization certiﬁcate is issued and signed by the customer to the beneﬁt

of the merchant. The axiom also states that the submitted tokens should be valid and

not spent before.

Deduction rules. Deduction rules typically deﬁne equivalences between certiﬁcate chains

or more precisely, request histories and have the following form:

(C’,y) ∈ R

π(C,C’)

—————-

(C,y) ∈R

R1-Closed-world Rule (C.c2;v)∈ R,

there is a naming certiﬁcate c1 ∈ C;

signer (c2) = owner(c1),

C’ does not contain any request related to c1

—————————————————-

(C.c1.C’.c2;v) ∈ R

The closed-world Rule states that the system response to a request related to a given

account should remain independent from any other request or operation that does not

involve this account.

R2- Certiﬁcate Revocation Rule (C.x.C’.x

.C”; y) ∈ R

x: request for the issuance of name certiﬁcate c

x: request for the revocation of name certiﬁcate c

———————————————————

(C.C”; y) ∈ R

Where C is a request submitted before the issuance of c and C” is a request submit-

ted after the revocation of C .

The certiﬁcate revocation rule insures that as soon as a certiﬁcate is revoked it has

no effect on the responses generated for the following requests.

6 Correctness issues

As declared in [1], the compliance checking relation is a solution of the system : A∪D◦R

⊆R, where A is a subset of all pairs (C,y) in X

× Y for which an axiom is satisﬁed

and D is a subset of all pairs (C,C’) of lists in X

× Y for which a rule is applicable.

By using the least ﬁx-point approach, R is given by :

R= A∪D◦A∪D

◦A∪D

◦A∪... = ( ∪

I≥0

)◦A

Speciﬁcation completeness. Speciﬁcation completeness is achieved when the system

requirements are entirely covered by the speciﬁcation of entities, actions and particu-

larly the input set X, the output set Y and the relation R (axioms and rules). A special

care should be dedicated to deﬁne a minimal, consistent and non redundant speciﬁcation

of axioms and rules.

Speciﬁcation validation. Veriﬁcation and Validation (V&V) techniques [11]help de-

tecting requirements and speciﬁcation errors at an early stage.

Compliance correctness. Compliance correctness directly depends on security policy

speciﬁcation correctness. The compliance checking process involves axioms and rules

declarations by using a reduction process and computing the appropriate output.

Certiﬁcate Chain discovery. Several certiﬁcate chain discovery solutions have been

proposed [12] for TM systems. In our TM system, certiﬁcate chains can be directly

derived from requests and requests histories.

Handling revocation. Monotonicity requirement can be a problem for revocation han-

dling in certain TM systems[9]. Our TM language supports negative assertions and

revocation is handled by the revocation rule which includes the account history c

after

certiﬁcate revocation in replacement of certiﬁcate c. Hence, a revoked certiﬁcate has no

effect on future requests.

Performance issues. Our TM system enhances the relational calculus performance by

virtue of reduction algorithms provided by equivalence classes. Equivalence classes

deduced from rules reduce the compliance checking process run-time by providing the

possibility to reduce certiﬁcate chains supporting a request, i.e., the certiﬁcate chain

C.c0.c1 is reduced to C.c0 for validity checking providing that signer(c1)=owner(c0).

7 Implementation Issues

The following methodology is suggested to implement the relational based TM system

in electronic PSs (1) Establishing the needs : Several approaches [13]have been sug-

gested for the speciﬁcation of policy and requirements, particularly in electronic com-

merce systems. This step leads to the deﬁnition of the security policy, (2) Customizing

the relational model: The building blocks of our TM model are the compliance engine,

the security policy module and the request histories database. The model requires a

relatively small coding effort, (3) Using the appropriate relational engine : relational

calculus algorithms for compliance checking and system state derivation have been

deﬁned in [1] and constitute the core of the compliance engine, (4) Building useful in-

terfaces : the compliance engine needs interfaces to interact with several components:

policy block, CA, RA,..., (5) Testing the implementation: several testing techniques are

provided for the V&V purposes such as white-box testing and black-box testing.

8 Conclusion

We have presented the novel techniques and special features of our relational based

TM system through its application to a generic payment model. The elaboration of the

security policy axioms and rules demonstrates the expressiveness of the TM relational

language. Moreover, we explained how compliance correctness can be demonstrated

through completeness and minimality of security policy. Finally, an implementation

methodology is proposed. Future work will focus on delegation issues as well as formal

veriﬁcation of the TM model.

References

1. Guemara-El Fatmi, S., Boudriga, N., Obaidat, M.S.: Relational-based calculus for Trust

Management in network services. To appear in Computer Communication Journal (2004)

2. Asokan, N., Janson, P.A., Steiner, M., Waidner, M.: The state of the art in electronic payment

systems. IBM Zurich (1997)

3. Bellare, M., Garay, J., Herzberg, A., Krawczky, H., Steiner, M., Tsudik, G., Waidner.M.:

Design implementation and deployment of the iKP secure electronic payment system. IEEE

Journal of Selected Areas in Communications (2000)

4. Abad Peiro, J.L., Asokan, N., Steiner, M., Waidner., M.: Designing a generic payment ser-

vice. IBM Systems Journal, vol. 37, N

◦

1 (1998)

5. Dasweni, N., Boneh, D., Garcia-Molina, H., Ketchpel, Paepcke, S.A.: SWAPEROO: a sim-

ple wallet architecture for payments, exchanges, refunds and other operations. 3rd Usenix

workshop on electronic commerce (1998)

6. Bolignano, D.: Towards the Formal Veriﬁcation of Electronic Commerce Protocols. 10th

Computer Security Foundations Workshop, IEEE Computer Society Press (1997) 113–147

7. Weeks, S.: Understanding Trust Management systems. In Symp.on. Res.in Sec and Privacy

.IEEE Computer Society Press (2001)

8. Blaze, M., Ioannidis, J., Keromytis, D.: Experience with the Keynote Trust Management Sys-

tem: Applications and Future Directions. In Proceedings of the 1st International Conference

on Trust Management (2003) 283–300

9. Seamons, K., Winslett, M., Yu, T., Smith, B., Child, E., Jacobson, J., Mills, H., Yu, L.: Re-

quirements for Policy Languages for Trust Negotiation (2002)

10. Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B., Ylonen, T.: SPKI Certiﬁcate

Theory. RFC 2693 (1999)

11. IEEE Standard 1012 for Software Veriﬁcation and Validation (1998)

12. Li, N., Mitchell, J., Winsborough, W.: Distributed Credential Chain Discovery in Trust Man-

agement. Stanford Security Workshop (2002)

13. Anton, A., Earp, J.: Strategies for developing Policies and Requirements for Secure Elec-

tronic Commerce Systems. CCS2000 (2000)