Formal Verification of the Merchant Registration Phase of the SET ...

1 downloads 0 Views 343KB Size Report
Abstract: This paper describes the formal verification of the Merchant Registration phase of the Secure ..... merchant's principal account number and the symmet-.
International Journal of Automation and Computing 2 (2005) 155-162

Formal Verification of the Merchant Registration Phase of the SET Protocol Xiao-Qi Ma∗ , Xiao-Chun Cheng Department of Computer Science, The University of Reading, Reading RG6 6AY, UK

Abstract: This paper describes the formal verification of the Merchant Registration phase of the Secure Electronic Transactions (SET) protocol, a realistic electronic transaction security protocol which is used to protect the secrecy of online purchases. A number of concepts, notations, functions, predicates, assumptions and rules are introduced. We describe the knowledge of all legal participants, and a malicious spy, to assess the security of the sub-protocol. Avoiding search in a large state space, the method converges very quickly. We implemented our method in the Isabelle/Isar automated reasoning environment, therefore the whole verification process can be executed mechanically and efficiently. Keywords: Formal verification, electronic transaction protocol, knowledge-based system.

1

Introduction

Much research work has been conducted in the field of protocol verification. Numerous flaws hidden in cryptographic protocols have been found, while other protocols have been proved secure. However, research focus has mostly been placed on protocols arising in the academic community[1] . Realistic protocols are seldom studied due to their complexity. Among them is the Secure Electronic Transactions (SET) protocol. The SET protocol[2∼4] is much more complicated than those created by the academic community, such as the Needham-Schroeder public key protocol, the Otway-Rees protocol, or even the Kerberos protocol. It is composed of five relatively independent subprotocols, and involves at least five active participants. The SET protocol also introduces some new mechanisms which are difficult to formalise, including dual digital signature and digital envelope, which involve multi-level nested encryption. Some researchers have worked on the SET protocol, but very few methods have successfully verified it. Meadows and Syverson[5] “have proposed a language to describe the specification but have not actually verified the protocol”[1]. Kessler and Neumann[6] have provided a belief logic to prove accountability, but have not proved the security of the protocol. They also proved ——————— Manuscript received June 24, 2005; revised September 28, 2005. This work was supported by EC, EPSRC, the National Natural Science Foundation of China (No.60496320, 60496321), and Hong Kong K C Wang Education Foundation. ∗ Corresponding author. E-mail address: [email protected]

the accountability manually, in stead of automatically. Using the inductive method[7] , Bella et al.[1,8∼10] verified part of the SET protocol. However, their method is not very efficient; it takes about 150 seconds to prove the Cardholder Registration phase, and even more for the Purchase phase. In addition, no state based method has been reported to successfully verify or find flaws in this protocol. In this paper, we provide a knowledge-based framework to verify the Merchant Registration phase of the SET protocol. Our method analyses the knowledge of participating principals, and infers what they can know and never know[11,12] . By avoiding search in a large state space, and by implementing the method in a mechanical reasoning platform Isabelle[13] , it can be used to mechanically verify protocols, and can converge very quickly, providing high efficiency. It only takes a few seconds to verify the Merchant Registration phase of the SET protocol. Section 2 gives a brief overview of the SET protocol, as well as a closer look at the Merchant Registration phase. Our method is described in detail in section 3. Section 4 provides a proving process for the Merchant Registration phase. Some discussion is included in section 5.

2

Overview of the SET protocol

With the popularity of electronic commerce, more and more transactions are conducted through the Internet. However, buyers (cardholders) and sellers (merchants) face the risk of revealing sensitive information, due to the vulnerability of network environments. In

156

International Journal of Automation and Computing 2 (2005) 155-162

such a background, the SET Secure Electronic Transaction protocol was jointly developed by two international credit card associations, namely Visa and MasterCard, with advice and assistance from several software corporations, including GTE, IBM, Microsoft, Netscape, RSA, SAIC, Terisa and VeriSign. The purpose of the SET protocol is to “secure payment card transactions over open networks”. It has been published as an open specification for the industry[2∼4] . The SET protocol is based on a pre-registration scheme. Both a cardholder and merchant must register with a certificate authority (CA) before they can begin the purchasing process. These registration procedures enable the certificate authority to identify participating parties in commercial transactions. During registration, the cardholder and merchant obtain credentials, which can be used to prove their identities. With confidence in the identity of each other, they can then exchange order and payment information through the Internet, and a payment gateway (PG) can safely clear payment between them. Unlike simple protocols, SET is a multi-part protocol, which is composed of five sub-protocols, namely cardholder registration, merchant registration, purchase request, payment authorization, and payment capture. The number of messages sent from one participant to another in each sub-protocol ranges from two to six. The SET protocol relies heavily on cryptography. Encryption, digital signatures and certificates are nested to protect and authenticate important information. In addition, SET introduces a new application of digital signatures, namely the concept of dual signature, to protect combinational messages and their signatures. A. The Merchant Registration Phase This paper concentrates on the second phase of the SET protocol − Merchant Registration. Merchants must register with the Certificate Authority (CA), before they can receive SET payment instructions from Cardholders, or process SET transactions through a payment gateway. In order to send SET messages to the CA, the merchant must have a copy of the CA’s public key-exchange key, which is provided in a CA keyexchange certificate, and its own certificate. Merchant certificates function as an electronic substitute for the payment brand decal that appears in a store window − a decal itself is a representation that a merchant has a relationship with a financial institution allowing it to accept a payment card brand. Because they are digitally signed by the merchant’s financial institution,

merchant certificates cannot be altered by a third party and can only be generated by a financial institution[2] . This phase is composed of four messages sent between the merchant and the CA: 1) Initiate Request. The merchant starts the subprotocol by sending a message to the CA to request a copy of the CA’s key-exchange certificate and an appropriate registration form. 2) Registration Form. The CA identifies the merchant’s financial institution and selects the appropriate registration form. It returns this registration form along with a copy of its own key-exchange certificate to the merchant. 3) Merchant Certificate Request. The merchant’s software verifies the CA certificate, then holds the CA certificate to use later during the registration process. Once the software has a copy of the CA key-exchange certificate, the merchant can register to accept SET payment instructions, and process SET transactions. To register, the merchant fills out the registration form on the screen with information such as the merchant’s name, address, and ID. The merchant’s software takes this registration information and combines it with the public keys in a registration message. The software digitally signs the registration message. Next, the software generates a random symmetric encryption key. It uses this random key to encrypt the message. The random key is then encrypted into a digital envelope using the CA’s public key-exchange key. Finally, the software transmits all of these components to the CA. 4) Merchant Certificates. The CA decrypts the digital envelope to obtain the symmetric encryption key which it uses to decrypt the registration request. It then uses the signature key in the message to ensure that the request was signed using the corresponding private signature key. Next the CA must verify information from the registration request using known merchant information. If the information in the registration request is verified, the CA creates and digitally signs the merchant certificates. The certificates are then encrypted using a new randomly generated symmetric key, which in turn is encrypted using the merchant public key-exchange key. The response is then transmitted to the merchant. When the merchant’s software receives a response from the CA, it decrypts the digital envelope to obtain the symmetric encryption key. It uses the symmetric key to decrypt the registration response containing the merchant certificates. After the merchant’s software verifies the certificates by traversing the trust chain to the root key, it stores the certificates on the merchant’s

Xiao-Qi Ma et al./Formal Verification of the Merchant Registration Phase of the SET Protocol

computer for use in future electronic commerce transactions.

3

Verification framework

Our method focuses on the knowledge of participants engaged in the protocol. We describe their initial and inferred knowledge with the progress of the protocol, processing this knowledge in formal logic. In other words, it concerns the knowledge analysis of protocol participants. This method can be implemented in Isabelle to enable mechanical verification. A. Notations and Data structures We call all participants taking part in electronic transactions principals. There are four active principals involved in the SET protocol, who send and receive messages directly, and three of them are mentioned in the Merchant Registration phase. They are the cardholder, the merchant, and the certificate authority. Besides these honest principals, the protocol may be attacked by malicious principals, which are called spy, or, in some literature, adversary or intruder. In Isabelle notation, the principles can be described as follows: datatype principal = CA | Cardholder | Merchant | Spy The SET protocol involves a number of pieces of information with a fixed format. By convention, we call them nonces, although they are not randomly generated. Such information includes initiate request, registration form, certificate response, principal account number (PAN), and so on. They can be formally expressed as follows: datatype nonce = InitReq principal |InitRes principal |RegReq principal |RegForm principal |CertReq principal |CertRes principal |PAN principal |CardSecret principal Every principal has some keys, such as a public encryption key, and a private signature key. They are defined as natural numbers. One of the most important concepts is the message. A message is a piece of information sent from one principal to another. A message can consist of the names of principals, nonces, keys, encrypted messages, signed messages, certificates, hashed messages, or a combination of these. They are recursively defined in Isabelle

157

as follows: datatype message = Principal principal |Nonce nonce |Key key |MPair message message |Encrypt message key |Sign message key |Cert message principal |Hash message Paired messages can be abbreviated using curly braces. For example, MPair M1 M2 can be written as {M1, M2}. A compound message consisting of more than two components can be understood as a nested compound message. For example {M1, M2, M3} is the abbreviation of {M1, {M2, M3}}. B. Functions and Predicates We define a number of useful functions and predicates. Among these are key functions. Function Kpb has the type principal ⇒key, which maps a principal to its public encryption key. Functions Kpv, Spb, and Spv similarly map a principal to its private encryption key, public signature key, and private signature key, respectively. Both Kpb and Spb are injective functions. Besides public cryptosystem keys, SET also uses symmetric cryptosystem keys. Therefore, we define another key mapping function, Ksym. In addition to the two names which share the key, this function accepts an integer as a third parameter, for two principals may share more than one symmetric key, which need to be distinguished from each other. To determine whether a message is part of another, we introduce a function msg part. For a non-compound message, only itself is a part of it. For a compound message, message M1 is part of message M2, if and only if the component set of M1 is the subset of the component set of M2. The predicate Know has the type principal ⇒ message ⇒ bool, describing a principal’s knowledge state about a certain message. In addition, we define two predicates, namely Verify and Trust, which mean a principal verifies a message and trusts a principal, respectively. To describe cryptographic protocols, two action functions need to be introduced. One is Send, with the type principal ⇒ principal ⇒ message ⇒ bool, representing that one principal sends a message to another. Correspondingly, the other function is Rcv, with the type principal ⇒ message ⇒ bool, meaning that a principal receives a certain message from others. C. Assumptions

158

International Journal of Automation and Computing 2 (2005) 155-162

Our method is based on a number of assumptions which are widely accepted by most researchers in this field. The most important assumptions are key assumptions. In public cryptosystems, the public key of any principal is known to all other principals: axioms KeyAssump1: “∀ X Y. Know X (Key (Kpb Y))” In contrast, any principal’s private key is initially secret from others except itself: KeyAssump2 : “∀X. Know X (Key (Kpv X))” KeyAssump3 : “∀X Y. ((X 6= Y) → ¬ (Know X (Key (Kpv Y))” In symmetric cryptosystems, no one knows a symmetric key except the two principals who own this key: KeyAssump4 : “∀X Y Z n. ((Z6=X)∧(Z6=Y) → ¬(Know Z (Key (Ksym X Y n)))” We also assume that the certificate is also worth trusting; every principal can verify its signature. axioms Verify CA signature : “∀X M. Verify X (Sign M (Spv CA))” Trust CA : “∀X. Trust X CA” According to the definition of spy, it is not an honest principal, so we have: axioms Honest not spy : “ Spy 6= CA ∧ Spy 6= Cardholder ∧ Spy 6= Merchant” In addition, we also have some other assumptions, which are described as follows: • The spy always observes all messages sent through the network. It tries to use all the keys it knows to decrypt messages on the network, and to send forged messages to others. It can also intercept messages sent from one principal to another. That is, the spy has “full” control over the network. • There is only one spy in the network. • The spy cannot read an encrypted message without a corresponding decryption key; i.e. secret keys are not guessable. • An honest principal only reads information addressed to it. • A principal never sends messages to itself.

D. Rules We introduce a group of inference rules into the method to infer new knowledge from old. All of these rules can be divided into four categories. The first is the encryption/decryption rule, which includes two rules. When a principal knows a message and a key, it can use this key to encrypt the message and obtain the encrypted message: Rule1 1 : “Know X M ∧Know X (Key K) ⇒ Know X (Encrypt M K)” When a principal knows a message encrypted with a key and knows the reverse of the key, it can use the reverse of the key to obtain the original message: Rule1 2 : “Know X (Encrypt M K) ∧ Know X (Key (invKey K)) ⇒ Know X M” The second category is the message signature/ verifying rule, which also includes two rules. When a principal knows a message and a key, it can use this key to encrypt the message and obtain the signature: Rule2 1 : “Know X M ∧ Know X (Key K) ⇒ Know X (Sign M K)” When a principal knows a signature and the corresponding public key, it can verify the signature: Rule2 2 : “Know X (Sign M K) ∧ Know X (Key (invKey K)) ⇒ Verify X (Sign M K)” The third category is the trust rule, which only includes one rule. When a principal trusts someone and knows a certificate issued by it, this principal will believe the authenticity of the certificate. Rule3 1 : “Know X (Cert M Y) ∧ Trust X Y ⇒Know X M” The fourth category is the message combination/ separation rule, which also includes two rules. When a principal knows two messages, it can know the combination of them: Rule4 1 : “Know X M1 ∧Know X M2 ⇒ Know X {M1, M2}” When a principal knows the combination of two messages, it can know them separately: Rule4 2 : “Know X {M1, M2} ⇒Know X M1 ∧ Know X M2”

Xiao-Qi Ma et al./Formal Verification of the Merchant Registration Phase of the SET Protocol

These two rules can be used inductively to deal with compound messages consisting of more than two components. The fifth category is the message sending/receiving rule, which includes four rules. If a principal sends a message to another, the object principal will eventually receive it: Rule5 1 : “Send X Y M ⇒ Rcv Y M” As one of our assumptions describes, the spy can observe all information flowing over the network: Rule5 2 : “Send X Y M ⇒ Rcv Spy M” After a principal receives a message, it will know it: Rule5 3 : “Rcv X M ⇒Know X M” If a principal sends a message to another, it must know that principal first: Rule5 4 : “Send X Y M ⇒Know X M” The sixth category is the ignorance rule, which includes one rule. If a principal knows a message only in its encrypted form and does not know the decryption key, it will not know the message itself: Rule6 1 : “Know Y (Encrypt M K) ∧¬Know X (Key (invKey X)) ∧(∀MM. Rcv X MM ∧ msg part M MM →msg part (Encrypt M K) MM) ⇒ ¬Know X M”

4 Verifying the merchant registration phase of the SET protocol To verify the Merchant Registration phase of the SET protocol, we first need to model it in our framework, then prove a number of important lemmas and properties, and ultimately prove the final theorems. A. Modelling the Protocol Normally, the protocol can be formalised in four steps for all honest principals: 1. Initiate Request: SET2 1 : “Send Merchant CA {Principal Merchant, Nonce(InitReq Merchant)}” 2. Registration Form: SET2 2 : “Send Merchant CA {Principal Merchant, Nonce(InitReq Merchant)} ⇒ Send CA Merchant {Sign (Nonce (RegForm Cardholder)) (Spv CA), Cert (Key (Spb CA)) CA,

159

Cert (Key (Kpb CA)) CA}” 3. Merchant Certificate Request: SET2 3 : “Send CA Merchant {Sign (Nonce (RegForm Cardholder))(Spv CA), Cert (Key (Spb CA)) CA, Cert (Key (Kpb CA)) CA} ⇒Send Merchant CA {Encrypt (Sign {Nonce (CertReq Merchant), Key (Kpb Merchant), Key (Spb Merchant)} (Spv Merchant)) (Ksym Merchant CA1), Encrypt {Key (Ksym Merchant CA1), Nonce (PAN Merchant)} (Kpb CA)}” 4. Merchant Certificates: SET2 4 : “Send Merchant CA {Encrypt (Sign {Nonce (CertReq Merchant), Key (Kpb Merchant), Key (Spb Merchant)} (SpvMerchant)) (KsymMerchantCA1), Encrypt {Key(KsymMerchantCA1), Nonce (PANMerchant)} (KpbCA)} ⇒ Send CA Merchant {Sign (Nonce (CertRes Merchant)) (Spv CA), Cert (Key (Spb Merchant)) CA, Cert (Key (Kpb Merchant)) CA, Cert (Key (Spb CA)) CA}” These four steps describe the message sent between (honest) principals. B. Some Lemmas Before we can prove final security properties, we need to first prove some important lemmas. One of these lemmas is that the spy can only receive the encrypted form of a symmetric key shared by a merchant and the certificate authority. In other words, if the spy receives a piece of information containing the merchant’s principal account number and the symmetric key of the merchant and the CA, the key must be encrypted (with the CA’s public encryption key). lemma SessionKey1 part : “Rcv Spy M ∧ msg part {Key (Ksym Merchant CA 1), Nonce (PAN Merchant)} M ⇒msg part (Encrypt {Key (Ksym Merchant CA 1), Nonce (PAN Merchant)} (Kpb CA)) M”

160

International Journal of Automation and Computing 2 (2005) 155-162

In proving this lemma, we use implication elimination (impE) and universal elimination (allE) rules provided by higher order logic. We also use an assumption rule, which means that the result we need to prove exists in assumptions. To make proofs concise and clear, we usually prove the simplest subgoals first. So when we find the second (or later) subgoal generated by the system is simpler than the first subgoal, we may use the command prefer n to move the nth subgoal to the front. In the proof, we use another two simple rules. The first is Key1 received, which means that if a legal message contains the first symmetric key shared by the merchant and the CA and the merchant’s PAN, it should be the message sent in step 3. The second rule is SKey1 part, which indicates that the encrypted combination information, containing the first symmetric key shared by the merchant and the CA, and the merchant’s PAN is part of the message sent in step 3. The proving scripts for the lemma SessionKey1 part are as follows: apply (rule impE) prefer 3 apply (rule SKey1 part) apply assumption apply (rule allE ) apply (rule Key1 received) by assumption+ With the above lemma we can easily infer another lemma: lemma Spy only know encrypted Key1 : “∀M. Rcv Spy M∧msg part {Key (Ksym Merchant CA 1), Nonce (PAN Merchant)} M → msg part (Encrypt {Key (Ksym Merchant CA 1), Nonce (PAN Merchant)} (Kpb CA)) M” To prove this lemma, we use implication introduction (impI) and universal introduction (allI) rules, in addition to the impE and allE rules. The sign “+” appearing after the assumption rule (and other rules) indicates that the current rule can be executed more than once whenever possible. The proving steps are shown below: apply apply apply apply

(rule (rule (rule (rule

allI ) impI ) SessionKey1 part) impE)

apply (rule allE ) apply (rule Key1 received) by assumption+ Based on the Spy only know encrypted Key1 lemma, we can introduce another more important lemma: lemma Secrecy1 : “¬ Know Spy {Key (Ksym Merchant CA 1), Nonce (PAN Merchant)}” This lemma shows that the spy can never know the plain text of the combination of the symmetric key of the merchant and the certificate authority, and the principal account number of the merchant. The proof of this lemma concerns the SessionKey1 part lemma and the higher order unification mechanism of Isabelle, such as the conjunction introduction (conjI), and conjunction elimination (conjunct1, conjunct2) rules. We also suppose that the CA is uncompromised, and that all honest principals are not spies. The inv publicKey rule means that in public key cryptosystems, a pair of public key and private keys are reverse keys of each other. The simp only rule means that the system only uses a certain rule instead of searching all applicable simplification rules automatically, while the simp rule performs the automatic search. So we have the following proving scripts: apply (rule Rule6 1 ) apply (rule conjI ) prefer 2 apply (rule conjI ) prefer 2 apply (rule Spy only know encrypted Key1 ) apply (simp only: inv publicKey) apply (rule conjunct1 ) apply (rule CA uncompromised) apply (simp only: Honest not Spy) apply simp apply (rule conjunct2 ) apply (rule Rule4 2 ) apply (rule Rule5 3 ) apply (rule Rule5 2 ) apply (rule SET2 3) apply (rule SET2 2) apply (rule SET2 1) done C. Properties of Secrecy The correctness of the Merchant Registration phase of the SET protocol relies on the secrecy of the symmetric keys and principal account number. Therefore,

Xiao-Qi Ma et al./Formal Verification of the Merchant Registration Phase of the SET Protocol

the key point is to prove that they are never divulged, that is, the spy can never know the plain text of them. The first goal we can prove is the secrecy of the principal account number of the merchant: goal Spy not know PAN : “¬ Know Spy {Nonce (PAN Merchant)}” The meaning of this goal is straightforward. We prove it with contrapositive rules in the following form: apply (rule tac Q=“Formula” in contrapos nn) where Formula is the result we infer when we suppose the conclusion is false. We can prove that if the goal does not hold, then the spy will know the following information: {Key (Ksym Merchant CA 1), Nonce (PAN Merchant)} In the proof, we use the Know PAN axiom, which means that if the spy knows the PAN of the merchant, it cannot know it independently; it must know the combination of the PAN and the first symmetric key shared by the merchant and the CA. The later used axiom Know Key1 imply Key1PAN has a similar meaning. We can use the following scripts to prove this goal: apply (rule tac Q = Know Spy {Key (Ksym Merchant CA 1), Nonce (PAN Merchant)} in contrapos nn) prefer 2 apply (rule Know PAN) apply assumption apply (simp only : Secrecy1 ) by simp Proving the secrecy of the symmetric key shared by the merchant and the certificate authority also involves proof by contradiction: if this theorem does not hold, the lemma Secrecy1 will be offended. Here is the corresponding goal: theorem Spy not know Key1 : “¬Know Spy (Key (Ksym Merchant CA 1))” To prove this theorem, we use the above contrapositive rule and Secrecy1 lemma: apply (rule-tac Q = Know Spy {Key (Ksym Merchant CA 1 ), Nonce (PAN Merchant)} in contrapos-nn) apply (rule Secrecy1 ) by (simp only : Know Key1 imply Key1PAN)

5

161

Conclusions

In this paper, we reported our work to verify the Merchant Registration phase of the Secure Electronic Transactions (SET) protocol using a knowledge-based framework. We modelled the sub-protocol using logic formulae and analysed principals’ knowledge states –what they can know and what they can never know. We have introduced notations, data structures, functions, predicates, assumptions, and inference rules to describe the knowledge of principals and the relationships among them. We have implemented the model in Isabelle, in which we can verify cryptographic protocols mechanically. We described the notations, data structures, functions, predicates, assumptions, and inference rules using Isabelle statements, and verified the sub-protocol with hundreds of lines of Isabelle code. Our implementation runs very fast; by constraining induction and recursion to a low limit, it takes less than five seconds to prove all lemmas and theorems on a 1.8 gigahertz PC processor, compared to 30 seconds when using an induction method. However, the verification of SET is far from complete. The rest of the protocol will pose new challenges. For example, the dual signature will be more difficult to formalize, and its properties still need further study. The message structure in the Purchase phase is also far more complicated and deserves much more effort.

References [1] G. Bella, F. Massacci, L. Paulson. Verifying the SET registration protocols. IEEE Journal on Selected Areas in Communications, vol.21, no.1, pp.77–87, 2003. [2] MasterCard International Incorporated and Visa International Service Association (1997). SET Secure Electronic Transaction Specification, Book 1: Business Description, first edition, MasterCard & Visa, San Francisco, 1997. [3] MasterCard International Incorporated and Visa International Service Association (1997). SET Secure Electronic Transaction Specification, Book 2: Programmer’s guide, first edition, MasterCard & Visa, San Francisco, 1997. [4] MasterCard International Incorporated and Visa International Service Association (1997). SET Secure Electronic Transaction Specification, Book 3: Formal Protocol Definition, first edition, MasterCard & Visa, San Francisco, 1997. [5] C. Meadows, P. Syverson. A Formal Specification of Requirements for Payment Transactions in the SET Protocol. In proceedings of the Second International Conference on Financial Cryptography, Anguilla, British West Indies, Sringer Verlag, London, pp.122–140, 1998. [6] V. Kessler, H. Neumann. A sound logic for analysing electronic commerce protocols. In J.-J. Quisquater, Y. Deswarte, C. Meadows, D. Gollmann. In proceedings of the 5th European Symposium on Research in Computer Security, Lecture Notes in Computer Science, SpringerVerlag, vol.1485, pp. 345–360, 1998.

162

International Journal of Automation and Computing 2 (2005) 155-162

[7] L. Paulson. The inductive approach to verifying cryptographic protocols. Journal of Computer Security, vol.6, no.1–2, pp. 85–128, 1998. [8] G. Bella, F. Massacci, L. Paulson, P. Tramontano. Formal verification of cardholder registration in SET. F. Cuppens et al., Computer Security–ESORICS2000, of Lecture Notes in Computer Science, Springer Verlag, Heidelberg, Vol. 1895, pp. 159–174, 2000. [9] G. Bella, F. Massacci, L. Paulson. The verification of an industrial payment protocol: the SET purchase phase. In proceedings of the 9th ACM Conference on Computer and Communications Security, Washington DC, USA, ACM Press, New York, pp.12–20, 2002. [10] G. Bella, F. Massacci, L. Paulson. An overview of the verification of SET. International Journal of Information Security, vol.4, no.1–2, pp.17–28, 2005. [11] X. Cheng, X. Ma, M. Cheng, S. Huang. Proving secure properties of cryptographic protocols. In proceedings of the 24th IEEE International Performance Computing and Communications Conference (IPCCC 2005), Phoenix, Arizona, USA, pp. 3–9, 2005. [12] X. Ma, X. Cheng, R. McCrinde. Knowledge based approach for mechnically verifying security protocols. In proceedings of the 19th International Joint Conference on Artificial Intelligence (IJCAI 2005), Edinburgh, Scotland, UK. IJCAI: California, pp. 1572–1573, 2005. [13] T. Nipkow, L. Paulson, M. Wenzel. Isabelle/HOL: a proof assistant for higher-order logic, Springer Verlag, Heiderberg, 2003.

Xiao-Qi Ma graduated from Nanjing University of Science and Technology, China, in 1997. He received his Master’s degree from the Institute of Software, Chinese Academy of Sciences in 2003. He is currently a PhD student at the University of Reading. His research interests include computer network security, knowledge-based systems, and operating systems.

Xiao-Chun Cheng obtained his PhD in 1996. He has worked as a lecturer at the University of Reading since 2000. He is a guest professor at North East Normal University and Beijing Normal University. His research interests include theoretical and applied aspects in decision support systems, knowledge-based systems and intelligent systems.