secure electronic tendering - qut · thesis title: secure electronic tendering under the...

Secure Electronic Tendering

by

Rong Du

Previous qualifications – Master of Information Technology

Thesis submitted in accordance with the regulations for

Degree of Doctor of Philosophy

Information Security Research CentreFaculty of Information Technology

Queensland University of Technology

2 August 2007

QUEENSLAND UNIVERSITY OF TECHNOLOGY

DOCTOR OF PHILOSOPHY THESIS EXAMINATION

CANDIDATE NAME: Rong Du

CENTRE/RESEARCH CONCENTRATION: Information Security Research Centre

PRINCIPAL SUPERVISOR: Dr. Ernest Foo

ASSOCIATE SUPERVISOR(S): Professor Colin Boyd

Professor Sharon Christensen

THESIS TITLE: Secure Electronic Tendering

Under the requirements of PhD regulation 9.2, the above candidate was examined orallyby the Faculty. The members of the panel set up for this examination recommend thatthe thesis be accepted by the University and forwarded to the appointed Committee forexamination.

Name: Dr. Ernest Foo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Signature . . . . . . . . . . . . . . . . . . . . . . . .Panel Chairperson (Principal Supervisor)

Name: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Signature . . . . . . . . . . . . . . . . . . . . . . . .Panel Member

Name: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Signature . . . . . . . . . . . . . . . . . . . . . . . .Panel Member

Under the requirements of PhD regulation 9.15, it is hereby certified that the thesis ofthe above-named candidate has been examined. I recommend on behalf of the ThesisExamination Committee that the thesis be accepted in fulfilment of the conditions for theaward of the degree of Doctor of Philosophy.

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Signature . . . . . . . . . . . . . . . . . . . . . . Date . . . . . . . . . . .Chair of Examiners (Thesis Examination Committee)

ii

Keywords

E-Tendering, E-Procurement, E-Auction, E-commerce, E-business, Business Process,

E-Tender Negotiation, E-Tender Submission, Security, Security Requirements,

Secure Protocol, Security Functions, Integrity, Confidentiality, Threat, Threat

Scenario, Cryptology, Cryptography, Generic Security Mechanism, Cryptographic

Hash Function, Digital Signature, Commitment Scheme, Identity Based Encryp-

tion, Formal Method, SHVT, Model Checking, Threat modeling, Verification

Elements, Verification Process

iii

Abstract

Tendering is a method for entering into a sales contract. Numerous electronic

tendering systems have been established with the intent of improving the effi-

ciency of the tendering process. Although providing adequate security services

is a desired feature in an e-tendering system, current e-tendering systems are

usually designed with little consideration of security and legal compliance.

This research focuses on designing secure protocols for e-tendering systems.

It involves developing methodologies for establishing security requirements, con-

structing security protocols and using formal methods in protocol security ver-

ification. The implication is that it may prove suitable for developing secure

protocols in other electronic business domains.

In depth investigations are conducted into a range of issues in relation to estab-

lishing generic security requirements for e-tendering systems. The outcomes are

presented in a form of basic and advanced security requirements for e-tendering

process. This analysis shows that advanced security services are required to se-

cure e-tender negotiation integrity and the submission process.

Two generic issues discovered in the course of this research, functional differ-

ence and functional limitations, are fundamental in constructing secure protocols

for tender negotiation and submission processes. Functional difference identifi-

cation derives advanced security requirements. Functional limitation assessment

defines how the logic of generic security mechanisms should be constructed. These

principles form a proactive analysis applied prior to the construction of security

protocols.

Security protocols have been successfully constructed using generic crypto-

graphic security mechanisms. These protocols are secure e-tender negotiation

integrity protocol suite, and secure e-tender submission protocols. Their security

has been verified progressively during the design. Verification results show that

protocols are secure against common threat scenarios. The primary contribution

v

of this stage are the procedures developed for the complex e-business protocol

analysis using formal methods. The research shows that proactive analysis has

made this formal security verification possible and practical for complex proto-

cols.

These primary outcomes have raised awareness of security issues in e-tendering.

The security solutions proposed in the protocol format are the first in e-tendering

with verifiable security against common threat scenarios, and which are also prac-

tical for implementation. The procedures developed for securing the e-tendering

process are generic and can be applied to other business domains. The study

has made improvements in: establishing adequate security for a business process;

applying proactive analysis prior to secure protocol construction; and verifying

security of complex e-business protocols using tool aided formal methods.

vi

Contents

Certificate Recommending Acceptance ii

Keywords iii

Abstract v

Declaration xvii

Previously Published Material xix

Acknowledgements xxi

1 Introduction 1

1.1 Aims and Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Contributions and Achievements . . . . . . . . . . . . . . . . . . . 4

1.3 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Electronic Tendering 9

2.1 Traditional Tendering . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.1 Tendering . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.2 Tendering Parties . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.3 Tendering Components . . . . . . . . . . . . . . . . . . . . 11

2.2 E-Tendering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.1 E-tender Components . . . . . . . . . . . . . . . . . . . . 16

2.2.2 International E-Tendering Standards . . . . . . . . . . . . 19

The United Nations ebXML e-Tendering Project . . . . . . 19

IDABC E-Procurement Protocol . . . . . . . . . . . . . . 21

eLEGAL Project . . . . . . . . . . . . . . . . . . . . . . . 22

2.2.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

vii

2.3 Related Research on E-procurement . . . . . . . . . . . . . . . . . 23

2.3.1 Electronic Procurement . . . . . . . . . . . . . . . . . . . 24

2.3.2 Auction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.3.3 Tendering versus Auction . . . . . . . . . . . . . . . . . . 27

2.3.4 Reverse and Multi-Attributes or Dimensional Auctions . . 29

2.3.5 Security Issues . . . . . . . . . . . . . . . . . . . . . . . . 30

E-Auction Security . . . . . . . . . . . . . . . . . . . . . . 30

E-procurement and Reverse Auction Security . . . . . . . 34

2.4 Current Electronic Tendering Systems . . . . . . . . . . . . . . . 35

2.4.1 Principal-Based E-Tendering Systems . . . . . . . . . . . . 36

2.4.2 TTP-Based E-Tendering System . . . . . . . . . . . . . . . 38

2.4.3 E-tendering System Security Discussion . . . . . . . . . . . 41

2.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3 Security Technologies for E-Tendering 45

3.1 Cryptographic Technology . . . . . . . . . . . . . . . . . . . . . . 46

3.1.1 Cryptographic Hash Function . . . . . . . . . . . . . . . . 46

3.1.2 Hash Chain Related Applications . . . . . . . . . . . . . . 48

3.1.3 Public Key Cryptosystem . . . . . . . . . . . . . . . . . . 52

3.1.4 Digital Signature . . . . . . . . . . . . . . . . . . . . . . . 53

Generic Public Key Digital Signature Scheme . . . . . . . 53

Applications and Considerations . . . . . . . . . . . . . . . 54

3.1.5 Public Key Infrastructure PKI . . . . . . . . . . . . . . . . 56

3.1.6 Public Verifiability . . . . . . . . . . . . . . . . . . . . . . 58

3.2 Cryptographic Protocol Security Verification Tools . . . . . . . . 59

3.2.1 Asynchronous Product Automata . . . . . . . . . . . . . . 60

3.2.2 Simple Homomorphism Verification Tool . . . . . . . . . . 61

3.2.3 Difficulties of Using Tool Assisted Formal Methods . . . . 62

4 Electronic Tendering System Security Requirement Analysis 63

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.2 Obligations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.2.1 Obligations for the Principal . . . . . . . . . . . . . . . . . 66

4.2.2 Obligations for Tenderers . . . . . . . . . . . . . . . . . . . 66

4.2.3 Other Considerations . . . . . . . . . . . . . . . . . . . . . 67

4.3 Mapping Business Requirements to Security Policies . . . . . . . . 67

viii

4.3.1 Tendering Stages . . . . . . . . . . . . . . . . . . . . . . . 68

4.3.2 Pre-Qualification and Registration . . . . . . . . . . . . . 69

4.3.3 Tender Invitation and Submission Stage . . . . . . . . . . 71

4.3.4 Tender Assessment Stage . . . . . . . . . . . . . . . . . . . 74

4.3.5 Tender Acceptance . . . . . . . . . . . . . . . . . . . . . . 76

4.3.6 Essential Security Mechanisms for Electronic Tendering . 78

4.4 Generic E-Tendering Security Requirements . . . . . . . . . . . . 80

4.4.1 Non-repudiation . . . . . . . . . . . . . . . . . . . . . . . . 81

4.4.2 Secure Time . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Time Integrity . . . . . . . . . . . . . . . . . . . . . . . . . 82

Closing or Opening Time of E-tender Box . . . . . . . . . 82

Time of Receipt of Electronic Communications . . . . . . . 83

4.4.3 Secure Record-keeping . . . . . . . . . . . . . . . . . . . . 84

4.4.4 E-tendering System Security . . . . . . . . . . . . . . . . 85

Principal-Based System . . . . . . . . . . . . . . . . . . . 85

Trusted Third Party Based System . . . . . . . . . . . . . 86

Distributed Security Services E-tendering System . . . . . 86

Trust Between E-Tendering Participants . . . . . . . . . . 87

Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

4.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

5 Secure Electronic Tendering Negotiation Integrity 91

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

5.2 Security Requirements . . . . . . . . . . . . . . . . . . . . . . . . 93

5.2.1 Functional Differences . . . . . . . . . . . . . . . . . . . . 93

5.2.2 Threats and Security Requirements . . . . . . . . . . . . . 94

5.3 Related Technology and Application Issues . . . . . . . . . . . . . 97

5.4 Secure Electronic Tendering Negotiation Integrity . . . . . . . . 99

5.4.1 Notation and System Setup . . . . . . . . . . . . . . . . . 99

5.4.2 Secure E-tendering Negotiation Integrity Protocol Suite

(EtenderNI) . . . . . . . . . . . . . . . . . . . . . . . . . . 101

E-Tender Negotiation Protocol . . . . . . . . . . . . . . . 102

Final Stage Protocol . . . . . . . . . . . . . . . . . . . . . 104

Protocol Disruption Protection . . . . . . . . . . . . . . . 104

5.5 Protocol Analysis Issues . . . . . . . . . . . . . . . . . . . . . . . 109

5.6 Informal Analysis of EtenderNI Protocol . . . . . . . . . . . . . . 111

ix

5.6.1 Security Goals . . . . . . . . . . . . . . . . . . . . . . . . . 111

5.6.2 Attacker’s Power . . . . . . . . . . . . . . . . . . . . . . . 111

5.6.3 Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . 112

5.6.4 Data Origin Authentication . . . . . . . . . . . . . . . . . 113

5.6.5 Original Integrity Confirmation . . . . . . . . . . . . . . . 113

5.6.6 System Reliability . . . . . . . . . . . . . . . . . . . . . . 114

5.7 Formal Specification of EtenderNI Protocol Suite . . . . . . . . . 115

5.7.1 Language and Tool . . . . . . . . . . . . . . . . . . . . . . 116

5.7.2 Procedures of Formal Specification . . . . . . . . . . . . . 117

5.7.3 Required Verifying Elements . . . . . . . . . . . . . . . . . 117

5.7.4 Verification Process . . . . . . . . . . . . . . . . . . . . . . 118

5.7.5 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . 119

5.7.6 Derive Protocol Security Goals . . . . . . . . . . . . . . . 120

5.7.7 Specify Initial State Sets . . . . . . . . . . . . . . . . . . . 121

5.7.8 Specify Transition Relations . . . . . . . . . . . . . . . . . 122

5.7.9 Discussion of Verification Results . . . . . . . . . . . . . . 125

Protocol Flaws Found During Specification . . . . . . . . 125

Verification on Scenario: All Players are Honest . . . . . . 126

Verification on Scenario: Only B is Dishonest . . . . . . . 126

Verification on Scenario: Only A is Dishonest . . . . . . . 127

5.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

6 Secure Electronic Tendering Submission 131

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

6.2 E-tender Submission Security Requirements . . . . . . . . . . . . 133

6.2.1 Functional Differences Between Traditional and E-tendering

Boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

6.2.2 Threats and Security Requirements . . . . . . . . . . . . . 134

6.3 Related Technologies and Application Issues . . . . . . . . . . . . 135

6.3.1 Commitment Scheme . . . . . . . . . . . . . . . . . . . . . 136

Role of Players . . . . . . . . . . . . . . . . . . . . . . . . 138

6.3.2 Time Stamping Services . . . . . . . . . . . . . . . . . . . 138

6.3.3 Identity-Based Encryption . . . . . . . . . . . . . . . . . . 139

6.4 E-Tender Submission Protocols . . . . . . . . . . . . . . . . . . . 140

6.4.1 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

6.4.2 Submission Protocol I . . . . . . . . . . . . . . . . . . . . 141

x

6.4.3 Submission Protocol II . . . . . . . . . . . . . . . . . . . 142

6.4.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

6.5 Informal Security Analysis . . . . . . . . . . . . . . . . . . . . . . 146

6.5.1 Protocol Security Goals . . . . . . . . . . . . . . . . . . . 146

6.5.2 Player’s Attacking Power . . . . . . . . . . . . . . . . . . 146

6.5.3 Hiding Tender Submission . . . . . . . . . . . . . . . . . . 147

6.5.4 Binding Tender Submission . . . . . . . . . . . . . . . . . 148

6.5.5 Fixing Submission Time . . . . . . . . . . . . . . . . . . . 149

6.6 Formal Specification and Analysis . . . . . . . . . . . . . . . . . . 149

6.6.1 Language and Tool . . . . . . . . . . . . . . . . . . . . . . 149

6.6.2 Procedures of Formal Specification . . . . . . . . . . . . . 150

6.6.3 Required Verifying Elements and Verification Process . . . 151

Submission Protocol I . . . . . . . . . . . . . . . . . . . . 152

Submission Protocol II . . . . . . . . . . . . . . . . . . . . 153

6.6.4 Protocol Assumptions . . . . . . . . . . . . . . . . . . . . 154

6.6.5 Formalized Protocol Security Goals . . . . . . . . . . . . . 155

6.6.6 Specify Initial State Sets . . . . . . . . . . . . . . . . . . . 156

6.6.7 Specify Transition Relation or Patterns and SHVT Analysis 156

Modeling all Players as Honest . . . . . . . . . . . . . . . 157

Modeling Threat Scenario One (S1) . . . . . . . . . . . . . 157

Modeling Threat Scenario Two (S2) . . . . . . . . . . . . . 158

Modeling Threat Scenario Three (S3) . . . . . . . . . . . . 159

Modeling Threat Scenario Four (S4) . . . . . . . . . . . . 159

6.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

7 Conclusion 163

7.1 Conclusions and Contributions . . . . . . . . . . . . . . . . . . . . 163

7.2 Future Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

A Cryptography 171

A.1 RSA Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

A.2 Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . . . . . 172

A.3 ElGamal Public Key Cryptosystem . . . . . . . . . . . . . . . . . 173

A.4 Plain RSA Signature Scheme . . . . . . . . . . . . . . . . . . . . . 174

A.5 ElGamal Signature Scheme . . . . . . . . . . . . . . . . . . . . . . 175

A.6 Identity-Based Encryption . . . . . . . . . . . . . . . . . . . . . . 176

xi

B SHVT Code for Chapter 5 181

C SHVT Code for Chapter 6 207

Bibliography 227

xii

List of Figures

2.1 Tendering Process . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Market framework (modified from Teich et al. [101]) . . . . . . . . 24

2.3 Principal Based System . . . . . . . . . . . . . . . . . . . . . . . . 36

2.4 Trusted Third Party Based System . . . . . . . . . . . . . . . . . 39

3.1 Simplified classification of cryptographic hash functions ([81]) . . 48

3.2 Hash chain forming process diagram . . . . . . . . . . . . . . . . . 49

3.3 Signing in Digital Signature with Appendix . . . . . . . . . . . . 54

3.4 Strict Hierarchical Model . . . . . . . . . . . . . . . . . . . . . . 58

3.5 APA Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.1 Qualification & selection stage . . . . . . . . . . . . . . . . . . . . 72

4.2 Tender invitation & submission stage . . . . . . . . . . . . . . . . 74

4.3 Tender assessment stage . . . . . . . . . . . . . . . . . . . . . . . 76

4.4 Tender acceptance stage . . . . . . . . . . . . . . . . . . . . . . . 78

4.5 Distributed Security Service Principal-Based System . . . . . . . 86

4.6 Distributed Security Service TTP-Based System . . . . . . . . . 87

5.1 Chaining Evidential Material in E-tendering . . . . . . . . . . . . 97

5.2 Notation1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

5.3 Electronic Tendering Secure Communication Protocols . . . . . . 101

5.4 E-Tender Negotiation Protocol - chaining evidence . . . . . . . . 102

5.5 E-Tender Negotiation Protocol . . . . . . . . . . . . . . . . . . . . 103

5.6 Final Stage Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 105

5.7 Dispute I Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 106

5.8 Dispute II Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 107

5.9 Termination Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 108

5.10 Engage TTP Protocol . . . . . . . . . . . . . . . . . . . . . . . . 109

xiii

5.11 Required Verifying Elements for E-Tender Negotiation Protocol

Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

5.12 APA diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

6.1 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

6.2 E-Tender Submission Protocol I . . . . . . . . . . . . . . . . . . . 143

6.3 E-Tender Submission Protocol II . . . . . . . . . . . . . . . . . . 145

6.4 APA Diagram of E-Tender Submission Protocol I . . . . . . . . . 150

6.5 APA Diagram of E-Tender Submission Protocol II . . . . . . . . . 151

7.1 Protocol Design Process Diagram . . . . . . . . . . . . . . . . . . 166

xiv

List of Tables

2.1 E-Tendering components and e-tender processes . . . . . . . . . . 17

2.2 Business Process and Business Collaboration use cases . . . . . . 20

2.3 Property Differences Between Auction, Procurement, Tendering . 28

4.1 Tendering stages and components . . . . . . . . . . . . . . . . . . 69

4.2 Security policy & threats of qualification & selection stage . . . . 73

4.3 Security policy & threats of tender invitation & submission stage 75

4.4 Security policy & threats of tender assessment stage . . . . . . . . 77

4.5 Security policy & threats of tender acceptance stage . . . . . . . . 79

4.6 Common Threats & Essential Security Mechanisms . . . . . . . . 80

5.1 Initial State Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

5.2 Example code of Player B is Dishonest . . . . . . . . . . . . . . . 124

5.3 Example code of Player A is Dishonest . . . . . . . . . . . . . . . 129

6.1 Property Differences Between Tendering and Auction . . . . . . . 132

6.2 Required Verifying Elements for E-Tender Submission Protocol I . 152

6.3 Required Verifying Elements for E-Tender Submission Protocol II 153

6.4 Example Code of Player A in Protocol I . . . . . . . . . . . . . . 161

6.5 Example Code of Player B in Protocol II . . . . . . . . . . . . . . 162

xv

Declaration

The work contained in this thesis has not been previously submitted for a degree

or diploma at any higher education institution. To the best of my knowledge and

belief, the thesis contains no material previously published or written by another

person except where due reference is made.

Signed: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Date: . . . . . . . . . . . . . . . . . . . . . .

xvii

Previously Published Material

The following papers have been published or presented, and contain material

based on the content of this thesis.

[1] R. Du, C. Boyd, and E. Foo. A secure e-tender protocol. In Simone Fischer-

Hubner, Steven Furnell, and Costas Lambrinoudakis, editors, TrustBus 2006,

volume 4083 of LNCS, pages 213–222. Springer-Verlag GmbH, 2006.

[2] R. Du, E. Foo, C. Boyd, and Kim-Kwang Raymond Choo. Formal analy-

sis of secure contracting protocol for e-tendering. In Safavi-Naini, Rei and

Steketee, Chris and Susilo, Willy, editor, Fourth Australasian Information

Security Workshop (Network Security) (AISW 2006), volume 54 of CRPIT,

pages 155–164, Hobart, Australia, 2006. Australian Computer Society Inc and

ACM.

[3] R. Du, E. Foo, J.G. Nieto, and C. Boyd. Designing secure e-tendering systems.

In S.Katsikas and J. Lopez and G. Pernul, editor, TrustBus 2005, volume 3592

of LNCS, pages 70–79. Springer-Verlag GmbH, 2005.

[4] R. Du, E. Foo, C. Boyd, and B. Fitzgerald. Secure communication protocol

for preserving e-tendering integrity. In Fifth Asia-Pacific Industrial Engineer-

ing and Management Systems Conference (APIEMS’2004), volume 14, pages

16.1–16.15. Asian Pacific Industrial Engineering and Management Society,

2004.

[5] R. Du, E. Foo, C. Boyd, and B. Fitzgerald. Defining security services for

electronic tendering. In The Australasian Information Security Workshop

(AISW2004), volume 32, pages 43–52. Australian Computer Society Inc and

ACM, 2004.

xix

[6] Ed Dawson, Sharon Christensen, Bill Duncan, Ernest Foo, Rong Du,

Juan Gonzalez Nieto, and Peter Black. eTendering - Security and Legal

Issues. Technical report, CRC Construction Innovation, www.construction-

innovation.info, 2006.

[7] M. Betts, P. Black, S. Christensen, E. P. Dawson, W. Duncan R. Du, E. Foo,

and J. Gonzalez Nieto. Towards secure and legal e-tendering. Electronc Jour-

nal of Information Technology in Construction, 11:89–102, April 2006.

xx

Acknowledgements

Thanks to all my supervisors at QUT. Dr. Ernest Foo, principal supervisor, for

his great generosity, helpful advice, honesty and friendship. Professor Colin Boyd,

associate supervisor, for his professional knowledge, direction and advice. Both of

whom showed great patience in providing editorial advice, feedback and genuine

concerns about my research. Professor Sharon Christenson, associate supervisor,

valuable feedback on legal issues. Professor Brian Fitzgerald, previous associate

supervisor, who introduced me into the legal world.

And further thanks to: Professor Edward Dawson, Director of ISI, for his

encouragement when I started out on this research, and who gave me the op-

portunity to participate in various research projects and making contact with

other researchers, which has enriched my professional knowledge. Dr. Carsten

Rudolph, Fraunhofer Institute, supply of SHVT software, example source code

and immaculate tourist guide in Frankfurt. Dr. Kim-Kwang Raymond Choo,

introduction of using SHVT. Dr. J.G. Nieto, the joint work done in Section 4.4.

Professor Adrian John McCullagh, intuitive discussion of the e-tender submission

process. FIT, ISI for giving me the opportunity to do this research. My thanks

also go to the people who worked with me in QUT.

Special thanks to my proof readers: by the time I hand in this thesis, they

have all got sick of correcting ‘biding’s and ‘bider’s, shifting millions of ‘the’s

and ‘a’s, the most frequently used and also the most redundant English words

(IMHO).

My last thank goes out to my family: Frank, Sha, and my parents, without

them life would not be so much enjoyable and distractable.

xxi

Chapter 1

Introduction

“Past success is no guarantee against future failure”

— Henry Petroski

Attracted by efficiency and convenience, an increasing number of business

bodies are using the internet to conduct business transactions. This has opened

many avenues for the creation of new business processes, including electronic

tendering systems, which are supplanting those used traditionally by business.

Tendering, a method of entering into a sales contract, has been regarded as

an effective contracting method to achieve favorable outcomes for both public

and private entities. It is a complex business process and generates a series of

contractually related legal liabilities. Substantial construction and engineering

contracts are entered into through the tendering process [105]. In Australia,

government at all levels has used tendering to contract out multi-billion dollars

worth of business for many years.

In order to seek legal protection and to provide fair trading practices, tradi-

tional tendering has incorporated many elaborate procedures into their regular

business processes such as signing a written contract and using a public tender

submission box. These legal compliance procedures are also desirable processes

for e-tendering systems, in order to offer the same level of assurance as traditional

tendering. Although many generic cryptographic solutions have been provided

for e-business, such as digital signature, time-stamping, e-payment, e-auction,

their application to complex business systems are not straightforward. There is

1

2 Chapter 1. Introduction

a need to conduct further in depth research into the conversion from traditional

to electronic business.

Currently, many e-business systems are built by simply replacing a paper-

based traditional business process with the electronic medium. It is a simple

mirroring process and is also the most common method for converting tradi-

tional business processes to an electronic business format. This mirroring process,

though creating a boom in e-tendering systems around the world (details in Sec-

tion 2.4), has left trails of security traps in current e-tendering systems. An

e-tendering system without adequate security creates undetected legal challenges

[27] which may place both vendor and clients outside the existing legal framework.

A simple replacement of paper by the electronic medium has the capacity to

change the security functionality embedded in traditional tendering. This is due

to the introduction of generic security threats inherent to the electronic medium

into the e-tendering process. Therefore, extra security services may be needed

to achieve adequate functionality to match the paper based tendering system.

These threats may also cause potential legal threats or issues which have been

discussed by Christensen and Duncan [27].

Legal professionals also noticed that an electronic medium is not the auto-

matic equivalent of a paper-based environment [26, 4]. For example, in business,

an electronic document may not provide the same functional purpose as its paper

based counterpart with regard to securing document integrity. A similar situation

occurs in the e-tendering process. It has been discovered that a simple e-tender

box [39] does not provide functionally equivalent security for maintaining tender-

ing business integrity compared to the traditional public tender box. Maintaining

legal compliance is a technical challenge when replicating the functionality of a

traditional paper-based system in the electronic environment [36].

The building of secure electronic business protocols has been researched in

several business areas such as electronic auction and e-cash. Normally a secure

protocol design contains:

• establishing security requirements,

• choosing or developing generic security mechanisms for building secure pro-

tocols,

• constructing security protocols, and

• analysing protocol security.

1.1. Aims and Objectives 3

Cryptographic technology has also shown to be effective in providing desired

security in business transactions such as performing system authentication and

protecting electronic transaction confidentiality.

The security of an e-business system could fail in two ways: a system design

failure or an implementation failure. This research will concentrate on issues

of design in security services for the protection of e-tendering processes. The

investigation of implementation issues is outside the scope of the research.

1.1 Aims and Objectives

Preliminary research (Chapter 2) has shown several facts in the context of build-

ing secure electronic tendering system.

• In order to avoid unnecessary legal challenges, providing adequate security

services is a desired feature in an e-tendering systems.

• Current e-tendering systems have been developed in the absence of estab-

lishing comprehensive security requirements, and are usually designed with

little consideration of security and legal compliance.

• Security is an add-on component after system development, and this add-on

security mechanism is normally untested with respect to potential threats.

• It appears that security protocol design is the missing process in e-tendering

system development.

• In other business areas, it has been shown that a secure business proto-

col can be constructed using cryptographic technology to provide effective

security services.

Therefore, this research is aimed at designing secure e-tendering protocols.

The methodology used in the secure protocol design will contribute to the devel-

opment of generic processes for secure e-business protocol design. The research

is organised in the following research objectives:

Objective 1 Establishing generic security requirements for e-tendering process.

The first objective contains several preliminary research goals: investigate busi-

ness processes involved in tendering and e-tendering systems, related obligations


for e-tendering process, and tendering processes provided by current e-tendering

systems, and determine the knowledge gaps between the implementation of the

current e-tendering system and a secure e-tendering system. Based on the pre-

liminary research, potential threats will be anticipated for establishing security

requirements of an e-tendering system.

Objective 2 Associating security requirements to generic cryptographic security

mechanisms for e-tendering process. The second objective will be focused on ex-

tracting generic cryptographic mechanisms as the building block for constructing

secure e-tendering protocols. It will be also aimed at developing practical method

for associating security requirements to generic cryptographic mechanisms.

Objective 3 Designing secure e-tendering protocols to provide advanced security

services. Further research will be conducted to find the functional limitations

when a generic security cryptographic mechanism is applied to the e-tendering

process. Secure e-tendering protocols will then be designed to provide compre-

hensive security services and improve business legal compliance for e-tendering

systems.

Objective 4 Performing security analysis of e-tendering protocols using formal

methods. The final objective of the study is to establish practical processes for

complex protocol security analysis using formal methods.

1.2 Contributions and Achievements

To help the reader in understanding contribution of research to the field, we will

first clarify the protocol development process. The contributions and achieve-

ments will then be discussed briefly.

Converting a traditional business process to its electronic format involves the

definition of a new business process. Providing security services for the new busi-

ness requires constructing security protocols. The design of a security protocol

requires both the establishment of desired security requirements and obtaining a

set of generic cryptographic security mechanisms. The desired security require-

ments are derived from the set of anticipated potential threats for the e-business

process. Associating security requirements with generic cryptographic security

mechanisms obtains a set of potential building blocks for the targeted security

protocols. An e-business security protocol normally is the composition of generic

1.2. Contributions and Achievements 5

cryptographic security mechanisms. It is the logic of this composition that pro-

vides the adequate security for the e-business. The security verification is applied

to verify the logic.

This research identified two generic issues as the design principles: functional

difference identification and functional limitation assessment.

Principle 1 Functional Difference Identification. This principle is a process

for identifying the security functional differences between a traditional business

process and its mirrored e-business process.

Principle 2 Functional Limitations Assessment. This principle is a process of

finding the assumptions and limitations of each potential generic cryptographic

security mechanism before it can be used to construct a security protocol for

e-business.

The process of Principle 1 involves understanding the traditional e-tendering

process, its potential threats and security obligations; knowing the potential

threats in the electronic medium; anticipating potential threats to the mirrored

e-business process. The aim of the process is to establish a set of desired security

requirements and obtain a set of potential generic cryptographic security mech-

anisms. The aim of Principle 2 is to analyse the limitations when applied to the

e-business environment. A security protocol is finally constructed to avoid these

limitations.

These design principles have successfully generated the following new outputs:

• functional differences were identified between traditional and electronic ten-

dering processes through anticipating threat scenarios,

• desired security requirements were established for the e-tendering process,

• security services were associated to security requirements for e-tender sys-

tems,

• generic security requirements were established and categorized for e-tendering

systems: basic security services and advanced security services,

• protocols were designed for preserving e-tender negotiation integrity,

• protocols were designed for secure e-tender submission process,


• protocol security has been verified progressively throughout various design

stages.

The research has investigated each research objective stated in Section 1.1.

Protocols for securing e-tender negotiation integrity and e-tender submission

process have been constructed using generic cryptographic security mechanisms.

The protocols’ security logic were also verified by SHVT model checking tools to

increase the design credibility. The potential threat environment is also modeled

to analyse whether the protocol is capable of protecting against common threats

or business collusions.

These primary outcomes have raised awareness of security issues in e-tendering.

The security solutions proposed in the protocol format are the first in e-tendering

with verifiable security against common threat scenarios, and which are also prac-

tical for implementation. The procedures developed for securing the e-tendering

process are generic and can be applied to other business domains. The study

has made improvements in: establishing adequate security for a business process;

applying proactive analysis prior to secure protocol construction; and verifying

security of complex e-business protocols using tool aided formal methods.

1.3 Thesis Outline

The thesis contains seven chapters including this Chapter 1 Introduction and

Chapter 7 Conclusion. The knowledge is constructed in the sequence of reviewing

the current state of research on e-tendering, understanding generic cryptographic

security mechanisms, establishing security requirements for e-tendering system,

designing protocols to secure e-tendering negotiation integrity and submission

process. Based on literature reviews, Chapters 4, 5 and 6 document new knowl-

edge advancement in securing e-tendering. This information is organized in the

following chapters.

Chapter 2 is the literature review and serves as an overall understanding of

the current research on e-tendering. It covers review of tendering, e-tendering,

security of e-tendering, related business processes, international standards, and

existing e-tendering systems and system architectures. It also clarifies the most

confusing terms existing between procurement, tendering, auction and reverse

auction. The conclusion of the review focuses on critically assessing the state of

security research for these e-business areas, such as the establishment of security

1.3. Thesis Outline 7

requirements, or of ways to integrate security into the systems. The outcome

supports the objectives for the thesis.

Chapter 3 is a review of cryptographic technology and protocol analysis

tools. It supports the understanding of building blocks for constructing secure e-

tendering protocols. This chapter reviews a set of generic cryptographic technolo-

gies including: asymmetric encryption, digital signature, hash functions, public

key infrastructure, hash chain technology, and protocol verification tool SHVT.

Chapter 4 establishes e-tendering system generic security requirements, which

have been undefined previously. It looks into issues such as obligations of the tra-

ditional tendering process and anticipated potential threats when the business

process is changed from a paper based to an electronic medium. The correlations

are then mapped between the set of potential threats and the required security

services. This mapping serves as a mechanism to establish adequate security re-

quirements for e-tendering system. Two critical e-tender business processes are

selected for the design of secure protocols.

Chapter 5 is devoted to a new protocol for securing electronic tender nego-

tiation integrity. Tender negotiation is a way of entering a sales contract, which

bears legal significance. The chapter begins by identifying functional differences

between traditional tendering and e-tendering negotiation process caused by the

changing of potential threats when the process medium changes. It then estab-

lishes security requirements for the e-tender negotiation process. The limitations

of generic cryptographic security mechanisms are assessed against their usage in

providing required security services. Protocols are finally designed and analyzed

using SHVT.

Chapter 6 is concerned with building of new e-tender submission protocols

for securing electronic tendering submission. Following the same principle as

Chapter 5, this chapter assesses the functional differences between a traditional

tender submission box and an e-tender box, identifies threats scenarios and estab-

lishes security requirements for the e-tender submission process. The limitations

of generic cryptographic security mechanisms for the provision of desired security

services of e-tender submission are also investigated. Two secure e-tender submis-

sion protocols are designed and verified against well known attacking scenarios

using SHVT.

Chapter 2

Electronic Tendering

“Technological advancement is not unqualified technological improve-

ment.”

— Henry Petroski

This chapter critically analyses past research and existing systems to iden-

tify problems in providing security services for the e-tendering process. It also

documents the first research objective and provides a general understanding of:

which business processes are involved in tendering and e-tendering systems; ten-

dering related research; and which tendering processes are employed in current

e-tendering systems.

This chapter contains 5 sections to discuss:

• traditional tendering process and components involved;

• electronic tendering and its international standards;

• related research on e-procurement, which includes e-market and e-auctions

• investigate local and international e-tendering systems that are currently in

use;

• summary;

The general discussion of tendering and e-tendering in this chapter will be

sourced mainly from the report [36] of the research project eBusiness: Security

9

10 Chapter 2. Electronic Tendering

and Legal Issues (this author was a member of the research team). The half year

project began in 2004 and was supported by the Cooperative Research Centre

(CRC) for Construction Innovation research project 2002-067-A. This coopera-

tive research conducted a pioneering investigation of legal and security issues in

electronic tendering. “eTendering-Security and Legal Issues” [36] is the resultant

comprehensive report from this project. The report provides an overall snapshot

in: governing law and legal hurdles of tendering and e-tendering, security threats

and requirements of e-tendering, current possible legal and security practices for

reducing the risks in e-tendering. Several outstanding issues in legal and security

are also discussed. The security analysis of e-tendering systems will be discussed

in Chapter 4 in relation with establishing security requirements.

???The regulation of tendering process may vary in each country, but business

goals of tendering are common internationally. The United Nation has tries

to standardize the e-tendering process for the increasing international business

activities. The study of the Australian tendering system have broad application

to other country’s e-tendering system.

2.1 Traditional Tendering

Tendering is a process commonly used in awarding government contracts. In

Australia, this paper based tendering process is governed mostly by contract

law [36, 27]. The basic components in the tendering process are performed in

sequential order as shown in Figure 2.1. The components are: pre-qualification

and registration, public invitation to tender, tender preparation and submission,

close or open of tender, tender evaluation, award of tender, and archiving [36]. A

tenderer must ensure that their tender is submitted before the tender close time.

The opening of tenders occurs after the tender close time.

Tender submission close timeTender invitation

Pre−qualification and registration

Tender preparation and submission period

Tender opening time Award tender

Archiving

Tender evaluation periodTime line

Figure 2.1: Tendering Process

2.1.1 Tendering

A formal definition of tendering can be expressed as follows.

2.1. Traditional Tendering 11

Tendering: an invitation to relevant parties to make an offer to the principal,

which must be capable of accepting the offer, thereby creating a legally

binding contract [7, 105].

Tendering processes are designed to contain all relevant contracting elements,

also to operate under other legal regulatory frameworks to ensure business in-

tegrity [105, 7], and to protect against common collusions. The tendering process

is conducive to equity and economy. In Australia, unlike other jurisdictions, such

as United State or European Union, the legal framework for tendering is under-

developed [36]. In fact, most of the legal challenges to a given tendering process

are settled by the common law of contract [27].

2.1.2 Tendering Parties

Parties involved in tendering are the principal, who runs the tendering process,

and the tenderer, sometimes called contractor, who makes offers to the principal.

Principal: any party inviting and receiving tenders. A principal may include a

contractor or subcontractor [1].

Tenderer: any party submitting tenders, including contractor, subcontractor

and supplier [1].

For e-tendering systems, a trusted third party may be introduced, and it is

possible that the tender system may be run by this trusted third party.

2.1.3 Tendering Components

The name and details of steps in the tendering process can be quite different due

to the scale of the projects, and from country to country. A tendering process,

however, should contain the following common elements [36]: pre-qualification,

invitation to tender, submission of tenders, closing or opening of tender, evalu-

ation of tenders, award of tender, and archiving. Based on these common ele-

ments, each tendering process may contain special procedures for different types

of projects. The Code of tendering (AS4120-1994) [1] have classified few types of

tendering process: selected tenders, open tenders, preregistered tenders, invited

tenders, and negotiation.


Pre-Qualification and Registration This component is optional but is a prefer-

able step for complex projects such as construction projects. The traditional

pre-qualification requires a tenderer to supply its qualification to the prin-

cipal. The principal will normally perform an assessment of the tenderer’s

general expertise, reputation, financial standing, capability and integrity.

The assessment result will allow the principal to classify tenderers into dif-

ferent ability levels or compile a preferred tenderers list.

For example, the Queensland Department of Main Roads have classified

their construction projects into different levels of complexities. They require

each tenderer to supply its qualifications for an assessment. In this way

the department maintains a classified tenderer list with qualification levels

matched to the level of complexity of a project. For a given project, only

qualified tenderers are allowed to tender. Tenderers or Contractors who are

interested in the project respond with their expression of interest.

Registration is a process involved in using electronic tendering system. In

some small projects, or where there is a requirement to maintain good

purchasing practice, pre-qualification may not be a required step, tenderers

will submit a registration application to the principal. Part of this process

may involve the principal issuing a user name and password to the tenderer.

The main problem that may arise is if tenderers provide a forged identity

or non-authorised qualification. Although it is necessary to maintain the

integrity of the business process in pre-qualification and registration, these

problem have been considered as a minor issue at this stage of tendering

[36].

Invitation to tender The public invitation to tender begins with the principal

(procuring entity) establishing a project strategy. This involves writing the

tender specifications in a tender document for the project. The document

normally contains detailed contract terms, and the terms of the tender

such as tender close time, format of tender or weighting systems for tender

evaluation. The principal publishes the invitation to tender through media

such as newspaper, website or selective invitation. The process ends when

tenderers receive tender invitation.

In the tender document the terms of the tender are crucial. To a large

extent, it determines whether a principal can accept a non-conforming ten-

2.1. Traditional Tendering 13

der. Upon tender submission, it has been recognised that a second collateral

contract exists between the principal and a tenderer who submitted a con-

forming tender [36], which governs the pre-award period tender process.

Failure to comply with the terms may entitle a tenderer who submitted

a conforming tender to seek damages [36, 2]. For this reason, caution is

needed when drafting the invitation to tender and tender conditions.

Tender Submission On receiving the invitation to tender, interested tender-

ers should submit their intention to tender and request a detailed tender

specification document. When the principal receives the intention to tender

submission, it will perform tenderer registration.

Potential tenderers will prepare their tender according to the tender terms

and conditions. Other activities may involve tenderers requesting the prin-

cipal to clarify these terms, and the principal distributing the response or

addendum to all tenderers. Tenderers then submit tenders to the principal.

The process ends when the principal receives tenders.

During the tender submission period, tenderers should comply with the

tender process and requirements laid out in the tender terms, submit their

tenders in the specified format and before the tender close time. These are

the most common disputes in tendering process. Failure to comply with

the terms and conditions may result in a non-conforming tender [36]. For

example, any late tenders may be rejected automatically by the principal.

Thorpe and Bailey [105] point out that at a practical level, the tendering

process is vulnerable to abuse. One common collusion is for the contractor

to induce an insider either to give special consideration for its offer, or to

reveal a competitor’s offer. There are general practices to guard against

these types of collusion in the paper-based system. Sealed bids can be used

to stop anybody viewing the bid before all tenders are submitted.

To maintain tender submission integrity, a traditional tender submission

normally uses a tender box with two keys. It is normally placed in a public

area. This security function is to protect the principal from allegations of

collusion, fraud or other improper conduct by tenderers [36]. The electronic

tender box has a potential to lower the security level in the paper-based

traditional system. This issue will be discussed in Section 6.2.1

Close or Open of Tender The principal will close tender at the tender close


time and open the tender box by following all required procedures. A non-

conforming tender, due to wrong format or late submission, are rejected

after opening. If the principal wishes to consider a late tender, it is impor-

tant that the principal explicitly places this direction in the tender terms.

Otherwise, the principal may not have the discretion to consider a late ten-

der [36]. Tender closing and opening procedures are highly sensitive. In

order to control opening time and prevent other collusions, it is important

that security procedures are not compromised.

Tender Evaluation The principal assesses each offer against its quality and

price or through a scoring system. During the evaluation, the principal will

also perform post-offer open negotiations to consolidate contractual terms

and conditions. In this situation, the principal may need to request more

information from the tenderer.

In the tender evaluation process, the principal’s legal obligation can be

imposed by several sources of law: contract law, administrative law, mis-

leading or negligent conduct, equity, and restitution [36]. For example, in

contract law there are implied terms of fairness, meaning that a principal

would conduct its tender evaluation fairly without favouring its preferred

tenderer. Forming a tendering committee or ‘tender board’ may provide

a certain degree of protection against an individual making a decision to

favour friends. If non-compliance of either an express or implied term occurs

in this stage of tendering, a tenderer can sue for damages.

The administrative law enables a dissatisfied tenderer to have the assess-

ment decision reviewed by the courts for breach of the tendering policy

or procedure. Misleading or negligent conduct could occur if the principal

fails to follow evaluation procedures stated in the pre-award contract terms.

This will be in breach of section 52 of the Trace Practices Act 1974(Cth) or

section 38 of the Fair Trading Act 1989(Qld) [36].

Award of Tender The principal will accept a tender and send notification to

the winning tenderer. It also involves the public announcement of the re-

sult. A formal contract can then be signed between the principal and the

winning tenderer. Under contract law the main contract is formed when the

acceptance of a tender is communicated to the tenderer. However, formally

signing the contract between the principal and the tenderer has been the

2.2. E-Tendering 15

usual practice. The signing of the contract in the paper based system does

not raise any significant legal issues.

Archiving Both tenderers and the principal need to find a secure way to store

their documents. Document retention should consider the file format, ac-

cess, viewing software and integrity verification. The principal is responsible

for secure record keeping.

In Queensland the State Archivist is required to keep and maintain all public

records according to the Public Record Act 2002(Qld). This requirement

would include documents relevant to the evaluation and award of tenders.

These documents would need to be kept for at least six years when the

limitation of action expires as indicated by section 10 of the Limitation of

Actions Act 1974(Qld). In some situation, the documents would be kept

for a longer period of time. These requirements of document retention are

easily met in a paper-based system [36].

2.2 E-Tendering

The term ‘electronic tendering’ has been widely used, but its formal definition has

not been properly documented. The reason may be that no electronic tendering

system fully reflects or mirrors every step of the traditional tendering process. E-

tendering in the public view refers to the use of an electronic medium to facilitate

some part of the tendering process. Commonly, tender requests for tenders are

posted to an electronic tender distribution service, which may also allow addenda

to be distributed, or tenders to be submitted electronically into a tender box. A

more detailed interpretation of the meaning of e-tendering has been generalized

as follows.

Electronic Tendering: is “the electronic publishing, communicating, access-

ing, receiving and submitting of all tender related information and docu-

mentation via the internet, thereby replacing the traditional paper-based

tender processes, and achieving a more efficient and effective business process

for all parties involved.” [27]

Christensen et al. [27] further placed e-tendering systems into three categories,

based on the level of electronic procedures used, each category building on the


previous one: principal to tenderer communication; tender submission and two

way communication; and electronic tendering contract formation.

In the first category, electronic communication is used only from principal

to tenderers. The system allows the principal to post tender documents to a

website, from which tenderers can download the tender documents. The tenderers

still submit their tender on paper, and two way communication is carried out by

traditional methods.

The second category is an extension of the first one. It allows two way elec-

tronic communications between the principal and tenderers. A tenderer can both

download and submit the tender documents through electronic communication.

This two way communication may also include distribution of addenda to the

tender documentation, and negotiation of further terms. However, the awarding

of the tender and contract formation are still usually paper based.

The third category is a fully electronic system which provides all the func-

tionality of the second category as well as the electronic awarding of the tender

and formation of the contract.

The adoption of e-tendering systems is intended to replicate the paper-based

business process with the more efficient electronic business processes, achieving

the same business objective. However, the electronic business process has to

preserve the same set of core functions including security functions for contract

formation.

2.2.1 E-tender Components

Theoretically, the e-tender system should contain at least the same set of ten-

dering components as the paper-based system. These components are core func-

tionalities which provide a basic framework for contract formation during the

tendering process. Table 2.1 lists the e-tender components and their associated

high level electronic processes. In the e-tendering system, all tendering processes

in each tendering component are conducted through the electronic medium. One

of the challenges is to maintain legal compliance when using the electronic process

whilst providing the same functionality as the paper-based process.

Shifting from the paper-based system to the electronic-based system will in-

troduce potential security threats uniquely associated with using the electronic

medium, such as document integrity and communication confidentiality. These

threats will be discussed in Chapter 4 in relation with providing security services

2.2. E-Tendering 17

E-tender Components E-tendering process

Pre-Qualification Registration Pre-qualification registration

Issue user name and password

Invitation to tender Tender advertisement

Tenderer views tender advertisement and notice

Tender submission Tenderer registration to tender for a project

Download tender document

Addendum distributed by principal

Tenderer submits tender

Close or Open tender Close tender

Principal opens tender

Tender evaluation Tender evaluation process

Award of tender Request for information

Award tender or Acceptance of tender

Sign the formal agreement

Archiving Retention of document

Table 2.1: E-Tendering components and e-tender processes

for the e-tendering system.

The Electronic Transactions (Queensland) Act 2001 (the ETQA) will have

an impact upon any e-tendering system adopted in Queensland [36]. ETQA is

an adaption of the Commonwealth’s Electronic Transactions Act 1999, which is

derived from the United Nations Commission on International Trade Law’s Model

Law on Electronic Commerce [36].

This purpose of this model law is to facilitate using electronic communica-

tion for international business. It follows two fundamental principles: functional

equivalence and technology-neutral. Under the legal interpretation of these terms,

’functional equivalence’ means paper-based and electronic transactions should be

treated equally, and ’technology neutral’ means that equal treatment is to be

given to all different kinds of technologies. An electronic transaction should not

be invalid purely because it took place with electronic technology or with more

than one technology [36]. Electronic technology should meet the requirements

of: given information in writing, providing a signature, producing a document,

recording information and keeping a document. These requirements are described

in Chapter 2 of the ETQA.

Although these provisions are in place, the ETQA presents several unsolved

issues in the context of e-tendering [36]: “


• receipt of electronic communications

• formation of contracts electronically

• authority to enter into contracts electronically

• evidence of electronic communications and contracts ”

As the law governing electronic transactions is underdeveloped, legal hurdles

involved with each e-tender components have been discussed in the report of

“eTendering - Security and Legal Issues” [36] and by Christensen and Duncan

[27]. The report also provides prudent practices for reducing potential risks in

the e-tendering system.

Pre-Qualification Registration Introduce security mechanisms in this com-

ponent will reduce the potential risk from identity forgery.

Invitation to tender In this step, it is important to: “

• limit access to tender documentation to pre-qualified individuals via

secure electronic means;

• appropriate terms allowing the incorporation of addenda to documen-

tation through electronic distribution;

• appropriate terms that allow the principal to exercise discretion over

tenders that do not conform;

• a clear definition of what will constitute a non-conforming tender in

an electronic environment;

• consent of the tenderer to the use of electronic communication in the

contracting process. ” [36]

Tender submission Similar security needs to be provided for the tender sub-

mission process and document integrity. This is to protect the principal

from allegations of collusion, fraud or other impropriety by tenderers. The

e-tendering system also need to deal with non-conforming tenders.

Close or Open tender Many issues should be stated clearly in the tender terms

and conditions to reduce the process dispute, such as the time a tender is

to be submitted, when a tender or offer is received, discretions on when a

late tender can be accepted, and the definition of information systems.

2.2. E-Tendering 19

Tender evaluation The e-tendering system needs to provide a method of main-

taining integrity and confidentiality when opening the tender box. A similar

security level needs to be met for the e-tender box.

Award of tender Some issues need to be clarified beforehand, such as forma-

tion of contract, time of receipt, revocation of an offer and the authority of

officers of the tenderer.

Archiving In Queensland, e-tendering documents are public records and need

to be maintained according to the Public Records Act 2002 (Qld).

As the report is only an overall ‘snapshot’ for e-tendering systems, these high

level legal and technical suggestions are neither an exhaustive list or best practice.

These recommendation are also not tested theoretically or practically.

2.2.2 International E-Tendering Standards

The move to e-tendering over open networks has occurred internationally. The

need for recognised e-tendering related standards has been acknowledged by the

United Nations Trade Facilitation and Electronic Business Centre and the Eu-

ropean Union. These organisations have run projects to develop standards the

results of which may have an impact upon Australian e-tendering solutions. The

two main standards are the United Nations ebXML e-Tendering Project and the

e-Legal Project.

The United Nations ebXML e-Tendering Project

UN/CEFACT, the United Nations Centre for Trade Facilitation and Electronic

Business is the Global eBusiness standardization body of the United Nations.

Five groups have been established to develop global eBusiness standards. One op-

erational group was the International Trade and Business Process Group (TBG),

which is responsible for business and governmental process analysis, best prac-

tices, and international trade procedures using the UN/CEFACT Modelling Method-

ology to support the development of appropriate trade facilitation and electronic

business solutions. TBG contains 17 subgroups. TBG6 is the Architecture, Engi-

neering and Construction subgroup which ran the the e-tendering ebXML Stan-

dards Project in 2002 and 2003.


E-tender business process can be different between countries. The ebXML

e-Tendering project aimed to standardise common (major) process and data ele-

ments amongst all countries by using the UN/CEFACT Modelling Methodology.

The Electronic Tendering International Standardization on Business Requirement

and Specification [107] viewed the e-tendering process in three different perspec-

tives: ‘Business Process Elaboration’, ‘Business Information Flow Definition’,

and ‘Business Information Model definition’.

The scope of the document covers the e-tendering business context of the

process. It further partitions the e-tendering business domain into business areas,

process areas, and business processes. This standard describes five tendering

areas, Procurement by Tender, Procurement of Works, Procurement of Goods,

Procurement of Service and Engineering Service. The tender process area model

described Tender, Open Tender and Selective Tender. The e-tendering business

process described Registration, Public Invitation, Tender or Opening of Tenders

and Publication of award processes.

The Business Process Elaboration is a description of micro business processes.

It details each e-tendering business process and captures the business scenarios,

inputs, outputs, constraints and boundaries for processes, and their interrelation-

ships within business process collaborations. The business collaboration use cases

have been listed in the following Table 2.2.

Business Process use case Business Collaboration use caseRegistration RegistrationPublic Invitation Establishment of Project Strategy

Invitation to TenderIssue Tender DocumentPre-Qualification (if required)Selection of Tenderers (if required)

Opening of Tenderers GuaranteeTenderOpening of TendersQualificationTender Result Notice

Publication of Award Contract Award Publication

Table 2.2: Business Process and Business Collaboration use cases

The Business Information Flow Definition identifies business information enti-

ties and the flow of exchange between roles as they perform business activities. In

2.2. E-Tendering 21

this section business transactions have been defined for each e-tendering business

collaboration use case for software development.

The Business Information Model Definition defines fields or data elements that

are needed for providing each e-tendering business collaboration use case services.

It is represented as diagrams using software developer’s view or language.

However, this standard’s purposed is to standardise e-tendering business and

has no intention of discussing legal and security requirements for an e-tender

system. We believe that legal requirements may be specific to each country

but security threats introduced by using electronic medium are generic to all

e-business.

IDABC E-Procurement Protocol

IDABC2 of European Union stands for Interoperable Delivery of European eGov-

ernment Services to public Administrations, Businesses and Citizens. Its objec-

tives are to use ICT:

• to encourage and support the delivery of cross-border public sector services

to citizens and enterprises in Europe,

• to improve efficiency and collaboration between European public adminis-

trations and

• to improve Community decision-making, facilitate operation of the internal

market and accelerate policy implementation.

Public procurement has been identified as a key issue to reducing borders

and contributing to the enforcement of the single European Market and the com-

petitiveness of European businesses. The e-Procurement guidelines [56, 57] from

the program have provided technical solutions and practices for e-procurement.

Volume-I report gives description and activity flows for e-procurement procedures,

functional requirements, technical specifications and open issues. Volume-II pro-

vides in-depth technical analysis and scenarios to experiment with the dynamic

demonstrators and further understand the concepts described for e-procurement.

Security discussion and suggestions are limited to term definitions and off-shelf

products such as ssl, firewall.

Another document is the eProcurement XML schemas initiatives [59, 58]. It

aims at proposing a set of generic XML schemas to support the automation of


data exchanges in the different phases of electronic public procurement. The

schemas are separated into two documents: eOrder and eInvoice phases, and

e-Tendering and e-Awarding phases. These documents have a similar function

to the United Nations’s ebXML e-tendering standard document. The security

consideration is limited only to the optional signature element attached to each

business document in e-Tendering and e-Awarding Phases. As with ebXML, this

project is not intended to provide security solutions.

eLEGAL Project

eLEGAL was a research project within the European Information Society Tech-

nologies program. The two-year project had nine participating organisations from

four European Union countries and consists of seven Work Packages. The project

started in November 2000 and finished at the end of 2002. There are currently

11 deliverables publicly accessible 1.

The project’s early research found that the use of ICT seems to be only

intended to speed up the transmission process, but lacks legal compliances. Based

on this finding, the project targeted the contractual process in the construction

industry as the starting point for collaborating virtual enterprises. eLEGAL

had no intention to address all aspects of e-contracting, but was rather intended

to provide some legal support and tools to facilitate the electronic contracting

environment.

A conceptual model of virtual enterprises in construction was set up to be

used as the framework for outlining essential concepts and their relationships.

The project also classified user requirements for legal support and considered

contractually supported email communications, CAD data exchange and project

collaboration websites. Other deliverables raised the legal issues of architecture,

engineering and construction objects; developed a library of model contracts for

virtual enterprise; and recommendations to standardisation (XML) of eLEGAL

components. A contract wizard was developed by Ponton Consulting from Ger-

many.

The eLEGAL Project had different aims to those of the ebXML e-Tendering

Project, as the ebXML Project concentrated on standardising legal procedures

when contracting using XML. There was no discussion of what security threats

could potentially compromise the legal procedures or how to verify the trustwor-

1http://cic.vtt.fi/projects/elegal/public.html[accessedMay2007]

2.3. Related Research on E-procurement 23

thiness of the contractual evidence generated from the system. Because tendering

is essentially a means of entering a sales contract, therefore the outcome of the

project could have an impact on the e-tendering process.

2.2.3 Summary

Similar to traditional tendering processes, e-tendering will be vulnerable to abuse,

by threats inherited from the traditional tendering process as well as those in-

troduced by the use of electronic transactions. E-tendering systems should also

provide functional security services to maintain business accountability, trans-

parency and integrity. These are the main research areas upon which the thesis

will be focusing.

2.3 Related Research on E-procurement

Research into electronic commerce covers a wide range of business domains such as

e-cash, and e-voting. This section investigates the e-procurement related research

as tendering is one category of procurement. Other business domains may share

some fundamental security requirements such as confidentiality and integrity, but

do not share business process or advanced security requirements with e-tendering.

Therefore their design strategies are rather different.

Essentially, procurement is a purchasing activity for obtaining goods or ser-

vices at the best possible total cost of ownership via contracting. Simple pro-

curement may only involve repeat purchasing. Complex procurement is a multi-

dimensional activity and could involve such elements as finding long term partners

or even ‘co-destiny’ suppliers that might fundamentally commit one organisation

to another.

Procurement may involve a bidding process. For example, the Australian

Commonwealth Government requires that any government procurement exceed-

ing a certain value will have to go through a tendering process involving one or

multiple rounds of tender submissions [3]. In some cases, this tender submission

can be compared with the bidding process in auctions. Because the roles of buyer

and seller of the tender are reversed to those in traditional auctions, the auction

process has been modified to a reverse auction for procurement.

Based on Guttman and Maes’s [92] online market analysis, Teich et al. [101]

classified the online market using the number of buyers and sellers involved in an


online business negotiation (Figure 2.2).

MARKETSREVERSE AUCTION

AUCTIONNEGOTIATION

BUYERS

SELLERS

ONE

MANY

ONE

MANY

Figure 2.2: Market framework (modified from Teich et al. [101])

One buyer and one seller defines the traditional business negotiation. One

seller and many buyers define the auction type of negotiation. Many sellers and

one buyer define a reverse auction, exemplified by government procurement with

a bidding process. Many buyers and many sellers represent a market place. Our

tender definition is procurement with a bidding process which falls into the reverse

auction category.

The word ‘auction’ had been used in many papers to refer to all contracting

methods involving a bidding process. For this thesis we follow the definition from

Teich et al. [101] shown in Figure 2.2. This definition allow us to highlight the

differences between auction and tendering.

A large quantity of research and standards on e-tendering , e-procurement,

and reverse auction have contributed to system functionality [67, 66, 20, 9, 23] and

their financial benefits to the government and private sectors [24, 10, 37, 22, 99].

Few research projects or standards have discussed the security and legal impact

on these forms of e-business.

2.3.1 Electronic Procurement

E-procurement is the application of e-commerce in procurement [22]. Existing

research into e-procurement [20, 37, 22, 66, 23] covers research areas such as

alternative system design, system optimization, system uptake impact, system

cost and benefit analysis.

E-procurement has been considered as using Internet technology in the pur-

chasing process [37]. E-procurement systems normally support three major areas

of business processes: procurement transactions, procurement management and

market-making [99].


E-procurement transaction systems provide an interface for the end user to

access a search engine and locate a product from a central electronic catalog. The

search result of products will generate a requisition which can be electronically

routed to obtain any needed approval. The approved requisition will be used to

create an electronic purchasing order.

Procurement management supports product catalog management. It includes

specification and price of all products sourced from suppliers. In some cases, the

system may allow suppliers to directly update their product information. An

analytical tool may also be provided for decision making.

Market making support provides the type of functionalities which used to be

human intensive, such as managing quotes, bidding and negotiation through the

web. The enterprise can use these functions to conduct auctions, or its internal

users and suppliers can bid and trade goods. This is the part of the system where

e-auction, e-reverse auction and e-tendering mechanisms will be implemented as

online tools.

Depending on differences in Internet technologies, e-procurement can occur

in various forms. According to existing products, e-procurement may take the

following forms [37]: e-MRO (maintenance, repair and operating supplies), web-

based ERP(enterprise resource planning), e-sourcing, e-tendering, e-reverse auc-

tioning, e-informing. These forms of e-procurement systems have their emphasis

on different parts of procurement. For example, e-tendering and e-reverse auc-

tioning can be classified as tools for market making to support buyer and seller

negotiation.

It is worth noting that the e-tendering described by Boer et al. [37] is similar to

the second category of e-tendering systems in Section 2.2 described by Christensen

and Duncan [27]. The description of e-tender from Boer et al. only refers to a

system that facilitates partial communication of a full tendering process, such as

sending requests for information and prices to suppliers, receiving the responses

of suppliers using Internet technology, and sometimes includes the analysis and

comparison of responses.

E-procurement has made four major impacts on B2B (business to business)

procurement activities [99]. It has increased an organization’s ability to search

for suitable products, smoothed order processing, enabled monitoring and bal-

ancing of demand and supply, and has enabled organizations to coordinate more

suppliers’ information than before. The security impact of e-procurement system


has been identified [92, 22, 62, 94] but no adequate research had been carried out

thus far. E-procurement security research will be discussed in Section 2.3.5.

Directed by business management analysts, e-procurement system research

has been dominated by maximizing functionalities which have an impact for pro-

viding efficient and responsive procurement process, such as automated ordering

processes, development of buyer welfare function, optimal revelation mechanism

and utilities. The following section will further discuss various system designs

related to market making supporting tools, such as bidding mechanisms, auction,

reverse auction, multi-dimension or attribute auctions.

2.3.2 Auction

An auction is a manner or mechanism of selling, through bidding, in a public

competition. The item is normally sold to the party who made the highest bid

[78, 54].

A full auction process [54] starts from :

• signing contract between seller and auctioneer, plus goods inspections

• auctioneer defines the auction rules

• bidder registration with auctioneer

• bidding process

• determine the winner and

• formally entering the sales contract.

There are two basic types of auctions: open auctions (e.g. English, Dutch),

and sealed bid auctions (e.g. Sealed first price, Sealed second price). The sealed

second price auction is also known as Vickrey Auction.

The English Auction is an ascending system. The bidding starts low and

incrementally rises until somebody becomes the highest bidder, and no one is

willing to outbid the highest bidder. The winner is the bidder offering the highest

price.

The Dutch Auction is a descending system. The price starts high and grad-

ually decreases until some one bids. The first person to accept the offered price

wins. It is an efficient auction. The auctioneer offers the item at a high price. If


nobody is willing to accept the price, the price is lowered gradually until some-

body accepts.

In a sealed bid auction, no bidder knows the value that other bidders are

offering. Bidding is sealed and submitted. All bids are opened when submission

closes. The result is then announced. The highest bid submitted will be the

winning bid. For the first price sealed bid auction, the winning bidder pays what

they have bid.

The second price sealed bid auction is also called Vickrey auction [110]. A

winning bidder pays the second highest price. Vickrey did point out that the bid

from each bidder has to be secure from other bidders and auctioneers, otherwise,

the Vickrey auction loses its economic property. Vickrey auction bidders theoret-

ically from an economic incentive should bid their true value instead of bidding

strategically for winning when compared to open auctions.

The sealed bid mechanism has been used by government (USA) for tendering

process [78]. It is noted that the winner of a tender is not necessarily the lowest

price. If the word auction is used in the context of government procurement

process by researchers or reporters, it normally means procurement with a reverse

auction bidding mechanism which is a tendering process.

An English auction is strategically equivalent to a second price sealed bid

auction, and a Dutch auction similarly is strategically identical to the first price

sealed bid auction.

2.3.3 Tendering versus Auction

This section is intended to clarify confusions that may arise when discussing the

business processes of tendering and auction. Auction and tendering share some

common procedural steps and properties; for example, bidder registration, bid-

ding submission and, possibly, winner determination steps. Both auction and

tendering are mechanisms for entering a sales contract. Indeed, many govern-

ment tendering processes have imported the sealed bid concept as their tender

submission mechanism. However, there are many differences between auction and

tendering and these are summarized in Table 2.3.

1. Auctions reverse the roles of buyer and seller compared to those in ten-

dering. In auctions many buyers make an offer to the seller; in tendering

many sellers make an offer to the buyer. This is one of the fundamental

differences between auction and tendering.


Properties Auction Procurement Tendering

Bidding mechanism English, Dutch, Sealedbid first price, Vickrey

Reversed auctions Mainly reversed sealedbid

Products Single items or lot Projects, design, ser-vices, single item or lot

Construction project,government purchasing

Buyer Many One One

Seller One Many Many

Bidding party Buyers Sellers Sellers

Winner resolution attrubute Single attribute price Multi-attribute such asprice and quality

Multi-attribute

Table 2.3: Property Differences Between Auction, Procurement, Tendering

2. The winner of a tender is not necessarily the party that bids the lowest

tender price. Winner resolution in tendering is more complicated than in

auctions. In tendering, a buyer specifies what type of goods it wants to buy,

and assesses each tender with the consideration of additional factors such

as quality of service or time of delivery. Auctions determine the winner

using only the price factor, whether the auction is a traditional English,

Dutch, first price sealed bid or Vickrey auction. The tenderer (seller) in

a tendering process is, by comparison, bidding multiple contractual terms,

rather than for a single item, as in auctions.

3. Though auction and tender are both negotiation mechanisms for entering

a sales contract, their differences in business processes generate different

threat scenarios. Therefore, security requirements also vary. A direct ap-

plication of the auction bidding process to e-tendering may not provide the

desired security, and instead may increase the complexity. Normally sealed

bid e-auction schemes have a bidding mechanism which directly relates to

resolving the winning price as well as preserving the losing bidders’ privacy

[95, 70, 52, 16, 5, 17, 75, 93]. These schemes will increase protocol complex-

ity and computation intensity, which may not be practical or necessary in

tendering.

To solve these differences, a new business phenomenon, e-reverse auction

and multi-attributes or dimensional issues auction has been introduced for e-

procurement.


2.3.4 Reverse and Multi-Attributes or Dimensional Auc-

tions

E-reverse auction was first proposed by FreeMarkets Inc. [43] in 1995 for man-

aging the online tendering process. In a reverse auction, a seller (tenderer) bids

to secure a contract with a buyer (principal). E-Reverse auction adopted tradi-

tional auction bidding process and winner resolution mechanism. Therefore the

early version of e-reverse auction resolved winner by price only. It is capable of

handling simple goods purchasing in supply chain environment.

In most cases, a reverse auction deals with multiple contractors bidding mul-

tiple items and resolves winners using multiple attributes such as quality, deliv-

ery time or terms of payment [10]. Single price dominated reverse procurement

started to show its drawbacks when used for comprehensive construction or design

related projects [24, 15, 10] such as building a bridge, or designing an aircraft.

The need of a suitable selling mechanism for tendering has brought economists

to design and analyse multi-attribute or dimensional auction [24, 15, 10, 9, 34].

Che [24] designed three auction schemes with two-dimensional considerations

where firms bid for price and quality. Che’s [24] research focuses on an optimal

mechanism in that a procurer makes a pre-specified scoring scale available to

sellers before bidding. Bids are then evaluated against the scoring rules for the

buyer to make optimal decisions. These schemes can be implemented by two

staged sealed bid auction. In the first stage firms submit their bids using sealed

bidding mechanism. In the second stage, the buyer negotiates to confirm the level

of quality for the project the winning firm intends to provide. The bidder strategy

of multi-attribute reverse English auction has also been theoretically analysed by

David et al. [34].

An experimental analysis of multi-attribute auctions [10] has concluded that

multi-attribute auctions achieve better overall utility than single-attribute auc-

tions. The assumption is that the buyer’s preference can be mapped into utility

functions which generate scoring of bids. Subsequently applications of multi-

attribute auction systems have been discussed by Bichler et al. [9].

Their research is focused on the analysis of business performance in relation

to optimized cost benefit in e-procurement or design utility functions for opti-

mal decision making. The assumption is that the traditional auction mechanism

will support the bidding process required for multi-attribute reverse auctions in

procurement.


2.3.5 Security Issues

Most of the e-reverse auction and e-procurement research has no consideration

of security functions related to contracting elements associated to purchasing. E-

auction research has identified desired security requirements and proposed auction

protocols with security compliance. This section summaries the security research

related to e-auction and e-procurement.

E-Auction Security

Traditional e-auction schemes [111, 85, 69, 88] consider steps from bidder regis-

tration, bidding process to determine the winner. The discussion of contractual

elements in auction is usually not clearly stated. A summarized security require-

ment analysis was first done by Boyd and Mao [14] in 2000. They identified that

internet auctions face potential threats for being abused in the following ways:

Bid shielding in which the higher valued bid is withdrawn in the last minutes

before bidding closes, allowing the lower price to be accepted as the win-

ner. This is a problem directly associated with English Auction, which is

an open, progressive ascending process. If tendering adopted the English

auction bidding process, bid shielding may occur in tendering as well.

Bid siphoning in which the seller will monitor an auction. It then makes a di-

rect contact with a bidder and offers an equivalent item to the bidder. This

way the seller can obtain a buyer for its goods without paying commission

to the auction site. This will happen in a situation where bidders are not

anonymous which applies to all types of auctions. It may also happen in

the tendering process.

Shilling is a traditional abuse for driving bidding price up by inserting spurious

bids in English open cry auction. The seller colludes with the shill acting as

a bidder in the crowd. If the shill wins the auction, the item will be moved

to another auction for sale. It is even harder to detect in e-auction. Shilling

has application to Vickrey [110], where a spurious bid can be injected very

closely to the first highest or lowest price. It can happen in tendering when

these two types of bidding mechanisms are used.

Sniping bidder enters its bid at the last moment in the hope that this will pre-

vent other bidders from responding. Again it is associated with English


auction. It will happen in tendering when English auction bidding mecha-

nism is used.

Misrepresented or non-existent items are the most common complaints of

online auction, because the bidder cannot physically examine the goods

before bidding as in a traditional auction site.

Their analysis shows that e-auction threats are a mixture inherited from tra-

ditional auction such as bid shielding, shilling, and generated by using internet

for auction, such as misrepresentation or non-existent items.

Vickrey [110] pointed out that “Where the seller is a governmental body or

a large corporation, so that the agent handling the sale might not be adequately

motivated to serve the interests of his principal,”. Under these circumstances,

tendering, particularly used by government will be vulnerable to abuse regardless

of the type of bidding mechanisms used, and the abuse scenarios may be quite

different from traditional auction or e-auction. This thesis will further investigate

e-tendering related collusion scenarios to establish adequate security requirements

in e-tender protocol development.

The desired security requirements are also summarized as fairness, confiden-

tiality, anonymity and minimisation of trust [14].

• Fairness means that all parties should be treated equally during the auc-

tion, such as the winner must pay for the goods, no bidder should have

more information than other bidders or that the defined auction rules are

followed.

• Confidentiality means that the losing bid should be kept secret even after

opening. Peng et al. state that [88] confidentiality for sealed-bid auction

means that no bid should be revealed before bid opening time. Keeping

loser bidding secret is defined as another property called privacy [88].

• Anonymity refers to bidders bid as anonymous party. This normally ex-

cludes winning bidder’s identity. It also means that loser bidders’ identity

should be kept secret.

• Minimisation of trust is trying to reduce the trust from the auctioneer.

The set of desired properties of e-auction varies in different types of auc-

tion, therefore the definitions of these security properties vary from paper to


paper. Peng [88] categorized sealed bid auction properties into basic properties

and optional properties. The properties applicable to auction submission security

include correctness, confidentiality and fairness. The optional properties includes

anonymity, privacy and public verifiability.

• Correctness means the correct winning price and winner(s) can be deter-

mined according to the auction rule when every party acts honestly. This

is not the case in tendering.

• Confidentiality (of sealed bid): no bids can be revealed to any parties (in-

cluding the auctioneer) until the bid opening phase;

• Fairness refers to three concepts: no bidder knows anything about other

bidders’ bids before he submits his own bid; a submitted bid cannot be

modified; no bidder should be able to deny his bid submission, which may

be also called non-repudiation of bids.

• Anonymity means that the identities of losing bidders is kept secret.

• Privacy is defined as the losing bids remain confidential until the end of the

auction even to the auctioneer. In tendering, this property is not necessary

when tendered project is design or a construction project.

• Public verifiability means that the validity of the result of the auction is

publicly verifiable.

Confidentiality is a shared property between auction and tendering. Fairness,

anonymity and public verifiability are desired properties for tendering also, but

property definitions in e-auction must be redefined for the tendering process. Pub-

lic verifiability of auction process are the assurance of correctness, non-repudiation

[69, 95], accountability of bidders [69] and accountability of auctioneers [69].

The non-repudiation property has been used in many protocol designs. This

property means that one can prove that a party agreed to, or did, something

at a particular time by using a verifying function. Non-repudiation is the core

property for the contractual component in tendering process. It requires that the

protocol generates evidence, which can be verified publicly. It is this publicly

verifiable evidence that holds the accountability for each person’s action in the

e-tendering process. The ‘accountability property’ is a more acceptable phrase


than non-repudiation when referring to legal properties, because everybody has

the right to deny their actions.

Accountability means that the protocol is able to generate public verifiable

evidence, which proves somebody’s action at a particular time. It requires to have

evidence generation function and verifying function. “A Three Phased Schema for

Sealed Bid Auction System Design” [111] possesses very clear steps to generate

verifiable evidence in an auction protocol.

The traditional sealed bid auction submission concept has been adopted to

tender submission process. However, verifiable submission time of an e-tender is

a crucial issue that is not a desired security property in auction schemes. In the

fair tendering process, late tenders, in most cases, have to be formally rejected.

Because tender open time could be set at tender submission close time, any tender

submitted after tender close time could have already known the bidding strategy

of other tenderers. Therefore, late tenders have a greater chance of becoming the

winning tender than tenders submitted before tender close time. Furthermore,

winner resolution in tendering is far more complex than in auctions since the

tender assessment process cannot be handled effectively by any winner resolution

algorithms designed for sealed bid auction schemes without reconsideration.

For example, the sealed bid auction scheme by Sako [95] is designed to achieve

three desired security properties: fairness, correctness and privacy with special

emphasis on hiding losers’ bids. The fairness ensures that neither the value of a

bid itself nor any partial information will be disclosed before the opening time.

The privacy is to prevent revealing bidder identity and its bidding value even

after the opening. The correctness ensures that the winning value is the highest

(or lowest) bid and the winner is the one that made the winning bid.

This scheme contains four phases: set up, bidding, open, verification. In the

setup phase, the organizer chooses a set of predetermined values. Each bid will

be encrypted and signed in the bidding phase. A trusted distributed authority

will use downward searching to find the highest price in the opening phase. The

authority will stop downward searching when the highest price is found, therefore

losers’ bids will be protected. The computational complexity in this scheme

results from using a set of encryption functions to encrypt and a set of decryption

functions for downward searching to protect losers’ bids privacy.

Losers’ bid privacy is not necessary for tendering so there is no need to choose

sets of functions for encryption and a set of functions for downward searching de-


cryption. Without these security services, a bidding submission and bid opening

algorithm could be simpler for e-tendering.

From the above analysis we conclude that tendering would have a different

set of potential threats and collusion scenarios due to different business processes

between auction and tendering. Collusion that exists in English auction may

not exist in sealed bid auction or in tendering. Auction design has been using

generic security terms such as correctness, fairness, privacy; these terms have to

be redefined for each type of auctions which have different business processes.

It is impossible to use generic security terms to represent all requirements for

all types of auctions, particularly if business processes have different potential

threats. Auction schemes also vary due to different security requirements or other

properties. The tendering process may adopt bidding submission mechanism only

if the submission algorithm is not complicated for winner price resolution.

E-procurement and Reverse Auction Security

A large group of economists and system engineers have attempted to use reverse

multi-attribute or dimension to streamline tender assessment to resolve the winner

[24, 15, 100, 44].

Although e-procurement can take any new form of purchasing activities, the

buyer and seller relationship is a contracting relationship and will be essentially

guarded by contract law. In contrast to e-auction, there is little e-procurement

research considering security issues. A comprehensive security requirement re-

mains unidentified, potential threats to the new system are also under discussion.

As popularity grows, security becomes an issue for e-reverse auctions.

Despite the unquestionable benefits that e-procurement has brought to the

industry, a survey [22] shows that user’s distrust of ICT technology has an im-

pact on e-procurement system uptake and prevents the system reaching its full

potential. The primary concerns are: authentication, integrity, non-repudiation

and confidentiality. However, further discussion of these concerns and application

of each concern to each step of the business process have not investigated in this

survey.

Talluri and Ragatz [100] proposed a framework for multi-attribute reverse

auctions. They believe implementing security measures is a critical factor for

developing and operating multi-attribute auctions.

Goo et al. [94] conducted comprehensive research on security requirements

2.4. Current Electronic Tendering Systems 35

for mobile service provision via a digital marketplace (DMP) [61]. Based on

their system vulnerability and collusion scenarios analysis, they listed a set of

security requirements that DMP architecture must satisfy to enhance trust in

negotiation. The paper first discusses common electronic market security ob-

jective and services. To fulfill the security objective the DMP needs to provide

identification and authentication services; confidentiality, privacy, or secrecy ser-

vices; rights and permission services; and a data integrity service. The paper also

investigated DMP specific security issues and requirements. The essential secu-

rity requirements includes: DMP negotiation protocol, key system management,

rights management, trust evaluators or architecture, trusted system, policy and

policy language, time-stamping and others.

However, their paper is only a security guideline for future generations of

DMP. No security service protocols have been further provided. How this common

security service is to be integrated with specific service is also not discussed.

In earlier years Jaiswal et al. [62] discussed how to secure MAGNET [29], an

online multi-agent contracting system. MAGNET is designed to provide a con-

tracting service for auction, reverse auction, procurement which works effectively

for tendering as well.

Jaiswal et al. [62] identified that MAGNET is not providing secrecy of the

bids and non-repudiation; preventing prior opening of the bids and manipulation

of closing time; and providing fairness or fault tolerance. To combat this, three

building blocks are inserted, publish or subscribe systems, time-lock puzzles and

a communication anonymizer, for securing MAGNET.

Their security solution is based on several assumptions, for example, the cus-

tomer agent will not collude with any supplier agent [62]. This assumption con-

tradicts our discovery that customer agent (principal or buyer) and supplier agent

(tenderer or seller) collusion are the most common issues in the tendering process

[105, 7, 2, 32, 31]. It is also not clear how the time-lock puzzle can be used

effectively to control bid opening time abuse due to inadequate security analysis.

2.4 Current Electronic Tendering Systems

Interviews and online experiments have been used to gain hands on knowledge

of electronic tendering systems. Interviews have been conducted to obtain in-

formation of local government and proprietary e-tendering systems in Australia.


Four government bodies and two international level private companies have been

interviewed and their systems were demonstrated. E-tendering web sites were

also studied for systems in Australia, HongKong, UK and the USA.

These systems can be classified into principal-based systems and trust third

party (TTP) based (TTP-based) systems. The principal based system means

that the principal develops and runs an in-house e-procurement system with e-

tendering process. The trusted third party system is developed and run by a third

party who provides e-tendering related services for principals and tenderers. The

information of this section is sourced from the report (full version [35]) of CRC

Construction Innovation research project 2002-067-A.

2.4.1 Principal-Based E-Tendering Systems

The principal-based e-tendering systems are normally developed by one partic-

ular government department. The system is responsible for advertising and e-

tendering of all projects in the department. The system is not used by other

departments or principals [35].

The principal based architecture is displayed in Figure 2.3. This architecture

only requires two types of parties: the principal and the tenderer.

PrincipalTenderer

Tenderer

Figure 2.3: Principal Based System

Investigated systems were those utilised by QDPW, BCC, QDMR, and ETS.

They provide effective e-tendering tools for external tenderers to download tender

documents and submit tenders; and for internal users to advertise tender projects,

upload tender documents and download submitted tenders.

Queensland Public Works (QDPW) QDPW’s web based e-tender system

covers open and selective e-tender processes [35]. The e-tendering busi-

ness covers building design consultants and building contractors. The open

tender process means a tenderer can: view a current tender or offer listed in


the public area and choose an advertised tender from the list and apply for

the chosen tender or offer. The principal issues a username and password for

the applicant by email. The tenderer can then access the e-tender system

to download tender documents, compile the online tender form and submit

their tender online. The QDPW does not feel that external tenderers pose

great threats to their e-tendering system. The e-tender uses username and

password for authentication. Cookies are issued before each login session.

Each tender project has a TenderID which is shown on the URL after each

login. Audit trails and access control exist but their protocols and mech-

anisms are unknown. The security mechanisms for controlling the tender

closing time and tender opening authentication are uncertain.

Queensland Main Roads (QDMR) QDMR’s e-tendering system is still in

development [35]. The system purports to provide basic tendering functions

for submission of tenders online. Tenderers tend to download documents

from the system, but do not submit tenders through the system. QDMR is

willing to improve their e-tender system security.

Brisbane City Council (BCC) Brisbane City Council’s Tender Box2 provides

basic tendering tools. Businesses need to submit an application to use the

BCC’s Tender Box [35]. The BCC system allows tenderers to search and

download tender documents and submit tenders online to the Tender Box.

Tender Box has four development phases. The current phase only allows

the tenderer to submit their tender to the Tender Box.

BCC sees the main threat to the Tender Box system as unreliability, such

as failure of the tender platform, or that email may not be reliable for

important communications. The BCC Tender Box uses a username and

password for authentication and a cookie for subsequent session identifi-

cation. No technical mechanism was mentioned on the control of Tender

Box closing time. The process of opening the tender is controlled by two

rounds of key submissions. Users need to submit keys to be able to access

the Tender Box to view submitted tenders. It is assumed these keys act as

authorisation for access control. Audit trail or access control mechanisms

are not known. Logs of system access activities exist but information on

2http://www.brisbane.qld.gov.au/BCC:BASE:968723475:pc\=PC\ 327[accessed5/12/2006]


how it is done was not provided.

Hong Kong’s Electronic Tendering System The Electronic Tendering Sys-

tem (ETS) web site3 is hosted by the Government Logistics Department

(GLD) of the Government of the Hong Kong Special Administrative Re-

gion [35]. ETS displays tender notices, contract award notices and general

terms and conditions for government logistics department tenders. In addi-

tion, businesses can subscribe to access additional functions, such as updat-

ing company information, downloading tender documents and clarifications,

submitting queries on tenders and submitting tender offers. Businesses sub-

scribe for either HK$38 per transaction or HK$800 per year (although the

subscription fees are higher if the business is not based in Hong Kong).

The standard terms and Conditions for the tender comprehensively outline

the procedure for both paper-based tendering and e-tendering. Security

is maintained through the use of digital signatures. ETS adopts e-Cert,

issued by Hong Kong Post, and i-Cert issued by Global e-Business Solutions

Limited for suppliers from places outside Hong Kong.

The principal is the main administrator of the tendering process and com-

municates directly with the tenderers. The principal is responsible for ensuring

the authentication of the tenderers. Tenderers usually verify the identity of the

principal and all correspondence coming from the principal, including tender spec-

ification documents and addenda, using a certificate distributed by the principal.

Tenderers submit tender documents directly to the principal. The principal main-

tains the tender box application and must store all submitted tender documents

securely, and ensure that no tender documents are submitted after, or viewed

before the designated tender close time. The principal is also responsible for the

secure storage and archiving of documents after the tender has been awarded.

2.4.2 TTP-Based E-Tendering System

Now third party systems cover more business areas than just e-tendering, to

form an e-business collaboration platform. E-tendering is only one of the system

tools in this e-market [35]. The system is used by multiple principals. Many

private third party systems are instigated with the development of post-tender

3http://www.ets.com.hk[accessed5/12/2006]


Principal

Principal Tenderer

TendererTTP

Figure 2.4: Trusted Third Party Based System

project document management in mind. The TTP based system (Figure 2.4) is

commonly used by private industry, or a high level of independent government

bodies such as AusTender.

The systems investigated are ACONEX, Build Online, Bid Express and the

Australian Commonwealth Government Initiative AusTender.

ACONEX ACONEX platform4 is a java application and can be accessed through

a web browser. This platform provides email, a public and private docu-

ment register, tendering, a purchasing catalogue, a specification catalogue,

project management, knowledge management, community, and business

management. ACONEX has developed three sets of products to collab-

orate with a wide range of clients from different business areas such as

architects, consultants, head contractors, subcontractors or suppliers [35].

ACONEX’s e-tendering module can manage the entire tendering process

electronically. The system contains the following features:

• create invitation to tender;

• approve and submit;

• receive tender;

• request for information or create addenda;

• complete tender;

• submit tender;

• receive and assess tender;

• award tender and notify unsuccessful tenderers

4http://www.aconex.com/[accessed5/12/2006]


A patent has been filed for one of their tendering features. The ACONEX

platform employs username and password for login authentication. It pro-

vides one platform for all its clients to logon, which enables clients to ex-

change their information on the platform instead of using normal email

service. The system also provides access control and logs for all activities.

Each client can only access its own company working area and can also set

up access control for all users in the company. ACONEX also provide an

Automated Assessment Matrix tool for extracting tender data and compar-

ing responses. Clients can view original and adjusted amounts as well as

weighted scores. The system automatically notifies unsuccessful tendering

parties. The platform administration is done by ACONEX. It is not men-

tioned in ACONEX’s brochures whether there is a security management

procedure for its system administration.

Build Online BuildOnline provides an browser based On Demand tender man-

agement service5. It has been used to streamline and automate the tender

process from pre-qualification through to awarding the final contract. It

enables buyers and bidders to automate key steps [35].

The key steps for buyers: compile invite lists; pre-qualify bidders; invite

bidders; distribute information; re-distribute updated information; award

Tender; retain submissions for future bids; demonstrate compliance to pub-

lished standards (e.g. for public tenders). The key steps for bidders: down-

load information; prepare responses; complete sealed response; acknowledge

contract award; retain documents for future use. Only limited security fea-

tures have been provided, such as a secure central document manager which

allows buyers to create tender packages and store them for later use and an

audit trail with a complete log of all tender activity.

United States: Bid Express Bid Express US6 is a web-based bidding informa-

tion service developed for the US highway construction industry. Potential

‘bidders’ subscribe to the service and bid for projects posted by various

state transportation agencies. Encryption is used for security purpose. Bid

Express claim they use the same security system used by the National Se-

curity Agency, the banking industry and Internet commerce. Bid Express

5http://www.buildonline.com/en/index.php[accessed5/12/2006]6http://www.bidx.com/main/index.html[accessed5/12/2006]


US have been in operation for over five years and claim 99.95% reliability

[35].

Australian Commonwealth Government 7 The Commonwealth Electronic

Tendering system, AusTender is also web based and contains similar basic

tendering functions such as, advertising tender project, downloading tender

document online, or submitting tender online and display awarded tender

online. The development team listed some tendering issues that have to

be considered in the development and also listed some challenging issues as

major risk. It is a system used by multiple principals, which are common-

wealth government agencies [35].

Unlike the principal based architecture, the TTP architecture passes all com-

munications between the principal and tenderers through a TTP. The TTP is

the main administrator in this system. The TTP is responsible for ensuring the

authentication of the tenderers and the principal. All tender documents includ-

ing tender specification documents, addenda and negotiation messages are stored

by the TTP. The system is usually implemented using the HTTP protocol with

tenderers uploading offer documents to a web site. The principal also uploads

tender specifications and addenda to the web site. The TTP maintains the tender

box application by controlling who views or downloads the documents. Thus the

TTP will only allow the principal to view tender offers from the tenderer after

the tender close time. The TTP can also act as a messenger so no separate com-

munication between the principal and the tenderer needs to be sent via email.

All messages can be verified and authenticated or kept confidential if necessary

by the TTP.

2.4.3 E-tendering System Security Discussion

Most of these systems are semi automated tendering process, providing a tender-

ing process from advertising to submit tender as we discussed in Section 2.2. Our

interviews show that all systems appear to use username and password for au-

thentication; and web based where the communication may be through SSL/TLS

connections. BCC is using two encryption keys to maintain their e-tender box

security. Some proprietary system may explicitly state that the digital signature

7https://www.tenders.gov.au/federal/index.cfm,[accessed5/12/2006]


function is provided. The digital signature is an optional function in IDABC

XML schemas initiatives (Section 2.2.2).

Security is not a functional requirement in normal system design. Therefore,

the security requirements are not necessarily established and designed during

functional development stage. The industry has a low awareness of the security

issues associated with e-tendering process due to a lack of research output in this

business area.

2.5 Summary

In conclusion, the e-tendering system uses electronic business processes to repli-

cate the core functionalities of the paper-based process, in order to achieve the

business goal of forming a valid contract, discussed in 2.2. The problem is that

the electronic medium does not automatically provide the same functionality as

the paper medium; for example, in assuring document integrity [4]. We fur-

ther investigated current research and practices in the areas of e-procurement,

e-auction, reverse auction, current systems and system architecture, and sum-

marize whether they identify or provide methodologies to preserve the security

functions of paper-based systems during the conversion to electronic business

processes.

Current research and practices consider tendering as a procurement with bid-

ding process. Reverse auction is effectively a bidding process used by tendering.

If any purchasing is done by competitive bidding, there will be a winner resolu-

tion process. In most cases, the winner in tendering is resolved using multiple

attributes, different to auction.

Both auction and tendering are contract negotiation mechanisms. However,

they differ in areas such as bidding process, winner resolution process, and the

buyer and seller roles are reversed (Section 2.3.3). This can cause potential threat

scenario differences which can further lead to security requirement differences.

The reversed buyer and seller environment will generate different legal liabilities

and collusion scenarios. For example, the collusion of a principal with its favourite

tenderer is a common collusion in tendering, but is not the case in auction.

Due to its legal significance, an e-tendering system should be as secure as

a traditional paper based business process. Generally, security is not consid-

ered as a functional system requirement, and is normally paid little attention in

2.5. Summary 43

system design. This design principle has affected the development of existing

e-tendering systems. International standards for e-tendering also show a lack of

comprehensive security analysis, and are therefore unable to provide adequate

security solutions. A large number of e-tendering systems have only automated

some tendering functions in order to reduce unknown risks. Even though, survey

still shows that users, in general, distrust e-tendering systems.

The effort to integrate security into system design is based mainly on develop-

ing tools such as MOSSp [55] and UMLsec [64] for security analysis and design,

and to reduce dependency on expensive security experts. Not to be confused by

their design claims, we believe that they are more like an automation of secu-

rity management process for security integration rather than performing security

analysis or providing a security solution. The evidence is that people who use the

system have to know the security requirements beforehand, and security solution

have to be in existence. If there is a security solution for a particular threat or

security requirement, these tools can help a system designer define security re-

quirements and associate them to existing solutions, otherwise problems will be

diverted to alternatives. Another problem is that this loosely assembled security

solution cannot be tested as to whether this composition provides desired security

services before the system is fully built.

The disadvantage of these tools is that they cannot make the critical decisions

in defining the security requirements of the system, what the possible solutions

are for potential threats, and whether the assembled solution will provide the

desired security services for the system. These tools also put extra demands on

non security experts to make critical security decisions.

Another approach, such as in e-auction, large quantity of research has led

to the development of secure auction schemes using cryptographic mechanisms.

These schemes concentrate on securing the bidding process and winner resolution

by price only. Some of this research is theoretical with little possible practical

application. There is a need to find implementation solutions for protocols. The

application of security solution in e-auction to e-tendering becomes limited by

business process difference and the nature of e-auction research. It is evident

that the application of a cryptographic solution from one business environment

to another is not a straightforward exercise. The limitation of generic security

solutions also needs to be assessed.

After all these investigations, we still do not know what are the security re-


quirements for e-tendering business process. We also don’t know how to establish

an adequate security requirement for a business process. Without an established

security requirement, it is unable to provide an adequate security solution. It

is clear that little research has concentrated on security analysis of e-tendering

business process to establish security requirements and propose security solutions.

E-commerce is the use of the electronic medium for the exchange of infor-

mation rather than the traditional paper based medium. Security includes both

securing the communication medium as well as business communication processes

such as contracting negotiation, invoicing. Most of security solutions are generic

and targeted at securing communication medium confidentiality such as ssl, IPsec,

ssh, web security. Another generic solution is the application of digital signatures

to provide non-repudiation for contracting negotiations. Solutions for securing

business communication process to combat organized collusion and fraud are

unique to each business process. In order to provide an adequate security solution

for the e-tendering system, secure cryptographic protocols have to be developed.

The next chapter will discuss cryptographic technologies which will be used to

provide e-tender security services.

Chapter 3

Security Technologies for

E-Tendering

Everything that can be invented has been invented.

—Charles H. Duell

Technology is ruled by two types of people: those who manage what

they do not understand, and those who understand what they do not

manage.

—Mike Trout

Cryptography is flexible and effective in providing desired security at the ap-

plication level for a particular e-business. Many security services or solutions

are supported by using generic cryptographic security mechanisms. For example,

the first introduction of public key infrastructure [38] was to facilitate a digital

signature service or identity checking for e-commerce. Standard cryptographic al-

gorithms such as RSA [90] and SHA-1 have been used in commercial applications

to provide a digital signature service.

Developing a secure e-tender cryptographic protocol also requires one to per-

form a progressive protocol security analysis. Failure to do so may result in an

easy to break protocol or the protocol suite becomes too complicated to obtain

45

46 Chapter 3. Security Technologies for E-Tendering

a conclusive verification result when the design is completed, such as the Se-

cure Electronic Transaction (SET) protocol [8]. Either situation will mark design

failure.

This chapter will provide background knowledge for understanding suitable

generic cryptographic mechanisms. It will also discuss the protocol analysis tools

which will be used for assessing secure e-tender protocols in various design stages.

Section 3.1 will discuss cryptographic hash functions, public key cryptography,

digital signatures, public key infrastructure and public verifiability. Section 3.2

will discuss SHVT, a tool for model checking and its specification language.

3.1 Cryptographic Technology

The discussion will focus on general security properties of cryptographic hash

functions and digital signatures and some considerations of their applications.

Cryptographic hash functions and digital signatures are among the most popular

and standardized cryptographic mechanisms. They have broad application in

e-tender protocol design. To review these mechanisms in advance is necessary

and can reduce the repetition of discussion in following chapters. Other generic

cryptographic mechanisms: identity based encryption and commitment scheme

are more specific to e-tender submission and will be discussed in Chapter 6 in

relation to their applications for securing e-tender submission protocol design.

Another issue is that each generic cryptographic mechanism shows functional

limitations when applied to other business environments. The security func-

tional limitation can only be assessed when the desired security requirement is

established for each step of the e-tendering process. The investigation of these

functional limitations will also be discussed in later chapters.

3.1.1 Cryptographic Hash Function

The cryptographic hash function is a basic component for many algorithms in

modern cryptography. The hash function H normally maps an input message x

of arbitrary finite length, to an output H(x) of fixed bit length n. The output is

also known as the hash value, message digest or digest. This mechanism maps a

large (practically infinite) domain to a fixed range, mathematically stated as for

a domain D and range R with a hash function H: D → R with |D| > |R|. The

3.1. Cryptographic Technology 47

function is many to one and therefore possesses a compression property, however

potential collision is inevitable.

In order to be useful for other purposes, a hash function can be designed to

have properties, such as ease of computation. It means that for a hash function

H and its input x, it is ‘easy’ to compute output H(x). Easy, relatively speaking,

to the computation power required. In addition to the above properties, a hash

function satisfies some non-invertibility such as one-way or preimage resistant,

second preimage resistant, and collision free properties. These properties will

become an important component in the security cryptographic of algorithms.

Informal definitions of cryptographic hash function basic properties [81, 106]

are:

• One-way or preimage resistance: Given an output h(x) and a hash function

h, it is computationally infeasible to find an x′ with h(x′) = h(x).

• Second preimage resistance: Given a preimage x, hash function h, output

h(x) and preimage property, it is computationally infeasible to find a x′ 6= x

with same output h(x′) = h(x).

• Collision resistant: It is computationally infeasible to find inputs x 6= x′

with h(x) = h(x′). In another words two distinct inputs should not hash

into same outputs. Collision-resistant property offers strongest security

including one-way and 2nd preimage resistant.

In order to achieve different security goals, properties can be balanced, for

example, sometimes the compression property is sacrificed to achieve the non-

collision requirement. In this case, most image elements or outputs will have a

unique input or preimage. Cryptographic hash functions can be used for message

authentication, digital signatures, and encryptions. Because of the compression

property, cryptographic hash functions have been used to make digital signatures

more efficient.

The cryptographic hash function can be basically classified into keyed or un-

keyed functions (Figure 3.1). Another name for a keyed hash function is message

authentication code (MAC). For message authentication codes, a cryptographic

hash function is used with a secret key as part of the input to generate hash value

or digest.

The well known unkeyed hash functions are modification detection codes

(MDC), which can be either an one way hash function (OWHF) or a collision


Message authentication (MACs)Keyed:

Unkeyed:

Modification detection (MDCs):

Others

Others

1. OWHF

2. CRHF

Hash functions

Figure 3.1: Simplified classification of cryptographic hash functions ([81])

resistant hash function (CRHF). The OWHF will possess preimage resistant and

2nd preimage resistant properties. The CRHF will have preimage resistant, 2nd

preimage resistant and collision resistant properties.

In response to recently published attacks on SHA-1 hash function (FIPS 180-2)

by professor Xiaoyun Wang in 2005 1, National Institute of Standards and Tech-

nology (NIST) recommended a transition from the SHA-1 to the SHA-2 family as

new policy on hash function usage 2. It also hosted two hash function workshops

in 2005 and 2006 3, and finally issued a public competition for developing new

hash functions in January 2007.

The attacks on popular hash functions 4 such as MD4, MD5,RIPEMD, SHA-

0, SHA-1, have made an impact on their applications such as MAC and digital

signatures schemes. In order to reduce the impact, it is preferable to build appli-

cations with less alteration hash functions to make upgrade easy. Guidelines in

choosing a hash function for cryptographic purpose are to select the one without

known theoretical and practical attacks 5[89].

3.1.2 Hash Chain Related Applications

The contracting process in e-tendering is a sequential process. Chaining contract

negotiations and agreed terms can provide effective legal record management in

1http://www.csrc.nist.gov/pki/HashWorkshop/NIST\%20Statement/Burr\ Apr2006.html[accessedMay2007]

2http://www.csrc.nist.gov/pki/HashWorkshop/NIST\%20Statement/NIST Policy onHashFunctions.htm

3http://www.csrc.nist.gov/pki/HashWorkshop/index.html[accessedMay2007]4http://paginas.terra.com.br/informatica/paulobarreto/hflounge.

html[accessedMay2007]5http://homes.esat.kuleuven.be/∼preneel/


building a reliable e-tendering process. For example, two parties negotiating the

price of goods. The communication may contain offers, rounds of counter offers,

and perhaps acceptance. It is very important to preserve the chronological order

of the communication, in order to make it very clear which offer has been finally

accepted.

The most popular cryptographic hash functions are constructed using the

Merkle-Damgard iterative structure of hash function, for example MD4, MD5,

RIPEMD, RIPEMD-160, SHA-1, SHA-512 and so on. The concept of the chain-

ing process also provides another property, preserving the chronological order of a

set of events. The hash chain constructed with a one way hash function has been

applied to many cryptographic protocols and can also be a suitable technique in

preserving integrity for a set of sequenced events. ***

Based on the idea of Merkle-Damgard iterative structure of hash function, a

general form of hash chain can be represented as follow (Figure 3.2):

IV1

H2

H3

H5

H4

H

6m

5m

4m

3m

2m

1m

h hhhhh

Figure 3.2: Hash chain forming process diagram

Given a set of M = m1, m2, ...,mn, a set of H is formed by

Hi = h(Hi−1, mi), for i = 1, 2, ..., n,

h() is the underlying one-way hash function,

Hi is the individual hash chain node,

IV is the initial input.

Generation of the current node requires the input from the previous node.

Each node recursively depends on its previous node. This dependency forms

a strong security property to protect the order of events generated through a

sequential process such as contract negotiations in e-tendering. The difficulty

of altering a node of this hash chain without affecting its subsequent nodes is

equivalent to the difficulty of finding a preimage of the one way hash. In other

words, the security strength of the hash chain depends on the one way hash

function.


Using a hash chain as checksum for integrity service, the hash values’ in-

tegrity has to be assured. The following sections will discuss various hash chain

applications such as time-stamp [51], payment systems [6, 91], audit log system

[68].

Time-Stamp Linking Scheme The time stamp scheme based on the hash

chain technology was first proposed by Haber and Stornetta [51] in 1991. It relies

on the digital signature and the one way hash techniques to prevent the Time-

Stamping service from issuing a fake time stamp. In their scenario, a trusted

third party provides a time-stamping service. Their basic idea is to link a current

time-stamping request (hashed message) with a previous request by using one way

hash functions to form a linking node. This node is also signed by time-stamp

service and send to each requester. This way a hash chain is formed through

linked nodes. This hash chain serves as a check value for the later challenge of a

document’s generation time.

The only obvious attack of this hash chain is to recalculate the whole chain

once a node has been altered. In doing so the attacker has to collude with

the time-stamp service (TSS) provider. However this collusion can be detected

by requesting subsequent requesters to provide TSS signed nodes. Other linking

time-stamping schemes [19, 74, 18] were designed based on this idea with different

chaining structure (tree or binary).

Micro-payment System Applications A slightly different hash chain ap-

plication was used in micro-payment systems [6, 91]. The protocol from [91] is

shown below.

A hash chain is a sequence of values:

X0, X1, X2, ..., Xn, where Xi = h(Xi+1), for i = 0, 1, 2, ..., n− 1,

h() is the underlying one-way hash function, Xn is an individual PayWord.

This chain is used, by a client, to form a debit netcard [6] or a credit PayWord

[91] chain with a banker or broker’s certificate and information. It has fixed length

and is pre-calculated before usage. The client spends money from the bottom of

the chain. The vendor checks the client’s current PayWord hash back to the

previously spent coin to confirm whether the current spend is redeemable from

the banker or broker.


This situation is very different from the contracting environment in e-tendering.

Contracting messages are not fixed content. The length of the hash chain formed

from the contracting process is unpredictable and cannot be calculated before-

hand. This scheme is designed for lightweight processes. A small amount of

forgery is not considered as a security risk, such as double spending or form

another chain.

Audit Log Protection Another application of hash chains, protecting audit

logs [68] is a simplified version of Haber and Stornetta’s original linking idea.

This Audit Log protection scheme uses each encrypted log entry to generate a

hash chain to provide an integrity check value for a set of sequentially generated

log file entries. If an attacker took over a log machine, any alteration of the log

file can be detected by a trusted party. The trusted party also can prove whether

this set of logs is trustworthy or not.

There is no human interaction in the chain forming process because the logs

are generated by the system, which is different from the contracting process. The

encryption and hash chain are mainly used to hide log information therefore the

attacker cannot selectively delete log entries. It does not prevent the attacker

from corrupting or deleting the whole log section. Therefore, it cannot be used

for providing desired security services for the contracting process.

Summary The above discussion shows that hash chains can be used with other

algorithms (normally digital signature) to provide desired security services in a

particular business situation. The hash chain constructed by a one way hash

function shows strong security in preserving the sequence of chronological events.

The check value (for the original integrity verification) of each event is generated

each time it happens, and is linked by including bits from the previous event.

Each application of the hash chain has a different chain forming process accord-

ing to the business process it is simulating. The chain protecting algorithms

(normally signature schemes) are also constructed in a different way to guard

against particular attacks related to the business process.

As discussed above, contracting in the e-tendering process is quite different

from micropayments, and audit logs. It is impractical to base our chain forming

process on these protocols. The complete adoption of time-stamp scheme requires

expensive interaction with third party. Additionally, it needs complicated verify-

ing algorithms to reconstruct legal evidence for a complex contracting process in


e-tendering.

3.1.3 Public Key Cryptosystem

Public key cryptography was first publicly introduced by Diffie and Hellman [38]

in 1976. All public key crypto systems are based on mathematical problems that

are believed to be hard. The most common systems are based on problems such as

factorization of integers into their prime factors is hard, intractability of discrete

logarithm and the Diffie-Hellman problem. The idea was to allow Alice to send a

message to Bob such that only Bob can read it, but without having to negotiate

a shared key beforehand as in symmetric encryption. Public key cryptography

contains key generation, encryption and decryption phases:

???

g : jl → K

E : P ×Kpublic→ C

D : C ×Kprivate→ P

g represents a key generation function to generate a private and public key

pair. E is the encryption function to generate a cipher text C using a plain text

P and receiver’s public key Kpublic. D is the decryption function to obtain the

plain text using the receiver’s private key Kprivate and the received cipher text.

There will be a key pair, public key and private key, calculated beforehand

for both Alice and Bob. When Alice wants to send a message to Bob, she will

use Bob’s public key to encrypt the message and send the cipher text to Bob.

When Bob receives the message, he can then use his private key to decrypt the

message. Nobody can read the message without Bob’s private key.

The Merkle-Hellman knapsack public-key encryption was the first concrete

realization of a public-key encryption scheme, though it has since been proved to

be insecure [81]. Public-key encryption schemes have been proposed based on the

principle that it is hard to compute solutions for some mathematical problems.

For example, the RSA scheme is based on the large integer factorization problem,

the Diffie-Hellman algorithm is based on the hard to solve discrete logarithm

problem, and elliptic curve on a finite field over discrete logarithm problem.


3.1.4 Digital Signature

One of the major applications of the asymmetric key encryption is to construct

public key (asymmetrical) digital signature schemes. This section will discuss the

generic asymmetrical digital signature schemes and some existing standards.

Generic Public Key Digital Signature Scheme

In general a public key digital signature scheme has a pair of generated public

and private keys, including signing and verification procedures. A signer A who

possesses its public key and private key pair will sign a message with its private

key and the receiver party B will verify the received signature with A’s public key.

In the signing procedure the signer A using a signing function SA to transform

m to signature s, s = SA(m), s is called A’s signature over message m. In the

verification procedure the receiver B uses a verification function VA to verify s

and m, If the verification result is true, the receiver accepts the message and

signature, otherwise it rejects the signature. u = VA(m, s).

A signature scheme should satisfy two conditions [81]:

1. s can be a valid signature of A over message m, if and only if VA(m, s) =

true.

2. It should be computationally infeasible for any entity other than A to find

a m ∈M and an s ∈ S where VA(m, s) = true.

Digital signature schemes can be designed to be either with appendix or mes-

sage recovery. If a digital signature scheme requires the message as input to the

verification algorithm, it is called a digital signature scheme with appendix. One

has to know the message a priori for signature verification. If this prior knowl-

edge of the message is not required for signature verification, the digital signature

scheme is called a digital signature scheme with message recovery. The latter is

not efficient and is only used for short messages such as key exchanges.

The design of digital signature schemes with appendix relies on cryptographic

hash functions [65, 81]. In these schemes, a cryptographic hash function is used

to create the message digest h(m) before the signing procedure. The signing

transformation is applied to the message digest s = SA(h(m)) (Figure 3.3). It

is also proved that hashing a message before signing can render it less prone to

existential forgery attacks.


7babb87ab03a1986551eaaef3596a12ed2153336

a5677735c5786d7807feaf40d092a46d2b2be013

Plaintext Hash Function

Signing Function

Figure 3.3: Signing in Digital Signature with Appendix

Applications and Considerations

Digital signature schemes are designed to serve as a complement to hand written

signatures. It has been commonly used as a cryptographic primitive to provide

certain security services [65]:

Data integrity: is to assure that data has not been altered by unauthorized or

unknown means;

Data origin authentication: is to provide assurance that the source data is as

claimed;

Non-repudiation: assures that an entity cannot deny previous actions or com-

mitments;

Plain digital signature schemes are normally prone to forgery attacks. Three

types of forgeries can occur when following things happens [81]:

Total break A total break forgery occurs when

• a signer’s private key has been computed or

• an attacker finds an efficient signing algorithm has the function equiv-

alent to the valid signing algorithm.

For example, using existing integer factorization techniques one can com-

pute a signer’s private key generated by the RSA digital signature scheme.

Selective forgery In selective forgery, an attacker is able to create a signature

for a particular message or a class of messages chosen a priori. The creation

of the signature does not directly involve the legitimate signer.


Existential forgery An existential forgery happens when an adversary is able

to forge a signature for a message. The adversary has little or no control

over the message (which may be completely meaningless) whose signature

is obtained, and the legitimate signer may be involved in the deception.

Many techniques can be used for generating forged digital signatures. Key-

only attack and message attacks are two basic types of techniques for forgery. In

key-only attack, attacker only has access to signer’s public key. The attacker’s

power increases in message attacks, where attacker is able to examine signatures

corresponding either to known or chosen message. These forgery attacks vary in

each scheme.

To avoid possible forgery attacks, the security level should match the appli-

cation requirements of a digital signature scheme. For example, if the digital

signature scheme is applied to contract signing in e-commerce, a relatively high

security level should be achieved. In this situation an attacker has the power

to apply all types of forgery techniques, because the attacker has access to the

opponent’s public key, message, hash function, and is able to choose a message

for its opponent to sign.

NIST has recommended three schemes as the digital signature standards

(DSS): digital signature algorithm (DSA), RSA digital signature scheme, and

elliptic curve digital signature algorithm (ECDSA). Their basic security is based

on different underlying mathematical problems.

The DSA is a discrete logarithm scheme and it bases its security on the in-

tractability of the ordinary discrete logarithm problem in a finite field. RSA

signatures are integer factorization schemes and base their security on the in-

tractability of the integer factorization problem. The elliptic curve schemes base

their security on the intractability of the elliptic curve discrete logarithm problem.

The basic algorithm of RSA and DSA digital signature schemes can be found in

the appendix A.

As discussed before, a digital signature scheme does not achieve the required

security even though it is constructed by a public key encryption scheme which is

based on a difficult mathematical problem. For example, the plain RSA encryp-

tion scheme is insecure, particularly in small key exchanges. It is normally used

with Optimal Asymmetric Encryption Padding (OAEP) [72] to achieve provable

strong confidentiality. RSA Probabilistic Signature Scheme (PSS)[73] is the ac-

cording adjustment for RSA based digital signature schemes.


When implementing a digital signature scheme, one should also take into

account the following considerations:

Domain parameter generation : assures that domain parameters are selected

within a secure range to avoid possible attacks for each scheme;

Key pair generation : assures that a generated key pair is in a secure range,

public key validation is performed and proof of possession of a private key

is obtained.

Signature generation procedure : should be familiar with algorithm effi-

ciency for encryption. For example, DSA is faster than RSA in signature

generation because exponentiation can be pre-computed in DSA. [81].

Signature verification procedure : should be familiar with algorithm effi-

ciency for the signature verification process. It appears that RSA digital

signature schemes are faster in signature verification.

Security analysis : should be familiar with all known attacks for a particular

digital signature scheme and their associated cryptographic hash functions

or encoding functions [81, 65, 72]. Recommendations should also be followed

accordingly.

Many public key digital signature schemes (non-identity based encryption

schemes) can only bind a person’s public key to a message. Therefore it must

bind the public key to the person’s identity through other means. In many cases,

it requires a Public Key Infrastructure (PKI, is discussed in Section 3.1.5) to be

in place.

3.1.5 Public Key Infrastructure PKI

PKI is one type of key management scheme. It uses a trusted third party service

with a certificate. The trusted third party is known as the certification authority

(CA). When a key pair is generated, the CA will issue a certificate to state the

owner of the public key through key registration. The purpose of the certificate

is to bind a public key to the person’s identity. To ensure that the certificate

is valid, one can verify certificate issuer’s (CA’s) signature and check certificate

status.


There is a list of information contained in certificates. The complete list can be

obtained from standard X.509. A certificate normally contains the information of

a person’s public key, this person’s identity, the CA’s signature of this certificate

and other technical information. Other information in the certificate can include:

• the public key’s validity period;

• serial number which is the key’s identifier for identifying the certificate or

key;

• additional information about the owner of the public key such as street,

email, phone;

• the purpose of the key such as digital signature or key encipherment;

• signature algorithm to be used such as RSA or DSA;

• the certificate issuer information such as country, organization;

• quality measures related to the identification of the subject entity, the gen-

eration of the key pair, or other policy issues;

• signature verification information such as a signature algorithm and com-

pression functions used;

• status of the key when it is a revocation certificate.

The public and private key pair can be generated by a trusted authority or

generated by the entity itself. Either way identity evidence such as a passport

has to be provided for the CA to authenticate an entity. When the entity passed

authentication, the CA will perform key registration and issue public key certifica-

tion or just issue a certificate for self generated keys. Apart from key registration,

the CA has to manage key revocation. When a public key expires or its private

key is compromised, the CA has to issue a key revocation certificate.

For example, to manage users on a large scale globally, the PKI has to use

a cluster of CAs. Therefore a trust has to be established between CAs. Many

trust models for CAs have been proposed in the past. Models establish a trust

relationship between CAs to build certificate chains and certification paths. For

example, in Figure 3.4, a verifier A has the public key P5 of CA5, and wishes

to verify entity B’s public key issued by CA7 with P7. The solid arrows shows


that a trusted path can be built from CA5 to CA7 for entity A. It indicates that

CA5’s public key can be certified by CA1, CA1 by CA root, CA root also can

certify CA2, which in turn it certifies CA7.

A B

CA8CA7CA6CA5CA4CA3

CA2CA1

CA_root

Figure 3.4: Strict Hierarchical Model

Models include trust with separate domains, strict hierarchical trust model,

multiple rooted trees, hierarchy with reverse certificates and directed graph (di-

graph) trust model. The constraints in building these models are limits of chain

length and limits of the set of valid domains [81].

3.1.6 Public Verifiability

Even in the traditional tendering process, the bidders or contractors have to trust

that the client is running a honest and fair business. There is no effective method

to monitor both parties’ activity. The public verifiability of a cryptographic sys-

tem can reduce these blind trusts between business parties, thereby increasing the

reliability of the system. For the tendering process, the document evidence and

its verifying function need to be preserved in the long term for public verification

when disputes arise.

Public verifiability normally refers to a situation where both the verifying

function and its input are published on a bulletin board, and anybody can verify

the result using the function and its input. It has been proposed in e-auction

[87, 85], e-voting [63], and e-cash systems. Public verifiability has been discussed

by Jakobsson [63] with a definition and properties that public verifying techniques

3.2. Cryptographic Protocol Security Verification Tools 59

should possess.

The public verifying function and its input should not compromise the privacy

and confidentiality properties of a protocol. The reliability of an e-commerce

cryptographic system largely depends on the level of its public verifiability.

Many types of public verifying functions have been proposed in the past to

achieve verifying correctness, as well as to protect privacy and confidentiality, such

as zero-knowledge [49], and challenge-response [38, 76] protocols, and millionaire

problems [71, 82].

Damgard in 1999 introduced a commitment scheme [33] between a prover and

a verifier. A commitment scheme normally provides binding and hiding properties

which are particularly useful for e-tender submission process. A comprehensive

discussion of the commitment scheme and its applications will be discussed in

relation to e-tender submission protocol design in Section 6.3.1.

3.2 Cryptographic Protocol Security Verification

Tools

Cryptographic protocol security verification uses formal methods with or without

supporting analytical tools to examine a designed security protocol and verify

whether the protocol achieves its security goals. Many formal methods and tools

had been developed with various sophistications of complexity [80, 53]. Model

checking is one type of method which can be used for protocol security verification.

Model checking is a process to check whether a given model satisfies a given logical

formula. Using model checking in security protocol verification normally involves

firstly specifying a security protocol with a formal modeling language. Various

analytical processes can then be performed using the associated tools.

From the comparison of analytical tools [53], Simple Homomorphism Verifi-

cation Tool (SHVT) [84] has several advantages over some other tools. It is one

of the tools that is easy to learn and produce graphical analytical result. SHVT

also allows users to insert attacker behaviours and the specification can be at a

high level. The tool provides the properties required for our protocol analysis.

SHVT is an analytical tool supporting several formal specification environ-

ments, labeled transition systems. Basically, SHVT provides specification tools

or environments for product net, APA and temporal logic modeling language.

We chose to use SHVT with APA specification language. APA stands for asyn-


chronous product automata.

3.2.1 Asynchronous Product Automata

The asynchronous product automata (APA) language is a universal and flexible

operational description concept for cooperating systems. It is a formal language

which is defined by an alphabet and formation rules. An APA can be considered

as a family of elementary automata. The APA’s set of all possible states is

constructed as a product set. Each state is divided into state components.

The formal definition of APA can be expressed as follows [84, 47]:

• a family of State Sets ZS, S ∈ S, which is a collection of all State Sets ZS

• a family of Elementary Automata (Φe, ∆e), e ∈ E

• a Neighbourhood Relation N : E→ P (S)

Φe is its Alphabet for example, elementary automaton A or Alice. ∆e is its

State Transition Relation, represents the process to bring the elementary au-

tomaton from one state to another. E and S are index sets of name of elementary

automata and state sets. The Neighbourhood Relation N is a function. It maps

E to the power set P (S) of S. P (S) is a set that contains all subsets of S.

Figure 3.5 shows that this APA contains two elementary automata, A and

B. It also contains three state components SC A, SC Share and SC B, with

SC Share as the shared state component between A and B. Each of these state

components contains one or more elements. They can be represented as state

sets ZSC A, ZSC Share, ZSC B. The state set of the APA is the product of ZSC A,

ZSC Share and ZSC B. The state set of A is the product of ZSC A and ZSC Share,

and the state set of B is the product of ZSC Share and ZSC B.

Joining lines represent neighbourhood relation N. If an elementary automaton

A is connected with a state component SC A by a line, it means that SC A is

included in the state of A. This relationship also indicates that A can change

SC A, adding or removing elements from ZSC A through A’s transition relation.

The same rules applies to shared state component SC Share. A full specification

of the elementary automaton such as A includes specifying A’s initial state (define

elements in SC A and SC Share) and defining its transition relations.

A relatively small protocol can be modeled using one APA diagram or spec-

ification. The specification allows all players in the protocol to be modeled as a

3.2. Cryptographic Protocol Security Verification Tools 61

SC_BSC_ShareSC_A A B

Figure 3.5: APA Diagram

family of elementary automata. Players can communicate through shared state

component normally called the network. If A wants to send a message to B,

the message can be put into a shared state component by A then B can retrieve

this message from the state component. All the state components can be used

as memory space to store the state of elementary automata and the APA. The

neighborhood relation specifies which players can change which state component.

The processes and communication between each player in the protocol can be

specified by transition relations of each player. One player may be associated with

a set of transition relations depending on the protocol it models. A specification

of a transition relation may include retrieving an element from a shared or private

state component; comparing elements; adding or removing elements to or from

a private state component; performing encryption or sending or adding elements

to a shared component.

A protocol or a system specified with APA requires preambles for the alloca-

tion of roles of each automata, the specification of their initial state components

and the transition relations. The preambles then can be analysed by SHVT which

explores all possible states.

3.2.2 Simple Homomorphism Verification Tool

Simple Homomorphism Verification Tool [84] was developed based on the defi-

nition of simplicity of language homomorphisms and labeled transition systems

[83, 84]. SHVT supports the protocol specification, analysis and verification.

???Each protocol agent contains its local states and these states are structured

into several components [47]. The components will describe its knowledge of keys,

its “view” of the protocol and the goals to be achieved within the protocol. The

protocol communication is then to be conducted by add or remove the element

from a shared component such as Network. The cryptographic mechanisms can

be modeled as symbolic functions with certain properties and conditions. In ad-

dition to protocol agents, an intruder is specified to create attacking environment.

The intruder cannot access each agent’s local state component, but it can access


the shared Network component, which means that the intruder may intercept

messages, create new ones based on his initial knowledge and on what he can

extract from the intercepted messages. Violations of the security goal can be

found by SHVT inspecting local state space.

Gurgens and Rudolph [48] have successfully analysed dishonest players in a

fair exchange protocol [112] using SHVT. Fairness is a very important property

in e-commerce protocols, such as e-tendering protocols.

The security protocols will be specified using APA. The attacking environment

will then be modeled by inserting the attacker’s transition patterns to the specified

protocol. SHVT will search all reachable transition states and the result will be

displayed in a graph. The result will then be analyzed to determine whether

there is any state representing an attacker has achieved its goals. If no such state

is found in SHVT’s finite state search, we can claim that our secure e-tendering

protocol will provide security services under specified attacking environments.

3.2.3 Difficulties of Using Tool Assisted Formal Methods

The protocol verification has to be performed by people who know the protocol

well, preferably the protocol designer. This is to ensure that the specified model

accurately represents the given protocol. SHVT like all other tools has to specify

abstract conditions or constraints to ensure it is a finite state search and not

causing state explosion. Too many assumptions or constraints can lead to an

unreliable verification result; and too few may cause an inability to reach a result.

To find the balance can be a lengthy exercise and require a skilled tool user.

The number of permutations and combinations of how a protocol can be

attacked is sometimes too large for any of the tools and users to model. For

an e-commerce protocol, the security verification normally models the human

foreseeable attacking environment, which means the possible attack is designed

and specified by the user. The chance of finding an unforeseeable attack is slim.

This chapter has discussed generic security mechanisms and protocol security

verification tools. The next chapter will analyse e-tender system security.

Chapter 4

Electronic Tendering System

Security Requirement Analysis

“Successful design, whether of solid or intangible things, rests on an-

ticipating how failure can or might occur”

— Henry Petroski

The traditional tendering process should be fair to all parties to achieve an

optimally priced bid, which is the favored outcome. This business principle of

tendering implies that there is a set of obligations to be followed when conducting

a tendering process. Case law [2, 36] also indicates that fairness of process is

the implied contract for principals to follow (see also Section 2.1.3). In order

to combat potential misconducts, standards and codes of conduct are introduced

along with existing regulations. For the purpose of compliance, a set of procedures

are integrated to safeguard the traditional tendering by improving the process

transparency and integrity. It is difficult to preserve these existing safeguards,

when moving from traditional tendering to e-tendering process due to a lack of

understanding of legal and business perspectives in system development.

This chapter focuses on finding a practical way of associating obligations to

generic security requirements of the e-tendering system. It is the first step in

security protocol design process and contributes to the understanding of what

needs to be protected for a complex system.

63

64 Chapter 4. Electronic Tendering System Security Requirement Analysis

Five sections are included in this chapter. The Section 4.2 will discuss the

obligations and considerations for the principal, tenderers; the Section 4.3 will

map business requirements to security policies; Section 4.4 will extract generic

e-tendering security requirements and discuss the e-tender system structures in

relation to distributed security services.

4.1 Introduction

The unguarded use of electronic technology in electronic tendering and post-

tendering project management is due to the trade off between efficiency and

security. Shan [98] in his thesis indicated that there is uncertainty in the le-

gal impact of using existing e-tendering project management systems. For this

reason, industry is reluctant to conduct final contracting activities such as the

tendering process to select main contractors and subcontractors using current

e-tendering systems. Another factor contributing to this reluctance, is the ease

with which documents can be manipulated electronically, such as copying, delet-

ing, altering, or searching. This further threatens the issues of confidentiality,

integrity and copyright.

Fitzgerald and Fitzgerald (2002) [45] point out that electronic commerce so-

lutions are undertaken in the absence of the ability to authenticate participating

parties by sight. This immediately creates problems with authenticity and in-

tegrity of electronic transactions as trust has been compromised. These threats

have undermined the foundation of the admissibility of contract evidence, which

consequently affects every step of an e-tendering process.

Improper use of electronic communication systems could also increase the

possibility of collusion. Still the most common form of collusion is the leaking of

a competing tenderer’s information by the principal to its favoured tenderer in

the traditional tendering process [32, 31, 105]. By law, the principal is obliged

to conduct a fair and transparent tendering process, which also discourages any

collusion activities [1, 2]. Multiple communication channel usage in current e-

tendering systems can cause untraceable breaches of a document’s confidentiality.

In this case, the unguarded use of electronic communication is, in fact, providing

a basis upon which collusion activities can operate undetected.

The above discussion shows that there is an increasing demand that the legal

requirements should be integrated into the e-tendering system design. Modern

4.2. Obligations 65

cryptographic research has developed security mechanisms to safeguard electronic

commerce processes, such as e-auction [88, 111], and time stamping [51, 19, 108].

This has the potential to improve not only efficiency, but also business process

security and reliability over that of the traditional system.

Menezes et al. (1997) [81] stated that achieving information security goals in

an electronic world, there is a need to acquire significant skills and knowledge

in technical and legal areas. This also implies that legal issues are a subset of

requirements in respect to information security. We, therefore, are obliged to

include the legal practice into the electronic commerce protocol design.

Security requirements differ significantly from business to business, due to

their particular legal issues and business flows involved. In order to overcome the

problems related with ad-hoc systems, we want to make sure that legal issues are

a part of security policies, and that security is part of the design of e-tendering.

Therefore, defining security properties is the primary step towards a successful

design.

The following sections are aimed, firstly, at mapping the e-tendering proce-

dure, and defined obligations, to security policies; secondly, to suggest security

mechanisms or functions which can be used to enforce the security services re-

quired.

4.2 Obligations

This section discusses major legal areas affecting the electronic tendering process,

which creates obligations for each party and the design of an electronic tendering

system. Obligations define how each party and the system should perform, in an

e-tendering process, to either protect against or detect non-ethical behaviour. The

obligations defined in the Australian Standards (AS2124-1992, AS4120-1994) are

summaries of obligations drawn from the governing law [36] that have impacted

on the tendering process.

Obligations for one party give rights to the other party. The principal is

obliged to run the tendering process with clear and fair procedures [50]. The

recent analysis [27] of case Hughes Aircraft Systems International v Airservices

Australia [2] also indicates that the principals need to act fairly in the way they

deal with, and award, tenders. The obligations for principal and tenderers stated

in Australian Standard Code of Tendering is summarized as follow.


4.2.1 Obligations for the Principal

During the pre-tender stage, the basic obligation for principal is to provide clear

project definition and clear tender documents. Pre-tender information (tender

documents, tender enquiry, clarification, amendments) should be available to

every potential tenderer [1].

In the tender invitation and submission stage, the principal should apply

conditions for all tenderers equally. All tender inquiries and answers should be

made available to all potential tenderers. The principal should choose any of the

valid types of tender method and allow sufficient time for the tender process to

complete [1, 50].

All submitted documents for tender should be safeguarded with security and

confidentiality. The principal should not open submitted tender documents before

receiving all submissions or deadlines. It should not disclose any information from

one tenderer’s documents to any other tenderer at any stage of the tendering

process, except when publishing the winner’s price.

During the assessment period, the principal should apply conditions stated in

its tender document equally to all submitted tenderer documents. In post-tender

negotiation, the principal should only confirm the contract term conditions, and

should not engage in any price cutting activities. All negotiations should be

recorded clearly by the principal.

On accepting an offer, evidence of contract should be generated by the prin-

cipal for the main contractor to sign. Procedures should follow the Australian

Standard of General Conditions of Contract (AS 2124-1992), and standard forms

for tendering (AS 2125-1992, AS 2127-1992), or any other forms which may be

used to finalise the tendering procedure.

4.2.2 Obligations for Tenderers

Tenderers should only submit their tenders within their capacity and competence.

They should also evaluate and fully understand the principal’s tender documents.

If an error exists, the tenderer should advise the principal promptly. They should

not engage in any collusion and misleading activities, and should consider confi-

dentiality.

4.3. Mapping Business Requirements to Security Policies 67

4.2.3 Other Considerations

The enforceability of an electronic contract relies on its evidential weight, and

is assessed by the reliability of the manner in which the e-contract is formed.

Similar security level should be provided as paper-based system.

Boulmakoul and Sall [12] have pointed out that electronic contract negotiation

and other e-trading mechanisms must inherently provide some security properties:

• Authentication of the participating parties. An e-tender system should be

able to confirm the identity of the contractual participants.

• Confidentiality and privacy of contract documents. To ensure that only

participating parties should be able to view the content of the electronic

contract.

• Integrity of contract document. A series of contracting documents should

remain complete and unaltered once they have been generated.

• Non-repudiation. Contracting parties should not be able to deny their in-

tention to be bound by the contractual agreements.

4.3 Mapping Business Requirements to Secu-

rity Policies

The tendering process and defined obligations are a particular set of statements

which define what is, and what is not, allowed for a sets of actions performed in

an e-tendering process. These actions generate a set of time sequenced evidence,

including a large subset of contract evidence.

Legally admissible contract evidence is the primary legal protection of parties

involved in a multi-million dollar contract process. This section maps the above

statements to security policies that an e-tendering system should possess. There-

fore, the generation of legally admissible evidence can be ensured in the later

design.

An e-tendering system is a collection of users, electronic media, digital data

and actions that can be performed, enabling those users to interact. Actions

change the e-tendering system state. The e-tendering system security policies

define a subset of actions that transform e-tendering system from a secure state


to another secure state. Threats and possible violations define the subset of

actions that transform the e-tendering system from secure to insecure states.

The e-tendering security mechanism is the collection of mechanisms which either

prevent the change from a secure to insecure state, or detect and log when this

change occurs.

Users in the e-tendering system are the principal, tenderers and trusted third

parties. Electronic medium are communication media and databases.

The major actions involved in e-tendering are documentation, assessment,

document handling and communications. New digital data is generated during

the e-tendering process by user interaction with electronic medium and digital

data.

For example, documentation and assessment generate tender documents, con-

tract terms, assessment results, and documented tendering procedures. Docu-

ment handling involves document accessing, copying, printing, altering and dis-

tribution. These actions can generate the document access log histories for a ten-

dering process. Communication can be subdivided into four types: registration

process, contract term condition negotiation, notification or response, submission

or notice of receiving, and inquiry or clarification. Communication generates a

series of time sequenced messages for a particular e-tendering process.

For electronic tendering systems the threats are inherited from two areas,

traditional process and the introduction of electronic technology. The security

policies and threats are discussed within each tendering stage.

4.3.1 Tendering Stages

The e-tendering components (discussed in Section 2.1.3) can be grouped into four

stages, as shown in Table 4.1. Each stage contains a distinct set of activities in a

tendering process.

Stage 1: Qualification registration covers all business processes involved in

qualification and registration tender components.

Stage 2: Tender invitation and submission involves three tender components:

public invitation, tender submission, close or open of tender.

Stage 3: Tender evaluation contains only tender evaluation process.


Tendering Stages Tendering Components

Pre-qualification registration Pre-qualification registrationTender invitation submission Public invitation

Tender submissionClose or Open tender

Tender evaluation Tender evaluationTender acceptance Award of tender

Archiving

Table 4.1: Tendering stages and components

Stage 4: Tender acceptance covers components of award of tender and archiv-

ing.

The electronic medium will introduce the potential threats to an e-tendering

system such as repudiation, eavesdrop [81]. The following is a list of generic

threats introduced by using the electronic medium:

Breach of Confidentiality means that information is accessible to those unau-

thorized to have access.

Breach of Integrity is the action of altering existing fact such as altering ex-

isting digital documents without permission.

Repudiation is the act of repudiating of what have been committed in the past

such as a message communicated through the Internet.

Masquerade refers to an action or appearance that is mere disguise when using

electronic systems.

Eavesdrop is to secretly overhear a private conversation through the electronic

medium such as Internet.

??? These threats have the potential to weaken the traditional tendering

process and bring the security into an unknown state.

4.3.2 Pre-Qualification and Registration

The goal for this stage is to generate a final tenderer list for a project from an ap-

propriate approved list. Figure 4.1 shows the process and parties in this stage of

tendering. The horizontal arrows represent the communication between the prin-

cipal and tenderers. The vertical arrows indicate the business flow steps. The


rectangular boxes represent internal activities. The oval boxes represent commu-

nication activities. There are three cycles of selection to draw a final tenderer list.

The principal compiles a preliminary list from contractor’s qualification (technical

and financial). After the preliminary query and response, the principal compiles

a draft and a reserve tenderer list. According to the final confirmation of the

tenderers interest, the principal compiles the final tender list. For electronic ten-

dering, potential tenderers should be requested to make formal registration for

tender. This step is to formalise keys and communication functions for continued

process.

For example, a principal wants to call a tender for a project to construct

a multi-level building block, and chooses to use Selected Tender method on an

electronic tendering system. The principal will search a register of approved

prospective tenderers, whose capability has been confirmed. According to their

qualification and financial ability, the principal will compile a preliminary list,

then prepare a document which briefly describes the project. The principal sends

a query to all tenderers in the primary list about their willingness to tender for

this project, along with the project description. On receiving the query, the

tenderers will send a response to the principal as to their interest in this project.

The principal then compiles a draft tender list and a reserve tender list, which

only contains a small number of registrants. If there are withdrawals, the principal

will choose replacements from the reserve list, and compile a final tender list. If

there are no withdrawals, the principal will finalise the tender list. The principal

will then inform those not invited to tender, and request tenderers in the final

list to register.

Major documents generated at this stage, include submitted tenderer quali-

fications, project definition, tender lists compiled by principal and logged infor-

mation.

From the discussion of obligations and business flow, we summarise a set of

security policies required for this stage, and threats related to the security policies.

Because the security policies are restrictions of parties’ actions in the tendering

process, these policies have been further categorised into four action subgroups:

communication, documentation, assessment, and document ( Table 4.2).

The security policies related to communication are as follows: Identify com-

munication parties, record time and date of the message, ensure communication

privacy and message original integrity. The common threats are masquerade, re-


pudiation, time repudiation, eavesdropping and integrity violation. The principal

needs to make sure that the project description is accurate and avoid any mislead-

ing statements. For the assessment, the rules should be applied to all qualified

tenderers fairly without favouring the preferred tenderer. In the document han-

dling, the principal needs to ensure that document integrity, confidentiality and

authenticity are provided. All pre-tender information should be available to all

potential tenderers instead of the principal’s favourite tenderer.

In order to emphasise the importance of security policies we continue the above

example. The principal chooses to use email as the communication method to

send or receive inquiries and documents. Unfortunately, a general email system

cannot identify communication parties, or ensure communication privacy and

integrity. Messages are sent as plain text and sending an impersonated fake email

is a trivial exercise. Company B obtains the list of companies that will be invited

to tender, and knows that company A in the list is its strongest competitor. It

then sends a fake email to notify the principal that company A has withdrawn

from the tender process. The result is that company A is removed from the final

tender list and the principal believes that company A is accountable for the email

containing the withdrawal notification.

When company A discovers the reason, it decides to take the principal to

court for fraudulent activity. In the court, company A denies having sent such a

withdrawal email to principal. Because the original integrity and sender identity

was never calculated and checked, the email can not be publicly verified for its

trustworthiness, and then becomes non-admissible evidence in court.

Unreliable communication methods will directly affect admissibility of evi-

dence. It will cause more severe problems in the later stages of the tendering

process.

4.3.3 Tender Invitation and Submission Stage

This stage is the starting point of the contractual process and every step has

to be evidenced and be publicly verifiable. From Figure 4.2, we can see that

the principal should finalise its tender query documents, issue tender invitation,

organize pre-tender meetings and clarify any queries made by tenderers. Tender-

ers should prepare their tender documents and submit within the specified time

frame. After submission and deadline, the principal will reject the late tenders,

and open and record the submitted tenders.


Qualification & selection stage

Tenderer

?

Principal

?

�� SubmitQualification

-

?

Project definition

Compile preliminary list

?�� Issue preliminary

enquire�

?

�� Respond from

preliminary tenderer-

?

Compile draft &

reserve tender list

?

�� withdrawals if any -

?

Finalisetender list

?�� Inform those notinvited to tender

�

?�� Request those

invited for registration�

?next stage

�� Registration

for tendering-

Figure 4.1: Qualification & selection stage

The major documents generated in this stage contain tender documents pre-

pared by the principal, invitation, minutes of meetings, notes and reports of

evaluation committee, queries of tender documents, clarification of tender docu-

ments, rejections notes, logged information and tenderer submitted documents.

The principal has also added activities to handle these increasing amount of doc-

uments.

???This is the stage at which the principal and tenderers are engaged in the

contract process. Most of the security policies from stage one are carried to this

stage to ensure the basic reliability of forming legal admissible contract evidence.

The principal also needs to ensure that the digital signature scheme is used in

a proper way, the generated contract evidence is long term verifiable, and the

tenderer can submit sealed tender documents. These extra policies are to protect

against signature repudiation, key revocation and collusions.

We could assume that companies A, B, C and D are invited for tendering. All

these companies’ email addresses are stored in a list for automatic email sending

process. One of the tender board members is a friend of company D, and company

B is the strong business competitor to company D. The telephone is still a valid

communication channel and its contents are not recorded.


POLICY THREAT

Communication:Identify communication parties Masquerade, repudiation

Record time and date Time repudiation

Ensure communication privacy Eavesdropping

Ensure message original integrity Integrity violation

Documentation:Project description is accurate Misleading

Assessment:Assessing rules applied equally and fair Favour preferred tenderer

Tender lists compiled with only qualified tenderers Favour preferred tenderer

Document handling:Ensure same project definition distributed to all tenderers Favour preferred tenderers

Ensure document integrity Integrity violation

Ensure digital information authenticity Masquerade, authorisation violation

Ensure digital information confidentiality Confidentiality violation

Table 4.2: Security policy & threats of qualification & selection stage

This time the principal has secured its email communication, but the docu-

mentation and internal document handling still don’t meet the security require-

ments specified in Table 4.3. There are still many ways that company D could

drive B out of business. The tender documents prepared by the principal are the

first set of contract documents in this tender process, but its original integrity

is not calculated so the trustworthiness cannot be verified later on. There is an

amendment of the tender documents prepared by the principal after the inquiry

from company C. The friend of company D could delete company B’s email ad-

dress from the list without trace. When the board secretary send the emails to

tenderers, company B will not receive the notice of inquiry and document amend-

ment. The result is that company B has submitted a non-compliant tender and

its tender has been automatically rejected.

Company B later is informed about the amended tender documents from

company C, and sues the principal for misconduct, or unfair procedure and for

recovery of tendering costs. The principal will have difficulty in providing the

evidence of the reliability of its procedures that ensure its documents are properly

protected against integrity, authentication, and authorisation violations.

The friend of company D could also disclose company B’s price to company

D without trace, because the principal did not provide a digital seal submit-


Tender invitation & submission stage

Tenderer

?

Principal

?Finalise tender

enquiry documents

?�� Issue tenderinvitation

�

?

?

Prepare

Tenders

'

&

$

%Attend

pre-tender

meetings

&Query tender

documents

-��

'

&

$

%Organise

pre-tender

meetings

&Clarify

queries

?

�� Submittenders

-

Open & record

tenders

?�� Reject

later tenders�

?next stage

Figure 4.2: Tender invitation & submission stage

ting service, document access is not logged and telephone communication is not

recorded.

The unsecured system is not only unable to provide admissible evidence in

court, but also promotes collusion activities.

4.3.4 Tender Assessment Stage

At this stage, the principal has the full control of the assessment. In most cases

clarification of the contract terms requires post-tender negotiation. It may, in

turn, form collateral contracts as well. The strategy is to increase the account-

ability and transparency with public verifiability. The major activities involved

are assessing submitted tender documents, and performing post-tender negotia-

tion.

Figure 4.3 shows that for assessment, the principal needs to check each ten-

derer’s qualifications, evaluate compliant tenders and their alternative approaches.

After assessment, the principal can select a preferred tender, and next preferred


POLICY THREAT





Reliable digital signing process Repudiation, non admissible evidence

Documentation:Tender documents are accurate and conditions are fair Misleading

Ensure document’s original integrity Integrity violation

Document handling:Ensure tender documents distributed to all tenderers Favour preferred tenderers

Ensure tender documents are correct and trustworthy Integrity violation



Ensure tender documents, contract evidence, tender processlog are long term verifiable

Key revocation

Ensure all invitations are send at the same time Favourite tenderer get invitation earlier

Ensure all tender document enquires available to all tenderers Favour preferred tenderers

Ensure all tender clarifications and amendments of tender doc-uments available to all tenderers

Favour preferred tender

Publish enquire anonymously Mistakes

Tenderer submit sealed tender documents Collusion, disclose price, violate confiden-tiality

Table 4.3: Security policy & threats of tender invitation & submission stage

tender. For negotiation, the principal should negotiate with the preferred ten-

derer first. If the negotiation fails, it can then instigate negotiations with the

next preferred tenderer. The principal also needs to perform other activities,

such as rejecting non-compliant tenders, logging activities for handling digital

documents. Documents generated in this stage are rejection notices, evaluation

results, recorded negotiations, and other logged information.

As in the last two stages, this stage has to establish the same desired security

policies (Table 4.4). Therefore if somebody challenges the tendering procedure,

the principal is able to provide admissible evidence for public verification. For

contract negotiation, depending on what has been stated in the tendering docu-

ments prepared by the principal, this stage should also be able to assist parties

to distinguish different contract negotiation steps such as offer, counter offer and

acceptance for each contract term negotiated. Without completing the whole

contract negotiation cycle, some terms could be invalid, and liabilities can not be


Tender assessment stage

Tenderer

?

Principal

?Check tenderer’s

qualification

?��

��

Reject

non-compliant

tenders

�

?Evaluate

compliant tenders

&alternative approaches

&Interview tenderers

?Select preferred &

next preferred tender

?��

��Negotiate with

preferred tenderer

�

?

��


principal -

��

��Negotiate with next

preferred tenderer

�

?next stage

��


principal -

Figure 4.3: Tender assessment stage

enforced.

For example the principal may state that the floor covering of a chemistry

lab in the building should resist acid spills with two years warranty. The factory

only offers one year warranty with their floor covering normally used for this

purpose. Therefore, company D only offers a one year warranty. The principal

either unconditionally accepts D’s offer, or puts up a counter offer insisting on two

years warranty. It is now up to the company D to accept or reject the principal’s

counter offer. Before a decision can be made by company D, this term can not

be consolidated.

4.3.5 Tender Acceptance

This is the final stage of the tendering process, as well as a contracting process

for selecting main contractors. Steps involved are, the principal sends formal

acceptance to the winner and informs the unsuccessful tenderers. A successful

tenderer issues an acknowledgment to the principal on receipt of the acceptance.


POLICY THREAT





Post-tender negotiation only to confirm term conditions Collusion, price cutting

Contract term negotiation complete full cycle Contract terms dispute, repudiation


Documentation:Formalise each agreed term and sign Repudiation, dispute


Assessment:Applying weighing system equally Favour preferred tenderer

Compile preferred tender and next preferred tender from com-plied tenders

Favour preferred tenderer

Document handling:Principal open submitted tenders after deadline or when re-ceive all tenders

Violate open rules

Record tender open person, time and witnesses Violate open rules

No price change is allowed Integrity violation

Protect unauthorized information (tender designs) disclosure Violate confidentiality, copy right infringe-ment



Ensure submitted tender documents are correct and trustwor-thy

Integrity violation

Ensure tender documents, contract evidence, tender processreport and evidence are long term verifiable

Key revocation

Table 4.4: Security policy & threats of tender assessment stage

The principal prepares a formal record of the selection of the successful tenderer,

and draws formal contract evidence for both parties to sign using standard forms,

if they exist. The business flow has been highlighted in Figure 4.4.

Documents generated in this stage include formal acceptance notice, notifica-

tion and briefing of unsuccessful tenders, formal record of tender process, signed

contract evidence, and logged activities.

Security policies and common threats for this stage are summarized in Ta-

ble 4.5. From Table 4.5 we can see that this stage needs to possess most of the

basic security policy stated previously. The main requirement in this stage is to

form long term verifiable contract evidence. For example, the principal chooses


Tender acceptance stage

Tenderer Principal

?�� Notify

unsuccessful tender�

?

�� Acknowledge receiving

unsuccessful notice-�� Accept

successful tender�

?

�� Acknowledge receiving

successful notice-

?

Prepare

formal record&

drawcontract evidence

?�� Request on signing

contract evidence�� Return signed

contract evidence-

Figure 4.4: Tender acceptance stage

to use a digital signature to sign the contract evidence with PKI support, the

keys of which are revoked within two years. In this example, the floor cover in

the chemistry lab is an unconsolidated term. The previous stage did not provide

an alert to inform this term’s condition and final contract drawn up to accept

company D’s offer. The floor cover in the lab failed after one year in use, and

the principal seeks replacement from company D. It took one year for company

D to construct the building, and two years had passed when floor cover failed. A

dispute could occur, but neither negotiation evidence, nor final contract evidence

could be publicly verifiable, due to key revocation or key loss. In this case, there

will be no chance of having the floor cover replaced by company D.

4.3.6 Essential Security Mechanisms for Electronic Ten-

dering

Threats are potential violations of the security properties or polices required for

e-tendering. Security mechanisms are the technical tools for enforcing security

policies. The previous section discussed essential security policies for protection

against threats. The essential security mechanisms are suggested in Table 4.6, and

they can be used to protect against the major security threats of the e-tendering

system.

From previous tables we can see that some security requirements, and associ-

ated threats, are listed across many tendering stages, and action categories. Such


POLICY THREAT






Documentation:Prepare formal contract evidence signed by both par-ties

Repudiation

Prepare formal tender process report with evidence Procedural dispute, non transparent process


Document handling:Ensure contract evidence origin integrity Masquerade, integrity violation

Ensure tender documents, contract evidence, tenderprocess report and evidence are long term verifiable

Key revocation

Table 4.5: Security policy & threats of tender acceptance stage

threats include masquerading, eavesdropping, signature repudiation. They form

basic threats to the e-tendering system, and require the system to provide more

fundamental security services such as authentication, confidentiality, integrity,

reliable signature scheme. For example, an eavesdropper could monitor insecure

communication and gather valuable information. They could also use compro-

mised secrets to impersonate an authorised person, in order to steal confidential

information, or change document integrity.

With the emplacement of these basic security mechanisms, a system can pro-

vide more advanced security services, such as secret sharing schemes, to increase

the accountability of the tender board, and time chaining contract negotiations

and terms. These are also essential for a reliable e-tendering system.

For example an invalid contract term could occur in any of the following

cases: signed person not properly identified, original integrity violated, original

integrity not verifiable after key revocation, incorrect time sequence of evidence,

or contract process not completed. The first three cases can be prevented by

the basic security mechanisms of authentication, reliable signature scheme and

time stamp scheme. The last two cases, however, require the introduction of

more complex schemes, such as time stamped chain of contract negotiations and

consolidated terms.

In Section 2.4.3, we discussed security functions that have been implemented


THREATS SECURITY MECHANISMS

Basic:Masquerade Authentication

Eavesdropping Confidentiality

Signature repudiation Reliable signature scheme

Time repudiation Time stamp

Integrity violation Integrity

Authorisation violation Access control, security audit trail

Confidentiality violation Confidentiality, access control, security audit trail

Key revocation Time stamp

Advanced:Procedural dispute Time stamped chained evidence

Contract terms dispute Time stamped chained terms

Misleading Accountability

Favour preferred tenderer Form tender board with shared secret schemes to increase ac-countability

Non transparent process Public verifiability

Violate open rules Sealed bidding scheme, access control, security audit trail

Table 4.6: Common Threats & Essential Security Mechanisms

in some of the current systems. Using user name and password have the function

to identify communication parties. The digital signature can reduce the repudi-

ation threats. The e-tender box access control is not a simple issue which can

be protected by encryption only (see detailed discussion in Section 6.2.1). The

communication confidentiality is to be provided by using SSL or TLS. Apart from

these general practices, other identified security policies are not enforced by the

system.

4.4 Generic E-Tendering Security Requirements

Based on the mapping of potential threats to security policy and common threats

to security mechanism or functions, this section establishes generic security re-

quirements to be addressed in the design of secure e-tendering systems. However,

to establish security requirement of a system is a progressive process. This generic

security requirements serve as essential guidelines which are used to examine each

component of the system design. After this examination, more detailed security

requirements will be established for individual component of the e-tendering sys-

tem in the following chapters, such as components that preserve e-tender negoti-

4.4. Generic E-Tendering Security Requirements 81

ation integrity and e-tender submission.

This section will discuss the generic security requirements and possible generic

technical solutions. The more complex security solutions will be addressed in the

following chapters.

To summarize Table 4.6, generic security issues to be addressed are: Non-

repudiation, secure time, and secure record keeping.

4.4.1 Non-repudiation

Non-repudiation is proof or evidence that a particular action has taken place.

It protects against denial by a participating party, can be an extension of the

authentication process and ensures that the originator of a message cannot deny

having sent it, ??? this includes the message sent and the response to receipt of

the message.

Non-repudiation is critical in most electronic commerce applications. In the

e-tendering process, non-repudiation is required to ensure that the principal can-

not deny that it has advertised the tender specification documents or awarded the

winning tender. Non-repudiation should also be used to ensure that each autho-

rised pre-qualified tenderer cannot deny their submitted tender offer document.

Non-repudiation is usually implemented through the use of a digitally signed

message. Digitally signed messages can be as legally binding as physical sig-

natures. Public key cryptography enables the use of digital signatures. In an

e-tendering system, the digital signature mechanism [38, 41, 90], can provide au-

thentication and non-repudiation. E-Tendering system design should include a

public key infrastructure to support a digital signature mechanism.

4.4.2 Secure Time

The security of an e-tendering system relies crucially on the recording of the date

and time at which events occur within the system, as well as on the compliance

to agreed timelines. This is particularly important at the close of tender as late

tenders may be deemed to be nonconforming. There are three main areas of

concern relating to secure time: Time integrity, the closing and opening of the

e-tender box and the time of receipt of electronic communications.


Time Integrity

In e-tendering, it is important to establish when key events occur. The integrity

of timestamps for the e-tendering process can be provided by a time stamping

mechanism [51, 19, 108], which associates a date and time to a system event. An

example of this event is the receipt of an electronic document or the opening of the

e-tender box. The evidentiary value of recorded temporal information depends

on the technical assurance that derives from both the particular choice of time

stamping mechanism and from correct deployment and maintenance.

The first option for time stamping an event is to generate a log record that

includes a description of the event and the time of occurrence as measured by

the clock of the local host computer. A second option involves using a digital

time stamping service that associates date and time information to electronic

documents in a cryptographic manner. Digital time stamping services are usually

provided by third parties. The third party digital time-stamping provides a high

level of assurance with respect to the authenticity and integrity of time stamped

documents. However they incur high overhead costs of running or contracting the

service. They also presuppose the existence of a public key infrastructure. There

already exist standards for digital time stamping [104, 103] as well as commercial

digital time stamping service providers 1.

Closing or Opening Time of E-tender Box

The closing time for e-tender submission and the opening time of the e-tender

box are critical from both a legal and security point of view. No tender submis-

sions should be allowed after the stipulated closing time. In order to mitigate the

threat of insider collusions, submitted tenders should not be opened before the

established opening time, which must be set to be after submission closing time.

There may be situations when deadlines need to be extended in response to extra-

ordinary circumstances, such as when due to technical failure of the e-tendering

system tenderers have been unable to submit tenders for a prolonged period. The

e-tendering system should ensure that the functionality for extending submission

deadlines is only available to authorised parties.

A submission closing time and a reasonable transmission time frame need to

be clearly stated in tender specification. A tender submission should be initiated

before the closing time and completed within this reasonable time frame. A time

1http://www.digistamp.co and www.e-timestamp.com.au


synchronisation mechanism needs to be in place. Sometimes there are multiple

tender boxes, both electronic or physical. Synchronisation of electronic boxes

can be achieved using time synchronisation protocols, such as NTP [102], which

afford high accuracy and cryptographic authentication.

For the control of e-tender box opening time, there are a variety of technical

mechanisms that can be considered in order to protect the confidentiality of

submitted tenders until the pre-accorded opening time. There are two types

relevant mechanisms, ordinary access control mechanisms and encryption-based

access control mechanisms.

Ordinary access control mechanisms rely on the access control policies en-

forced by the operating system that stores the documents. Such a mechanism

would typically allow the e-tendering application to limit access to tender sub-

missions to specific users (e.g. users with the role of evaluator for a given tender).

Unfortunately, it does not prevent authorised users from accessing tenders before

submission closing time; it merely aims to detect and record such access.

Encryption-based access control mechanisms protect against the main secu-

rity threat posed by inside attackers to the e-tender box. The use of encryption

appears to be a more suitable mechanism for protecting submitted tenders. The

tender or offer will be encrypted and stored as encrypted before opening time.

Even if an insider manages to get access to the submitted tender files, no in-

formation will be revealed. The control of decryption key releasing time can be

achieved by many technologies such as time vault service [21] using pairing based

encryption.

Time of Receipt of Electronic Communications

From a legal point of view, in case of litigation, it is important to know when a

communication was recieved by the system. A clear definition of time-of-receipt

for communications that occur as part an e-tendering process is required. For

email based communication clarification of time of receipt is required as there

may be a delay between when the message is sent and when the receiver reads the

message. When using slow communication links there needs to be clarification

as to whether time of receipt should be recorded at the beginning of the file

transfer or whether the time of receipt should be recorded when the file transfer

is complete.


4.4.3 Secure Record-keeping

E-tendering systems generate and process electronic documents that are part of

business activities and hence need to be preserved as records within a record

keeping system in order to comply with relevant legislation and standards. A

key legal requirement for recordkeeping is the preservation of the evidentiary

integrity of records, both documents and contextual data; this poses a major

technical challenge in an electronic environment.

The Standards Australia (HB171-2003) has provided “Guidelines for the man-

agement of IT evidence”. In the respect of maximising the evidentiary weight of

electronic records, an e-tendering system needs to ensure that evidentially signif-

icant electronic records are identified, are available and are usable; identify the

author of electronic records; establish the time and date of creation or alteration;

establish the authenticity of electronic records; and establish the reliability of

computer programs.

A detailed assessment of the electronic information within an e-tendering sys-

tem that has evidentiary value needs to be performed. Such assessment should

employ a risk management approach, taking into account the likelihood of a

record being used for evidentiary purposes together with the severity of the con-

sequence of the record not being accepted as evidence. The following e-tendering

documents are important evidential material: tenderer document submissions;

tender specification and addenda produced by the principal; tender revocation

notices submitted by tenderers; negotiation communications post tender close

time; request for explanation communications pre-tender close time; award of

tender announcement; and any receipt of message acknowledgments.

When determining the evidentiary weight of a record, it may be necessary to

demonstrate that the software that generated the record was operating correctly.

Assuring high levels of reliability of complex information systems is a difficult and

expensive engineering task. It requires methodological design and deployment,

as well as detailed evaluation. A number of strategies can be taken to enhance

the demonstrable reliability of the software in relation to the evidential value

of records. The first strategy involves identifying and isolating the functionality

within the e-tendering system on which the evidential value of the record relies.

Another strategy involves using certified products which are assessed by an ac-

credited body according to the existing security evaluation standards [30, 60].

Finally, the use of trusted operating systems, such as Sun Trusted Solaris of Sun


Microsystems Inc. 1, provides strong assurance of the operating system’s access

control mechanisms.

4.4.4 E-tendering System Security

The section discusses how security mechanisms can be better addressed at a sys-

tem design level. Existing e-tendering systems have been classified into two types

(Section 2.4): the principal-based and the TTP-based. The following analysis

shows that it is better the system security to be addressed by distributed trusted

security services for both principal-based and TTP-based e-tendering systems.

These trusted security services are provided by multiple specialized trusted third

parties.

In the following discussion, we assume that each e-tendering system has the

ability to address generic security issues such as using trusted operating systems

and apply suitable mechanisms for access control. The analysis will be focused on

deriving preferred practice rather than producing a system architectural design.

Principal-Based System

The principal-based system has been discussed in Section 2.4.1. This system

places a great deal of trust in the principal. Tenderers place their trust in the ac-

cess control system employed by the principal to ensure that collusion or internal

malfeasance by the principal’s users is difficult. The principal must also develop a

scheme for verifying the identity of, and authenticating documents from, the ten-

derers. To achieve this, the principal may have to, for example, run a certificate

authority, issue certificates and conduct a cryptographic key generation process

with tenderers when they complete the pre-qualification process. The principal

may also be responsible for providing a standard time service for the e-tendering

process.

In summary principal-based systems depend on the principal enforcing and

maintaining the essential e-tendering requirements of non-repudiation and au-

thentication, secure time and secure record keeping.

1http://www.sun.com/software/security/blueprints/


Trusted Third Party Based System

In a TTP-based system (in Section 2.4.2), the TTP holds all documents during the

tender process. It then became the TTP’s responsibility to secure the storage and

archiving of documents after the tender has been awarded. Like the principal in

the principal-based system, the TTP is responsible for authentication of all parties

in the system. To enable this, the TTP may have to act as a certificate authority

issuing certificates and cryptographic keys to the principal and tenderers.

The TTP may also have to act as a secure time server. The principal and ten-

derers should synchronise their clocks with the time published by the TTP. Thus

in the TTP-based system the TTP entity is responsible for enforcing and main-

taining the e-tendering security requirements of non-repudiation, authentication,

secure time and record keeping.

Distributed Security Services E-tendering System

CASTS

Tenderer

Tenderer

Tim

e Syn

chro

nise

Ser

vice

Time Synchronise Service

E−Tender Communications

Service Cluster

Key registration &CertificateVerification

Key Reg

istrat

ion & Cert

ificate

Veri

ficati

on

Principal

Figure 4.5: Distributed Security Service Principal-Based System

The distributed security services system (Figure 4.5) uses distributed TTPs to

provide specialized security services such as the secure time server (STS) and the

certificate authority (CA). The STS performs two functions, time synchronisation

and time controlled key release for accessing submitted tenders. The CA has

the function of key registration and key verification. These are separate TTPs

although both these services may be provided by the same entity. Because of

the separation of these roles this system lends itself to a large scale e-tendering

implementation.


Unlike the TTP-based system, the distributed TTP does not host the e-tender

box, but only provides security services to protect e-tendering process integrity.

This distributed trusted third party architecture is a suitable framework for the

implementation of e-tender systems proposed in Chapter 6. For providing ade-

quate security services, submission protocols require timestamp, distributed iden-

tity based key generation services, and certificate verification services.

STS

TTP

Tenderer

Tenderer

Principal

Principal

CA

Key R

egist

ration

& C

ertifi

cate

Verific

ation

Time S

ynch

ronise

Service

Time Synchronise Service

Key registration &CertificateVerification

E−Tender Communications

Service Cluster

Figure 4.6: Distributed Security Service TTP-Based System

Trust Between E-Tendering Participants

In a principal-based system, tenderers must put their full trust in the principal,

therefore employees of the principal have the potential to manipulate the system.

For a TTP-based system, both tenderers and principals must put their full trust

in the TTP, the service provider. For example, both principal and tenderers have

to trust the third party to store their confidential documents, such as bidding

strategy. This is an uncomfortable situation for many companies, particularly

government entities. However, the TTP-based system may reduce the principal’s

capacity for collusion or internal malfeasance of the system.

A key question is the impartiality of the TTP. The principal is in a position to

choose which third party’s system to use, and tenderers are forced to go along with

the decision. It is obvious that principals will have a more favourable relationship

with the TTP than any tenderers in the process.

The trust in the distributed TTP system is shared and inter-controlled by

separate TTPs. It minimises the reliance on one party thus reducing the chance of


collusion and single point failure problems. Also the documents for each tendering

project do not have to be stored on a third party system.

CA and STS are specialized security services in controlling of key registration,

certificate verification and opening time of submitted tender document. These se-

curity functions address security issues discussed at the beginning of this section,

improve process integrity and increase evidential weight in e-tendering process.

In the distributed TTP architecture, the privilege of controlling these security

services has been separated from the parties who host the e-tendering business

process, principal or single TTP. Tenderers could have the opportunity to choose

the service provider without affecting their ability to tender for a project. The

CA and STS in the distributed TTP architecture are more impartial than the

TTP in existing systems.

The use of an impartial TTP as a certificate authority (CA) allows for a more

trustworthy authentication and identification system. The implementation of

public key infrastructure allows for the user of digital signatures to provide non-

repudiation of documents, although this solution is available for all architectures.

An impartial STS allows parties to be sure that the time cannot be changed to

suit the principal or a malicious tenderer.

Scalability

Widespread use of a TTP-based system for e-tendering would reduce costs sig-

nificantly over a scenario where every principal implemented their own system.

A reduction in the number and variety of systems would create cost savings in

system development and maintenance, and through standardisation, reduce mon-

itoring and regulation costs to government.

However, as all documents are no longer stored locally (on the principal or

tenderer systems), accessing these documents on the TTP-based system would

generate additional traffic over that in the principal based tendering process.

For the distributed TTP architecture, this design can be easily integrated

into current systems for both principal and TTP based systems. Other security

mechanisms can be added on in the future by using more specialized TTPs. Each

party can focus on its speciality. The e-tendering business process system can

be standardised and developed as universal software for commercial sale. The

security services can be developed and modifed to suit local legal and security

requirements.

4.5. Summary 89

4.5 Summary

The benefit of using an e-tendering system derives from strategically integrating

the appropriate security mechanisms to provide the desired security service and

efficiency.

The traditional tendering system relies on transparency to achieve equity.

Because of the need for confidentiality, the transparency of the tendering process

is low. The confidentiality mechanisms can increase the public verifiability of

information without revealing the content. The e-tendering system can increase

public verifiability to enhance its transparency, thereby achieving greater equity

and economy for the principal.

At a practical level, the traditional tendering procedure is vulnerable to abuse

[105, 7]. One common collusion is for the tenderer to induce an insider either to

give special consideration to its offer and/ or or to reveal a competitor’s offer.

The traditional practice to guard against this type of collusion, is to use a public

tender box with two locks to seal the submitted tenders. Many cryptographic

sealed bid schemes have been developed for e-auction [88]. Due to different types

of collusions in e-tender and e-auction, it could be difficult to adopt e-auction

solutions directly for e-tendering. The differences between e-tender and e-auction

have been discussed in Section 2.3.3.

A signature scheme with PKI can ensure evidence origin integrity, but does

not detect integrity violation after the key has been revoked. With combined

schemes (checking identification, ensuring that contract process is complete, re-

liable signature procedure, time-stamp for long term verifiability) the original

integrity of contract evidence can be protected and subsequent integrity violation

can be detected.

Chained and time-stamped contract terms and its negotiations, and tender-

ing activities will improve the system reliability, reduce disputes, and increase

individual accountability. This can be designed to automatically generate legally

admissible time sequenced evidence for formal report writing, and to draw up

formal contract evidence.

Access control and security audit trails increase system security for account-

ability, however it does not stop, for example, authorized users accessing e-tender

submission before opening time.

As the discussion shows, a simple ad-hoc cryptographic mechanism will not

eliminate the possible threats existing in the e-tendering system, and will not


meet legal requirements for the e-contracting process. The reason is that: all

cryptographic mechanisms are designed for generic purpose with functional lim-

itations. Each business process is different from another. For example, most

potential threats to the e-tender system are from inside users abusing the process

to gain personal benefit.

Two significant issues have to be addressed for the e-tendering system:

1. How to preserve e-tender process integrity and generate reliable evidence

for communicated messages, for example, offer and acceptance of the offer;

2. How to stop internal common collusion such as a principal releasing other

tenderer’s tender submission to its favourite tenderer.

Technically, these issues have to be addressed with advanced security mech-

anisms or protocols to provide complex security services. The generic security

mechanisms have to be carefully integrated into the system to provide desirable

security services for the complex contract processes involved in an e-tendering

system.

The following two chapters contribute by establishing methodologies for de-

signing protocols that provide complex security services. The methodology will

be used to develop two protocol suites: to maintain e-tender negotiation integrity

and to secure the e-tender submission box.

Chapter 5


Negotiation Integrity

“If security engineering has a unifying theme, it is the study of security

protocols”

— Ross Anderson

An unprotected electronic transaction is not automatically equivalent to a

paper based transaction. In many respects, an unprotected electronic document

does not necessarily perform all conceivable functions of a paper document, such

as maintaining the integrity of the contents, or satisfying signature requirements

[4]. These functional differences need to be identified and analysed in the context

of e-tendering, to determine how those purposes or functions in the traditional

process could be fulfilled through secure e-tendering protocols, in which security

mechanisms are added to safeguard the electronic medium.

This chapter will analyze functions of traditional tender negotiation, derive

security requirements to maintain e-tender negotiation integrity and discuss the

functional limitations of generic cryptographic technologies when applied to pro-

tocol suite construction. The Secure E-Tender Negotiation Integrity Protocol

(EtenderNI) suite will then be constructed, and its security will be analyzed

informally and tool assisted formal method with the Simple Homorphism Verifi-

cation Tool (SHVT).

91

92 Chapter 5. Secure Electronic Tendering Negotiation Integrity

The information is organized as: 5.2 Security Requirements; 5.3 Related Tech-

nology and Application Issues; 5.4 Secure Electronic Tendering Negotiation In-

tegrity; 5.5 Protocol Analysis Issues; 5.6 Informal Analysis of EtenderNI Protocol;

5.7 Formal Specification of EtenderNI Protocol Suite;

5.1 Introduction

As a special contracting process, the traditional tendering procedure is designed

to facilitate the forming of a valid contract between contracting parties as an

outcome. In general, the contracting terms, including tendering terms, are gen-

erated when the principal distributes the tender document (TD) and the invi-

tation for tender to all potential tenderers, as discussed in Section 2.1.3. The

subsequent steps involved are tender document clarification, tender preparation,

tender submission, tender assessment, post tender negotiation and signing of the

final contract. The communication for contracting could take any such form: an

invitation, offer, clarification, amendment, acceptance or signing final contract.

After potential tenderers receive the tender document and the formal invita-

tion from the principal, they can each send anonymous requests to the principal

for clarification of the tender document. The request and clarification or amend-

ment are distributed among all tenderers. Tenderers will prepare their tender

according to the guidelines or requirements from the tender document. After

tenderers submit their tenders, the principal will undertake assessment to choose

the first preferred tender for post tender negotiation. A successful negotiation

will lead to awarding the contract and signing the final contract.

A contract is formed through interactive communication in the tendering

process, in which offers, acceptances and intention of entering contract are sent

to the other contracting party for consideration. Tendering negotiation is a con-

tract negotiation, and the tendering process is entering into a sales contract [105].

Legally enforceable contract evidence is the primary means of assessing both the

validity of a contract and fair trading practice. Because of its legal significance,

electronic communication and its record keeping have become primary targets for

attackers. The management of electronic documents as legal evidence has been

discussed in Section 4.4.3.

5.2. Security Requirements 93

5.2 Security Requirements

This section covers the analysis of functional differences between paper and elec-

tronic based communications and documents, and security requirements for de-

signing secure negotiation for e-tendering system.

5.2.1 Functional Differences

Many contracting related written documents can be generated during the ten-

der negotiation period. They have been used for recording tender documents

prepared by the principal, tender invitation, tender document addenda, minutes

of meetings, submitted tenders, reports of tender evaluation or assessment, ten-

der rejection, tender award or the final contract formed between principal and

winning tenderer.

One of the fundamental purposes of written documents in the contracting

process is permanence and the capability of being referred to by the parties at

a later time, because individual memory is considered to be unreliable and oral

promises, impermanent [26].

The functions of paper documents in tendering should be able to serve any of

the following purposes: to ensure that a record would be legible by all; to ensure

that a record would remain unaltered over time; to allow for the reproduction

of a document so that each party would hold a copy of the same data; to allow

for the authentication of data by means of a signature; and to provide that a

document would be in a form acceptable to public authorities and courts. The

contracting legal framework discussed by Christensen [25] has indicated that not

only the communicated contracting evidence needs to be kept in the form it was

when first generated, but also in correct order to reflect the sequence of offers,

acceptances, and counter offers.

Illegal activities form threats that could significantly compromise the legiti-

macy of the contracting process in e-tendering. The use of unguarded electronic

transactions opens up the following potential common threats for e-tendering:

masquerade, repudiation, time and signature repudiation, eavesdropping, in-

tegrity violation. These can also cause procedural dispute. Protocol related

attacks are also threats to the contracting process and may result in unfair trad-

ing.

It is these potential threats that compromise electronic transactions in per-


forming to the same level of security as paper based processes, causing functional

differences between paper and electronic transactions.

5.2.2 Threats and Security Requirements

??? There is a need to review the security threats that relate specifically to

e-tendering negotiations. Security threats occur in the following areas for e-

tendering negotiations.

Breach of confidentiality If no adequate security mechanisms are in place,

both the electronic communication and documents are viewable by the pub-

lic or attackers.

Repudiation Unless the identification of a sender and the integrity of its sent in-

formation are assured, both repudiation and unauthorised electronic trans-

action can occur complicating an e-tendering process.

Breach of integrity The lack of integrity verification mechanisms will allow the

alteration of electronic documents to pass undetected. This can affect the

integrity of a contract formed by an e-tendering process.

Unfairness A system design fault or failure could allow one party to exploit the

system and gain advantage over other parties in an e-tendering system.

These threats, if they occur, could reduce the evidential weight of the material

in a contract dispute. Detailed discussion of threats to the tendering process can

also be found in Section 4.3

Considering the legal significance and existing common threats, we need to

ensure that electronic communication is conducted within a legal framework, and

the communicated contracting evidence is managed as a legal record with special

consideration to its integrity. This digital record has to be publicly verifiable at

a later time to demonstrate that it contains a complete and uncorrupted set of

evidence of the e-tendering process.

In reference to the common threats toward the functions of electronic doc-

uments, the following security requirements have been established to provide a

reliable method of electronic communication and method of record keeping of

data messages created during e-tender negotiation.

5.2. Security Requirements 95

Confidentiality Confidentiality means that only the e-contracting parties are

privy to the information related to the contract negotiation, to ensure

their privacy. Providing a confidentiality service is a general requirement

throughout the whole tendering practice. It is to prevent unauthorized re-

lease of the tenderer strategy, design and other private information. This

type of information leak could lead to a criminal offense in trading prac-

tice. This property eliminates any opportunity for an eavesdropper to gain

access to any confidential information communicated between contracting

parties.

Data Origin Authentication Data origin authentication means that the party

receiving a message can confirm the identity of the party originating the

message in a contracting process. This property also implicitly provides

an assurance of message integrity [81]. The data origin authentication en-

sures that the e-contracting evidence (proof of a valid and binding contract)

is trustworthy when it is first generated. It involves binding the message

originating party to the message to prevent repudiation, message replay,

and impersonation attacks. It also provides confirmation of the message’s

original integrity.

The data origin authentication has stronger meaning than usual meaning

of authentication. In particular non-repudiation is usually not implied by

authentication, because in contrast to non-repudiation the establishment of

authentication usually does not imply the existence of evidence to be shown

to others.

The validity of an e-contract requires that it demonstrate that it has been

formed within the legal framework. One party must have made an offer,

that offer must have been accepted by another party in unequivocal terms,

and that acceptance must be communicated to the first party. Both parties

are required to have the intention to create this legal relationship under

contract law principles.

Traditionally, valid and binding contract evidence relies on the assumption

that parties can visually identify each other through the signing process. In

contrast, this assumption does not apply when parties communicate through

the Internet. Therefore, this property is required to be in place to provide

a functional equivalent practice in the digital world. It is aimed against


masquerading attacks, and eliminates signature repudiation.

Original Integrity Confirmation Original integrity confirmation means that

original contract evidence integrity can be confirmed and any alteration can

be detected. This service is to ensure that the original integrity of informa-

tion related to a contract is effectively preserved and this integrity is verifi-

able at any given time. The important evidentiary material in e-tendering

and guidelines of secure record keeping are discussed in Section 4.4.3. A key

requirement for record keeping is preserving the original integrity of records

both documents and contextual data [36].

Contracting evidence is generated chronologically through parties’ commu-

nication. The original integrity confirmation property is used to prove

whether or not the contracting evidence can be used in a chronological

reconstruction of the original e-contracting negotiations. This property re-

quires the protocol to provide a security service to prevent the contracting

evidence from being deleted, altered or re-sequenced after generation, and

to prevent the insertion of fake evidence. The achievement of this security

property can also create a barrier to deliberate time and signature repudi-

ations.

System Reliability A new protocol is a unique set of cryptographic procedures

for a special business process. It is constructed with cryptographic prim-

itives or building blocks to provide conventional security services as dis-

cussed above. There are always unavoidable protocol disruptions related

to the business process, which the protocol is modeling. These disruptions

can be protocol attacks, or simply that the business itself can not proceed.

The protocol disruption protection will discuss alternative solutions for

identified protocol disruptions. There are two types of disruptions in the

contracting process (1) normal termination (terminate negotiation) from

one party; (2) abnormal behavior from either one or both parties. This

property ensures that normal disputes can be easily resolved and that one

party cannot use the protocol algorithm to gain advantage over the other

party.

5.3. Related Technology and Application Issues 97

Chain Node 2

Chain Node 1

Chain Node 0Hash

Hash

Hash

Hash

HashEvidential Material n

Evidential Material n−1

Evidential Material 2

Evidential Material 1

Tender SpecificationE

vide

ntia

l Mat

eria

l − re

cord

ing

tend

erin

g ev

ents

in c

hron

olog

ical

ord

er

Time

Chain Node n−1

Chain Node n

Figure 5.1: Chaining Evidential Material in E-tendering

5.3 Related Technology and Application Issues

The contracting process in e-tendering is a sequential process. Chaining con-

tract negotiations and agreed terms have been identified as one of the advanced

essential security services for an effective legal record management in a reliable

e-tendering process (in Section 4.4 and in Table 4.6). One way function chaining

is a suitable technique for providing this type of integrity service. The most pop-

ular chaining technology is the hash chain constructed by using an cryptographic

hash function, such as iterative hash functions. The hash chain algorithm (de-

scribed in Section 3.1.2) is one of the most suitable technology to be integrated

into electronic communication for preserving e-tendering integrity.

Figure 5.1 demonstrates that the hash chain for an e-tendering process can

be formed by:

• generating chain node 0 from tender specification

• forming chain node 1 using evidential material 1 and chain node 0


• forming subsequent chain node n using evidential material n and chain node

n− 1

Generation of the current hash chain node requires input from the previous

chain node. The evidential material integrity can be verified using the formed

hash chain because an alteration of any evidential material can be detected by

the verification process. Section 3.1.2 also stated that this dependency forms a

strong security property to protect the order of events generated through contract

negotiations in e-tendering.

However, without the effective integrity protection of a hash chain, it cannot

be a reliable checksum to provide an integrity confirmation service for the original

information. Some applications such as time-stamp [51], payment systems [6, 91],

audit log systems [68] have demonstrated that a hash chain can be used with

other algorithms (eg. digital signatures) to provide desired security services for

a particular business situation. Each application of hash chains has a different

chain forming process according to the business process it is emulating. The

chain protecting algorithms (normally signature schemes) are also constructed

in a different way to protect against particular attacks related to the business

process.

Among all these hash chain applications, the time-stamp scheme by Haber and

Stornetta [51] emulates the closest business process to the contracting process in e-

tendering. They have combined signature and one way hash techniques to prevent

the time-stamping service from issuing a fake time stamp. In their scenario, a

trusted third party provides a time-stamping service (notary system). Their basic

idea is to link a current time-stamping request (hashed message) with a previous

request by using one way hash functions to form a linking node. This node is

also signed by the time-stamp service and sent to each requester.

Their scheme is designed for a random client to make a request to a trusted

third party which provides the time-stamping service. In e-tendering, communi-

cations are complex and every contract related communication bears evidential

weight. It is a very expensive exercise for the contracting parties to make time-

stamping requests on every one of their communications.

For example, the principal and all potential tenderers could use this type

of time-stamp service through their possibly half-year long contracting process.

Their contracting evidence would be mixed with all other requests. The verifying

process would involve all intermediate parties cooperation to confirm the integrity

5.4. Secure Electronic Tendering Negotiation Integrity 99

of their evidence on the chain. It would be very difficult to reconstruct the e-

tendering contracting evidence set when a dispute occurs.

A complete adoption of time-stamp scheme faces expensive interaction with a

third party. Additionally it needs complicated verifying algorithms to reconstruct

legal evidence for a complex contracting process in e-tendering.

A protected chain forming process is still open to some protocol attacks, such

that both parties can manipulate the last node of the chain. In this situation,

trust is an issue when parties attempt to use dishonest protocol operation to

gain an advantage over the other party. The introduction of a trusted third

party may be necessary for e-tendering protocols. The protocol suite will focus

on modeling traditional contracting procedures to avoid exposing protocols to

traditional attacks.

5.4 Secure Electronic Tendering Negotiation

Integrity

We present a secure communication protocol as the security framework (foun-

dation) for our first layer of a secure e-tendering scheme. This protocol suite is

focused on securing the communication and record keeping related to the con-

tracting process in e-tendering. The protocol considers how to (1) ensure that

an e-contract communication or negotiation is conducted within a legal security

requirement, (2) preserve sequentially generated e-contract evidence integrity ef-

fectively by using chaining technology.

This section is organized into four subsections to discuss notation, system

setup and the cryptographic scheme. All contracting stages require some special

security properties and consideration other than the underlying communication

security properties. The following scheme is the framework for the e-tendering

process, and only considers providing the security service for secure e-contracting

communications and its related evidence.

5.4.1 Notation and System Setup

All the notation used in this chapter are listed in Table 5.2.

Parties involved in e-contracting are the principal(A), tenderers group (B)

or tenderer (B), and trusted third party TTP . All parties have their private,


SYMBOL NAME

−→ One party sends another party a message eg. B −→ A, B send A

‖ Concatenation

PrivID Private key of party ID eg. PrivB , B’s private key

PubID Public key of party ID

CID Certificate of party ID

h Secure hash function

Sig Signature generation function

V Signature verifying function

Ex Asymmetrical encryption function, x represents input key

Dx Asymmetrical decryption function, x represents input key

mn nth communicated message of a contract negotiation

TD Tender Document by principal

HCID One party’s entire hash chain or TTP rolled back hash chain

DS Start of dispute

TM Start of termination

RTM Respond of the termination

mcf Confirmation message generated by TTP

mer Error message generated by TTP

Figure 5.2: Notation1

public key pairs and certificates for their public keys. All private keys are secure

and have not been compromised. We assume that the local area Public Key

Infrastructure is in place for tendering process.

All the communication methods used in contracting (phone, email, web sub-

mission...) are logged.

TD is the Tender Document. The initial chain root node L0 is always gener-

ated by the principal A with TD.

The preferred one way hash function should be a current recommended cryp-

tographic hash function (SHA-2 family such as SHA-256 or SHA-512, at time of

writing in Section 3.1.2) or an equivalently well established one way hash func-

tion. The asymmetrical encryption refers to the standard public key systems

[81, 65], discussed in Section 3.1.3. The signature algorithm should use standard

schemes such as ElGamal [41], RSA [90] or ECDSA [65] since their security has

been widely discussed in the past. The security issues relating to the use of digital

signatures are discussed in Section 3.1.4. If either party’s key pair is compromised

or revoked during the contract negotiation period (an exceptional condition), all

the hash chain nodes have to be re-signed by both parties.


Engage TTP

Termination

NegotiationStage

Final Stage

Main Group Protocol Protection Group

Dispute

Figure 5.3: Electronic Tendering Secure Communication Protocols

5.4.2 Secure E-tendering Negotiation Integrity Protocol

Suite (EtenderNI)

The protocol contains five sub protocols showed in Figure 5.3. The Negoti-

ation Stage, and Final Stage Protocols are main communication protocols for

e-tendering. The Dispute, Termination and Engage TTP are error control pro-

tocols. Their relationships are also shown in Figure 5.3. The arrows in the

Figure 5.3 represent directions of connectivities. ??? There is an assumption

that the content of message is checked by each party to ensure that it belongs to

the current and correct tender.

During the e-tendering process, the principal will initiate the negotiation pro-

tocol (Figure 5.5) and the parties will proceed with the communication using the

negotiation protocol. When the final contract is formed, both parties will enter

the final protocol (Figure 5.6) to close their e-tendering communication with the

trusted third party as witness.

If there is a dispute over the hash chain integrity, any party can connect to

the dispute protocol. The dispute protocol contains two sub-protocols, Dispute

I (Figure 5.7) and Dispute II (Figure 5.8). If the responding party agrees with

the hash chain integrity from the initiating party, these parties will enter into the

Dispute I Protocol. From the Dispute I Protocol, the communicating parties can

switch back to the Negotiation Stage Protocol or connect to the Engage TTP

Protocol (Figure 5.10) depending on the parties responses. If the responding

party disagrees with the hash chain integrity from the initiating party, these


Chain Node 4

Chain Node 3

Chain Node 2

Chain Node 1

Chain Node 0mini cycle of E−TenderNegotiation Protocol

mini cycle of E−TenderNegotiation Protocol




Award Tender

Post TenderCommunication

Tender Offer

Addendum

Tender Specification

Time

Figure 5.4: E-Tender Negotiation Protocol - chaining evidence

parties will enter into the Dispute II Protocol. From the Dispute II Protocol, the

parties can formally terminate the communication with the Termination Protocol

(Figure 5.9) or the Engage TTP Protocol.

The termination protocol can be directly connected to through the negotiation

protocol, in order to stop the parties’ formal communication with the TTP , before

the final stage. This modular architecture is designed such that it can link to

other security modules in future work.

E-Tender Negotiation Protocol

Tenderers and principal will, in turn, use the E-Tender Negotiation Protocol (Fig-

ure 5.5) to exchange their tender negotiation messages up to the point when the

final formal contract can be formed. The messages can be of any type: tender

clarification, tender submission, tender assessment result, post tender negotia-

tions and award tender. Figure 5.4 shows how to use the E-Tender Negotiation

Protocol to preserve process integrity.

In the protocol initial stage, the principal will initialise the record keeping


hash chain by generating the root node. The principal first creates the Tender

Document. This document may include a project description, tender specifica-

tion, and weighting system. Principal A calculates the root node L0 at the start

of the contracting process with its Tender Document as the first message, and

makes it available to the potential tenderers group B.

The principal uses tender documents as the input of h hash function to gener-

ate L0 as the first step. It then uses its private key PrivA and signature function

Sig to produce its signature σA over root node L0. The principal also encrypts the

tender documents and its signature using the public key PubB and concatenates

its certificate CA to produce the M0 for sending to a tenderer over an insecure

network.

After the tenderers receive the Tender Document, for example, during the

post tender negotiation stage, the process of nth negotiation message from B to

A is listed in Figure 5.5.

A BLn = h(mn‖Ln−1)

σnB = Sig(Ln, P rivB)

Mn = EPubA(mn‖σnB)‖CB

Mn←−(mn‖σnB) = DPrivA

(Mn)

Ln = h(mn‖Ln−1)

if VPubB(σnB , Ln) = 1

σnA = SigPrivA(Ln)

RSPn = EPubB(σnA)‖CA

RSPn−→if VPubB

(σnB , Ln) 6= 1

do not send RSP trigger Mn resend

(σnA) = DPrivB(RSP )

if VPubA(σnA, Ln) = 1

one mini cycle finished

Figure 5.5: E-Tender Negotiation Protocol

In this stage, the sender B concatenates mn‖Ln−1 as input of h to generate

the nth node Ln. B then signs the node with its private key PrivB to produce its

signature σnB over Ln. It also binds its commitment to the message. B encrypts

mn‖σnB with A’s public key PubA, concatenates CB and sends the encrypted

message Mn to A.

On receiving the message Mn, A decrypts the message Mn with its private


key PrivA, extracts the nth node Ln using B’s public key PubB, and checks B’s

certificate CB. A calculates the nth node L′n itself by concatenating mn and the

previous node Ln−1 as the input of the one way hash function h. At this stage A

can compare whether L′n = Ln to confirm message integrity. If L′n = Ln, A will

sign the Ln and send RSP to B. If L′n 6= Ln, A will not send RSP . It will trigger

B to re-send Mn to A. Both parties also have the option to start the Disruption

Protection Protocol.

In the last section of protocol, the party that receives this RSP will verify

the contents.

Final Stage Protocol

When the final node Lf is generated after both parties have signed the final

formal contract, they need to send the final node to the TTP for long term

preservation of the contracting evidence. The TTP normally will have a more

secure environment than the communicating parties. The TTP can have longer

lived keys, less vulnerabilities in the system, and better facilities for key updates

and upgrades to re-sign the documents.

This stage is to confirm that both parties have agreed on the final contract.

TTP is the witness. This stage’s protocol is listed in Figure 5.6.

Both parties A and B have to sign the final node Lf . Signatures σfA and σfB

are encrypted with the public key PubTTP of TTP , then the encrypted messages

MfA and MfB are sent to TTP .

On receiving messages (service requests from A and B), TTP decrypts the

message with its private key PrivTTP , extracts the parties signature, identifies

the corresponding party’s ID. The TTP uses each party’s public key to extract

and compare whether both parties’ Lf are equal. If they are equal, the TTP

will send confirmation and preserve the last node for the contracting parties. If

the results are not equal, TTP will sign the concatenation of σfA, σfB and error

message mer. Encrypted error messages MfTTPA MfTTPB will be sent to party

A and B correspondingly.

Protocol Disruption Protection

This stage of protocol has fall back functionality to increase system reliability. It

initiates early involvement of the TTP when trust becomes an issue. The secure


A TTP BσfA = SigPrivA

(Lf ) σfB = SigPrivB(Lf )

MfA = EPubT T P(σfA‖B)‖CA MfB = EPubT T P

(σfB‖A)‖CB

MfA−→MfB←−

L′f = VPubA

(σfA)

L′′f = VPubB

(σfB)

if L′f = L′′

f

σTTP = SigPrivT T P(σfA‖σfB‖mcf )

MfTTPA = EPubA(σTTP )‖CTTP

MfTTPB = EPubB(σTTP )‖CTTP

MfTTPA←−MfTTPB−→

if L′f 6= L′′

f

σTTP = SigPrivT T P(σfA‖σfB‖mer)

MfTTPA = EPubA(σTTP )‖CTTP

MfTTPB = EPubB(σTTP )‖CTTP

MfTTPA←−MfTTPB−→

*** any party can start dispute protocols ***

Figure 5.6: Final Stage Protocol

communication protocol can be operated dishonestly, the last one or two hash

chain nodes being vulnerable to this type of attack.

1. One party receives a message but does not send RSP and claims either to

have not received the message, or to have technical problems

2. The party, further more, can add its own node and send it, such that there

is no evidence that it ever received the other party’s message

3. One party can add a message to its hash chain but does not send it to the

other party

Such problems and attacks will result in contracting parties having an unsyn-

chronized hash chain, meaning they no longer have identical contracting evidence.

In this situation, any party can initiate this set protocol to engage the TTP .

The TTP will act in such a role: witness the dispute between two parties

on the hash chain and roll back the hash chain to a common point to re-start

the negotiation. Parties also have choices of either terminating or restarting the

negotiation.


The protocol disruption protection contains four protocols: Dispute I and II

Protocols, Termination Protocol, and Engage TTP Protocol. This set of pro-

tocols will resolve most common situations providing both the reliability of the

communication protocol and the flexibility for freedom of contract. In this case,

party B initiates the protocol to engage TTP for communication with party A.

A TTP BLdB = (HCB‖DS‖B‖A)

σdB = SigPrivB(LdB)

MdB = EPubT T P(LdB‖σdB)‖CB

MdB←−σdTTP = SigPrivT T P

(σdB)

MdTTPA = EPubA(σdB‖σdTTP )‖CB‖CTTP

MdTTPA←−LdA = (HCB‖RDS‖B‖A)

σdA = SigPrivA(LdA)

MdA = EPubT T P(LdA‖σdA)‖CA

MdA−→σdTTP = SigPrivT T P

(σdA)

MdTTPB = EPubB(σdA‖σdTTP )‖CA‖CTTP

MdTTPB−→if RDS = Engage

*** connect “Engage TTP Protocol” ***

if RDS = NotEngage

*** back to “Negotiation Stage Protocol” ***

Figure 5.7: Dispute I Protocol

Dispute I Protocol In Dispute I Protocol (Figure 5.7), party B raises the

dispute and A agrees that party B is right. Party A has two options after it

accepts B’s hash chain integrity. In this protocol, B first sends its own hash

chain HCB along with DS‖B‖A to TTP . This message indicates to the TTP

that there is a hash chain integrity dispute between parties A and B. The party

B is the initiator. TTP computes the signature σdB and passes it to party A. A

will sign B’s hash chain as proof of the agreement on hash chain integrity, and

sends back RDS along with other information to indicate to the TTP what it

prefers to do next. TTP signs and passes the message from A to B. According


to A’s response RDS, parties can connect to Engage TTP Protocol or back to

the negotiation Protocol.

A TTP BLdB = (HCB‖DS‖B‖A)




(σdB)


MdTTPA←−

LdA = (HCA‖RDS‖B‖A)




(σdA)


MdTTPB−→if RDS = TM

*** connect “Termination Protocol” ***

if RDS = Engage

σTTP = SigPrivT T P(HCTTP )

MTTPB = EPubB(HCTTP ‖σTTP ‖A)‖CTTP

MTTPA = EPubA(HCTTP ‖σTTP ‖B)‖CTTP

MTTPA←− MTTPB−→*** connect “Engage TTP Protocol” ***

Figure 5.8: Dispute II Protocol

Dispute II Protocol This Dispute II Protocol (Figure 5.8) starts in the same

manner as “Dispute I Protocol”. The difference is that A disagrees with B’s

hash chain integrity. Instead of signing HCB, A signs its own hash chain HCA

along with a response message and sends it to the TTP . The party A has two

choices; either terminate the communication or roll back to a common point, then

resume the communication under TTP ’s supervision. TTP passes the response

to B. If A’s response is termination, parties connect to “Termination Protocol”,


otherwise TTP rolls back to a common point HCTTP , and connects to “Engage

TTP Protocol”.

A TTP BLdB = (HCB‖TM‖B‖A)




(σdB)


MdTTPA←−LdA = (HCA‖RTM‖B‖A)




(σdA)


MdTTPB−→

Figure 5.9: Termination Protocol

Termination Protocol The “Termination Protocol” (Figure 5.9) has the same

format of dispute protocols, with TTP passing and witnessing the parties’ ter-

mination process. The “Termination Protocol” can be executed from any stage

of the protocol instead of only from dispute protocols. In the protocol, B initi-

ates termination by sending its signed hash chain (HCB) to TTP . TTP signs

B’s signature (σdB) and passes the message to A. Within the response of B’s

termination request, A signs its own hash chain (HCA) and sends it to TTP for

witnessing. TTP also signs A’s signature and passes the response to B.

Engage TTP Protocol The “Engage TTP Protocol” (Figure 8) is similar

to “E-Tender Negotiation Protocol” with extra information for TTP to build a

hash chain that both parties agree upon. Figure 8 demonstrates that the message

originator B encodes the original message with A’s public key to block the TTP

from viewing the message content. B then encodes the rest of the information

with Mn using TTP ’s public key, and sends MnTTP to TTP . TTP signs the

(Ln‖σnB) and sends all information to A. When A receives the message, it can

5.5. Protocol Analysis Issues 109

A TTP BLn = h(mn‖Ln−1)

σnB = SigPrivB(Ln)

Mn = EPubA(mn)

MnTTP = EPubT T P(Ln‖σnB‖Mn)‖CB

MnTTP←−σnTTP = SigPricT T P

(Ln‖σnB)

MnTTP = EPubA(Ln‖σnB‖σnTTP ‖Mn)‖CB‖CTTP

MnTTP←−Ln = VPubB

(σnB)

L′n = h(mn‖Ln−1)

L′′n = VPubT T P

(σnTTP )

if L′n = Ln = L′′

n

σnA = SigPrivA(Ln)

RSPn = EPubT T P(σnA)‖CA

RSPn−→L′

n = VPubA(σnA)

if L′n = Ln

σrn = SigPrivT T P(Ln‖σnA)

RSPnTTP = EPubB(σnA‖σrn)‖CA‖CTTP

RSPnTTP−→

Figure 5.10: Engage TTP Protocol

calculate Ln with original message and compare the Ln with the extracted Ln

from the two signatures. A then signs the hash chain node and sends RSPn back

to TTP . When TTP confirms that both parties agree on the same Ln, TTP

passes the RSPTTP to A.

5.5 Protocol Analysis Issues

EtenderNI protocol suite combines several generic cryptographic mechanisms to

provide complex security services for securing e-tender negotiation integrity. It is

based on one way hash functions and asymmetrical encryption, and combines digi-

tal signature and hash chain algorithms to achieve the specified security properties

or requirements. This protocol suite uses a hash chain forming process to emu-

late traditional contracting procedure for e-tendering, which protects the protocol

from traditional business attacks. Confidentiality is protected by asymmetrical


encryption. The digital signature algorithm provides data origin authentication,

and the hash chain provides original integrity confirmation.

Security analysis is the only means to demonstrate that the protocol suite

meets security requirements. Since the security requirements were established

by analyzing functional differences between paper based and electronic medium

based tendering negotiation, the security analysis will explicitly demonstrate com-

pliance of legal requirements with respect to providing reliable methods for e-

communication and for data message keeping.

For security analysis, any analytical theories, methods and processes have

to be adopted for different type of protocols. Considering the complexity, the

EtenderNI protocol suite will be analyzed in two stages, informal and formal

analysis.

Generally speaking, the first step of both stages of analysis is to establish the

security goals that the protocol is trying to achieve. The security requirements

will be re-stated informally as security goals for informal analysis; One of the

practical ways of defining formal security goals is to abstract security goals into

predicate sets which will capture the informally stated goals that derive from

security requirements.

The process of informal analysis will be to define security goals, attacker’s

power and analyze the protocol suite against each security requirement. The

formal specification will formally specify the protocol security goals, specify pro-

tocols using formal language, model attacking scenarios with supporting tools

to conduct finite state search. The informal analysis is a pre-process for formal

specification of the protocol and the formal analysis is the complement of the in-

formal analysis. Normally different analytical processes will look at the protocol

in different respects which may identify different problems.

??? The formal protocol analysis in this thesis is not a complete formal

verification. Several attack scenarios and threats are considered, but the protocols

could be insecure in the context of other attack scenarios. However, the current

state of the art in protocol verification does not provide the approaches and tools

for a formal security proof for e-tendering protocols. Even if the tools could cope

with complexity of the protocols, the security requirements for e-tendering are

also very complex and include requirements that are usually not considered in

protocol verification.

5.6. Informal Analysis of EtenderNI Protocol 111

5.6 Informal Analysis of EtenderNI Protocol

Procedures for informal analysis contain: define security goals from security re-

quirements established in Section 5.2, define attacker’s power according to com-

mon threats, and discuss assumed attacking scenarios against each security goal

for the protocol. The informal analysis intends to determine whether the proto-

col suite will provide complex security services for protecting e-tender negotiation

integrity when the generic cryptographic mechanisms or algorithms satisfy their

security definitions.

5.6.1 Security Goals

The security goals of the provided security services are to combat common threats

when using unguarded electronic medium. Security goals can be stated as follow-

ing:

• the plain text of any transmitted encrypted data message cannot be re-

vealed unless the data message obtainer has or owns the private key which

correlates to the encryption public key;

• any impersonation of a data message will be detected by digital signature

verification process unless the private key has been compromised;

• any alteration of an original data message can be detected by the verification

process;

• any disruption of e-tendering process can be resolved or terminated with

correlated data message records;

5.6.2 Attacker’s Power

Although the player’s behaviour cannot be predicted beforehand, it will affect the

protocol running environment significantly. For example, we do not know where

or when a player will inject a malicious action. A can initiate the termination

protocol with TTP at the start of the protocol or during a later stage of the

protocol run, while it still conducts a negotiation protocol run with B. We also

don’t know which party is going to be dishonest. There are four choices: A is

honest but B is dishonest; B is honest but A is dishonest; both A and B are


honest; or both A and B are dishonest. The following assumptions will be true if

players are honest. Only A (principal) should distribute the tender specification;

no other party should start the protocol and generate the initial node of the hash

chain. Only B ∈ B (potential tenderers) should send an offer; this is the rule of

the business process. One tenderer B should only submit one tender once to A.

Only principal A should send the tender acceptance. Only one acceptance can

be sent by principal, and this acceptance should be only sent to one tenderer.

Because of these uncertainties, we assume that all players (principal and ten-

derers) are dishonest players. They have interception, insertion and alteration

powers at any stage of the protocol run. The attacker’s power can be summarised

as follows:

Interception Power: the power to intercept all parties’ network messages in

order to gain other parties tendering strategies.

Insertion Power: the power to insert malicious messages into the network dur-

ing the protocol run. For example, players can replay or relay intercepted

messages or insert extra tender values during a protocol run.

Alteration Power: the power to manipulate (alter, delete, and insert) all proto-

col generated elements belonging to them. It includes: the set of communi-

cated messages, the set of signatures from message originator and receiver,

and the set of signatures from the trusted third party.

5.6.3 Confidentiality

Confidentiality is achieved by using asymmetrical encryption. For example, party

A sends party B a message, the message will be encrypted with party B’s pub-

lic key using a secure asymmetrical encryption. If an eavesdropper intercepts

the message, this secure asymmetrical encryption will block extraction of any

information from the cyphertext without B’s private key. The communication

confidentiality relies on the security of asymmetrical encryption. ??? The proto-

col assumes that B will not lose its private key, therefore nobody will be able to

impersonate B and trick A to send a message.

5.6. Informal Analysis of EtenderNI Protocol 113

5.6.4 Data Origin Authentication

A digital signature scheme has been used to achieve the Data Origin Authentica-

tion security property. The main advantage of this protocol is that the message

originator is in charge of generating a check value (hash chain node) which is used

to confirm this message’s original integrity at a later time. This check value is

also digitally signed by the message originator using their own private key, which

demonstrates their commitment to the transaction.

A secure digital signature algorithm will bind the message to the originator.

It prevents the message originator from denying the transaction (message and

hash chain node). This will achieve data origin authentication. For example, if

later on, party A denies that it sent the above message to B, the challenger can

use verifying algorithm to provide evidence. If the message can hash back into

the corresponding chain node in a hash chain, and this node is equal to the chain

node extracted from A’s signature (only A can generate its own signature), party

A cannot deny the transaction, unless it declares that its private key had been

compromised.

5.6.5 Original Integrity Confirmation

The hash chain is the check value that confirms the input message has remained

unchanged from its original form. Hash chain integrity itself is protected by the

signature over each node during the contracting period, and by the TTP for the

end node of the chain.

This hash chain prevents both contracting parties from altering the set of

contracting evidence (messages and chain nodes). If B alters a message and

corresponding hash chain node generated by A, B cannot compute A’s signature

over this altered node, because B does not know A’s private key. If B alters a

message and node generated by itself with a new signature, A can prove that

the new signature does not match the one it received before. According to this

evidence, A can prove that B is dishonest.

Under a protocol attack, the hash chain can be recalculated to cover up any

trace of interference (deletion, insertion, resequencing, alteration of content), after

a contracting party has varied a chain node. This recalculation can occur during

and after the contracting process. A personal digital signature has the function-

ality to prevent this recalculation during the contracting process by protecting


chain nodes (as demonstrated in the above example). But after the contracting

process, the key pairs may be revoked in the short term.

The TTP is introduced to preserve the last node of the hash chain after a

successful contract negotiation in the e-tendering process. In a technical sense the

TTP is incorporated to further protect the hash chain’s integrity, by eliminating

the short term key revocation of the digital signature, which is used to protect

the hash chain during the contracting process.

For example, after the final contract is formed, party B obtains A’s private key

(worst case condition). B’s intention is to vary the contract evidence, recalculate

the hash chain, and use this key to re-sign each node created by A. The result

is that A has evidence which is different from B’s evidence. Theoretically, both

parties should possess one identical set of contracting evidence. Without the

TTP holding the last node, a challenger may not be able to distinguish which

party has recalculated the entire hash chain to suit their own purpose.

In contrast, any recalculated hash chain is unable to match the last node

that is held by the TTP . Our protocol prevents the hash chain from being

recalculated both during, and subsequent to, the contracting process. Contracting

parties’ interaction with the TTP can also confirm that both parties agreed on

one set of agreements and possess identical contracting evidence. The assurance

of contracting parties holding identical contracting evidence set is not provided

by traditional tendering systems.

The TTP preserves the integrity of the last node of the hash chain and in turn

protects the original integrity of contract evidence over the term of the contract.

In a legal sense the TTP is acting as the witness of the final contracting result.

Because the chain integrity is preserved the original integrity of contract evi-

dence can be confirmed by the hash chain as the check value at any later time.

5.6.6 System Reliability

Any party can invoke fall back protocol involving the TTP . The Dispute I,

II, Termination and Engage TTP Protocols are constructed to solve common

disputes. Therefore the communication protocol can proceed to a more secure

termination or to the final stage of e-tendering. With this set of protocols in

place, parties are able to collect and maintain a complete set of communicated

evidence regardless of whether a contract is awarded or negotiation is terminated

prematurely.

5.7. Formal Specification of EtenderNI Protocol Suite 115

In Dispute I and Dispute II Protocols, the TTP ’s intervention will force party

A to respond and make decisions about how the rest of the e-tendering process

will be conducted with party B. Dispute I covers human errors and technical

problems causing mismatching hash chain integrity. A agrees with B’s hash chain

integrity and resumes the communication. Dispute II covers dishonest operation

causing mismatching hash chain integrity. In this situation, trust is an obvious

issue. If parties still want to proceed, the rest of communications need to be

monitored. Otherwise, parties can formally terminate the communication with

the involvement of TTP .

5.7 Formal Specification of EtenderNI Protocol

Suite

The main function of the e-tender negotiation protocol is to collect reliable evi-

dence to prove that the principal and tenderer have committed to a business deal.

After a successful negotiation, parties must agree on the same set of issues and

express the intention to enter a legal binding contract. The protocol must ensure

that reliable evidence is generated and that the original integrity of this evidence

can be verified at a later date.

The protocol uses asymmetrical encryption, cryptographic hash functions and

digital signatures to prevent a dishonest participant from gaining benefit by al-

tering contractual evidence. During the e-tendering process, a hash chain is gen-

erated from each message sent. It acts as the checksum for verifying the integrity

of contractual evidence at a later time. Therefore the protection of the hash

chain integrity is a primary goal for the protocol design. During the e-tendering

contracting period, a digital signature is applied over each chain node and corre-

sponding message to protect hash chain integrity as well as provide evidence that

a player committed to the message.

At the conclusion of the contracting process, a trusted third party is intro-

duced to digitally sign and preserve the last node of the hash chain. To finalize

and terminate the e-tendering process, all contracting parties and the TTP need

to be involved in digitally signing the termination messages. No contracting

party can successfully finalize or terminate the e-tendering process unilaterally

with the trusted third party without the other party being notified. The formal

specification and analysis must provide evidence that at the end of each suc-


cessful protocol run, both parties hold identical verifying elements for checking

contractual evidence integrity.

This section describes how a formal specification is constructed while designing

the protocol in its early stages. The specification must be complete, consistent,

and unambiguous to find protocol flaws in the protocol design stage. The veri-

fication should prove that security functions work together in a desired manner

under our defined limitation of malicious actions.

Three independent analyses have been performed for the e-contracting proto-

col. Player A has the role of the principal and Player B takes the role of tenderer.

The first analysis assumes that all players are honest at all times. A minimal set

of assumptions can be found when the protocol works in a desired way. The sec-

ond analysis assumes that B is dishonest at tender offering step but A is honest.

It tries to send two offers to A hoping to swap the message at a later stage. The

third analysis assumes that A is dishonest in the tender offer step but B is honest

during the protocol run. A’s attempt is to find out whether any message signed

by B in the main protocol can be substituted for other protocol.

5.7.1 Language and Tool

Using formal methods for protocol security analysis has proved to be successful

[79, 80]. Particularly, the verification of fair exchange [13] and non-repudiation

[48] protocols have explored dishonest player’s malicious behaviour. Asynchro-

nous product automata (APA) formal specification with SHVT [84] have been

successfully used to analyse fair exchange protocols [47, 48]. Both SHVT and

APA have been discussed in Section 3.2.

Gurgens and Rudolph were modeling fairness of a non-repudiation protocol

[112]. They formally defined fairness of the non-repudiation protocol. The defined

fairness is set as the security goal for the modeling. During the modeling, attacks

are introduced to break the protocol security goals. However, their strategies

cannot be directly employed in the analysis of EtenderNI e-tender negotiation

integrity protocols. EtenderNI protocol is a larger and more complex protocol

than the fair non-repudiation protocol [112]. The security goal of the EtenderNI

protocol is also different. The following sections will discuss a process for formally

examining security of complex protocols.


5.7.2 Procedures of Formal Specification

From informal analysis, it is conclusive that the contract evidence integrity as-

surance has to be achieved using the verification process. To formally specify and

analyze e-tendering negotiation protocols the following steps have to be followed:

1. identify all the required verifying elements;

2. specify all the verifying procedures;

3. define protocol assumptions;

4. formalize protocol security goals;

5. specify protocol initial state components;

6. specify transition patterns for formal analysis with SHVT;

5.7.3 Required Verifying Elements

The required verifying elements are determined by the following principle:

For contracting purposes At the end of the e-tender submission process A

needs to have evidence to prove that it is B who sent the commitment and

B needs to have the evidence to prove that A received the commitment.

For evidence reliability the contracting evidence should be the complete set

of inputs for the integrity verification process.

The verifying procedure requires the following sets of elements (communicated

messages, checksum, and confirmations ) to be generated, verified and stored

by the e-contracting protocol. Elements required for verifying the integrity of

contracting evidence are:

• a set of finite, sequenced and communicated messages M with f number of

elements; These messages record all the information related to contracting

offer, acceptance, and negotiation of agreement.

• a set of hash chain nodes L formed by each Ln = h(Ln−1, mn), for mn ∈M

and n = 1, 2, ..., f , where h() is the underlying cryptographic hash function;


• a set of signatures SigO over each Ln ∈ L for n = 1, 2, ..., f when the hash

chain node is generated by the sender;

• a set of signatures SigR over each Ln ∈ L for n = 1, 2, ..., f when the hash

chain node is verified by the receiver.

• a set of signatures SigTTP over last hash chain node Lf ∈ L

Verifying elements generated by each protocol are listed in Figure 5.11

M L SigO SigR SigTTP

Negotiation {m0...mf} {L0...Lf} {SigO0...SigOf} {SigR0...SigRf}

Final LfA, LfB σfA, σfB σTTP

Termination LdB σdB σdBTTP

LdA σdA σdATTP

Engage TTP {m0...mf} {L0...Lf} {SigO0...SigOf} {SigR0...SigRf} {SigTTP0...SigTTPf}

Dispute HCdB LdB σdB σdBTTP

HCdA LdA σdA σdATTP

HCTTP σTTP

Figure 5.11: Required Verifying Elements for E-Tender Negotiation ProtocolSuite

5.7.4 Verification Process

The verifying process can be represented as following:

• A and B each provide their set of {M , L, SigO, SigR and SigTTP}.

• verify that each mn ∈ M can hash back into the hash chain by calculating

Ln = h(Ln−1, mn), for n = 1, 2, ..., f , for both A and B provided sets of

information;

• verify VPubTTP(SigTTP, Lf ) = 1 for both players’ supplied last node Lf ;

• if necessary, further verification on each SigO, SigR to determine whether

VPubO(SigOn, Ln) = 1 and VPubR

(SigRn, Ln) = 1 for n = 1, 2, ..., f , PubO is

the message originator’s public key and PubR the message receiver’s public

key.


5.7.5 Assumptions

Assumptions place limitations on a player’s dishonest behaviour. Simplifying

assumptions [13] should be consistent with business rules. They must be made

before a formal specification. A first round high abstract specification should

also be used to refine the assumptions set. This approach provides benefits to

the protocol design process, in that there is a clear understanding of the protocol

running environment for the contracting process, and that honest behaviour for

each player is defined.

Some assumptions must be true for the protocol. These assumptions cannot

be varied during protocol modelling. Others are temporal assumptions which

are indeterministic and their existence is random. These assumptions can be

varied or omitted during specification to facilitate exploration of insecure states.

Assumptions can be varied to simulate malicious actions. For example, some of

the assumptions can be relaxed to give more power to dishonest players, such as

the ability to insert malicious actions.

The following assumptions either define the protocol run conditions that must

be met, or state unchangeable truths of a player’s behaviour.

• TTP is always honest and can always be trusted. This is the condition

that cannot be relaxed. Both contracting players know that the TTP can

be trusted. Although in reality a fully trusted TTP may not exist, in a

relative sense the TTP is more trustworthy than a contract partner.

• The assumptions derived from secure cryptographic functions are reliable

assumptions. This set of assumptions include:

– encryptions are perfect, keys can not be guessed;

– if EPub(m) = EPub′(m′), it implies Pub = Pub′ and m = m′;

– if h(m) = h(m′), it implies m = m′, for h is a cryptographic hash

function;

– if SigPriv(h(m)) = SigPriv′(h(m)′), it implies h(m) = h(m)′, and

Priv = Priv′;

• At this level of protocol analysis, we have to assume that these secure

cryptographic functions exist and are provably secure.


• We assume that computer and network security are provided. Crypto-

graphic functions rely on secure computer platforms to provide a security

service. If these functions are secure, these assumptions have to be true.

This analysis will focus on dishonest player specifications, therefore network

security is assumed.

• Players only explore behaviour that will benefit themselves. No party will

release its private key to another party.

Other temporal assumptions are defined during protocol modeling. Such as-

sumption are dependent on tools and languages used for modeling.

5.7.6 Derive Protocol Security Goals

The integrity of contractual evidence needs to be verified when a dispute occurs.

The contractual evidence integrity protocol is responsible for generating reliable

checksum elements to verify the integrity of contractual evidence. The verifying

process determines what verifying elements the protocol should produce. We will

define the protocol security goal as satisfaction of the following terms.

Under predefined assumptions, and after each successful protocol run, the

protocol should ensure:

1. that it generates a complete set of elements to verify the contractual evi-

dence integrity , {M,L, SigO, SigR, SigTTP};

2. that both A and B possess identical sets of elements,

A {M,L, SigO, SigR, SigTTP} ≡B {M,L, SigO, SigR, SigTTP}

3. that each element is verified during its generation process.

If these goals are satisfied, any alteration of the data message after the protocol

run should be detected by the verification procedure. We can assess whether the

protocol can generate the complete set of these elements. We can also verify

whether the protocol ensures that all players hold identical sets of elements.

The formal method will be used to explore the possible protocol states that

breaches the above stated security goals. It can also provide evidence to show

that the set of cryptographic functions work together in a desired manner under

a defined set of assumptions.


A B

TTP

A_THashChain

A_HashChain

A_Asmykeys

A_StateNetwork

B_THashChain

TTP_State TTP_Asmykeys TTP_HashChain TTP_THashChain

B_State

B_Asmykeys

B_HashChain

Figure 5.12: APA diagram

5.7.7 Specify Initial State Sets

In this APA diagram (Figure 5.12), each automaton is connected to its own 4

state components, State, Asymkeys, HashChain and THashChain. All automata

share the Network state component.

The state initialization (Table 5.1 ) defines roles of automata A (principal), B

(tenderer) and TTP (trusted third party). State components State, HashChain,

and THashChain are assigned Messages_seq as their data type. The state com-

ponent Asymkeys is assigned data type of Asymkeys_seq. The initial elements

are then assigned to each state component.

For example, “A State” (line 4) is a type of Messages_seq and has [TTP,’server’]

and [‘start’,B] as initial elements. The initial elements means that role A

knows TTP is the server, and can start the protocol with role B. The role A’s “A

Asymkeys” (line 5) of Asymkeys_seq type contains initial elements of (A,’priv’,’Apriv’),

(B,‘pub’,‘Bpub’) and (TTP,’pub’,’TTPpub’). These initial elements indicate

that A knows its own private key, B’s public key and TTP’s public key. Role A’s

“A HashChain” (line 6) and A THashChain (line 7) state components are empty

when the protocol first starts.


Define Roles1 def \_role A;2 def\_role B;3 def\_role TTP;

Role A’s State Components4 A State: Messages_seq := [TTP,’server’] . [’start’,B];5 A Asymkeys: Asymkeys_seq :=

(A,’priv’,’Apriv’).(B,’pub’,’Bpub’).(TTP,’pub’,’TTPpub’);6 A HashChain: Messages_seq := ::;7 A THashChain: Messages_seq := ::;

Role B’s State Components8 B State: Messages_seq := [TTP,’server’].[’respond’,A];9 B Asymkeys: Asymkeys_seq :=

(B,’priv’,’Bpriv’).(A,’pub’,’Apub’).(TTP,’pub’,’TTPpub’);10 B HashChain: Messages_seq := ::;11 B THashChain: Messages_seq := ::;

Role TTP’s State Components12 TTP State: Messages_seq := [A,’agent’] . [B,’agent’];13 TTP Asymkeys: Asymkeys_seq :=

(A,’pub’,’Apub’).(B,’pub’,’Bpub’).(TTP,’priv’,’TTPpriv’);14 TTP HashChain: Messages_seq := ::;15 TTP THashChain: Messages_seq := ::;

Global State Components16 Network: net_elem_seq := ::;17 Netmsg: Messages_seq := ::;

Table 5.1: Initial State Sets

5.7.8 Specify Transition Relations

The specification was applied to E-Tender Negotiation protocol, Final Stage and

Termination protocol from EtenderNI protocol suite. In the real protocol run, the

E-Tender Negotiation protocol will be executed over multiple rounds to complete

the contracting procedure in the e-tendering process. The multiple cycles of E-

Tender Negotiation protocol have been modeled to cover stages of contracting

process, offer and acceptance.

During the specification cycle, role A starts the E-Tender Negotiation proto-

col. In the offer cycle, role B starts the E-Tender Negotiation protocol. For the

acceptance cycle, role A starts the E-Tender Negotiation protocol.


Tables 5.2 and 5.3 are examples of specified transition relation for the protocol.

The left hand column of the tables represents actions of honest players.

Transition Pattern if All Players are Honest Left hand side of tables 5.2

and 5.3 represent A and B acting honestly in their exchange of messages for the

tender offer. B sends the offer to A, A verifies the specification, produces its hash

chain node, signs the node and sends the confirmation back to B.

def_trans_pattern B offer1_3 (Table 5.2 line 1) states that this is role B’s

transition pattern in the first step of offer cycle. This is the third step in the total

transition pattern specification. Line 2 declares all the variables needed for this

transition pattern.

[M0,L0,’L_n’]<<B_HashChain, (line 9) indicates that B retrieves the previ-

ous hash node into the current variable L_n for generating new nodes. Line 12

ts:=[M1,L0], and line 13 L1:=hash(ts), show that B generated a new hash

chain node for its offer. Line 14 [M1,L1,’expects_CON’]>>B_HashChain, B

marks the new node as unconfirmed and adds a new node into B_HashChain

state component. Line 15 rB:=sign(bpriv,L1), indicates that B signs its new

node with its private key. Line 16 eB:=crypt(apub,[M1,rB]), shows that B

encrypts its offer M1$and signs the hash chain node with A’s public key. Line

17 (A,B,[eB,’offer’])>>Network, indicates that B adds the message to the

Network state component.

In Line 1 def_trans_pattern A offer2_4 A’s transition pattern in step 2 of of-

fer cycle. In Line 2 (M,M0,M1,L0,L1,L1c,Ls1,rA,eA,ts,ts1,ts2,apriv,bpub,rA1,

eA1,HCA,ttppub) are A’s variables needed for this step. In Line 8 M<<Network, A

retrieves the message from Network state component. In Line 13 ts1:=crypt(apriv,ts),

A decrypts message with its private key. In Line 14 M1:=head(ts1), A extracts

B’s offer message into M1. In Line 15 L1:=elem(3,head(tail(ts1))), A extracts

new hash chain node sent by B. In Line 17 verify(bpub,ts2)=‘true’, A verifies

B’s signature is true. In Line 20 Ls1:=[M1,L0], and line 21 L1c:=hash(Ls1), A

calculates its own new hash chain node with B’s offer M1 with its own previous hash

chain node. In Line 22 L1=L1c, A ensures that both received node and calculated

node are the same. In Line 23 [M1,L1,’L_n’]>>A_HashChain, A advances its

hash chain In Line 24 rA:=sign(apriv,L1), and line 25 eA:=crypt(bpub,[rA]),

A signs and confirms the new node and encrypts the confirmation. In Line 26

(B,A,[eA,’A_cfm’])>>Network, A adds confirmation to Network state for B.


Honest Actions Dishonest Actions

1 def_trans_pattern B offer1_32 (M0,M1,L0,L1,rB,eB,ts,bpriv,apub)3 (B,’priv’,bpriv) ? B_Asymkeys,4 (A,’pub’,apub) ? B_Asymkeys,5 [’start’, A] << B_State,6 [’spec’] ? B_State,7 [’offer’] ~? B_State,8 [A_abort] ~? B_State,9 [M0,L0,’L_n’] << B_HashChain,10 M1 := ’m1’,11 [M0,L0] >> B_HashChain,12 ts := [M1,L0],13 L1 := hash(ts),14 [M1,L1,’expects_CON’] >> B_HashChain,15 rB := sign(bpriv,L1),16 eB := crypt(apub,[M1,rB]),17 (A,B,[eB,’offer’]) >> Network,18 M2 := ’m2’,19 ts2 := [M2,L0],20 L2 := hash(ts2),21 [M2,L2,’expects_CON’] >> B_HashChain,22 rB2 := sign(bpriv,L2),23 eB2 := crypt(apub,[M2,rB2]),24 (A,B,[eB2,’offer’]) >> Network,25 [’expect_A\_cmf’] >> B_State,26 [’offer’] >> B_State;

Table 5.2: Example code of Player B is Dishonest

Transition Pattern of B is Dishonest Only This is the example code for

the case where B is dishonest (Table 5.2). B has inserted the following malicious

actions into step 1 of the offer cycle. In line 19 ts2:=[M2,L0], and line 20

L2:=hash(ts2), B uses offer 2 to generate a new node with the previous node

L0. In line 21 [M2,L2,’expects\_CON’]>>B_HashChain, B adds to its hash

chain and waits for confirmation. In line 22 rB2:=sign(bpriv,L2), and line 23

eB2:=crypt(apub,[M2,rB2]), and line 24 (A,B,[eB2,’offer’])>>Network, B

signs, encrypts and adds to the Network state for A.

Transition Pattern if A is Dishonest Only This is the example code for

the case where A is dishonest (Table 5.3). Malicious actions have been inserted

into A’s transition pattern in step 2 of offer cycle.


In line 27 HCA:=[L0,L1,‘termination’,‘AB’], A starts the termination pro-

tocol with TTP while still maintaining normal communication with B. In line 28

rA1:=sign(apriv,HCA), line 29 eA1:=crypt(ttppub,[HCA,rA1]), and line 30

(TTP,A,[eA1,‘abort’])>>Network, A signs, encrypts and adds the termination

message to the Network state for TTP.

5.7.9 Discussion of Verification Results

Applying a formal method for protocol design is a self assessment process. Firstly,

a set of simplifying assumptions needs to be found; Secondly, protocol security

goals must be clearly defined for the formal specification and verification. The

protocol can then be formally specified using constraints derived from simplifying

assumptions. Machine verification can then be performed for protocol analysis.

Malicious actions are modeled by gradually relaxing simplifying assumptions to

give more power to the attacker. Malicious action modeling can be performed in

many rounds with different levels of difficulties.

Each step of this self assessment process can find flaws in a protocol. Most of

the incompleteness in the design can be found before modeling malicious actions.

Each step will also give input to refine the previous steps.

Protocol Flaws Found During Specification

Some flaws of initial design of the protocols were found by examining the security

goals. The previous design contains initial stage protocol and e-tender negotiation

protocol. The initial stage protocol did not generate all the required elements

for contractual evidence verification and the e-tender negotiation protocol was

missing the last verifying procedures. The security goals require that the protocol

generates a full set of verifying elements to checking contractual evidence integrity,

{M , L, SigO, SigR and SigTTP}.For the initial stage protocol, a flaw of the protocol is that player B does not

verify the signature of node L0 therefore B does not know whether L0 is related

to m0 or other data. A also does not have SigR from B. The result of this is that A

can have two messages m0 and attack_data. m0 is for B to read and attack_data

is for applying its signature. B will then think that it is extending the hash chain

related to m0. In fact, it is extending the hash chain related to attack data. After

a successful protocol run, B signs a contract with A for attack_data. But B has


only obtained A’s SigO of attack_data. Therefore it cannot provide evidence

that A has made a committment to message m0.

This proves that incomplete design can breach the security goal easily, and this

type of flaw can be found in the early stage of self assessment process. The same

attack was also performed on the improved E-Tender Negotiation protocol. No

party can successfully complete a protocol run. Therefore the improved protocol

can prevent this dishonest action.

From the formal specification we notice that the initial protocol can be con-

sidered as a special situation (one mini cycle) of the negotiation protocol. The

negotiation protocol has to be executed with many rounds to complete a contract-

ing process. An improved protocol merges the initial protocol and the negotiation

protocol into one protocol called “E-Tender Negotiation Protocol” to handle con-

tracting.

This formal specification analysis was performed on the final version of the

protocol suite. SHVT generated reachability graphs for scenarios where all players

are honest, where only B is dishonest and where only A is dishonest.

Verification on Scenario: All Players are Honest

The state reachability graph shows that when all players are honest, the main

group of protocols can function correctly. Contracting parties had a successful

protocol run. Role A and B each obtained a complete set of verifying elements.

They also maintained identical sets of verifying elements for verifying contractual

evidence.

Verification on Scenario: Only B is Dishonest

The state reachability graph for the scenario of only B is dishonest shows that an

error path has been generated by B sending two offers to A. However A did not

respond the way that B expected therefore B cannot use the incorrect message

after protocol run. In this graph, it also shows that the correct contracting paths

have been performed. The end nodes show that both A and B have obtained a

complete set of verifying elements and that they are identical.

5.8. Summary 127

Verification on Scenario: Only A is Dishonest

In the scenario of only A is dishonest, A attempts to terminate the negotiation

protocol with B while maintaining a valid negotiation protocol run at the same

time with B. This attempt explores whether any B signed messages can be sub-

stituted. Again the reachability graph showed some error paths, but no error

path is able to complete the negotiation protocol or termination protocol. A cor-

rect contracting path was generated, and both A and B end nodes again show no

security goal has been breached.

The protocol behaved correctly under our three different sets of assumptions.

5.8 Summary

The secure e-tender negotiation integrity (EtenderNI) protocol suite contains four

sub-protocols: e-tendering contract negotiation, dispute resolution, termination

and final contracting protocol discussed; shown in Figure 5.3. This protocol suite

was designed to provide security requirements during the e-tender negotiation

process. A protocol design without sufficient specification to clarify the protocol

running environment has become one of the major barriers to secure protocol

implementation.

The e-tendering protocol is modeling a complex business process. Providing

assurance for secure and trusted protocols or systems should be an essential part

of the secure protocol development process. Informal and formal analysis have

been applied to the EtenderNI protocol suite. The formal verification of whether

the protocol has achieved its security goals requires the transform of the security

requirements to formally specified security goals. These transformations are:

1. It is established that e-tender negotiation requires Confidentiality, Data Ori-

gin Authentication, Original integrity confirmation, and System Reliability

security services.

2. A set of cryptographic technologies: digital signature, hash chain tech-

nology, symmetrical and asymmetrical encryption are used to achieve the

following security goals.

3. Define protocol security goals.


4. The protocol security goals are then transformed into technical goals for

the formal specification and verification.

The EtenderNI protocol suite has set up a framework for preserving the in-

tegrity of the e-tendering process. It requires techniques for logging all types

of communication and produces integrity check values for the entire contract-

ing process in e-tendering. These check values have been effectively preserved

by cryptographic algorithms to provide reliable confirmation checking of original

integrity for contracting evidence. It is the first step for legal compliance of an

e-tendering scheme.

The security property of the protocol also eliminates the existing problems in

the tendering process such as logging telephone negotiations. It eases the long

existing problem of how to provide reliable digital evidence in court, which has

put risks in e-commerce. Using formal methods during protocol design has proved

to be successful in finding protocol flaws. Our formal analysis also defined a set of

assumptions. These assumptions can then act as guidelines for further protocol

analysis. This gradual approach is more suitable for assessing protocol design of

complex systems.

The protocol suite is designed to use the standard cryptographic algorithms

such as digital signature and cryptographic hash functions. Therefore the pro-

tocol suite will not increase the computation cost other than just the normal

business process required. In addition, the e-tendering process lasts long period

of time and it is not a time critical process (such as military operations). Us-

ing standard cryptographic computation will not affect the performance of an

e-tendering system.

The e-tender submission integrity is another important process that needs

to be secured, particularly against collusions (as discussed in Section 4.5). The

next chapter will use same design process to secure e-tender submission process

integrity.

5.8. Summary 129

Honest Actions Dishonest Actions

1 def_trans_pattern A offer2_42 (M,M0,M1,L0,L1,L1c,Ls1,rA,eA

ts,ts1,ts2,apriv,bpub,rA1,eA1,HCA,ttppub)

3 (A,‘priv’,apriv) ? A_Asymkeys,4 (B,‘pub’,bpub) ? A_Asymkeys,5 (TTP,‘pub’,ttppub) ? A_Asymkeys,6 [‘respond’, B] << A_State,7 [’offer’] ~? A_State,8 M << Network,9 p(1,M)=A,10 head(tail(p(3,M)))=‘offer’,11 [’offer’] >> A_State,12 ts := head(p(3,M)),13 ts1 := crypt(apriv,ts),14 M1 := head(ts1),15 L1 := elem(3,head(tail(ts1))),16 ts2 := head(tail(ts1)),17 verify(bpub,ts2)= ‘true’,18 [M0,L0,‘L_n’] << A_HashChain,19 [M0,L0] >> A_HashChain,20 Ls1 := [M1,L0],21 L1c := hash(Ls1),22 L1 = L1c,23 [M1,L1,‘L_n’] >> A_HashChain,24 rA := sign(apriv,L1),25 eA := crypt(bpub,[rA]),26 (B,A,[eA,‘A_cfm’]) >> Network,27 HCA := [L0, L1, ‘termination’, ‘AB’],28 rA1 := sign(apriv, HCA),29 eA1 := crypt(ttppub,[HCA,rA1]),30 (TTP,A,[eA1,‘abort’]) >> Network,31 [‘respond’, B] >> A_State;

Table 5.3: Example code of Player A is Dishonest

Chapter 6


Submission

“Whatever is being designed, success is achieved by properly antici-

pating and obviating failure.”

— Henry Petroski

The development of secure electronic tendering submission protocols will fol-

low our design principle established in Chapter 5. We will first (Section 6.2)

identify the functional differences between the traditional process and its mirrored

e-business process. This is to identify advanced security requirements specially

related to e-tender submission process. We then review the functional possibili-

ties and limitations of a set of cryptographic technologies when they are applied

to the e-tender submission process in Section 6.3. This demonstrates how a set

of cryptographic technologies can be correctly integrated to provide complex se-

curity services for a new e-tender submission business process. In Section 6.4,

we describe our new protocols and Section 6.5 explains why the security goals

are met by our protocols using informal security analysis. In Section 6.6, we em-

ploy an established formal security analysis procedure for protocols which provide

complex security services.

131

132 Chapter 6. Secure Electronic Tendering Submission

Properties Auction Tendering

Bidding mechanism English, Dutch, Sealed bid firstprice, Vickrey

reversed auctions but mainlyreversed sealed bid

Products Single items or lot Construction project, govern-ment purchasing

Buyer Many One

Seller One Many

Bidding party Buyers Sellers

Winner resolution attrubute Single attribute price Multi-attribute such as priceand quality

Table 6.1: Property Differences Between Tendering and Auction

6.1 Introduction

Submitted tenders are confidential and are commonly the target of business col-

lusion [105, 2] when a tenderer attempts to obtain its competitor’s tender offer

before opening time. To prevent this collusion requires implementing an advanced

security protocol, going beyond basic security services such as confidentiality and

data integrity. It could also aid in the reduction of allegations of unfairness in

the e-tendering process.

An electronic tender box has been included in most fielded e-tender systems

to collect submitted tenders before tender opening time. Various proprietary

solutions have been used to protect the e-tender box but the common problem

with these solutions is that a system administrator still has the full capacity to

tamper with the submitted tenders. Although a secure e-contracting protocol has

been proposed in Chapter 5, to maintain the integrity of the e-tendering process,

adequate security solutions for the e-tender submission phase remain undiscussed.

This has hindered the full conversion of the traditional process to an electronic

form. Industry normally reverts to traditional paper based processes [27] when

high security is required such as when forming critical contracts.

Many government tendering processes have imported the sealed bid concept

(from auction) as their tender submission mechanism and this has been discussed

in Chapter 2. The difference between tendering and auction again is highlighted in

Table 6.1 for clarification. From the previous discussion, it can be concluded that

due to business process differences, e-tender security is better constructed using

more generic cryptographic mechanisms than by adapting e-auction schemes.

6.2. E-tender Submission Security Requirements 133

6.2 E-tender Submission Security Requirements

Traditional business practice contains certain levels of built-in security, such as

procedures to combat common fraud, or to meet a particular legal compliance.

However its mirrored e-business process may not function at the same security

level. These functional differences generate unexpected security problems and

can cause legal confusion. This section will assess the functional changes between

a traditional and an e-tender submission process; discuss common threats that an

e-tender submission faces; and derive the security requirements for the process.

6.2.1 Functional Differences Between Traditional and E-

tendering Boxes

Traditionally, the tender submission process has been carried out using a physical

tender box placed in a public area. Tenderers submit their tenders into the

tender box before submission close time. The tender box is normally opened at

the submission close time. Tenders that are submitted on time will be publicly

recorded. Any later submission is considered as a non-conforming tender and will

be rejected. Making the tender box publicly accessible increases the transparency

of the process.

A simple e-tender box does not function in the same way as a traditional

tender box. The simple e-tender box is typically a directory in a system server,

which allows tenderers to upload their tender offers to that directory. The funda-

mental difference from the physical tender box is that access to the e-tender box

has become a private activity and cannot be publicly monitored, thus removing

transparency. A significant opportunity has been created for business collusion

by using a simple e-tender box even though access to it may be protected by

cryptographic keys. The server administrator typically has access to the e-tender

box and is able to read its contents before the submission close time or alter those

contents after the close time.

The integrity of time of receipt could be compromised by both receiver and

senders if there were no security mechanism in place. This provides an opportu-

nity for collusion and may lead to unfair trading practices. Moreover, any late

submission should be identified as a non-conforming tender. The alteration of the

submission or receiving time can raise a dispute as to whether a tender conforms

or not. If the system clock is controlled by the local administrator there is scope


for the time of submission to be changed at any time.

In a normal sales contract, seller and buyer try to maximize their own benefits.

In tendering, when one of the tenderers (sellers) is the principal’s favourite, there

is a temptation to alter submitted tenders (price or other items) in order to win

the contract. This collusion is a type of social engineering technique which poses

a threat to the e-tender process integrity.

For example, the principal may allow its favoured tenderer to submit multiple

tenders to cover a range of prices or advantages, and include these submissions

into the tender opening process, in order to maximize the tenderers winning op-

portunity. The redundant submissions can be deleted from the submission pool

after the tender is opened. In tendering only one submission from a tenderer is

allowed to be included in the tender opening process. Although a legitimate ten-

derer can have multiple submissions before tender close time, a later submission

should override the previous ones.

6.2.2 Threats and Security Requirements

Any e-tender system requires a number of basic security services to protect the

confidentiality and integrity of tendering information and to authenticate the

parties concerned [40]. However, the simple e-tender box functionally changes

the security process. Therefore e-tender submissions face some specific threats

illustrated in the following four risk scenarios.

Scenario 1 The principal releases tender submissions to its favoured tenderer

before tender submission opening time. The principal’s favoured tenderer

can then submit a competitive tender and win the tender project.

Scenario 2 The principal allows its favoured tenderer to alter its tender after

the tender official opening time. This tender then becomes competitive and

wins the tender project. This alteration is not limited to price change.

Scenario 3 A dispute may occur between the principal and any of the tender-

ers over whether any tender submission occurred before tender submission

closing time. This may allow a tenderer to submit a late tender without

risking rejection, thereby gaining an advantage over other tenderers.

Scenario 4 The principal may include multiple tenders submitted by its favoured

tenderer into the tender opening process. This is to maximize the winning

6.3. Related Technologies and Application Issues 135

opportunity for its favoured tenderer. The redundant submissions can be

deleted from the submission pool after the tender is opened.

Consideration of these threat scenarios leads to the following security require-

ments for electronic tender submission.

Submission hiding ensures that no party can reveal any electronically submit-

ted e-tender document before the designated tender opening time. This is

to prevent any party from gaining another party’s tender strategy before

tender close time.

Submission binding detects whether any party altered or deleted any tender

submission after the tender closing time. This is to prevent business collu-

sion between the principal and its favoured tenderer.

Submission time integrity ensures that the time of tender submission can be

recorded in a reliable manner. This is to provide reliable evidence to deter-

mine whether a tender submission is on time.

6.3 Related Technologies and Application Issues

Every cryptographic technology has its assumptions which define the functional

limitations of its application to real cases. Every generic security mechanism only

provides its designated security service when operating within these limitations.

In this section, we provide assessments of possible cryptographic technologies (or

generic security mechanisms) in terms of their purpose of use, functional limita-

tions of application, and how each technology will be assembled and integrated

to provide adequate and comprehensive security services for our new e-tender

submission business process.

Submission hiding is the first security requirement of e-tender submission.

We have considered two ways of achieving this, firstly by a commitment scheme,

secondly by identity based encryption. Both strategies will need the support of a

digital signature scheme and time stamp service to provide credible evidence for

legal purposes.

For the commitment scheme approach, the commitment function will be used

to generate a document integrity checksum whilst hiding the tender submission.

Integrity protection of the checksum is provided by a digital signature during


the tender submission process. Time stamps will be provided by a time stamp

authority (TSA) to guarantee the submission time of all parties’ commitments.

The advantage of using a commitment scheme is that the trust of submission

hiding is controlled by the tenderer itself.

Our second approach uses identity based encryption to hide a tender submis-

sion in the submission phase. Each tenderer digitally signs its tender submission

first and obtains a time stamp on the signature. Each tender will be bound to

its submission by its signature. The time stamp will provide the evidence of sub-

mission time. The concept of this is to delegate the submission hiding to the key

generation centres (KGC) with the support of a threshold scheme. The thresh-

old scheme increases the guarantee that the decryption key cannot be generated

before tender closing time by distributing trust amongst a group of decryption

key generators.

6.3.1 Commitment Scheme

A commitment scheme [33] is a protocol between two parties called the prover P

and the verifier V . There are two phases.

1. In the commitment phase P provides V with the commitment C(m) to the

message m.

2. In the opening phase P enables V to recover the value m and V can verify

whether or not it is a correct opening of C(m).

Commitment schemes are typically constructed from one-way functions. For ex-

ample, consider the commitment function C(m) = gm where g is a generator of

Z∗p, the integers modulo p for some prime p. Given the value m the verifier V

can re-compute gm in order to check the commitment. There are two basic but

essential properties to any commitment scheme.

1. The hiding property prevents V from revealing the committed value m in

the protocol commitment phase.

2. The binding property prevents P from changing its committed value m

after the commitment phase.

We can apply the concept of the commitment scheme to e-tender submissions

to ensure that the principal cannot reveal a tenderer’s submission before tender


opening time, and tenderers cannot change their submissions after the tender

close time.

A commitment function can provide either unconditional or computational

assurance of hiding and binding. For example, consider again the commitment

function C(m) = gm. If 1 < m < p then this function provides unconditional

binding since there is only one possible value of m given C(m). Therefore even

with unlimited computational power, it would be impossible for the prover P to

change its mind after committing. However, this same function provides only

computational hiding since if V has sufficient computational power to calculate

discrete logarithms then V can reveal m before it is opened by P .

There are also commitment functions which, in contrast, have unconditional

hiding and computational binding [86]. However, it is not hard to show that no

commitment scheme can provide both unconditional hiding and unconditional

binding. Likely candidates for the commitment function in our protocols include

the following.

• C(m) = gm where g is described above. Such a function is suitable when

unconditional binding is important.

• C(m) = gmhr where g and h are independent generators of Z∗p and r is

chosen randomly each time a commitment is made. This is Pedersen’s

scheme [86] and provides unconditional hiding.

• C(m) = h(m) for some one-way hash function h. This may be suitable

when efficiency is most important but this provides (at best) computational

hiding and binding.

In choosing a suitable commitment scheme for our protocol we must balance

the level of assurance for e-tender submission according to its legal purposes. The

submitted tender offer must be preserved over the long term as a requirement for

archiving purposes. Therefore it is preferable to choose a scheme that provides

unconditional binding assurance rather than one that provides unconditional hid-

ing assurance (since we cannot have both). Although in the tender submission

(commitment) phase, only computational hiding is provided, the period between

submission and tender opening time will be within a few hours. This is signifi-

cantly shorter than the period between tender opening and awarding time (which

may be days or months), and particularly shorter than the document archiving

requirements (which will usually be years). Therefore the binding property should


be given the higher assurance. Note that even though computational assurances

are less strong than unconditional assurances, we still expect them to hold within

any reasonable lifetime.

Role of Players

All commitment schemes assume that the prover P and the verifier V are ad-

versaries. The scheme will provide the hiding and binding properties only if no

collusion occurs between the players P and V . When collusion happens, the prin-

cipal is not a trustable verifier. One way to achieve this may be to distribute the

role of V amongst multiple players.

It must be assumed that all tendering related parties are dishonest players,

namely the principal A and the set of tenderers B. In a real situation, it is

very difficult to determine at what point which party is honest, therefore their

commitments preferably should be held by trusted third parties.

In a colluding situation, the colluding parties will include the prover P and

their opponents include the verifier V . We therefore need to assume that non-

colluding parties hold the commitments. This will increase the credibility of the

verifying process in the protocol. At this point, it will be a good strategy to

introduce a time stamping service.

6.3.2 Time Stamping Services

The function of a time stamping service is to reduce disputes over document

generation time. Time-stamping services have been proposed and analysed by

many researchers [51, 19, 77, 108]. The definition of a time stamp is digital data

intended to prove the existence of digital documents prior to, or at, a specified

time.

In general, a time-stamping service requires that a client send a request to

a service provider through the Internet to gain a time stamp for a document.

The service provider issues the time stamp of the document and sends it back

to the requester. Other processes could be involved, such as the service provider

publishing the time stamp to enhance the service integrity. If a dispute occurs at

a later time, the integrity of the time stamp and related document will be verified

through verification procedures associated with the chosen time-stamping service.

Time-stamping technology has been studied for more than a decade [51]. Tra-

ditionally it has been classified into two types according to the issuing process:


conventional or simple and linking schemes Section 3.1.2. Haber [51] also pro-

posed a distributed trust scheme by involving a trusted third party in the issuing

process. For systematic security analysis of time stamp schemes, Une and Mat-

sumoto [109, 108] performed fine grained classification based on many aspects

involved in time stamping other than just the issuing process.

Regardless of the significant body of research [18, 19], all time stamping ser-

vices require that a requester and issuer do not collude [109]. A hybrid time

stamping service1 with hardware support2 and linked schemes will largely limit

the capacity for collusion between requester and issuer.

6.3.3 Identity-Based Encryption

IBE schemes normally contain four algorithms: set up, extract, encrypt and

decrypt. A key generation centre (KGC) uses the set up algorithm to generate

global system parameters and a master-key. A user can then use the global system

parameters plus a personal identity (public key ID which can be any bit string) to

encrypt the message. The KGC uses the extract algorithm and the master-key to

generate the private key corresponding to the public key string ID. The encrypt

algorithm encrypts messages using the public key ID; and the decrypt algorithm

decrypts messages using the corresponding private key. Boneh and Franklin [11]

developed the first implementable IBE scheme based on elliptic curve pairings.

Another, less practical, IBE scheme based on quadratic residues was developed

by Cocks [28] around the same time. Detailed algorithms for IBE is attached in

Appendix A

The IBE system based on Weil Pairing by Boneh and Franklin [11] is proven

to provide a strong confidentiality security property. However, this does not

guarantee that the IBE scheme will provide submission hiding security service for

our e-tendering process. Submission hiding requires that no party can reveal any

electronically submitted e-tender document before the designated tender opening

time. If the decryption key is released before tender closing time, a colluding party

can gain another party’s tender strategy before tender close time, breaching the

security requirement for e-tender submission hiding.

A distinctive feature of IBE, as opposed to usual public key cryptosystems, is

that encryption can be performed even before the corresponding decryption key

1http://www.e-timestamp.com/evidence.htm2http://www-03.ibm.com/security/cryptocards/pcicc.shtml


exists. Application of IBE to the e-tender submission process relies on whether

the generation or distribution of decryption key can be effectively delayed until

after tender closing time. In fact, the IBE’s private key can be generated at the

time when public key is chosen, therefore to delay the generation of the decryption

becomes a trust issue. It requires that the KGC follow a certain procedure.

A time vault [21] is a scheme that uses an add-on procedure to delay the

decryption key generation. In the time vault scheme, a user chooses a document

opening time as part of input of encryption key. The time vault needs to ensure

that the decryption key is only generated when the document opening time in the

encryption key is smaller or equal to a current secure clock. It requires the KGC

to maintain a highly secure clock and strictly follow the time checking procedure.

The vulnerability of the time vault is that trust is high on the one time vault

centre. The time checking and comparison procedure is detachable from the key

generation process and can be manipulated easily. If the operator can feed into

the time checking procedure a later time string, the decryption key then can

be generated earlier than it should be. This will breach the submission hiding

requirement.

The submitted tender is the main target for collusion and needs high security

to protect its confidentiality against outsiders and colluding parties. The trust

has to be distributed by using a Distributed Key Generation Centre (DKG).

Based on earlier threshold schemes or cryptosystems [96, 86], DKG has become

the main component of threshold schemes [46]. Boneh and Franklin [11] also

extended their scheme to use DKG.

Another solution could be that the tenderer runs its own KGC to guarantee

that the decryption key is not generated earlier. This is only suitable for large

organizations with strong IT support. The principal may then need to deal with

multiple types of IBE encryption systems.

6.4 E-Tender Submission Protocols

Based on the two different e-tender submission hiding strategies, we offer two

protocol solutions: the first based on commitment schemes, the second based

on identity based encryption. These two protocols represent a tradeoff between

efficiency and trust in protocol design. One attempts to reduce trust but will

have more principal and tenderer interaction. The other reduces the tenderer’s

6.4. E-Tender Submission Protocols 141

interaction in order to provide an easy to use algorithm.

6.4.1 Notation

Commonly used notation in the protocol is listed in Figure 6.1. The function

commit() will represent any suitable commitment function. Party A represents

the principal in the tender process. Party B represents a tenderer in the set of

all potential tenderers B.

SYMBOL NAME

−→ One party sends another party a message eg. B −→ A, B sends to A

←→ Two way communication

‖ Concatenation

TSA Time Stamp Authority

PrivID Long term private key of party ID eg. PrivB , B’s private key

PubID Long term public key of party ID

CID Certificate of party ID

Sig Signature generation function

V Verifying function for timestamps

VPub Verifying function for digital signatures

Ex Asymmetrical encryption function, x represents input key

Dx Asymmetrical decryption function, x represents input key

ms Tender submission message in the contract negotiation

TSs TSA’s time-stamp on tenderer’s commitment on its ms

TSpl TSA’s time-stamp on concatenation of all tenderer’s commitments re-

ceived by principal

KGC Key Generation Centres for identity based encryption

DKG Distributed Key Generation Centres for identity based encryption

EKID IBE Encryption Key constructed by using DKG scheme

DKID IBE Decryption Key corresponding to the EKID, generated by DKG

Figure 6.1: Notation

6.4.2 Submission Protocol I

Submission Protocol I (Figure 6.2) uses a commitment scheme to hide tender

submissions. Both tenderer and principal need to request timestamps for their

crucial commitments. The submission protocol contains five messages between a

tenderer B and principal A.


1. Every tenderer B requests a timestamp TSB for its commitment Cs of its

offer ms. It also signs the commitment to form the signature σsB. The

tenderer then sends (Cs‖σsB‖TSs‖CB) to principal A before tender close

time.

2. A will verify TSs, σsB and send its confirmation RSPs including σsA to each

tenderer B. On receiving the message, each B will verify A’s signature over

its Cs.

3. At the tender closing time, A concatenates all received commitments Cpl =

(CsB1‖CsB2...‖CsBi...‖CsBj) and requests a timestamp for the concatenation

(TSpl). A then sends Mpl to all tenderers who have submitted offers (ten-

ders). The message includes concatenated commitments Cpl, A’s signature

σplA, timestamps TSpl and its certificate. The message also acts as a call

from principal A to all tenderers to submit their full documents (offers).

4. On receiving Mpl, each tenderer verifies Cpl, σplA, Cpl, TSpl, and checks

whether its Cs is in the received Cpl. If so, the tenderer signs the re-

ceived Cpl. Each tenderer also generates and signs the final submission

Cfs = commit(ms|Cpl) and sends Mfs to A with its full tender document

ms and other relevant values.

5. A extracts (ms‖σplB‖σfsB) from the received Mfs for each B and verifies

the signatures σplB, σfsB. A also verifies the integrity of ms, Cs and Cfs.

When the verifications are passed, A generates signature σfsA for the node

Cfs, and sends RSPfs to each B. On receiving the response, each B will

verify the confirmation and store the information as a record.

The protocol consists of the tender submission process (messages 1 and 2),

the tender closing process (message 3), and the tender opening process (messages

4 and 5). Once all of the full tender documents are received, tenders can be

officially opened.

6.4.3 Submission Protocol II

Instead of a commitment scheme, Submission Protocol II (Figure 6.3) uses iden-

tity based encryption with a Distributed Key Generation Center (DKC) for hid-

ing tender submissions. As for Protocol I, both a tenderer B and the principal


TSA A(Principal) B(Tenderer) TSACs = commit(ms)

σsB = Sig(Cs, P rivB)

get TSs for Cs←→

Ms = (Cs‖σsB‖TSs‖CB)

Ms←−if VPubB

(σsB , Cs) = 1

if V (TSs, Cs) = 1

σsA = SigPrivA(Cs)

RSPs = EPubB(σsA)‖CA

RSPs−→

(σsA) = DPrivB(RSPs)

if VPubA(σsA, Cs) = 1

—— tender submission close time ——

Cpl = (CsB1‖CsB2...‖CsBi...‖CsBj)

σplA = SigPrivA(Cpl)

get TSpl for Cpl←→

Mpl = (Cpl‖σplA‖TSpl‖CA)Mpl−→

if VPubA(σplA, Cpl) = 1 and

if V (TSpl, Cpl) = 1 andB check CsBi = Cs, with CsBi ∈ Cpl

σplB = Sig(Cpl, P rivB)

Cfs = commit(ms‖Cpl)

σfsB = Sig(Cfs, P rivB)

Mfs = EPubA(ms‖σplB‖σfsB)‖CB

Mfs←−(ms‖σplB‖σfsB) = DPrivA

(Mfs)

if VPubB(σplB , Cpl) = 1 and

if commit(ms) = Cs, where Cs ∈ Cpl

and

calculate C′fs = commit(ms‖Cpl) and

if VPubB(σfsB , C′

fs) = 1

σfsA = SigPrivA(Cfs)

RSPfs = EPubB(σfsA)‖CA

RSPfs−→

(σfsA) = DPrivB(RSPfs)

if VPubA(σfsA, Cfs) = 1

—— tender opening time ——

Figure 6.2: E-Tender Submission Protocol I


A need to request timestamps for their important commitments. DKC acts as a

time vault to ensure that A can only obtain the decryption key after tender close

time. In contrast to Protocol I, Protocol II only contains two communications

between each pair of A and B.

1. Every tenderer B signs its tender submission document ms to form the

signature σsB with its long term private key PrivB. B also gets time stamp

TSs from TSA for its σsB. B use IBE encryption key EKA to generate

Ms = EEKA(ms‖σsB‖TSs)‖CB and send Ms to principal A. The encryption

key EKA string is formed by the concatenation of the tender ID, tender close

time and other preferred information.

2. Before tender opening time, A concatenates all submitted Ms from each

tenderer B to form Mpl. A signs the Mpl and obtains the time stamp TSpl

for its signature σplA.

3. After tender close time, A obtains the IBE decryption key corresponding to

the public key EKA from the distributed key generation centres at tender

submission opening time. A decrypts the message Ms, and verifies TSs

and B’s signature against its submission ms. A generates its signature σsA

of the ms with its long term private key PrivA and sends the response

message RSPs to B. On receiving the message, B verifies A’s signature

and timestamp.

6.4.4 Summary

In Protocol I, the tenderer has more control over release of its own secret, and

can store other parties’ commitments in order to monitor the process. But the

protocol is complex for end users (tenderer and principal) since it requires multiple

interactions. In Protocol II, we delegate the duty of guarding the secret to the

IBE based DKG centre to delay the generation or distribution of decryption

key (acting as a time vault). In this scheme, the tenderer only need make its

submission once. Its full tender document is encrypted with an encryption key

constructed with multi-threshold public parameter, plus other information such

as the principal’s identification, unique tender identification and tender opening

time. The DKG centre generates the decryption key for the principal at tender

opening time.


DKG A(Principal) B(Tenderer) TSAσsB = Sig(ms, P rivB)

get TSs for σsB←→

Ms = EEKA(ms‖σsB‖TSs)‖CB

Ms←−Mpl =(MsB1‖MsB2...‖MsBi...‖MsBj)

σplA = SigPrivA(Mpl)

get TSpl for σplA←→

—— tender submission opening time ——

—— principal obtain decryption key from DKG ——

get DKA for EKA←→

(ms‖σsB‖TSs) = DDKA(Ms)

if VPubB(σsB , ms) = 1

if V (TSs, σsB) = 1

σsA = SigPrivA(ms)

RSPs = EPubB(σsA, σplA, TSpl)‖CA

RSPs−→

(σnA, σplA, TSpl) = DPrivB(RSPs)

if VPubA(σsA, ms) = 1

if V (σplA, TSpl) = 1

—— tender opening finished ——

Figure 6.3: E-Tender Submission Protocol II


6.5 Informal Security Analysis

The secure e-tender submission protocol defines a business process and is a com-

plex protocol, constructed by a set of more basic security mechanisms. These se-

curity mechanisms are based on mathematical algorithms for solving generic and

abstract security problems which may occur in a wide range of business processes.

The application of these security mechanisms forms the security foundation in a

complex protocol designed for a real business process.

The security analysis of a complex protocol is not a straightforward process.

It is helpful to analyze protocol security in both informal and formal ways. In-

formal analysis discusses functions of generic security mechanisms in the e-tender

submission protocol enabling an understanding of why the security properties

are achieved. The objective is to determine whether our system security designs

meet e-tender submission security requirements when the generic security mech-

anisms satisfy their security requirements. The informal analysis stage is also the

preparation for formal analysis.

6.5.1 Protocol Security Goals

Security services provided by a complex protocol should be matched to the set of

security goals defined for the protocol. We summarise the required security goals

of the protocol.

1. The principal A and any favoured tenderer Bfav cannot reveal other ten-

derers tender value ms before tender opening time, due to ms being hidden

in C = commit(ms) in protocol I and Ms = EEKA(ms‖σsB‖TSs)‖CB in

protocol II.

2. Any alteration of ms after tender opening time can be detected by the

verification process.

3. Any alteration of time stamping value TSs and TSpl can be detected by the

verification process.

6.5.2 Player’s Attacking Power

We assume that all players (principal and tenderers) are dishonest players. They

have interception, insertion and alteration powers at any stage of the protocol

6.5. Informal Security Analysis 147

run, as described in Section 5.6.2. In addition, the colluding power has been

identified as to have high likelihood in the e-tender submission process.

Interception Power: the power to intercept all parties’ network messages in

order to gain other parties’ tendering strategies.

Insertion Power: the power to insert malicious messages into the network dur-

ing the protocol run. For example, players can replay or relay intercepted

messages or insert extra tender values during the protocol run.

Alteration Power: the power to manipulate (alter, delete, and insert) all proto-

col generated elements belonging to them. It includes: the set of communi-

cated messages, the set of signatures from message originator and receiver,

the set of time-stamps from TSA.

Colluding Power: the power to collude with other players to cheat the system.

A dishonest player may attempt to gain financial benefit through the defined

attacks by using the powers described above. These attacks should be deemed

successful only if they cannot be detected by the protocol verification procedures

and the dishonest player gains financial benefit.

6.5.3 Hiding Tender Submission

The protocol prevents a dishonest principal and its favoured tenderer from gaining

any other tenderer’s strategy during tender submission process, and before tender

opening time. This will prevent Bfav from submitting a more competitive tender,

by knowing any other tender price.

Protocol I During submission process only the commitment Cs is required.

Tenderers do not need to submit their full tender documents. The colluding

principal has the power to access every party’s commitments and pass them to

its favoured tenderer. However, if the commitment function provides the hiding

property, no tender strategy can be obtained from the commitment value. The

protocol uses the hiding property to prevent any colluding party from revealing

opponents’ tender value ms before tender opening time.


Protocol II The submitted tender value ms is encrypted with the IBE scheme.

As long as the IBE scheme provides confidentiality, the principal cannot gain any

information of ms from the ciphertext Ms. As discussed earlier, IBE alone will

not provide the required security service for hiding tender submission. IBE needs

to be extended to use a DKG (Distributed Key Generation Centre) with the

threshold scheme to distribute the trust. This is to ensure that it is very hard for

a principal to collude with all KGCs to construct the decryption key before tender

opening time. Protocol II uses the IBE with DKG for hiding tender submissions.

6.5.4 Binding Tender Submission

The protocols prevent colluding parties from successfully changing their commit-

ments during the tender opening process by detecting any alteration through the

protocol verification process.

In this situation, the colluding parties will change Bfav’s tender ms to a com-

petitive value m′s after all tenderers have submitted their full tender documents.

To cover this alteration, they would need to recalculate all related values to avoid

the attack being detected.

Protocol I The colluding parties cannot recalculate time stamps TSs and

TSpl. Therefore the verification process will detect that V (TSs, C′s) 6= 1 and

V (TSpl, C′pl) 6= 1, with TSs and TSpl supplied by time stamping authority TSA.

The non-colluding tenderers also hold the principal’s commitment Cpl and TSpl.

The binding property of the commitment scheme is able to detect alteration of

committed values ms.

Protocol II Similar to Protocol I, based on the above assumption that trusted

TSA will supply the evidence of TSs over σsB, the colluding party Bfav of

the principal cannot recalculate the time stamp TSs for its signature σsB. If

Bfav generates signature σ′sB for m′s, the verification process will detect that

V (TSs, σ′sB) 6= 1. If Bfav does not generate σ′sB for m′s, the verification process

will detect that VPubB(σsB, m′s) 6= 1 even though V (TSs, σsB) = 1.

The colluding parties cannot change ms to m′s without detection in both pro-

tocols, therefore rendering the attack unsuccessful.

6.6. Formal Specification and Analysis 149

6.5.5 Fixing Submission Time

To prevent dispute over submission time of a commitment all parties are re-

quired to obtain a time stamp for their commitments. The protocol assumes

that TSA is a trustworthy party - therefore time stamps TSs and TSpl are

trustable values. For Protocol I, the dispute can be resolved by examining whether

TSs ≤ closetime ≤ TSpl, with TSA supplying the TSs and TSpl. The integrity

of TSs and TSpl can also be verified. For Protocol II, TSs can be provided by

TSA and integrity can be verified assume trust in TSA’s service.

From the above analysis, it can be concluded that if the generic security

mechanisms satisfy their security specification, the e-tender submission protocols

will provide the complex security services stated in their security goals.

6.6 Formal Specification and Analysis

A formal specification translates the protocol, its security goals and threat scenar-

ios into a formal language which can be analyzed, sometimes by software tools.

It is the complement of informal analysis in that it reduces the human errors

that may occur. It also increases the credibility of protocol analysis. The formal

language, tool and analysis processes are same as described in Chapter 5.

6.6.1 Language and Tool

As discussed in Section 5.7.1, we used the same Asynchronous Product Automata

(APA) formal specification language which is supported by the Simple Homomor-

phism Verification Tool (SHVT) [84]. Gurgens and Rudolph [48] have successfully

analysed security of a fair exchange protocol [112] using SHVT. The fair exchange

protocol shares related concepts with our e-tendering submission protocol.

APA models the collection of automata as protocol players or agents; and

the internal states of each player or agent as a set of state components. Each

automaton can only access the state components which have a link to it. A

protocol or a system specified with APA requires the allocation of roles of each

automata, the initial state of state components, and the transition relations (state

transition or actions). The specification is then analyzed using SHVT which

explores all possible states.

Through a transition relation, each role can change its state by the addition


and removal of elements stored in its state components. SHVT will execute each

specified transition pattern when a pre-condition is met. Following APA diagrams

show the roles and their state components for the e-tender submission protocol I

(Figure 6.4) and the e-tender subission protocol II (Figure 6.5 ).

B2_TimeStamp

A_TimeStampB A_SigB2

A_SigB

B2_Sig

A_TimeStampB2

A_State

A

A_AsmykeysA_CommitB A_CommitB2

B_TimeStamp

B_Sig

B2_State

B2_Asmykeys

B2_Commit

B2B

B_Commit

B_Asmykeys

B_State

TSATSA_TimeStamp TTPGlobal States

Network

Figure 6.4: APA Diagram of E-Tender Submission Protocol I

The pre-condition reduces state explosions during the analysis. However like

other tools, SHVT faces the problem of state explosion when a full state search

is performed. It is also difficult to interpret the search result when the searching

space increases. These problems will become more significant for a complex e-

commerce protocol than for simple and generic protocols.

In our analysis, SHVT is used to search all possible states under specified

environments, normally threat scenarios. The search result is analyzed to deter-

mine whether any reachable state represents a successful attack. If no such state

is found, we claim that the protocol is secure under the specified condition.

6.6.2 Procedures of Formal Specification

The main purpose of the e-tendering submission protocols is to preserve submis-

sion integrity against alterations by players. Providing an adequate verification

procedure is the core of the protocol design. To formally specify and analyze


B2_State

B2_Asmykeys

B2_CommitA_CommitB2A_AsmykeysA_StateA_CommitB

B2

A

B

B_Commit

B_Asmykeys

B_State

TSATSA_TimeStamp TTPGlobal States

Network

Figure 6.5: APA Diagram of E-Tender Submission Protocol II

e-tendering submission protocols, we follow the same procedures discussed in

Section 5.7.2:

1. identify all the required verifying elements,

2. specify all the verifying procedures,

3. define protocol assumptions for defining transition pattern pre-conditions,

4. formalize protocol security goals,

5. specify protocol initial state components,

6. specify transition patterns for formal analysis with SHVT.

6.6.3 Required Verifying Elements and Verification Process

The required verifying elements are determined by the following principle:

For contracting purposes At the end of the e-tender submission process A

needs to have the evidence to prove that it is B who sent the commitment

and B needs to have the evidence to prove that A received the commitment.

For evidence reliability the contracting evidence should be the complete set

of inputs for the integrity verification process.


Submission Protocol I

The verification elements required for Submission Protocol I have been identified

and listed in Table 6.2.

M C SigO SigR TS

ms Cs σsB σsA TSs

Cpl σplA σplB TSpl

Cfs σfsB σfsA

Table 6.2: Required Verifying Elements for E-Tender Submission Protocol I

• The set {ms} is the communicated tender offer sent from party B to A.

• C {Cs, Cpl, Cfs} is a set of communicated commitments generated by both

parties.

• SigO {σsB, σplA, σfsB} is a set of sender signatures.

• The σsB, σfsB are signatures over each Cs and Cfs when it is generated by

the sender B.

• σplA is over Cpl when generated by sender A.

• SigR {σsA, σplB, σfsA} is a set of receiver signatures.

• The σsA, σfsA are signatures generated over each Cs and Cfs after the mes-

sage had been verified by the receiver A.

• σplB is a signature over Cpl after the message had been verified by the

receiver B.

• TS {TSs, TSpl} is a set of timestamps generated by TSA when requested

by B for ms and by A for Cpl.

• ms is the tender offer that both parties should agreed upon.

• C, SigO, SigR, TS are sets of elements for verifying ms’s integrity, evidenc-

ing of sending and receiving, and time of sending and receiving.


During the verification process each player should submit the set of elements

listed in Table 6.2 and the following verification is performed by a third party such

as a judge. Each element in C will be verified using the commitment scheme.

For example, to verify ms, calculate C ′s = commit(ms), and then determine

whether C ′s = Cs. Other commitments can also be verified using the same logic.

Each sender’s signature in SigO will be verified using corresponding signature

verification procedures. It can be generically represented as VPubO(σsO, Cs) = 1.

Each receiver’s signature in SigR will be verified using corresponding signature

verification procedures as well. The procedures will be similar to the procedures

in verifying sender’s signatures, such as VPubR(σsR, Cs) = 1. All timestamps

should be verified and the verification procedure can be generically represented

as V (TSs, Cs) = 1 and V (TSpl, Cpl) = 1.

Submission Protocol II

The verification elements required for submission protocol II have been identified

and listed in Table 6.3.

M SigO SigR TS

ms σsB σsA TSs

Mpl σplA TSpl

Table 6.3: Required Verifying Elements for E-Tender Submission Protocol II

• M {ms, Mpl} are communicated offers between tenderers in the set B and

principal A.

• The set ms is each tenderer’s full tender document.

• Mpl is the concatenation of each tenderer’s submission message. This mes-

sage is encrypted and includes all relative elements such as signatures and

timestamps.

• SigO {σsB} is the sender signature over ms when it is generated by the

sender B.

• SigR {σsA, σplA} are the receiver’s signatures over each ms and Mpl after

they had been verified by the receiver A.


• TS {TSs, TSpl} is a set of timestamps which is generated by TSA when

requested by B for ms and by A for Mpl.

During the verification process for Submission Protocol II, each player will

submit the listed elements in Table 6.3 and perform the following verification

mechanisms. The verification of sender’s signature SigO over ms can be generi-

cally represented as VPubB(σsB, ms) = 1. V represents corresponding verification

process related to each signature scheme. The verification of receiver’s signa-

ture SigR will be similar to the above sender’s signature and can be represented

as VPubA(σsA, ms) = 1. Depending on the timestamp scheme, the verification of

timestamps can be represented as V (TSs, σsB) = 1 for TSs and V (TSpl, σplA) = 1

for TSpl.

6.6.4 Protocol Assumptions

Simplifying assumptions [13] have been introduced to make the security analysis

feasible for the tool aided process. The objective of simplifying assumptions is

to define the limitations of an attacker’s power. It can also include definitions

of generic security mechanisms as black boxes providing their intended security

services. Therefore the definition of a set of simplifying assumptions becomes

a security metric for a complex protocol. The level of simplification becomes

a metric to measure the level of assurance for security analysis that a complex

protocol achieves.

We assume that TSA is a trusted party and generates reliable time-stamps.

Although a fully trusted TSA does not exist, as discussed in Section 6.3.2, a

hybrid timestamping system can largely eliminate collusions and provide an ad-

equate service.

We also assume that DKG is a trusted distributed key generation scheme for

the IBE system. This scheme can effectively delay the decryption key generation

or distribution to after tender close time. DKG has to use a threshold scheme

to ensure that keys are generated as the rules define. To compromise DKG, one

has to compromise key generation centres, which is not a trivial task.

For protocol players (tenderers and principal), we assume that keys are se-

curely stored and no party will intentionally release its private keys to any other

(non-colluding) party participating in the tendering. Release of a private key to

other parties is a self destructive behaviour. It does not bring any financial ben-

efit to a player. We also assume that no party will omit any verification process


during the protocol run. Omitting verification processes is equivalent to trusting

everybody. This behaviour is also not in the best interest of the party.

We assume that encryptions are perfect, and keys cannot be guessed. In

reality, a well established encryption scheme does provide the assumed security

services. Therefore we assume that:

• if EPub(m) = EPub′(m′), then Pub = Pub′ and m = m′;

• if commit(m) = commit(m′), then m = m′, for commit() any commitment

function;

• if SigPriv(commit(m)) = SigPriv′(commit(m)′), then commit(m) = commit(m)′,

and Priv = Priv′;

We also assume that the following principles are followed:

• supplied verifying (challenging) elements are publicly available during the

verifying process.

• no party can cheat on verifying (challenging) procedures: they are trans-

parent and run in public by third parties such as court and judges.

6.6.5 Formalized Protocol Security Goals

Under predefined assumptions, and after each successful protocol run, the e-

tender submission protocol should ensure:

1. that principal A cannot obtain ms before tender close time;

2. that A generates a complete set of elements for verifying the e-tender sub-

mission evidence integrity,

{M, C, SigO, SigR, TS } for Protocol I,

{M, SigO, SigR, TS } for Protocol II.

3. that both A and B possess identical sets of elements.

4. that each element is verified during its generation process.


6.6.6 Specify Initial State Sets

The APA diagram (Figure 6.5) shows the roles and their state components. Each

role is connected to its own state components, such as State,Asymkeys,CommitB.

All roles share the Network state component.

The specification of initial state sets involves defining roles, role state com-

ponents, functions, data types, and assigning initial values to state components

and constant variables.

The defined roles of both Protocol I and Protocol II are:

Command Role

def_role A; Role A is the principal

def_role B; Role B is the tenderer1

def_role B2; Role B2 is the tenderer2

def_role TSA; Role TSA is the TimeStamping service

def_role TTP; Role TTP is the judge for verifying protocol values

The role A’s state components are initialized as the following for protocol II:

def_state A State: Messages_seq :=

[TSA,‘server’].[‘respond’,B].[‘respond’,B2];

def_state A Asymkeys: Asymkeys_seq :=

(A,‘priv’,‘Apriv’).(B,‘pub’,‘Bpub’).(B2,‘pub’,‘B2pub’);

def_state A CommitB: Messages_seq := ::;

def_state A CommitB2: Messages_seq := ::;

def_state command states that role A have a state component State is

Messeges_seq type. := assign the initial values

[TSA,‘server’].[‘respond’,B].[‘respond’,B2] to state component State.

6.6.7 Specify Transition Relation or Patterns and SHVT

Analysis

Transition patterns have been specified for both Protocol I and II by using the

preamble editor in SHVT. The specifications firstly model that all players are

honest, then models four threats scenarios. The threat modeling is done by either

relaxing some pre-conditions in each transition pattern or inserting malicious

actions in some transition patterns.


Verification process transition patterns are also specified for both protocols.

A set of global state components have been defined for each player to submit

their verification elements. During the process, each player will send the relevant

verification elements (listed in Figure 6.2 and Figure 6.3) to correlated global state

components for trusted third party (TTP) to retrieve. The verification process will

perform the necessary comparison and calculation to detect possible attacks.

Modeling all Players as Honest

This step is to ensure that all the required verification elements can be collected

after a successful protocol run. The following two pieces of codes specify:

1. the first step of A at tender close period in protocol I (Table 6.4);

2. the first step of tender submission for tenderer B in protocol II (Table 6.5).

Modeling Threat Scenario One (S1)

Section 6.2.2 has described four threat scenarios that may happen in e-tender

submission. S1 describes that a principal may release other tender submissions

to its favourite tenderer before tender submission closing or opening time. For the

attacker (principal) to win, it has to obtain the plaintext of other tender submis-

sions before the tender close time. The S1 attack is only applicable to Protocol I.

It is not applicable to Protocol II, which using distributed IBE encryption system

for tender hiding. This has been discussed in Section 6.5.3.

Protocol I S1 The attacker, principal A, tried to obtain the plaintext tender

submission before tender close time. It first obtained timestamp from TSA earlier

than the tender close time. Because it could not collude with TSA, the principal

would have a timestamp with time value smaller than the tender close time. We

defined that ‘TS_A0’ contains time value smaller than the tender close time. We

defined ‘TS_A’ contains time value equal or greater than the tender close time.

Another transition pattern was defined for the principal, in which it obtains

time stamp ‘TS_A0’. The principal formed messages for B and B2 with the

timestamp

eAb:=crypt(bpub,[Lpl,sig,‘TS_A0’]) and eAb2:=crypt(b2pub,[Lpl,sig,‘TS_A0’]).

It then sent message (B,A,[eAb,‘hshpl’]), and message (B2,A,[eAb2,‘hshpl’])

to Network for B and B2.


eAb := crypt(bpub,[Lpl,sig,‘TS_A0’]),

eAb2 := crypt(b2pub,[Lpl,sig,‘TS_A0’]),

(B,A,[eAb,‘hshpl’]) >> Network,

(B2,A,[eAb2,‘hshpl’]) >> Network,

On receiving the message both B and B2 would test whether ‘TS_A0’=‘TS_A’.

The test failed and they did not respond to this malicious activity. Therefore A

failed to obtain plaintext tender submission before tender close time. The SHVT

analysis shows that no transition pattern of B and B2 had been executed to extend

this malicious transition pattern. It proved that our protocol is safe under this

attack.

Modeling Threat Scenario Two (S2)

S2 describes that the principal may allow its favoured tenderer to alter its tender

after the tender official opening time. We say that the colluding parties will win

only if they can change the submitted tender value to a winning one without

being detected by the verification process.

Protocol I We defined B as the principal’s favoured tenderer. Tenderer B

changed its original plaintext submission ‘msb’ to ‘attack_data’ and sent it

to the global state component for the TTP to retrieve. The Time Stamping Au-

thority TSA also sent B’s commitment on ‘msb’ and related timestamp ‘TS_B’ to

the global state component for TTP to retrieve. In the verification process tran-

sition pattern, B’s ‘attack_data’ was entered into the commitment function,

and this calculated commitment of B was compared with TSA’s submission. The

SHVT run showed that as a result of this comparison the transition pattern could

not be executed. This means that this attack will be detected by the Submission

Protocol I’s verification process.

Protocol II As in Protocol I, tenderer B changed its original plaintext submis-

sion ‘msb’ to ‘attack_data’ and sent to a global state component for the TTP

to retrieve. Time Stamping Authority TSA also sent B’s signature on ‘msb’ and

related timestamp ‘TS_B’ to the global state component for TTP to retrieve. In

the verification process transition pattern, B would have to re-sign its submitted

‘attack_data’,and this signature was compared with TSA’ s submission. The

SHVT run showed that this comparison failed and the transition pattern could


not be executed. It means that the Submission Protocol II can also detect this

attack through the verification process.

Modeling Threat Scenario Three (S3)

In S3, the principal may allow its favoured tenderer to submit a tender after

close time. Again for the colluding parties to win, the later tender must not be

detected by verification process. For this attack scenario, modeling uses the same

procedures as above and both protocols use the same time stamp comparison

process.

We defined that ‘TS_B’ contains a time value which is equal to or smaller

than tender close time and ‘TS_1B’ contains a time value which is greater than

the tender close time. Because B could not collude with TSA, it obtained ‘TS_1B’

from TSA.In the verification transition pattern, these two time values would be

compared. The SHVT analysis shows that verification process transition pattern

could not be executed which means that this attack will be detected. This analysis

has been performed in both protocols and the results are the same.

Modeling Threat Scenario Four (S4)

S4 states that the principal may include multiple tenders submitted by its favoured

tenderer for the tender opening process to maximize its winning opportunity. If

these redundant tender submissions can be deleted without being detected after

the tender opening time, the colluding parties will win the game. The detec-

tion process is same for both protocols though submitted value may be different

between Protocol I and Protocol II.

We defined B as the favoured tenderer of principal A. B submitted multiple

tenders to A. Because A could not obtain other parties’ plaintext tender submis-

sions before tender close time (see S1 section), it had to include B’s multiple

submissions into concatenated value Cpl for Protocol I and Mpl for Protocol II.

This was to ensure that all of B’s submissions were legitimate and timestamped

by TSA. During the verification process, TSA would submit its timestamps of the

corresponding value Cpl and A’s signature on Mpl. B could either send multiple

tender submissions to TTP or only send winning tender submission ‘msb’. This

first strategy would show that A had included B’s multiple tender submissions for

the tender opening process. For the second strategy, SHVT analysis showed that

the verification process transition pattern could not be executed in both protocol


models which means that the deleted multiple submission can be detected.

6.7 Summary

This chapter investigated the fundamental differences between a simple e-tender

box and a traditional physical tender box, and highlighted four common security

threat scenarios created by those functional differences. Based on our findings,

we have defined the security requirements for an e-tender submission protocol:

submission hiding, submission binding and integrity of submission time.

We also studied functional limitations of related cryptographic technologies

for their application in constructing a secure e-tendering submission protocol. A

set of cryptographic technologies has been chosen, digital signature, hash chain

technology, symmetrical and asymmetrical encryption, identity based encryption,

timestamping services, commitment scheme, to achieve the protocol security re-

quirement. As a result, two secure e-tender submission protocols were presented

which enable a secure e-tender submission. Protocols are assumed to run under

the condition that all tendering parties (principal and tenderers) are dishonest

players. Informal and formal methods have been applied for the analysis of these

protocols’ security.

A six-stepped formal specification process has been outlined in Section 6.6.

The security analyses were modeled against attacking scenarios, the result show-

ing the protocols are secure against designed attacks. The security analysis shows

that these protocols meet their security goals under well known collusion scenar-

ios.

The two protocols are also designed to use the standard cryptographic algo-

rithms such as digital signature, cryptographic hash functions and IBE. There is

no significant computation cost for each communicated message. The e-tendering

submission close time is normally an e-tendering term and condition which has

been notified to all the tenderers several months before hand. In our opinion, the

standard cryptographic algorithm used in the two e-tender submission protocols

will not affect the performance of the e-tender submission process.

6.7. Summary 161

/***** Protocol I ******/def_trans_pattern A clstndr1_10(Lpl,Lsb,Lsb2,sig,eAb,eAb2,apriv,bpub,b2pub)

(A,‘priv’,apriv) ? A_Asymkeys,(B,‘pub’,bpub) ? A_Asymkeys,(B2,‘pub’,b2pub) ? A_Asymkeys,[‘start’, B] << A_State,[‘acceptance’] ~? A_State,[‘offer’] ? A_State,(‘fnsh_sbmtb’) ? Netmsg,(‘fnsh_sbmtb2’) ? Netmsg,(‘TS_B’) ? Netmsg,(‘TS_B2’) ? Netmsg,[Lsb,‘expect_ms’] << A_CommitB,[Lsb2,‘expect_ms’] << A_CommitB2,Lpl := [Lsb,Lsb2],(TSA, A, [Lpl]) >> Network,

sig := sign(apriv,Lpl),sig >> A_SigB,sig >> A_SigB2,[‘TS_A’] >> A_TimeStampB,[‘TS_A’] >> A_TimeStampB2,[Lsb,Lpl,‘expect_ms’] >> A_CommitB,[Lsb2,Lpl,‘expect_ms’] >> A_CommitB2,eAb := crypt(bpub,[Lpl,sig,‘TS_A’]),eAb2 := crypt(b2pub,[Lpl,sig,‘TS_A’]),(B,A,[eAb,‘hshpl’]) >> Network,(B2,A,[eAb2,‘hshpl’]) >> Network,[‘hshpl’] >> A_State,[‘expect_ms’] >> A_State,(‘clstndr’) >> Netmsg;

Table 6.4: Example Code of Player A in Protocol I


/***** Protocol II ******/def_trans_pattern B offer1_1(Ms,sig1,sig2,eB,bpriv,apub)

(B,‘priv’,bpriv) ? B_Asymkeys,(A,‘pub’,apub) ? B_Asymkeys,[‘start’, A] << B_State,[‘offer’] ~? B_State,Ms := ‘msb’,sig1 := sign(bpriv,Ms),(TSA, B, [sig1]) >> Network,eB := crypt(apub,[Ms,sig1,‘TS_B’]),(A,B,[eB,‘offer’]) >> Network,

[Ms,sig1,‘TS_B’,‘expects_CON’] >> B_Commit,[‘expect_A_cmf’] >> B_State,[‘offer’] >> B_State;

Table 6.5: Example Code of Player B in Protocol II

Chapter 7

Conclusion

Securing the electronic tendering process has been the purpose of this research.

It focused on achieving each research objective (in Section 1.1) associated with

providing adequate security services for the e-tendering process. This chapter

summarizes the research conclusions and contributions, and discusses future re-

search directions.

7.1 Conclusions and Contributions

All four research objectives defined in Section 1.1 have been achieved. The fol-

lowing sections will discuss the research output and methods used for successful

secure protocol design.

Objective 1. Establishing generic security requirements for the e-tendering

process

The objective here was to investigate business processes involved in traditional

tendering and the tendering processes provided by current e-tendering systems

in Chapter 2. It also investigated related obligations and anticipated common

threats for the e-tendering systems in Chapter 4.

In order to establish generic security requirements, we anticipated potential

threats to each step of the e-tendering process. A set of generic security require-

ments or policies were drawn up to protect against those threats (Chapter 4).

The processes involved in establishing security requirements are:

163

164 Chapter 7. Conclusion

1. identifying the generic threats that exist in using an electronic medium;

2. anticipating potential security breaches against the tendering process when

replacing the paper-based medium with the electronic medium;

3. mapping the anticipated threats to generic security solutions to establish

generic security requirements for the e-tendering process.

This method has enabled us to establish basic and advanced high level security

requirements for securing an e-tendering system (in Chapter 4). A secure protocol

normally targets a subset of e-tendering processes to provide advanced security

services. In this case, security requirements need to be refined for each security

protocol. The above analysis also identified two significant security issues that

need to be addressed by advanced security services: e-tender negotiation integrity

and e-tender submission process integrity.

Objective 2. Associating security requirements to generic cryptographic security

mechanisms for the e-tendering process

This research objective is to refine security requirements for building a se-

cure e-tender negotiation integrity protocol suite and secure e-tender submission

protocols. From the refined security requirements, a set of generic cryptographic

mechanisms will be selected for building secure protocols. The method we used

are based on two principles described in Section 1.2: Principle 1. Functional

difference identification and Principle 2 Functional limitation assessment.

Principle 1: A functional difference could happen when potential threats and

threat scenario occurs. A combination of generic threats to the electronic

medium could form a threat scenario in a business process. Both the generic

threats and threat scenarios could cause an e-tendering system to function

differently to a traditional paper-based system. Identifying functional dif-

ferences will allow a designer to move away from the high level of generic

security requirements to define composite security requirements for provid-

ing advanced security services. Through these analyses we defined advanced

security requirements for building secure e-tender negotiation integrity pro-

tocol and secure e-tender submission protocols. The research outcomes have

been documented in Section 5.2 and Section 6.2 accordingly.

7.1. Conclusions and Contributions 165

Principle 2: A set of generic security mechanisms can be associated with the

above refined security requirements for this subset of processes in an e-

tendering system. This set of generic security mechanisms have to be

assessed with respect to their limitations for providing intended security

services. This assessment has found functional limitations when a generic

security mechanism is applied to an e-business protocol providing composite

security services. These discoveries have been documented in Section 5.3

for secure e-tender negotiation protocol and Section 6.3 for secure e-tender

submission protocols.

These two generic issues discovered in the course of this research, functional

difference and functional limitations, were fundamental in constructing secure

protocols for tender negotiation and submission processes. Functional differ-

ence identification derived advanced security requirements. Functional limita-

tion assessment defined how the logic of generic security mechanisms should be

constructed. These principles formed a proactive analysis applied prior to the

construction of security protocols.

Objective 3. Designing secure e-tendering protocols to provide advanced security

services

A secure e-tender negotiation protocol suite (Chapter 5) and two secure e-

tender submission protocols (Chapter 6) have been proposed to provide desired

security services for the e-tendering process. The secure e-tender negotiation

protocol suite contains a set of sub-protocols designed for contract negotiation

process, final contract signing process, and other premature termination processes

in e-tendering systems.

Selected generic security mechanisms were constructed in a unique way for

each protocol, such that their functional limitations were avoided. ??? It is the

logic of how generic security mechanisms are composed that provides the com-

plex security services for e-tendering process. Informal analyses were performed

for basic security verification of this structure. Informal analysis is used to un-

derstand the logic of how protocol is constructed rather than providing security

assurance.

Objective 4. Performing security analysis of e-tendering protocols using formal

methods


We performed formal analysis on both secure e-tender negotiation protocols

and submission protocols. The verification processes and results are in Section 5.7

for secure e-tender negotiation protocols and 6.6 for secure e-tender submission

protocols. Protocol flaws were also found during the formal specification process,

documented in Section 5.7.9. Threats are also modeled for both protocols.

Of great importance is the derivation of formal protocol security goals from

the plain English defined security requirements. This transformation is a progres-

sive process, requiring extra analysis and discussion. The process is intended to

encompass most of the security requirements for the protocol. As yet, the quality

of this process and the protocol assumption definition are not measurable.

The primary contributions of this stage were the procedures developed for the

complex e-business protocol analysis using formal methods. It also demonstrated

that proactive analysis has made this formal security verification possible and

practical for complex protocols.

Obligations (regulations and standards)

Anticipated threats

Threat scenarios

Generic security mechanism

Protocol assumption

Protocol construction logic

Security goals

Protocol security formal verification

Protocols

Attacker’s power

Advanced security requirements

Generic security requirements

Potential threats to electronic medium

Figure 7.1: Protocol Design Process Diagram

The Figure 7.1 provides a summary of intermediate outputs from our pro-

tocol design process. These study outcomes have raised awareness of security

issues in e-tendering. The security solutions proposed in the protocol format

7.2. Future Research 167

were the first in e-tendering with verifiable security against common threat sce-

narios, and which were also practical for implementation. To certain extend the

newly designed protocols provide better scheme in the evidential document in-

tegrity management and tender submission process than its paper based system.

The e-tender negotiation protocol suite will automatically manage e-tender docu-

ment security therefore reduce human errors. The e-tender submission protocols

provide securer document hiding than a sealed physical tender box.

As mentioned in Section 2.4.3, the current e-tender implementations provide

limited security functions such as using user name and password for system ac-

cess, and TLS for communication confidentially and digital signature for no-

repudiation. However these functions were not constructed in a way to provide

advanced security services discussed for e-tender negotiation protocol suite (Chap-

ter 5) and e-tender submission protocols (Chapter 6). Therefore they are prone

to the attacks defined in common threat scenarios. Our secure protocols have

the potential to provide verifiable security assurance for the full automation of a

tendering process.

The procedures developed for securing the e-tendering process were generic

and could be applied to other business domains. The study has made improve-

ments in: establishing adequate security for a business process; applying proactive

analysis prior to secure protocol construction; and verifying security of complex

e-business protocols using tool aided formal methods.

7.2 Future Research

Reviewing the research we see that protocol design normally contains the follow-

ing cycles: potential threat analysis, establish security requirements, associating

these requirements with generic security mechanisms, constructing protocols and

protocol security verification. Obtaining an adequate security requirement is the

first step of a successful protocol design.

There is no existing formula to direct a designer as to how to obtain adequate

security requirements. It is an engineering process and relies on investigation of

all possibly related issues such as legal, business, risk. Therefore accumulating

past experience and widening research areas into different business types are

very important for future research. Functional difference between a replicated e-

business and the traditional process can happen in other business domains. This


leads to a range of new security threats. Further research can extend to other

business domains or complex systems where obligation compliance is important.

The research results are valuable expert knowledge.

Mapping security requirements to a set of generic security mechanisms may

appear to be a easy process, but any ignorance of these mechanism’s limitations

can become a hidden point of failure for protocol designs. Again, the assess-

ment of functional limitations are based on expert knowledge, because protocol

assumptions are sometimes documented and sometimes hidden. For example,

knowing the functional limitations of generic cryptographic mechanisms is very

important for non-security specialists trying to associate a security function with

a system security requirement by using any of the software security analysis tools.

Third part of the design is to verify whether the designed security protocol

protects against common attacks, and carefully avoids the generic security mech-

anism’s limitations. The logic of composition of these generic mechanism are then

tested by modeling common threat scenarios. Tools used for security verification

are also designed for other logic verifications. There is a need to establish a sim-

plified security verification model for protocols within similar business domain.

It also depends on widening research area to other business process or domains

to optimize the verification process by establishing and reusing generic models.

Security study can be considered as two dimensional, horizontal and vertical.

Horizontal research tries to develop generic security solutions, such as generic

cryptographic mechanisms and communication protocols which can be applied

to many business environment. Vertical research refers to studying security re-

quirements and solutions for each type of business processes. This may include

analyzing one particular business process, its related potential security threats,

establishing security requirements, and providing adequate solutions. Each solu-

tion is unique in its way. Therefore developing generic processes by refining and

optimizing the current process are important for e-business security design.

Formal analysis of complex systems is more effective when applied by the de-

signer during the design. Identify the flaw in early stage design of complex secu-

rity protocols. Further investigation has the potential to discover more functions

using formal method in supporting protocol design or system security implemen-

tation. Another issue is to perform a fine grained protocol security analysis by

strategically relaxing more assumptions.

Formal verification or validation as shwon in this thesis does not provide proofs

7.2. Future Research 169

of security. The protocol is secure against attacks considered in the model, but

there might be other attacks. This is still an open issue.

In conclusion, the uncertainty of e-business security protocol design stays in

each business domain and a successful design relies on expert knowledge obtained

from each business domain. The accumulation of expert knowledge using generic

process may contribute to developing an intelligent reasoning system for security

protocol design. A future research goal can be to optimize the established process

by making the security analysis and proof more generic and efficient. Industry ap-

plication of this research can employ procedures to analyze other business process

areas, such as securing Internet property transactions, virtual markets and auto-

mated government procurement activities. These applications will also feed back

into process optimization research.

Appendix A

Cryptography

A.1 RSA Algorithm

The RSA public-key scheme is based on problem that factorization of integers into

their prime factors is hard. The scheme contains key establishment, encryption

and decryption phases. This plain RSA is not secure.

1. Key generation:

• Bob chooses two distinct large primes p and q and

• multiplies them together to form n = pq

• Bob chooses an encryption exponent e such that gcd(e, (p−1)(q−1)) =

1

• Bob computes d with de ≡ 1 (mod (p− 1)(q − 1) )

• he sends public key (n, e) to Alice

• he keeps private key (p, q, d) secret,

2. Encryption:

• Alice writes a message m, with m < n. If m > n, break m into blocks

such that each block is smaller than n

• Alice computes c ≡ me (mod n) and sends c to Bob

171

172 Appendix A. Cryptography

3. Decryption:

• Bob decrypts c by computing m ≡ cd (mod n)

The scheme can be adapted to RSA digital signature scheme. The plain

RSA encryption scheme is normally used with Optimal Asymmetric Encryption

Padding (OAEP) [72] to achieve provable strong confidentiality. RSA Probabilis-

tic Signature Scheme (PSS)[73] is the according adjustment for RSA based digital

signature schemes.

A.2 Diffie-Hellman Key Exchange

Diffie-Hellman key exchange scheme is based on Diffie-Hellman problem which

is no harder than a discrete logarithm problem. The discrete logarithm (DL)

problem states that given a prime p, a cyclic group Z∗p , a generator α, for every

elements β ∈ Z∗p , find integer x, 0 ≤ x < p − 2 with β ≡ αx ( mod p ) is

the discrete logarithm (DL) problem. In many groups the problem is hard or

intractable.

Diffie-Hellman (DH) problem can be described as given a prime p, generator

g ∈ Z∗p , and ga mod p and gb mod p, where a, b are randomly and independently

chosen, find gab (mod p) in not harder than the DL. The DH problem can be used

to establish a shared secret for two people to exchange messages.

Many of this shared key have to be sent to other party which run a risk to

be intercepted during the key transmission. Using Diffie-Hellman key exchange,

Alice and Bob only need to send partial information to each other. After infor-

mation exchange, both can calculate the shared key individually, which avoiding

transmit the shared key.

The Diffie-Hellman key exchange protocol:

1. Alice and Bob agree on a finite cyclic group Z∗p and a generator g ∈ Z∗p .

2. Alice chooses a random natural number a and sends ga to Bob.

3. Bob chooses a random natural number b and sends gb to Alice.

4. Alice computes (gb)a.

5. Bob computes (ga)b.

A.3. ElGamal Public Key Cryptosystem 173

Both Alice and Bob are now in possession of the group element gab which can

be used as the shared secret key.

Similar to DH problem, the Computational Diffie-Hellman (CDH) and Desi-

sional Diffie-Hellman (DDH) assumptions are also based on DL. These assump-

tions play important roles for building other asymmetrical cryptographic schemes.

The computational Diffie-Hellman (CDH) assumption is the assumption that

a certain computational problem within a cyclic group is hard. Consider a cyclic

group Z∗p . The CDH problem states that, given (g, ga, gb) for a randomly-chosen

generator g and random a, b ∈ {0, . . . , p− 1}, it is computationally intractable to

compute the value gab.

The decisional Diffie-Hellman assumption (DDH) is related to the CDH as-

sumption. DDH assumption believe that it is hard to distinguish tuples of the

form (g, ga, gb, gab) from random tuples. Consider a cyclic group Z∗p , the DDH

assumption states that, given (g, ga, gb) for a randomly-chosen generator g ∈ Z∗p

and random a, b ∈ {0, ..., p − 1}, the value gab is a perfectly random element of

Z∗p .

This fundamental concept formally states that the following two tuples are

computationally indistinguishable: (g, ga, gb, gab), where g, a, b are chosen at ran-

dom as described above ; (g, ga, gb, gc), where g, a, b are chosen at random and c

is chosen at random from {0, ..., q − 1}.

A.3 ElGamal Public Key Cryptosystem

The ElGamal public key cryptosystem is based on intractability of discrete loga-

rithm and the Diffie-Hellman problem [81, 106]. The encryption scheme is devel-

oped by ElGamal [42] in 1985.

1. Key generation:

• Bob chooses a large random prime p, a generator g ∈ Z∗p ,

• Bob chooses a secret random integer a, 1 ≤ a ≤ p− 2 and compute ga

(mod p )

• Bob makes ( p, g, ga ) to be public as his public key

2. Encryption:


• Alice creates a message m and obtains ( p, g, ga )

• Alice represents m as an integer in the range {0, 1, . . . , p− 1}

• Alice chooses a secret random integer k, 1 ≤ k ≤ p− 2 and

• Alice computes r ≡ gk (mod p)

• Alice calculates t ≡ (ga)km (mod p)

• Alice sends ciphertext c = (r, t) to Bob.

3. Decryption:

• Bob uses private key a to compute rp−1−a (mod p), which is rp−1−a =

r−a = g−ak

• Bob obtains m by computing tr−a ≡ m (mod p),

If ciphertext is correct then tr−a ≡ (ga)km(gk)−a ≡ gakmg−ak ≡ m.

The problem of recovering m by breaking the ElGamal encryption scheme with

known knowledge of p, g, ga, gk, mgak is equivalent for solving the Diffie-Hellman

problems. Effectively it can be viewed as the Diffie-Hellman key exchange proto-

col, to generate shared session key gak. Because the message is multiplied with

the session key, the security of the ElGamal encryption scheme is said to be based

on the discrete logarithm problem in Z∗p [81] (has not been proven).

A.4 Plain RSA Signature Scheme

RSA signature was first published by Rivest et.al.[90] with RSA public key encryp-

tion system. It relies on the intractability of the integer factorization problem.

The RSA signature scheme contains following procedures.

1. Set up:

• Alice generates two large primes p, q, and compute n = pq.

• She chooses ealice such that 1 < ealice < φ(n) with gcd(ealice, φ(n) =

1), φ(n) = (p− 1)(q − 1)

• compute dalice such that ealicedalice ≡ 1 (mod φ(n))

• Alice’s public key (ealice, n), private key (dalice, p, q)

A.5. ElGamal Signature Scheme 175

2. Signing procedure

• Alice’s signature over m is y ≡ mdalice (mod n)

3. Verification procedure

• Bob obtains Alice’s public key (ealice, n),

• Bob needs to ensure that (ealice, n) is certified and associated to Alice

• Bob computes z ≡ yealice (mod n). If z = m, the signature is a valid

signature, which generated by the above algorithm, other wise it is not

• prove yealice = (mdalice)ealice = mdaliceealice = m

To build a secure RSA signature, the p and q should be selected so that fac-

toring n is computationally infeasible. Other conditions are also need to be taken

to consideration such as hash the message, message padding. RSA Probabilistic

Signature Scheme (PSS)[73] is normally used.

A.5 ElGamal Signature Scheme

ElGamal signature scheme belongs to DSA (Digital Signature Algorithm) type

of digital signature scheme. DSA has been proposed by NIST (National Institute

of Standards and Technology) in 1991. DSA became Digital Signature Standard

(DSS) of U.S. Federal Information Processing Standard. The DSA is one variation

of the ElGamal signature scheme. The ElGamal Signature Scheme contains the

following steps.

1. Set up

• Alice chooses a large random prime p, a generator g ∈ Z∗p ,

• Alice chooses a secret random integer a, 1 ≤ a ≤ p − 2 and compute

ga (mod p )

• Alice makes ( p, g, ga ) as his public key, and a as private key to be

kept secret

2. Signing procedure

• Alice selects a secret random k with gcd(k, (p− 1)) = 1


• Alice computes r ≡ gk (mod (p− 1))

• Alice computes s ≡ k−1(h(m)− ar) (mod (p− 1))

• the signed message is the tuple (m, r, s)

3. Verification procedure

• Bob obtains Alice’s public key (p, g, ga)

• Bob calculates v1 ≡ (ga)rrs (mod p) and v2 ≡ gh(m) (mod p)

• because h(m) = sk + ar (mod (p− 1)),

• therefore, v2 ≡ gh(m) ≡ gsk+ar ≡ gargsk ≡ (ga)rrs ≡ v1

The security of ElGamal signature is based on discrete logarithm problems,

however this does not necessarily make the digital signature scheme secure [81].

To make a secure ElGamal digital signature scheme, it needs to satisfy some

conditions. The prime p is to be large enough for combating index-calculus at-

tacks. q is also needs to be large enough for preventing Pohlig-Hellman attack.

The ElGamel signature should be always used with cryptographic hash function.

Otherwise it could be vulnerable for existential forgery attack [81]. The different

k must be chosen for signing each message. Checking 0 < r < p is required every

time. A strong generator g should always be selected.

A.6 Identity-Based Encryption

The idea of identity-based encryption (IBE) was first introduced by Shamir [97] to

simplify the certification process in PKI by using a person’s well known identity

(email address, social security number) as his or her public key. If the public

key can be a meaningful string, identity based encryption will be user friendly

for the layman. More importantly, identity-based encryption can simplify key

management by removing the need for public key certificates.

Only in 2001, Boneh and Franklin [11] developed the first implementable IBE

scheme based on Weil Pairing. It was followed by another IBE scheme based on

quadratic residues [28] developed by Cocks. Bilinear pairings on elliptic curves,

such as the Weil and Tate pairing, are more efficient technologies than quadratic

residues. Weil pairing is a technology based on bilinear pairings on elliptic curves.

A.6. Identity-Based Encryption 177

Bilinear Map:

• Let G1 and G2 be two cyclic groups of order q, where q is large prime;

• Let G1 be the group of points of an elliptic curve E over Fp, written as

E/Fp, the G1 can be viewed as additive group;

• Let G2 be the subgroup of F ∗p2 , G2 is considered as a multiplicative group;

• A bilinear map e : G1 × G1 → G2, with e(aP, bQ) = e(P, Q)ab for all

P, Q ∈ G1 and all a, b ∈ Z

A useful bilinear map should have the following three properties.

1. Bilinearity:

∀P, Q ∈ G1,∀a, b ∈ Z∗q

e(aP, bQ) = e(P, Q)ab

2. Non-degeneracy: e(P, P ) is the generator of G2, in other words e(P, P )

generates G2, it can be written as

∀P ∈ G1, P 6= 0⇒ 〈e(P, P )〉 = G2

or

P 6= 0⇒ e(P, P ) 6= 1

3. Computability: Given P, Q ∈ G1, e(P, Q) is effectively computable.

A modified Weil and Tate pairings can be used to construct G1 and G2 with

above properties. Weil Pairing Bilinear Map can be defined as follows [11].

Weil Pairing Bilinear Map:

• Let p (of k bits) be a prime satisfying p = 2 mod 3 and p = 6q− 1 for some

prime q;

• Let E be the elliptic curve defined by the equation y2 = x3 + 1 over Fp;

• Let P ∈ E/Fp be a generator of the group Gq; The Gq will be correspond

to G1 described above;


• Let µq be subgroup of F ∗p2 ;

• The Weil pairing on the curve E/F ∗p2 is a mapping e : Gq × Gq → µq,

effectively µq is G2, which has been discussed above;

• the construction of Gq and µq satisfies the three properties of bilinear maps.

Identity based encryption (IBE) contains four algorithms: set up, extract,

encrypt and decrypt [11].

Set Up: A key generation centre (KGC), also called private key generation

centre, defines global system parameters and generates a master-key. The system

parameters include the definition of a finite message spaceM, the finite ciphertext

space C. These system parameters should be made to the public and master key

to be kept secret.

Based on the above defined Weil pairing bilinear map and random oracle the

set up process involves:

1. Define Weil pairing bilinear map; Let p (of k bits) be a prime satisfying

p = 2 mod 3 and p = 6q − 1 for some prime q; Let E be the elliptic curve

defined by the equation y2 = x3 +1 over Fp; Choose an arbitrary P ∈ E/Fp

be a generator of the group Gq

2. Choose a random s ∈ Z∗q and set Ppub = sP

3. Choose a cryptographic hash function H : F ∗p2 → {0, 1}n for some n, H is

random oracle

4. Choose a cryptographic hash function G : {0, 1}∗ → Fp. G is regarded as

random oracle in the proof.

5. The message spaceM = {0, 1}n.

6. The ciphertext space is C = E/Fp × {0, 1}n.

7. The system parameters params = (p, n, P, Ppub, G, H).

8. The master-key is s ∈ Z∗q .

A.6. Identity-Based Encryption 179

Extract: The KGC use params, master-key, and ID ∈ {0, 1}∗ to compute

private key (decryption key) d. Public key is ID with arbitrary bit length. Fol-

lowing the above setup, the private key d can be extracted with steps described

below.

1. map ID to a point QID ∈ E/Fp of the order q, which is QID ∈ Gq. For this

mapping:

• use random oracle G : {0, 1}∗ → Fp to compute y0 = G(ID); x0 =

(y20 − 1)1/3 = (y2

0 − 1)(2p−1)/3 mod p

• let Q = (x0, y0) ∈ E/Fp,

• to ensure that QID ∈ Gq set QID = 6Q

2. Set the private key dID = sQID, with s as master-key.

Encrypt The encrypt algorithm use messages M ∈M, the public key ID and

public system parameters params as the input to generate ciphertext C ∈ C.Steps involved are:

1. map ID to a point QID ∈ E/Fp of the order q, as discussed above.

2. choose a random r ∈ Zq

3. let gID = e(QID, Ppub) ∈ F ∗p2

4. set ciphertext to be C = 〈rP,M ⊕H(grID)〉

Decrypt The decrypt algorithm decrypts messages using the corresponding

decryption key or private key dID.

1. Let C = 〈U, V 〉 , U = rP, V = M ⊕H(grID) of public key ID

2. Ensure U ∈ E/Fp is a point with order q, which is rP ∈ Gq, otherwise

reject the ciphertext.

3. Decrypt C with private key dID as V ⊕H(e(dID, U)) = M

• Because e(dID, U) = e(sQID, rP ) = e(QID, P )sr = e(QID, sP )r =

e(QID, Ppub)r = gr

ID


• Therefore M ⊕H(grID)⊕H(gr

ID) = M

The security of Boneh and Franklin’s scheme [11] is based on Weil Diffie-

Hellman Assumption, known as Bilinear Diffie-Hellman Assumption (BDH). It

had been proved that the discrete log problem in G1 is no harder than the discrete

log problem in G2. It is observed that the DDH (Decisional Diffie-Hellman)

problem is easy in G1. Therefore one can easily reduces the WDH to discrete log

problem and design the scheme based on CDH (Computational Diffie-Hellman).

The IBE system based on Weil Pairing by Boneh and Franklin [11] is proved to

have strong security.

Appendix B

SHVT Code for Chapter 5

/********************************************/

/* file name: negoChainModelAllHonestv2.vsp */

/********************************************/

/****** definition and initialization part *******/

def_role A;

def_role B;

def_role TTP;

def_state A State: Messages_seq := [TTP,’server’].[’start’,B];


(A,’priv’,’Apriv’).(B,’pub’,’Bpub’).(TTP,’pub’,’TTPpub’);

def_state A HashChain: Messages_seq := ::;

def_state B State: Messages_seq := [TTP,’server’].[’respond’,A];

def_state B Asymkeys: Asymkeys_seq :=

(B,’priv’,Bpriv).(A,’pub’,Apub).(TTP,’pub’,TTPpub);

def_state B HashChain: Messages_seq := ::;

def_state TTP State: Messages_seq := [A,’agent’].[B,’agent’];

def_state TTP Asymkeys: Asymkeys_seq :=

(A,’pub’,Apub).(B,’pub’,Bpub).(TTP,’priv’,TTPpriv);

def_state TTP HashChain: Messages_seq := ::;

def_state Network: net_elem_seq := ::;

def_state Netmsg: Messages_seq := ::;

def_state new_mesg: Messages_seq := [’m0’,’m1’,’m2’,’mf’];

/* Transition pattern for Initialization Stage */

def_trans_pattern A spec1_1

(apriv,bpub,L0,rA,eA,M,M0)

(A,’priv’,apriv) ? A_Asymkeys,

(B,’pub’,bpub) ? A_Asymkeys,

(’expect_B_cmf’) ~? A_State,

[’respond’, B] ~? A_State,

[’spec’] ~? A_State,

[’start’, B] << A_State,

181

182 Appendix B. SHVT Code for Chapter 5

[m0,[hash,m0]] ~? A_HashChain,

M << new_mesg,

M0 := elem(1,M),

tail(M) >> new_mesg,

L0 := hash(M0),

[M0,L0,’L_n’] >> A_HashChain,

rA := sign(apriv,L0),

eA := crypt(bpub,[M0,rA]),

(B,A,[eA,’A_origin’]) >> Network,

[’start’, B] >> A_State,

[’respond’, B] >> A_State,

[’spec’] >> A_State;

def_trans_pattern B spec2_2

(M,bpriv,apub,M2,M1,cB,cB1,L0,cBt1,hashcB1)

(B,’priv’,bpriv) ? B_Asymkeys,

(A,’pub’,apub) ? B_Asymkeys,

[’respond’, A] << B_State,

[’start’, A] ~? B_State,

M << Network,

M2 := p(3,M),

M1 := head(M2),

cB := crypt(bpriv,M1),

cB1 := head(cB),

L0 := elem(3,head(tail(cB))), /* get hash node */

cBt1 := head(tail(cB)), /*extract signature of A*/

verify(apub,cBt1)=’true’,

hashcB1 := hash(cB1),

hashcB1 = L0,

[cB1,L0,’L_n’] >> B_HashChain,

[’respond’, A] >> B_State,

[’start’, A] >> B_State,

[’spec’] >> B_State;

/* END OF Transition pattern for Initialization Stage */

/**** transition patten for negotiation stage *****/

def_trans_pattern B offer1_3

(M0,M1,L0,L1,rB,eB,ts,bpriv,apub)



[’start’, A] << B_State,

[’spec’] ? B_State,

[’offer’] ~? B_State,

[M0,L0,’L_n’] << B_HashChain,

M1 := ’m1’,

[M0,L0] >> B_HashChain,

ts := [M1,L0],

L1 := hash(ts),

[M1,L1,’expects_CON’] >> B_HashChain,

rB := sign(bpriv,L1),

eB := crypt(apub,[M1,rB]),

(A,B,[eB,’offer’]) >> Network,

183

[’expect_A_cmf’] >> B_State,

[’offer’] >> B_State;

def_trans_pattern A offer2_4

(M,M0,M1,L0,L1,L1c,Ls1,rA,eA,ts,ts1,ts2, apriv,bpub)



[’respond’, B] << A_State,

[’offer’] ~? A_State,

M << Network,

p(1,M)=A,

head(tail(p(3,M)))=’offer’,

[’offer’] >> A_State,

ts := head(p(3,M)),

ts1 := crypt(apriv,ts),

M1 := head(ts1),

L1 := elem(3,head(tail(ts1))),

ts2 := head(tail(ts1)), /* extracted signature */

verify(bpub,ts2)= ’true’,

[M0,L0,’L_n’] << A_HashChain,

[M0,L0] >> A_HashChain,

Ls1 := [M1,L0],

L1c := hash(Ls1),

L1 = L1c,



eA := crypt(bpub,[rA]),

(B,A,[eA,’A_cfm’]) >> Network,

[’respond’, B] >> A_State;


(M,M1,L1,Ls,ts,ts1,bpriv,apub)



[’expect_A_cmf’] << B_State,

M << Network,

p(1,M)=B,

head(tail(p(3,M)))=’A_cfm’,

[M1,L1,’expects_CON’] << B_HashChain,

ts := head(p(3,M)),

ts1 := crypt(bpriv,ts),

/*ts2 := head(ts1),*/

Ls := elem(3, head(ts1)),

L1=Ls,

[M1,L1,’L_n’] >> B_HashChain,


(’finished’) >> Netmsg;

def_trans_pattern A accept1_6

(M1,Mf,L1,Lf,rA,eA,ts,apriv,bpub)





[’acceptance’] ~? A_State,

[’offer’] ? A_State,

’finished’ << Netmsg,


Mf := ’mf’,


ts := [Mf,L1],

Lf := hash(ts),

[Mf,Lf,’expects_CON’] >> A_HashChain,

rA := sign(apriv,Lf),

eA := crypt(bpub,[Mf,rA]),

(B,A,[eA,’acceptance’]) >> Network,

[’acceptance’] >> A_State,

[’expect_B_cmf’] >> A_State;

def_trans_pattern B accept2_7

(M,Mf,M1,Lf,L1,Lfc,Ls1,rB,eB,ts,ts1,ts2,bpriv,apub)




[’acceptance’] ~? B_State,

M << Network,

p(1,M)=B,

head(tail(p(3,M)))=’acceptance’,

[’acceptance’] >> B_State,

ts := head(p(3,M)),


Mf := head(ts1),

Lf := elem(3,head(tail(ts1))),


verify(apub,ts2)= ’true’,



Ls1 := [Mf,L1],

Lfc := hash(Ls1),

Lf = Lfc,

[Mf,Lf,’Lf’] >> B_HashChain,

rB := sign(bpriv,Lf),

eB := crypt(apub,[rB]),

(A,B,[eB,’B_cfm’]) >> Network,

[’start’, A] << B_State;


(M,Mf,Lf,Ls,ts,ts1,apriv,bpub)



[’expect_B_cmf’] << A_State,

M << Network,

p(1,M)=A,

head(tail(p(3,M)))=’B_cfm’,

185

[Mf,Lf,’expects_CON’] << A_HashChain,

ts := head(p(3,M)),



Lf=Ls,

[Mf,Lf,’Lf’] >> A_HashChain,



/* END of transition patten for negotiation stage ****/

/**** transition patten for final stage *****/

def_trans_pattern A final_1a_9

(apriv,ttppub,Mf,Lf,rA,eA)


(TTP,’pub’,ttppub) ? A_Asymkeys,

’finished’ ? Netmsg,

/* ’A’ ~? Netmsg, */

[’acceptance’] ? A_State,

[’start’,B] ~? A_State,

[’respond’,B] ~? A_State,

[’expect_TTP_cmf’] ~? A_State,

[Mf,Lf,’Lf’] << A_HashChain,



eA := crypt(ttppub,[rA]),

(TTP,A,[eA,AB,’A_origin’]) >> Network,

/* ’A’ >> Netmsg, */

[’expect_TTP_cmf’] >> A_State;

def_trans_pattern B final_1b_10

(bpriv,ttppub,Mf,Lf,rB,eB)


/* ’A’ ? Netmsg, /* prevent small loop */ */

/* ’B’ ~? Netmsg, /* prevent small loop */ */


(TTP,’pub’,ttppub) ? B_Asymkeys,

[’acceptance’] ? B_State,

[’start’,A] ~? B_State,

[’respond’,A] ~? B_State,

[’expect_TTP_cmf’] ~? B_State,

[Mf,Lf,’Lf’] << B_HashChain,



eB := crypt(ttppub,[rB]),

(TTP,B,[eB,AB,’B_origin’]) >> Network,

[’expect_TTP_cmf’] >> B_State;

/*’B’ >> Netmsg;*/

def_trans_pattern TTP final_2ttp_11

(ttppriv,apub,bpub,Ma,Mb,Ma1,Mb1,Sb,Sa,rTTP,eTTPA,eTTPB)


(TTP,A,Ma) << Network,

(TTP,B,Mb ) << Network,

(TTP,’priv’,ttppriv) ? TTP_Asymkeys,

(A,’pub’,apub) ? TTP_Asymkeys,

(B,’pub’,bpub) ? TTP_Asymkeys,

Ma1 := head(Ma),

Mb1 := head(Mb),

Sa := head(crypt(ttppriv,Ma1)), /*extract signature*/

Sb := head(crypt(ttppriv,Mb1)), /*extract signature*/

elem(3,Sb)=elem(3,Sa),

[Sa,Sb,AB]>> TTP_HashChain,

rTTP := sign (ttppriv,[Sa,Sb,’TTP_cfm’]),

eTTPA := crypt(apub,[rTTP]),

(A,TTP,[eTTPA,TTP]) >> Network,

eTTPB := crypt(bpub,[rTTP]),

(B,TTP,[eTTPB,TTP]) >> Network;


(M,Ms,M1,L1,ts,ts1,Sttp,apriv,ttppub)



(A,Ms,M) << Network,

[’expect_TTP_cmf’] << A_State,

/*A << Netmsg,*/

elem(2,M) = TTP,

Ms = TTP,

ts := elem(1,M),


Sttp := head(ts1),

verify(ttppub,Sttp)= ’true’,

[M1,L1,’Lf’] << A_HashChain,

[M1,L1,Sttp,’Lf’] >> A_HashChain;


(M,Ms,M1,L1,ts,ts1,Sttp,bpriv,ttppub)



(B,Ms,M) << Network,

[’expect_TTP_cmf’] << B_State,

/*B << Netmsg,

A ~? Netmsg,*/

elem(2,M) = TTP,

ts := elem(1,M),


Sttp := head(ts1),


[M1,L1,’Lf’] << B_HashChain,

[M1,L1,Sttp,’Lf’] >> B_HashChain;

/* END of transition patten for final stage ****/

187

/* */

/*******************************************/

/* file name: negoChainModelAdishoner2.vsp */

/*********************************/


def_role A;

def_role B;

def_role TTP;





def_state A THashChain: Messages_seq := ::;





def_state B THashChain: Messages_seq := ::;





def_state TTP THashChain: Messages_seq := ::;














M << new_mesg,

M0 := elem(1,M),


L0 := hash(M0),















M << Network,

M2 := p(3,M),

M1 := head(M2),


cB1 := head(cB),





hashcB1 = L0,














[A_abort] ~? B_State,


M1 := ’m1’,


ts := [M1,L0],

L1 := hash(ts),








(M,M0,M1,L0,L1,L1c,Ls1,rA,eA,ts,ts1,

ts2,apriv,bpub,rA1,eA1,HCA,ttppub)




189



M << Network,

p(1,M)=A,



ts := head(p(3,M)),


M1 := head(ts1),






Ls1 := [M1,L0],

L1c := hash(Ls1),

L1 = L1c,





/*** dishonest part****/

/* [’m0’, n1 ] ? A_HashChain,

HCA := [n1, L1, ’termination’, ’AB’], */

HCA := [L0, L1, ’termination’, ’AB’],

rA1 := sign(apriv, HCA),

eA1 := crypt(ttppub,[HCA,rA1]),

(TTP,A,[eA1,’abort’]) >> Network,

/*** finish of dishonest part ***/








M << Network,

p(1,M)=B,



ts := head(p(3,M)),


/*ts2 := head(ts1),*/


L1=Ls,














Mf := ’mf’,


ts := [Mf,L1],

Lf := hash(ts),














M << Network,

p(1,M)=B,



ts := head(p(3,M)),


Mf := head(ts1),


ts2 := head(tail(ts1)),




Ls1 := [Mf,L1],

Lfc := hash(Ls1),

Lf = Lfc,










191


M << Network,

p(1,M)=A,



ts := head(p(3,M)),



Lf=Ls,





/*** start termination portion of protocol ***/

def_trans_pattern TTP termination_1ttp

(ttppriv,apub,bpub,Ma,Ma1,Sa,rTTP,eTTPB)





head(tail(Ma)) = abort,

Ma1 := crypt(ttppriv,head(Ma)),

Sa := head(tail(Ma1)),

[Sa,’wait_B_abort’,AB]>> TTP_THashChain,

rTTP := sign (ttppriv,Sa),

eTTPB := crypt(bpub,[Sa,rTTP,’A_abort’]),


def_trans_pattern B termination_2b

(M,Ms,n1,n2,ts,ts1,HCB,rB,eB,bpriv,ttppub)




/* if it is in acceptance stage, B will not respond termination from A */



elem(2,M) = TTP,

ts := elem(1,M),


elem(3,ts1) = A_abort,

[A_abort] >> B_State,

elem(2,ts1) >> B_THashChain,

[’m0’, n1 ] ? B_HashChain,

[’m1’, n2, L_n ] ? B_HashChain,

HCB := [n1, n2, ’termination’, ’AB’],

rB := sign(bpriv, HCB),

eB := crypt(ttppub,[HCB,rB]),

(TTP,B,[eB,’abort’]) >> Network;


def_trans_pattern B termination_2b_otherStep

(M,Ms,n1,n2,ts,ts1,HCB,rB,eB,bpriv,ttppub)






elem(2,M) = TTP,

ts := elem(1,M),


elem(3,ts1) = A_abort,

[A_abort] >> B_State,

elem(2,ts1) >> B_THashChain,

[’m0’, n1 ] ? B_HashChain,

[’m1’, n2, ’expects_CON’ ] ? B_HashChain,

HCB := [n1, n2, ’termination’, ’AB’],

rB := sign(bpriv, HCB),

eB := crypt(ttppub,[HCB,rB]),

(TTP,B,[eB,’abort’]) >> Network;

def_trans_pattern TTP termination_3ttp

(ttppriv,apub,bpub,Mb,Mb1,Sa,Sb,rTTP,eTTPA)




[Sa,’wait_B_abort’,AB] << TTP_THashChain,

(TTP,B,Mb) << Network,

head(tail(Mb)) = abort,

Mb1 := crypt(ttppriv,head(Mb)),

Sb := head(tail(Mb1)),

[Sb,Sa,’A_terminated_B’]>> TTP_THashChain,

rTTP := sign (ttppriv,Sb),

eTTPA := crypt(apub,[Sb,rTTP,’A_terminated_B’]),

(A,TTP,[eTTPA,TTP]) >> Network;

def_trans_pattern A termination_4a

(M,Ms,ts,ts1,apriv,ttppub)




elem(2,M) = TTP,

ts := elem(1,M),


elem(3,ts1) = ’A_terminated_B’,

elem(2,ts1) >> A_THashChain;

/*** END of termination portion of protocol ***/


193






/* ’A’ ~? Netmsg, */










/* ’A’ >> Netmsg, */



















/*’B’ >> Netmsg;*/








Ma1 := head(Ma),

Mb1 := head(Mb),

















/*A << Netmsg,*/

elem(2,M) = TTP,

Ms = TTP,

ts := elem(1,M),


Sttp := head(ts1),










/*B << Netmsg,

A ~? Netmsg,*/

elem(2,M) = TTP,

ts := elem(1,M),


Sttp := head(ts1),





/**************************************************/

/* filename: negoChainModelAdishonetAtkData.vsp */

/**************************************************/


def_role A;

def_role B;

def_role TTP;



195















def_trans_pattern A step_1

(apriv,bpub,L0,rA,eA,M,M0,Mattac)








M0 := ’m0’,

Mattac := ’attack_data’,

L0 := hash(Mattac),

[Mattac,L0,’L_n’] >> A_HashChain,







def_trans_pattern B step_2






M << Network,

M2 := p(3,M),

M1 := head(M2),


cB1 := head(cB),



/*verify(apub,cBt1)=’true’,


hashcB1 = L0, */








def_trans_pattern B step_3StartofferToA








/*M0 = ’m0’,*/

M1 := ’m1’,


ts := [M1,L0],

L1 := hash(ts),







def_trans_pattern A step_4RespondOfferB






M << Network,

p(1,M)=A,



ts := head(p(3,M)),


M1 := head(ts1),






Ls1 := [M1,L0],

L1c := hash(Ls1),

L1 = L1c,






197

def_trans_pattern B step_5Verify_A_Respond





M << Network,

/*Mf := p(3,M),*/

p(1,M)=B,



ts := head(p(3,M)),


/*ts2 := head(ts1),*/


L1=Ls,




def_trans_pattern A step_6startAcceptanceToB

(M,M1,Mf,L1,Lf,rA,eA,ts,apriv,bpub)






M << Netmsg,

M = ’finished’,


Mf := ’mf’,


ts := [Mf,L1],

Lf := hash(ts),







def_trans_pattern B step_7RespondAcceptanceA






M << Network,

p(1,M)=B,




ts := head(p(3,M)),


Mf := head(ts1),






Ls1 := [Mf,L1],

Lfc := hash(Ls1),

Lf = Lfc,






def_trans_pattern A step_8Verify_B_Respond





M << Network,

/*Mf := p(3,M),*/

p(1,M)=A,



ts := head(p(3,M)),


/*ts2 := head(ts1),*/


Lf=Ls,






def_trans_pattern A step_9af





’A’ ~? Netmsg,








199



’A’ >> Netmsg,


/*

def_trans_pattern TTP step_7ttpf

(ttppriv,apub,bpub,M,M1,Ms,Sa)

M << Network,




p(1,M)=TTP,

M1 := p(3,M),

elem(2,M1)=AB,

elem(3,M1)=A_origin,

Ms := head(M1),

Sa := crypt(ttppriv,Ms),

[head(Sa),’expt_final’]>> TTP_HashChain,

(B,TTP,[’AB’,’expt_final’,TTP]) >> Network;*/

def_trans_pattern B step_10bf



’A’ ? Netmsg,

’B’ ~? Netmsg,












[’expect_TTP_cmf’] >> B_State,

’B’ >> Netmsg;

def_trans_pattern TTP step_11ttpf







/*’TTP’ ~? Netmsg,*/

/*p(1,M)=TTP,

M1 := p(3,M),


elem(2,M1)=AB,

elem(3,M1)=B_origin,*/

Ma1 := head(Ma),

Mb1 := head(Mb),



/*[Sa,’expt_final’] << TTP_HashChain,*/

/*[head(Sa),’expt_final’]>> TTP_HashChain,*/








def_trans_pattern A step_12af






A << Netmsg,

elem(2,M) = TTP,

Ms = TTP,

ts := elem(1,M),


Sttp := head(ts1),




/*(A,TTP,’finished’)>> Network;*/

def_trans_pattern B step_13bf






B << Netmsg,

A ~? Netmsg,

/*(A,TTP,’finished’) ? Network,*/

elem(2,M) = TTP,

ts := elem(1,M),


Sttp := head(ts1),




201

/*(B,TTP,’finished’) >> Network;*/


/******************************************/

/* negoChainModelBdishoner1.vsp */

/******************************************/

/****** definition and initialization part */

def_role A;

def_role B;

def_role TTP;

/*def_state new_mesg: msgs_seq := [1,3,5,7];*/


[TTP,’server’].[’start’,B];















/*********************************/











M << new_mesg,

M0 := elem(1,M),


L0 := hash(M0),















M << Network,

M2 := p(3,M),

M1 := head(M2),


cB1 := head(cB),





hashcB1 = L0,








(M0,M1,M2,L0,L1,L2,rB,rB2,eB,eB2,ts,ts2,bpriv,apub)







M1 := ’m1’,

M2 := ’m2’,


ts := [M1,L0],

L1 := hash(ts),

ts2 := [M2,L0],

L2 := hash(ts2),


[M2,L2,’expects_CON’] >> B_HashChain, /* dishonest offer to A */


rB2 := sign(bpriv,L2),


eB2 := crypt(apub,[M2,rB2]),


(A,B,[eB2,’offer’]) >> Network,



203







M << Network,

p(1,M)=A,



ts := head(p(3,M)),


M1 := head(ts1),






Ls1 := [M1,L0],

L1c := hash(Ls1),

L1 = L1c,











M << Network,

p(1,M)=B,



ts := head(p(3,M)),


/*ts2 := head(ts1),*/


L1=Ls,














M1 = m1,

Mf := ’mf’,


ts := [Mf,L1],

Lf := hash(ts),













M << Network,

p(1,M)=B,



ts := head(p(3,M)),


Mf := head(ts1),






Ls1 := [Mf,L1],

Lfc := hash(Ls1),

Lf = Lfc,











M << Network,

p(1,M)=A,



ts := head(p(3,M)),

205



Lf=Ls,











/* ’A’ ~? Netmsg, */










/* ’A’ >> Netmsg, */



















/*’B’ >> Netmsg;*/









Ma1 := head(Ma),

Mb1 := head(Mb),
















/*A << Netmsg,*/

elem(2,M) = TTP,

Ms = TTP,

ts := elem(1,M),


Sttp := head(ts1),










/*B << Netmsg,

A ~? Netmsg,*/

elem(2,M) = TTP,

ts := elem(1,M),


Sttp := head(ts1),





Appendix C

SHVT Code for Chapter 6

/********************************************/

/* file name: submitP1dhS1S2S3S4v4.vsp */

/********************************************/


def_role A;

def_role B;

def_role B2;

def_role TSA;

def_role TTP;


[TTP,’server’].[’start’,B].[’start’,B2].

[’spec’].[’respond’,B].[’respond’,B2];


(A,’priv’,’Apriv’).(B,’pub’,’Bpub’).

(B2,’pub’,’B2pub’).(TTP,’pub’,’TTPpub’);

def_state A CommitB: Messages_seq :=

[’m0’,[hash,’m0’],’L_n’];

def_state A CommitB2: Messages_seq :=

[’m0’,[hash,’m0’],’L_n’];

def_state A SigB: Messages_seq :=

[sign,’Apriv’,[hash,’m0’]].[sign,’Bpriv’,[hash,’m0’]];

def_state A SigB2: Messages_seq :=

[sign,’Apriv’,[hash,’m0’]].[sign,’B2priv’,[hash,’m0’]];

def_state A TimeStampB: Messages_seq := ::;

def_state A TimeStampB2: Messages_seq := ::;

/***** global state components *****/

def_state AAsymkeys: Asymkeys_seq :=

(A,’priv’,’Apriv’).(B,’pub’,’Bpub’).(B2,’pub’,’B2pub’).(TTP,’pub’,’TTPpub’);

def_state ACommitB: Messages_seq := ::;

def_state ACommitB2: Messages_seq := ::;

def_state ASigB: Messages_seq := ::;

def_state ASigB2: Messages_seq := ::;

207

208 Appendix C. SHVT Code for Chapter 6

def_state B State: Messages_seq :=

[TTP,’server’].[’respond’,A].[’spec’].[’start’, A];



def_state B Commit: Messages_seq := [’m0’,[hash,’m0’],’L_n’];

def_state B Sig: Messages_seq :=

[sign,’Apriv’,[hash,’m0’]].[sign,’Bpriv’,[hash,’m0’]];

def_state B TimeStamp: Messages_seq := ::;


def_state BAsymkeys: Asymkeys_seq :=


def_state BCommit: Messages_seq := ::;

def_state BSig: Messages_seq := ::;

def_state BTimeStamp: Messages_seq := ::;

def_state B2 State: Messages_seq :=

[TTP,’server’].[’respond’,A].[’spec’].[’start’, A];

def_state B2 Asymkeys: Asymkeys_seq :=

(B2,’priv’,B2priv).(A,’pub’,Apub).(TTP,’pub’,TTPpub);

def_state B2 Commit: Messages_seq := [’m0’,[hash,’m0’],’L_n’];

def_state B2 Sig: Messages_seq :=

[sign,’Apriv’,[hash,’m0’]].[sign,’B2priv’,[hash,’m0’]];

def_state B2 TimeStamp: Messages_seq := ::;


def_state B2Asymkeys: Asymkeys_seq :=


def_state B2Commit: Messages_seq := ::;

def_state B2Sig: Messages_seq := ::;

def_state B2TimeStamp: Messages_seq := ::;

def_state TSA State: Messages_seq :=

[A,’agent’].[B,’agent’].[B2,’agent’];

def_state TSA Asymkeys: Asymkeys_seq :=

(A,’pub’,Apub).(B,’pub’,Bpub).(B2,’pub’,B2pub).

(TSA,’priv’,TTPpriv);

def_state TSA Commit: Messages_seq := ::;

def_state TSA TimeStamp: Messages_seq := ::;


def_state TSACommit: Messages_seq := ::;

def_state TSATimeStamp: Messages_seq := ::;

/* def_state TTP State: Messages_seq :=

[A,’agent’].[B,’agent’];



(TTP,’priv’,TTPpriv);

def_state TTP Commit: Messages_seq := ::; */


def_state Netmsg: Messages_seq := (’spec’);


/*******************************************/

/****** m0 := Specification */

/****** m1,msb,msb2 := Offer */

209

/****** A := Principal */

/****** B := Tenderer */

/****** TTP := Trusted Third Party */

/****** TSA := Time-Stamp Authority */

/*******************************************/

/**** transition patten for tender submission process *****/


(M0,Ms,L0,Ls,Lsbb,sig,sig2,eB,eBB,ts,tsbb,bpriv,apub)






(’spec’) ? Netmsg,

[M0,L0,’L_n’] << B_Commit,

Ms := ’msb’,

[M0,L0] >> B_Commit,

ts := [Ms,L0],

Ls := hash(ts),

[Ms,Ls,’expects_CON’] >> B_Commit,

(TSA,B,[Ls]) >> Network,

sig := sign(bpriv,Ls),

sig >> B_Sig,

([’TS_B’]) >> B_TimeStamp,

eB := crypt(apub,[Ls,sig,’TS_B’]),


tsbb :=[’msbb’,L0], /* double offer */

Lsbb := hash(tsbb),

[’msbb’,Lsbb,’expects_CON’] >> B_Commit,

(TSA,B,[Lsbb]) >> Network,

sig2 := sign(bpriv,Lsbb),

sig2 >> B_Sig,

([’TS_B’]) >> B_TimeStamp,

eBB := crypt(apub,[Lsbb,sig2,’TS_B’]),

(A,B,[eBB,’offer’]) >> Network,



def_trans_pattern B2 offer1_6

(M0,Ms,L0,Ls,sig,eB,ts,b2priv,apub)

(B2,’priv’,b2priv) ? B2_Asymkeys,

(A,’pub’,apub) ? B2_Asymkeys,

[’start’, A] << B2_State,

[’spec’] ? B2_State,

[’offer’] ~? B2_State,


[M0,L0,’L_n’] << B2_Commit,

Ms := ’msb2’,

[M0,L0] >> B2_Commit,


ts := [Ms,L0],

Ls := hash(ts),

[Ms,Ls,’expects_CON’] >> B2_Commit,

(TSA,B2,[Ls]) >> Network,

/* need to add TSA steps */

sig := sign(b2priv,Ls),

sig >> B2_Sig,

[’TS_B2’] >> B2_TimeStamp,

eB := crypt(apub,[Ls,sig,’TS_B2’]),

(A,B2,[eB,’offer’]) >> Network,

[’expect_A_cmf’] >> B2_State,

[’offer’] >> B2_State;


(Mb,Mbb,Mb2,sigB,sigB2,Lsb,Lsbb,Lsb2,sigRB,eAb,eAbb,sigBB,sigRBB,

tsb,tssb,tsbb,tssbb,sigRB2,eAb2,tsb2,tssb2,apriv,bpub,b2pub,test)



(B2,’pub’,b2pub) ? A_Asymkeys,




(A,B,Mb) << Network,

head(tail(Mb))=’offer’,

tsb := head(Mb),

tssb := crypt(apriv,tsb),

Lsb := head(tssb), /* hashchain node recovered from signature */

sigB := elem(2,tssb), /* extracted signature */

elem(3,tssb) = ’TS_B’, /* verify timestamp after tsa is decided */

[’TS_B’] >> A_TimeStampB,

verify(bpub,sigB)= ’true’,

sigB >> A_SigB,

[Lsb, ’expect_ms’] >> A_CommitB,

sigRB := sign(apriv,Lsb),

sigRB >> A_SigB,

eAb := crypt(bpub,[sigRB]),

(B,A,[eAb,’A_cfm’]) >> Network,

/* BB’s section */

(A,B,Mbb) << Network,

head(tail(Mbb))=’offer’,

tsbb := head(Mbb),

tssbb := crypt(apriv,tsbb),

Lsbb := head(tssbb),

head(head(tail(Lsbb))) = ’msbb’,

sigBB := elem(2,tssbb), /* extracted signature */

elem(3,tssbb) = ’TS_B’,

[’TS_B’] >> A_TimeStampB,

verify(bpub,sigBB)= ’true’,

sigBB >> A_SigB,

[Lsbb,’msbb’ ,’expect_ms’] >> A_CommitB,

211

sigRBB := sign(apriv,Lsbb),

sigRBB >> A_SigB,

eAbb := crypt(bpub,[sigRBB]),

(B,A,[eAbb,’A_cfm’]) >> Network,

(A,B2,Mb2) << Network,

head(tail(Mb2))=’offer’,

tsb2 := head(Mb2),

tssb2 := crypt(apriv,tsb2),

Lsb2 := head(tssb2),

sigB2 := elem(2,tssb2), /* extracted signature */

elem(3,tssb2) = ’TS_B2’,

[’TS_B2’] >> A_TimeStampB2,

verify(b2pub,sigB2)= ’true’,

sigB2 >> A_SigB2,

[Lsb2, ’expect_ms’] >> A_CommitB2,

sigRB2 := sign(apriv,Lsb2),

sigRB2 >> A_SigB2,

eAb2 := crypt(b2pub,[sigRB2]),

(B2,A,[eAb2,’A_cfm’]) >> Network,




(M,Ms,Ls,ts,tss,Mb,Msb,Lsb,tsb,tssb,bpriv,apub)




(B,A,M) << Network,

head(tail(M))=’A_cfm’,

[Ms,Ls,’expects_CON’] << B_Commit,

ts := head(M),

tss := crypt(bpriv,ts),

head(tss) >> B_Sig,

verify(apub,head(tss))= ’true’,

Ls = elem(3, head(tss)),

[Ms,Ls,’L_n’] >> B_Commit,

(B,A,Mb) << Network,

head(tail(Mb))=’A_cfm’,

[Msb,Lsb,’expects_CON’] << B_Commit,

tsb := head(Mb),

tssb := crypt(bpriv,tsb),

head(tssb) >> B_Sig,

verify(apub,head(tssb))= ’true’,

Lsb = elem(3, head(tssb)),

[Msb,Lsb,’L_n’] >> B_Commit,


(’fnsh_sbmtb’) >> Netmsg;



(M,Ms,Ls,ts,ts1,b2priv,apub)



[’expect_A_cmf’] << B2_State,

(B2,A,M) << Network,


[Ms,Ls,’expects_CON’] << B2_Commit,

ts := head(M),

ts1 := crypt(b2priv,ts),

head(ts1) >> B2_Sig,

verify(apub,head(ts1))= ’true’,

Ls = elem(3, head(ts1)),

[Ms,Ls,’L_n’] >> B2_Commit,

[’start’, A] >> B2_State,

(’fnsh_sbmtb2’) >> Netmsg;

/* END OF Transition pattern for tender submission process */

/********* start timestamp section ********/

def_trans_pattern TSA TimeStampOffer

(CsB,CsB2,CsBB)

(’fnsh_sbmtb’) ? Netmsg,

(’fnsh_sbmtb2’) ? Netmsg,

(’clstndr’) ~? Netmsg,

/* [’TS_B’] ~? TSA_State, */

[B, ’agent’] ? TSA_State,

(TSA, B, CsB) << Network,

[’B’,’TS_B’, head(CsB)] >> TSA_TimeStamp, /* normal one */

[’B’,’TS_B’, head(CsB)] >> TSATimeStamp, /* normal one */

(TSA,B,CsBB) << Network,

[’B’,’TS_B’, head(CsBB)] >> TSA_TimeStamp,

[’B’,’TS_B’, head(CsBB)] >> TSATimeStamp,

[’TS_B’] >> TSA_State,

(’TS_B’) >> Netmsg,

[’TS_B2’] ~? TSA_State,

[B2, ’agent’] << TSA_State,

(TSA, B2, CsB2) << Network,

[’B2’,’TS_B2’, head(CsB2)] >> TSA_TimeStamp,

[’B2’,’TS_B2’, head(CsB2)] >> TSATimeStamp,

(’TS_B2’) >> Netmsg,

[’TS_B2’] >> TSA_State;

def_trans_pattern TSA TimeStampClose

(CplA)



(’clstndr’) ? Netmsg,

213

(’msb’) ~? Netmsg,

(’msb2’) ~? Netmsg,

[’TS_A’] ~? TSA_State,

[A,’agent’] << TSA_State,

(TSA, A, CplA) << Network,

[’TS_A’] >> TSA_State,

(’TS_A’) >> Netmsg,

[’A’,’TS_A’, head(CplA)] >> TSATimeStamp,

[’A’,’TS_A’, head(CplA)] >> TSA_TimeStamp;

/********* end timestamp section ********/

/**** transition patten for tender closing process *****/

/* blocking A S1

/* A S1 trans */

def_trans_pattern A clstndr1_10_beforeCloseTime

(Lpl,Lsb,Lsb2,sig,eAb,eAb2,apriv,bpub,b2pub)









/* (’TS_B’) ? Netmsg,

(’TS_B2’) ? Netmsg, */

[Lsb,’expect_ms’] << A_CommitB,

[Lsb2,’expect_ms’] << A_CommitB2,

Lpl := [Lsb,Lsb2],

(TSA, A, [Lpl]) >> Network,

sig := sign(apriv,Lpl),

sig >> A_SigB,

sig >> A_SigB2,

[’TS_A0’] >> A_TimeStampB,

[’TS_A0’] >> A_TimeStampB2,

[Lsb,Lpl,’expect_ms’] >> A_CommitB,

[Lsb2,Lpl,’expect_ms’] >> A_CommitB2,

eAb := crypt(bpub,[Lpl,sig,’TS_A0’]),

eAb2 := crypt(b2pub,[Lpl,sig,’TS_A0’]),

/* eAb := crypt(bpub,[Lpl,sig]),

eAb2 := crypt(b2pub,[Lpl,sig]), */

(B,A,[eAb,’hshpl’]) >> Network,

(B2,A,[eAb2,’hshpl’]) >> Network,

[’hshpl’] >> A_State,

[’expect_ms’] >> A_State,

(’clstndr’) >> Netmsg;

end blocking A S1 ******/

def_trans_pattern A clstndr1_10

(Lpl,Lsb,Lsbb,Lsb2,sig,eAb,eAbb,eAb2,apriv,bpub,b2pub)










(’TS_B’) ? Netmsg,

(’TS_B2’) ? Netmsg,

[Lsb,’expect_ms’] << A_CommitB,

[Lsbb,’msbb’,’expect_ms’] << A_CommitB,

[Lsb2,’expect_ms’] << A_CommitB2,

Lpl := [Lsb,Lsb2,Lsbb],

(TSA, A, [Lpl]) >> Network,

sig := sign(apriv,Lpl),

sig >> A_SigB,

sig >> A_SigB2,

[’TS_A’] >> A_TimeStampB,

[’TS_A’] >> A_TimeStampB2,

[Lsb,Lpl,’expect_ms’] >> A_CommitB,

[Lsbb,Lpl,’expect_ms’] >> A_CommitB,

[Lsb2,Lpl,’expect_ms’] >> A_CommitB2,

eAb := crypt(bpub,[Lpl,sig,’TS_A’]),

eAbb := crypt(bpub,[Lpl,sig,’TS_A’]),

eAb2 := crypt(b2pub,[Lpl,sig,’TS_A’]),

(B,A,[eAb,’hshpl’]) >> Network,

/* (B,A,[eAbb,’hshpl’]) >> Network, */ /* for short */

(B2,A,[eAb2,’hshpl’]) >> Network,

[’hshpl’] >> A_State,

[’expect_ms’] >> A_State,

(’clstndr’) >> Netmsg;

def_trans_pattern B clstndr2_11

(M,Ms,Lpls,Lpl,Ls,sig,sigRpl,eB,

ts,ts1,sigA,bpriv,apub,Lfs)




[’hshpl’] ~? B_State,

(’TS_A’) ? Netmsg,

(B,A,M)<< Network,

head(tail(M)) =’hshpl’,

[’hshpl’] >> B_State,

ts := head(M),


Lpl := head(ts1), /* C_pl send by A*/

sigA := elem(2,ts1), /* extracted signature */

Lpls := elem(3,sigA),

elem(3,ts1) = ’TS_A’,

[’TS_A’] >> B_TimeStamp,

215

verify(apub,sigA)= ’true’,

sigA >> B_Sig,

Lpl = Lpls,

[Ms,Ls,’L_n’] << B_Commit,

Ls = elem(1,Lpl),

sigRpl := sign(bpriv,Lpl),

sigRpl >> B_Sig,

Lfs := hash([Ms,Lpl]),

[Ms,Ls,Lpl,Lfs,’L_n’] >> B_Commit,

sig := sign(bpriv, Lfs),

sig >> B_Sig,

eB := crypt(apub,[Ms,sigRpl,sig]),



(’msb’) >> Netmsg;

def_trans_pattern B2 clstndr2_12

(M,Ms,Lpls,Lpl,Ls,sig,sigA,

sigRpl,eB,ts,ts1,b2priv,apub,Lfs)



[’respond’, A] << B2_State,

[’hshpl’] ~? B2_State,


(B2,A,M)<< Network,

head(tail(M)) =’hshpl’,

[’hshpl’] >> B2_State,

ts := head(M),


Lpl := head(ts1), /* hash pl send by A*/

sigA := elem(2,ts1),

Lpls := elem(3,sigA),


[’TS_A’] >> B2_TimeStamp,


sigA >> B2_Sig,

Lpl = Lpls,

[Ms,Ls,’L_n’] << B2_Commit,

Ls = elem(2,Lpl),

sigRpl := sign(b2priv,Lpl),

sigRpl >> B2_Sig,

Lfs := hash([Ms,Lpl]),

[Ms,Ls,Lpl,Lfs,’L_n’] >> B2_Commit,

sig := sign(b2priv, Lfs),

sig >> B2_Sig,

eB := crypt(apub,[Ms,sigRpl,sig]),

(A,B2,[eB,’B2_cfm’]) >> Network,


(’msb2’) >> Netmsg;

def_trans_pattern A clstndr3_13

(apriv,Mb,M0b,Msb,L0b,Lsb,sigplB,

sigfsB,Lplb,LfsB,rAb,eAb,tsb,bpub,


Mb2,M0b2,Msb2,L0b2,Lsb2,sigplB2,

sigfsB2,Lplb2,LfsB2,rAb2,eAb2,tsb2,b2pub)





[’hshpl’] ? A_State,


[’expect_ms’] << A_State,



head(tail(Mb))=’B_cfm’,

tsb := crypt(apriv,head(Mb)),

sigplB := elem(2,tsb),

sigfsB := elem(3,tsb),

Msb := elem(1,tsb), /* extracted msb */

verify(bpub,sigplB) = ’true’,

[Lsb,Lplb,’expect_ms’] << A_CommitB,

elem(3,sigplB) = Lplb,

[M0b,L0b,’L_n’] << A_CommitB,

Lsb = hash([Msb,L0b]),

Lsb = elem(1,Lplb),

LfsB := hash([Msb,Lplb]),

elem(3,sigfsB) = LfsB,

sigplB >> A_SigB,

sigfsB >> A_SigB,

[M0b,L0b] >> A_CommitB,

[Msb,Lsb,Lplb,LfsB,’L_n’] >> A_CommitB,

rAb := sign(apriv,LfsB),

rAb >> A_SigB,

eAb := crypt(bpub,[rAb]),

(B,A,[eAb,’msb_cfm’]) >> Network,

head(tail(Mb2))=’B2_cfm’,

tsb2 := crypt(apriv,head(Mb2)),

sigplB2 := elem(2,tsb2),

sigfsB2 := elem(3,tsb2),

Msb2 := elem(1,tsb2),

verify(b2pub,sigplB2) = ’true’,

[Lsb2,Lplb2,’expect_ms’] << A_CommitB2,

elem(3,sigplB2) = Lplb2,

[M0b2,L0b2,’L_n’] << A_CommitB2,

Lsb2 = hash([Msb2,L0b2]),

Lsb2 = elem(2,Lplb2),

LfsB2 := hash([Msb2,Lplb2]),

elem(3,sigfsB2) = LfsB2,

sigplB2 >> A_SigB2,

sigfsB2 >> A_SigB2,

[M0b2,L0b2] >> A_CommitB2,

[Msb2,Lsb2,Lplb2,LfsB2,’L_n’] >> A_CommitB2,

rAb2 := sign(apriv,LfsB2),

rAb2 >> A_SigB2,

eAb2 := crypt(b2pub,[rAb2]),

217

(B2,A,[eAb2,’msb2_cfm’]) >> Network,

[’clstndr’] >> A_State,


def_trans_pattern B clstndr4_14

(M,ts,ts1,sigA,Ms,AtDa,Ls,Lpl,Lfs,L0,bpriv,apub)



[’hshpl’] ? B_State,

/*[’respond’, A] << B_State,*/

(B,A,M)<< Network,

head(tail(M)) =’msb_cfm’,

ts := head(M),


sigA := head(ts1), /* extracted signature */

verify(apub,sigA) = ’true’,

[Ms,Ls,Lpl,Lfs,’L_n’] ? B_Commit,

[’m0’, L0] ? B_Commit,

/*** S2 attack ***/

/* AtDa :=’attack_data’,

[AtDa,L0,Ls,Lpl,Lfs,’L_n’] >> BCommit, */

[Ms,L0,Ls,Lpl,Lfs,’L_n’] >> BCommit,

Lfs = elem(3,sigA),

sigA >> B_Sig,

(’fnsh_clstndr’) >> Netmsg,

[’clstndr’] >> B_State;

def_trans_pattern B2 clstndr4_15

(M,ts,ts1,sigA,Ms,Ls,Lpl,L0,Lfs,b2priv,apub)



[’hshpl’] ? B2_State,

/*[’respond’, A] << B2_State,*/

(B2,A,M)<< Network,

head(tail(M)) =’msb2_cfm’,

ts := head(M),


sigA := head(ts1), /* extracted signature */


[Ms,Ls,Lpl,Lfs,’L_n’] ? B2_Commit,

[’m0’, L0] ? B2_Commit,

[Ms,L0,Ls,Lpl,Lfs,’L_n’] >> B2Commit,

Lfs = elem(3,sigA),

sigA >> B2_Sig,

(’fnsh_clstndr’) >> Netmsg,

[’clstndr’] >> B2_State;

/********** verification process ************/

def_trans_pattern TTP Verification


(TSAApl,TSAB2msb2,TSABmsb,

B2sigApl,Msb2,sigB2,sigAmsb2,b2priv,

BsigApl,Msb,sigB,sigAmsb,bpriv,

AsigApl,AsigApll,Amsb,AsigBmsb,AsigAmsb,

Amsb2,AsigB2msb2,AsigAmsb2,apub,apriv,

test1,test2,test3,test4,eB,eB2,

tsa,tsb,tsb2,

L0b,L0b2,LsB,LplaB,LfsB,LsB2,LplaB2,LfsB2)

/* sequence control */

/*(’bf’) ? Netmsg,

(’b2f’) ? Netmsg,

(’clstndr’) ? Netmsg, */

/* extract values from TSA */

[’A’,tsa, TSAApl] ? TSATimeStamp,

[’B’,tsb, TSAB2msb2] ? TSATimeStamp,

[’B2’,tsb2, TSABmsb] ? TSATimeStamp,

/* extract values from B */

/* [BsigApl, ’TS_A’] << BCommit, */

/* [msb,sigB,sigAmsb,’TS_B’] << BCommit, */

[Msb,L0b,LsB,LplaB,LfsB,’L_n’] ? BCommit,

/* extract values from B2 */

/* [B2sigApl, ’TS_A’] << B2Commit, */

/* [Msb2,sigB2,sigAmsb2,’TS_B2’] << B2Commit, */

[Msb2,L0b2,LsB2,LplaB2,LfsB2,’L_n’] ? B2Commit,

/* extract values from A

[AsigApl,’TS_A’] << ACommitB,

[AsigApll,’TS_A’] << ACommitB2,

[Amsb,AsigBmsb,AsigAmsb,’TS_B’] << ACommitB,

[Amsb2,AsigB2msb2,AsigAmsb2,’TS_B2’] << ACommitB2, */

/** verify S2 change ’msb’ to ’attack_data’ **/

/* */

(B,’priv’,bpriv) ? BAsymkeys,

test3 := hash([Msb,L0]), /* Msb hold ’attack_data’ */

/* test3 = TSABmsb; */ /* testing verification */

/** verify S3 submit late ’TS_BL’ **/

/* TS_A, TS_B, TS_B2 are valid timestamp.

TS_BL is later timestamp */

/* tsb hold ’TS_BL’ in second line of

this transition pattern */

tsb = ’TS_B’,

/** verify S4 double valid submission **/

/** digital certificate will

view B and BB are same role **/

test1 := hash([Msb,L0b]),

test2 := hash([Msb2,L0b2]),

test4 := [test1,test2],

/* test4 = TSAApl, */

/* TSAApl holds double submission in Cpl */

’TS_A’ << Netmsg;

219

/********************************************/

/* file name: submitP2dhs234v1.vsp */

/********************************************/


def_role A;

def_role B;

def_role B2;

def_role TSA;

def_role TTP;


[TTP,’server’].[’respond’,B].[’respond’,B2];


(A,’priv’,’Apriv’).(B,’pub’,’Bpub’).

(B2,’pub’,’B2pub’).(TTP,’pub’,’TTPpub’);

def_state A CommitB: Messages_seq := ::;

def_state A CommitB2: Messages_seq := ::;

/****** global *****/

def_state ACommitB: Messages_seq := ::;

def_state ACommitB2: Messages_seq := ::;

def_state AAsymkeys: Asymkeys_seq :=

(A,’priv’,’Apriv’).(A,’pub’,Apub).(B,’pub’,’Bpub’)

.(B2,’pub’,’B2pub’).(TTP,’pub’,’TTPpub’);

def_state B State: Messages_seq :=

[TTP,’server’].[’respond’,A].[’start’,A];



def_state B Commit: Messages_seq := ::;

/****** global *****/

def_state BCommit: Messages_seq := ::;

def_state BAsymkeys: Asymkeys_seq :=


def_state B2 State: Messages_seq :=

[TTP,’server’].[’respond’,A].[’start’,A];

def_state B2 Asymkeys: Asymkeys_seq :=


def_state B2 Commit: Messages_seq := ::;

/****** global *****/

def_state B2Commit: Messages_seq := ::;

def_state B2Asymkeys: Asymkeys_seq :=


def_state TSA State: Messages_seq :=

[A,’agent’].[B,’agent’].[B2,’agent’];

def_state TSA Asymkeys: Asymkeys_seq :=


(TSA,’priv’,TTPpriv);

def_state TSA TimeStamp: Messages_seq := ::;

/****** global *****/

def_state TSATimeStamp: Messages_seq := ::;

def_state TTP State: Messages_seq :=

[A,’agent’].[B,’agent’].[B2,’agent’].[TSA,’agent’];




(TTP,’priv’,TTPpriv);

def_state TTP Result: Messages_seq := ::;

/**** global state components ****/




/*******************************************/

/****** m0 := Specification */

/****** m1,msb,msb2 := Offer */

/****** mf := Acceptance */

/****** A := Principal */

/****** B := Tenderer */

/****** TTP := Trusted Third Party */

/****** TSA := Time-Stamp Authority */

/*******************************************/

/**** transition patten for tender submission process *****/


(Ms,sig1,sig2,eB,bpriv,apub)



[’start’, A] << B_State, /* tags for sequence control */

[’offer’] ~? B_State, /* tags for sequence control */

Ms := ’msb’,

sig1 := sign(bpriv,Ms),

(TSA, B, [sig1]) >> Network,

eB := crypt(apub,[Ms,sig1,’TS_B’]),


sig2 := sign(bpriv,’msbb’), /* double submission */

(TSA, BB, [sig2]) >> Network, /* double submission */

(A,BB,[crypt(apub,[’msbb’,sig2,’TS_B’]),’offer’]) >> Network,

/* double submission */

[Ms,sig1,’TS_B’,’expects_CON’] >> B_Commit,

(’fnsh_sbmtb’) >> Netmsg,



/******************************************/


(Ms,rB,eB,b2priv,apub)




[’offer’] ~? B2_State,

Ms := ’msb2’,

rB := sign(b2priv,Ms),

(TSA, B2, [rB]) >> Network,

eB := crypt(apub,[Ms,rB,’TS_B2’]),

221

(A,B2,[eB,’offer’]) >> Network,

[Ms,rB,’TS_B2’,’expects_CON’] >> B2_Commit,

(’fnsh_sbmtb2’) >> Netmsg,

[’expect_A_cmf’] >> B2_State,

[’offer’] >> B2_State;

/******************************************/


(Mb,Mbb,Mb2,Msb,Msbb,Msb2,Lsb,Lsbb,Lsb2,

sig,rAb,rAbb,eAb,eAbb,tsb,tsbb,ts1b,ts1bb,

rAb2,eAb2,tsb2,ts1b2,apriv,bpub,b2pub)






(’TS_A’) ~? Netmsg,




head(tail(Mb))=’offer’,

tsb := head(Mb),

ts1b := crypt(apriv,tsb),

Lsb := head(ts1b),

Msb := elem(2,ts1b),

elem(3,ts1b) = ’TS_B’,

verify(bpub,Msb)= ’true’,

Lsb = elem(3,Msb),

rAb := sign(apriv,Lsb),

(A,BB,Mbb) << Network,

head(tail(Mbb))=’offer’,

tsbb := head(Mbb),

ts1bb := crypt(apriv,tsbb),

Lsbb := head(ts1bb),

Msbb := elem(2,ts1bb),

elem(3,ts1bb) = ’TS_B’,

verify(bpub,Msbb)= ’true’,

Lsbb = elem(3,Msbb),

rAbb := sign(apriv,Lsbb),


head(tail(Mb2))=’offer’,

tsb2 := head(Mb2),

ts1b2 := crypt(apriv,tsb2),

Lsb2 := head(ts1b2),

Msb2 := elem(2,ts1b2),

elem(3,ts1b2) = ’TS_B2’,

verify(b2pub,Msb2)= ’true’,

Lsb2 = elem(3,Msb2),

rAb2 := sign(apriv,Lsb2),


sig := sign(apriv,[Mb,Mbb,Mb2]),

(TSA, A, [sig]) >> Network,

eAb := crypt(bpub,[rAb, sig, ’TS_A’]),

(B,A,[eAb,’A_cfm’]) >> Network,

[sig,’TS_A’] >> A_CommitB,

[Lsb,Msb,rAb,’TS_B’] >> A_CommitB,

[sig,’TS_A’] >> ACommitB,

[Lsb,Msb,rAb,’TS_B’] >> ACommitB,

eAb2 := crypt(b2pub,[rAb2, sig, ’TS_A’]),

(B2,A,[eAb2,’A_cfm’]) >> Network,

[sig,’TS_A’] >> A_CommitB2,

[Lsb2,Msb2,rAb2,’TS_B2’] >> A_CommitB2,

[sig,’TS_A’] >> ACommitB2,

[Lsb2,Msb2,rAb2,’TS_B2’] >> ACommitB2,

(’clstndr’) >> Netmsg,



/******************************************/


(M,Ms,sigB,ts,ts1,sigA,sigApl,bpriv,apub)







(B,A,M) << Network,


[Ms,sigB,’TS_B’,’expects_CON’] << B_Commit,

ts := head(M), /* cipher text from A*/


sigA := head(ts1),

verify(apub,head(ts1))= ’true’,

Ms = elem(3, sigA),

[Ms,sigB,sigA,’TS_B’] >> B_Commit,

[Ms,sigB,sigA,’TS_B’] >> BCommit,

/*** s2 attack change msb to attack_data ***/

/* [’attack_data’,sigB,sigA,’TS_B’] >> BCommit, */

/*** s3 attack change submit tender later ’TS_B1’ ***/

/* [Ms,sigB,sigA,’TS_BL’] >> BCommit, */

sigApl := elem(2,ts1),


[sigApl, ’TS_A’] >> B_Commit,

[sigApl, ’TS_A’] >> BCommit,

(’bf’) >> Netmsg,

[’start’, A] >> B_State;

/******************************************/

223


(M,Ms,sigB2,ts,ts1,sigA,sigApl,b2priv,apub)






[’expect_A_cmf’] << B2_State,

(B2,A,M) << Network,


[Ms,sigB2,’TS_B2’,’expects_CON’] << B2_Commit,

ts := head(M),


sigA := head(ts1),

verify(apub, sigA)= ’true’,

Ms = elem(3, sigA),

[Ms,sigB2,sigA,’TS_B2’] >> B2_Commit,

[Ms,sigB2,sigA,’TS_B2’] >> B2Commit,

sigApl := elem(2,ts1),


[sigApl, ’TS_A’] >> B2_Commit,

[sigApl, ’TS_A’] >> B2Commit,

(’b2f’) >> Netmsg,

[’start’, A] >> B2_State;

/********** timestamp trans ******/

def_trans_pattern TSA TimeStampOffer

(CsB,CsBB,CsB2)



(’clstndr’) ~? Netmsg,

[’TS_B’] ~? TSA_State,

[B, ’agent’] << TSA_State,

(TSA, B, CsB) << Network,

[’TS_B’, head(CsB)] >> TSA_TimeStamp,

[’TS_B’, head(CsB)] >> TSATimeStamp,

[’TS_B’] >> TSA_State,

(’TS_B’) >> Netmsg,

(TSA, BB, CsBB) << Network,

[’TS_BB’, head(CsBB)] >> TSA_TimeStamp,

[’TS_BB’, head(CsBB)] >> TSATimeStamp,

[’TS_BB’] >> TSA_State,

(’TS_BB’) >> Netmsg,

[’TS_B2’] ~? TSA_State,

[B2, ’agent’] << TSA_State,

(TSA, B2, CsB2) << Network,

[’TS_B2’, head(CsB2)] >> TSA_TimeStamp,

[’TS_B2’, head(CsB2)] >> TSATimeStamp,


(’TS_B2’) >> Netmsg,

[’TS_B2’] >> TSA_State;

def_trans_pattern TSA TimeStampClose

(CplA)




(’msb’) ~? Netmsg,

(’msb2’) ~? Netmsg,

[’TS_A’] ~? TSA_State,

[A,’agent’] << TSA_State,

(TSA, A, CplA) << Network,

[’TS_A’] >> TSA_State,

(’TS_A’) >> Netmsg,

[’TS_A’, head(CplA)] >> TSA_TimeStamp,

[’TS_A’, head(CplA)] >> TSATimeStamp;

/********** verification process ************/

def_trans_pattern TTP Verification

(TSAsigApl,TSAsigB2msb2,TSAsigBmsb,

B2sigApl,Msb2,sigB2,sigAmsb2,b2priv,

BsigApl,Msb,sigB,sigAmsb,bpriv,

AsigApl,AsigApll,Amsb,AsigBmsb,AsigAmsb,

Amsb2,AsigB2msb2,AsigAmsb2,apub,apriv,

test1,test2,test3,test4,eB,eB2)

/* sequence control */

(’bf’) ? Netmsg,

(’b2f’) ? Netmsg,


/* extract values from TSA */

[’TS_A’, TSAsigApl] << TSATimeStamp,

[’TS_B2’, TSAsigB2msb2] << TSATimeStamp,

[’TS_B’, TSAsigBmsb] << TSATimeStamp,

/* extract values from B */

[BsigApl, ’TS_A’] << BCommit,

/* [msb,sigB,sigAmsb,’TS_B’] << BCommit, */

[Msb,sigB,sigAmsb,test1] << BCommit, /* test1 hold ’TS_BL’ */

/* extract values from B2 */

[B2sigApl, ’TS_A’] << B2Commit,

/* [Msb2,sigB2,sigAmsb2,’TS_B2’] << B2Commit, */

[Msb2,sigB2,sigAmsb2,test2] << B2Commit,

/* extract values from A */

[AsigApl,’TS_A’] << ACommitB,

[AsigApll,’TS_A’] << ACommitB2,

[Amsb,AsigBmsb,AsigAmsb,’TS_B’] << ACommitB,

[Amsb2,AsigB2msb2,AsigAmsb2,’TS_B2’] << ACommitB2,

225

/** verify S2 change ’msb’ to ’attack_data’ **/

/*


test3 := sign(bpriv,Msb), /* Msb hold ’attack_data’ */

test3 = TSAsigBmsb;

*/

/** verify S3 submit late ’TS_BL’ **/

/* value will not get extracted for normal code*/

/* or test1 hold ’TS_BL’ in second line of code */

/** verify S4 double valid submission **/

/** digital certificate will view B and BB are same role **/


(B2,’priv’,b2priv) ? B2Asymkeys,

(A,’priv’,apriv) ? AAsymkeys,

(A,’pub’,apub) ? AAsymkeys,

Msb = Amsb,

Msb2 = Amsb2,

sigB = sign(bpriv,Msb),

eB := crypt(apub,[Msb,sigB,’TS_B’]),

sigB2 = sign(b2priv,Msb2),

eB2 := crypt(apub,[Msb2,sigB2,’TS_B2’]),

test1 = ’TS_B’,

test2 = ’TS_B2’,

test4 := sign(apriv,[[eB,’offer’],[eB2,’offer’]]);

/* test4 = TSAsigApl, */

Bibliography

[1] Code of tendering, Australian Standard. Prepared by Standards Australia

Committee on Construction Industry Practice, published by Standards As-

sociation of Australia, 1 the Crescent, Homebush, NSW 2140, 28 October

1994. AS 4120, 1994.

[2] Hughes Aircraft Systems International v Airservices Australis [1997] 558

FCA. Technical report, Federal Court of Australia, June 1997.

[3] Commonwealth procurement guidelines. Prepared by Department of Fi-

nance and Administration of Australian Government, January 2005.

[4] Uncitral LEGAL ASPECTS OF ELECTRONIC COMMERCE : EX-

PLANATORY NOTE ON THE CONVENTION ON THE USE OF ELEC-

TRONIC COMMUNICATIONS IN INTERNATIONAL CONTRACTS :

ADDENDUM (2006). prepared by the United Nations Commission on In-

ternational Trade Law (UNCITRAL), Vienna, 2006. A/CN.9/608/ADD.1.

[5] Masayuki Abe and Koutarou Suzuki. M+1-st price auction using homo-

morphic encryption. In Public Key Cryptology 2002, pages 115–124, Berlin,

2002. Springer-Verlag. Lecture Notes in Computer Science Volume 2288.

[6] R. Anderson, C. Manifavas, and C. Sutherland. Netcard – a practical elec-

tronic cash system. In Fourth Cambridge Workshop on Security Protocols,

pages 49–57, 1997.

[7] I. Atlas, A. Pitney, J. Curtis, P. Greenham, G. Hanly, D. Glodstein,

J. Mansfield, and T. Grace, editors. The Tendering Process. Blec Business

Law Education Centre from the training division of Longman Cheshire,

1993.

227

228 BIBLIOGRAPHY

[8] Giampaolo Bella, Lawrence C. Paulson, and Fabio Massacci. The verifica-

tion of an industrial payment protocol: the SET purchase phase. In CCS

’02: Proceedings of the 9th ACM conference on Computer and communica-

tions security, pages 12–20, New York, NY, USA, 2002. ACM Press.

[9] M. Bichler, J. Kalagnanam, K. Katircioglu, A. J. King, R. D. Lawrence,

H. S. Lee, G. Y. Lin, and Y. Lu. Applications of flexible pricing in business

to business electronic commerce. IBM Systems Journal, 41(2):287–302,

2002.

[10] Martin Bichler. An experimental analysis of multi-attribute auctions. De-

cision Support Systems, 29(3):249–268, 2000. www.sciencedirect.com.

[11] Dan Boneh and Matthew Franklin. Identity-based encryption from the weil

pairing. In Advances in Cryptology - CRYPTO 2001: 21st Annual Inter-

national Cryptology Conference, Santa Barbara,California, USA, August

19-23, 2001, volume LNCS 2139, pages 213–229, Berlin, Heidelberg, 2001.

Springer-Verlag.

[12] A. Boulmakoul and M. Sall. Integrated contract man-

agement. In Proceedings of the 9th Workshop of the HP

OpenView University Association Online conference, 2002.

http://www.hpovua.org/PUBLICATIONS/PROCEEDINGS/.

[13] Colin Boyd and Peter Kearney. Exploring fair exchange protocol using

specification animation. In E. Okamoto J. Pieprzyk and J. Seberry, edi-

tors, Information Security - ISW 2000, volume LNCS 1975, pages 209–223,

Berlin Heidelberg, 2000. Springer-Verlag.

[14] Colin Boyd and Wenbo Mao. Security issues for electronic auctions. Techni-

cal report, 2000. available at www.hpl.hl.com/techreports/2000/HP-2000-

90.html.

[15] F. Branco. The design of multidimensional auctions. The Rand Journal of

Economics, 28(1):63–81, Spring 1997.

[16] Felix Brandt. Secure and private auctions without

auctioneers. In Technical Report FKI-245-02, 2002.

http://wwwbrauer.in.tum.de/∼brandtf/studies.html.

BIBLIOGRAPHY 229

[17] Felix Brandt and Tuomas Sandholm. (im)possibility of unconditionally

privacy-preserving auctions. In Proceedings of the third international joint

conference on Autonomous agents and multiagent systems AAMAS’04, July

19-23 2004, New York. ACM, July 2004.

[18] Ahto Buldas and Peeter Laud. New linking schemes for digital time-

stamping. In Information Security and Cryptology, pages 3–13, 1998.

[19] Ahto Buldas, Peeter Laud, Helger Lipmaa, and Jan Villemson. Time-

stamping with Binary Linking Schemes. In Hugo Krawczyk, editor, Ad-

vances on Cryptology — CRYPTO ’98, volume 1462 of Lecture Notes in

Computer Science, pages 486–501, Santa Barbara, USA, August 1998.

Springer-Verlag.

[20] A. Byde, M. Yearworth, K. Chen, and C. Bartolini. Autona:a system for au-

tomated multiple 1-1 negotiation. In Proceedings of the IEEE International

Conference on E-Commerce (CEC’03). IEEE, 2003.

[21] Marco Casassa, Keith Harrison, and Martin Sadler. The HP time vault

service: exploiting IBE for timed release of confidential information. In

Proceedings of the twelfth international conference on World Wide Web,

May 2004, Budapest, Hungary, pages 160–169. ACM, 2003.

[22] J.K.Y. Chan and M.K.O. Lee. Sme e-procurement adoption in hong kong

- the roles of power, trust and value. In Ralph H. and Jr. Sprague, editors,

Proceedings of the 36th Annual Hawaii International Conference on System

Sciences (HICSS’03), page 10pp. IEEE Computer Society, 2002.

[23] G. Chang. The optimization and design of procurement strategy in e-

commerce. In Proceedings of the 2006 IEEE Asia-Pacific Conference on

Services Computing (APSCC’06). IEEE, 2006.

[24] Y.K. Che. Design competition through multidimensional auctions. The

Rand Journal of Economics, 24(4):668–680, Winter 1993.

[25] S. Christensen. Formation of contracts by email-is it just the same as the

post? Queensland University of Technology Law and Justice Journal, pages

22–38, 2001.

230 BIBLIOGRAPHY

[26] S. Christensen, B. Duncan, and R. Low. Moving Queensland Property

Transactions to the Digital Age: Can Writing and Signature Requirements

be Fulfilled Electronically? Technical report, Centre for Commercial and

Property Law Queensland University of Technology, Brisbane, December

2002. A Case for Reform Based upon the Electronic Transactions (Queens-

land)Act 2001.

[27] S. Christensen and W. Duncan. Maintaining the integrity of electronic

tendering - reflections on the capacity of the Australian legal framework to

meet this challenge. eLaw Journal, Murdoch University Electronic Journal

of Law, 13(2):8–36, 2006.

[28] Clifford Cocks. An identity based encryption scheme based on quadratic

residues. In Proceedings of the 8th IMA International Conference on Cryp-

tography and Coding, pages 360–363, London, UK, 2001. Springer-Verlag.

[29] J. Collins, B. Youngdahl, S. Jamison, B. Mobasher, and M. Gini. A market

architecture for a multi-agent contracting. In the 2th Int’l Conference on

Autonomous Agents, pages 285–292, May 1998.

[30] Commission of the European Communities, ITSEC,. In-

formation technology security evaluation criteria version 1.2.

http://www.ssi.gouv.fr/en/confidence/methodology.html, June 1991.

[31] The Independent Commissioner Against Corruption. Report on investiga-

tion into tendering for vinyl floor products. Box 500 GPO Sydney 2001,

DX 557, CNR Cleveland & George Streets Redfern NSW 2016, 1991.

[32] The Independent Commissioner Against Corruption. Report on investiga-

tion into the sydney water board and sludge tendering ICAC. This Report

results from an investigation and hearing conducted in late 1991 and early

1992 by Miss Margaret Beazley AC, Box 500 GPO Sydney 2001, DX 557,

CNR Cleveland & George Streets Redfern NSW 2016, May 1992.

[33] Ivan Damgard. Commitment schemes and zero-knowledge protocols. Lec-

ture Notes in Computer Science, 1561:63–86, Jan 1999.

[34] Esther David, Rina Azoulay-Schwartz, and Sarit Kraus. Bidders strategy

for multi-attribute sequential english auction with a deadline. In Proceed-

ings of the second international joint conference on Autonomous agents

BIBLIOGRAPHY 231

and multiagent systems AAMAS’03, July 14-18 2003, Melbourne, Australia,

July 2003.



Issues: Research Report. Technical Report Report No. 2002-067-A, CRC

Construction Innovation, www.construction-innovation.info, 2005.



Issues. Technical report, CRC Construction Innovation, www.construction-

innovation.info, 2006.

[37] Luitzen de Boer, Jeroen Jarink, and Govert Heijboer. A conceptual model

for assessing the impact of electronic procurement. European Journal of

Purchasing and Supply Management, 8:25–33, 2002.

[38] Whitfield Diffie and Martin E. Hellman. New directions in cryptography.

IEEE Transactions on Information Theory, IT-22(6):644–654, 1976.

[39] R. Du, C. Boyd, and E. Foo. A secure e-tender protocol. In Simone Fischer-

Hubner, Steven Furnell, and Costas Lambrinoudakis, editors, TrustBus

2006, volume 4083 of LNCS, pages 213–222. Springer-Verlag GmbH, 2006.

[40] R. Du, E. Foo, C. Boyd, and B. Fitzgerald. Defining security services for

electronic tendering. In The Australasian Information Security Workshop

(AISW2004), volume 32, pages 43–52. Australian Computer Society Inc

and ACM, 2004.

[41] T. ElGamal. A public key cryptosystem and a signature scheme based on

discrete logarithms. IEEE Transactions on Information Theory, 31(4):469–

472, 1985.

[42] T. ElGamal. A public key cryptosystem and a signature scheme based on

discrete logarithms. IEEE Transactions on Information Theory, 31:469–

472, 1985.

[43] M Emiliani. Business-to-business online auctions: key issues for purchas-

ing process improvement. Supply Chain Management: An International

Journal, 5(4):176–186, 2000.

232 BIBLIOGRAPHY

[44] M. L. Emiliani and D. J. Stec. Realizing savings from online reverse auc-

tions. Supply Chain Management: An International Journal, 7(1):12–23,

2002.

[45] B. Fitzgerald and A. Fitzgerald, editors. Cyberlaw, Cases and Materials on

the Internet, Digital Intellectual Property and Electronic Commerce. But-

terworths LexisNexis, 2002.

[46] Rosario Gennaro, Stanislaw Jarecki, Huge Krawczyk, and Tal Rabin. Se-

cure distributed key generation for discrete-log based cryptosystems. In

Advances in Cryptology - Eurocrypt’99, volume LNCS 1592, pages 295–310.

Springer-Verlag, 1999.

[47] S. Gurgens, P. Ochsenschlager, and C. Rudolph. Role based specification

and security analysis of cryptographic protocols using asynchronous prod-

uct automata. In DEXA 2002 13th International Workshop on Trust and

Privacy in Digital Business, pages 473 – 479. IEEE, 2002.

[48] Sigrid Gurgens and Carsten Rudolph. Security analysis of (un-) fair non-

repudiation protocols. In P. Ryan A.E. Abdallah and S. Schneider, editors,

Formal Aspects of Security 2002-BCS FASec 2002, volume LNCS 2629,

pages 97–114, Berlin Heidelberg, 2002. Springer-Verlag.

[49] O. Goldreich and Y. Oren. Definitions and properties of zero-knowledge

proof systems. Journal of Cryptology, 7:1–32, 1994.

[50] Working group 3. Code of Practice for the Selection of Main Contractors.

Construction Industry Board, May 1997.

[51] Stuart Haber and W. Scott Stornetta. How to time-stamp a digital docu-

ment. Journal of Cryptology, 3(2):99–111, 1991.

[52] Michael Harkavy, J D Tygar, and Hiroaki Kikuchi. Electronic auctions

with private bids. In 3rd Usenix Workshop on Electronic Commerce, pages

61–83, 1998.

[53] Butler M. Currie A. Henderson P. Leuschel M. Martin A. Smith A. Ultes-

Nitsche U. Hartel, P. and R. J. Walters. Questions and answers about ten

formal methods. In In Proceedings of Proc. 4th Int. Workshop on Formal

BIBLIOGRAPHY 233

Methods for Industrial Critical Systems II, pages 179–203. University of

Southampton, 1999.

[54] B.W. Harvey and F. Meisel. Auctions Law and Practice. London Butter-

worths, 1985.

[55] P. Herrmann and G. Herrmann. Security requirement analysis of business

process. Electronic Commerce Research, 6:305–335, 2006.

[56] IDABC. FUNCTIONAL REQUIREMENTS FOR CONDUCTING

ELECTRONIC PUBLIC PROCUREMENT UNDER THE EU FRAME-

WORK. Technical report, Interoperable Delivery of European eGov-

ernment Services to public Administrations, Businesses and Citizens,

http://ec.europa.eu/idabc/en/document/4721/5874 [accessed May 2007],

Jan. 2005.

[57] IDABC. FUNCTIONAL REQUIREMENTS FOR CONDUCTING

ELECTRONIC PUBLIC PROCUREMENT UNDER THE EU FRAME-

WORK. Technical report, Interoperable Delivery of European eGov-

ernment Services to public Administrations, Businesses and Citizens,


Jan. 2005.

[58] IDABC. IDA E-PROCUREMENT PROTOCOL XML SCHEMAS

INITIATIVE: e-Ordering and e-Invoicing Phases. Techni-

cal report, Interoperable Delivery of European eGovernment

Services to public Administrations, Businesses and Citizens,


Jan. 2005.

[59] IDABC. IDA E-PROCUREMENT PROTOCOL XML SCHEMAS

INITIATIVE: e-Tendering and e-Awarding Phases. Techni-

cal report, Interoperable Delivery of European eGovernment

Services to public Administrations, Businesses and Citizens,


Jan. 2005.

[60] International Standards Organisation, International Electrotechnical Com-

mission. Standard iso/iec 15408: Evaluation criteria for information tech-

234 BIBLIOGRAPHY

nology. http://www.iso-standards-international.com/iso-5725-kit70.htm,

1999.

[61] J. Irvine. Adam smith goes mobile: Managing services beyond 3g with the

digital marketplace. In European Wireless, Feb 2002.

[62] A. Jaiswal, Y. Kim, and M. Gini. Security model for a multi-agent market-

place. In In Proceedings of the 5th Int’l Conference on Electronic Commerce

(ICEC 2003), pages 119–124, 2003.

[63] M. Jakobsson, A. Juels, and R. Rivest. Making mix nets robust for

electronic voting by randomized partial checking. To be presented at

USENIX’02. citeseer.nj.nec.com/jakobsson02making.html.

[64] Jan Jurjens. UMLsec: Extending UML for Secure Systems Development.

In UML 2002 - The Unified Modeling Language : 5th International Con-

ference, Dresden, Germany, September 30 - October 4, volume LNCS 2460,

pages 412–425, Berlin Heidelberg, September 2002. Springer-Verlag.

[65] Don Johnson, Alfred Menezes, and Scott Vanstone. The elliptic

curve digital signature algorithm (ECDSA). Certicom Corporation,

www.certicom.com, 2001.

[66] R. J. Kauffman and H. Mohtadi. Information technology in b2b e-

procurement: Open vs. proprietary systems. In Proceedings of the 35th

Hawaii International Conference on System Sciences. IEEE, 2002.

[67] A. Kayed and B. Colomb. Infrastructure for electronic tendering interop-

erability, 1999.

[68] John Kelsey and Bruce Schneier. Minimizing bandwidth for remote access

to cryptographically protected audit logs. In Recent Advances in Intrusion

Detection, 1999.

[69] Hiroaki Kikuchi. (m+1)st-price auction. In The Fifth International Con-

ference on Financial Cryptography 2001, pages 291–298, Berlin, February

2001. Springer-Verlag. Lecture Notes in Computer Science Volume 2339.

[70] Hiroaki Kikuchi, Shinji Hotta, Kensuke Abe, and Shohachiro Nakanishi.

Distributed auction servers resolving winner and winning bid without re-

BIBLIOGRAPHY 235

vealing privacy of bids. In proc. of International Workshop on Next Gen-

eration Internet (NGITA2000), IEEE, pages 307–312, July 2000.

[71] Eyal Kushilevitz. Privacy and communication complexity. In IEEE Sym-

posium on Foundations of Computer Science, pages 416–421, 1989.

[72] RSA Laboratories. RSAES-OAEP Encryption Scheme. RSA Security Inc,

20 Crosby Drive Bedford, MA 01730 USA, 2000.

[73] RSA Laboratories. PKCS1 v2.1 RSA Cryptography Standard. RSA Secu-

rity Inc, 20 Crosby Drive Bedford, MA 01730 USA, 2002.

[74] Helger Lipmaa. On optimal hash tree traversal for interval time-stamping.

[75] Natalia Lopez, Manuel Nunez, Ismael Rodriguez, and Fernando Rubio. Im-

proving privacy in vickrey auctions. SIGecom Exch., 5(1):1–12, 2004.

[76] W. Mao and C. Boyd. On the use of encryption in cryptographic protocols.

Codes and Cyphers: Cryptography and Coding, IV:251–162, 1995.

[77] Henri Massias, Xavier Serret, and Jean-Jacques Quisquater. Main issues

on their use and implementation. In Infrastructure for Collaborative Enter-

prises - Fourth International Workshop on Enterprise Security, IEEE 8th

International Workshops on Enabling Technologies, pages 178–183. ISBN

0-7695-0365-9, 1999.

[78] R. Preston McAfee and John. McMillan. Auctions and bidding. Journal of

Economic Literature, 25(2):699 – 738, June 1987.

[79] Catherine Meadows. Invited address: Applying formal methods to crypto-

graphic protocol analysis. In Computer Aided Verification, 12th Interna-

tional Conference-CAV 2000, volume LNCS 1855, Berlin Heidelberg, 2000.

Springer-Verlag.

[80] Catherine Meadows. Formal methods for cryptographic protocol analysis:

Emerging issues and trends. IEEE Journal on Selected Areas in Commu-

nications, 21:44–54, 2003.

[81] A.J. Menezes, P.C. van Oorschot, and S.A. Vanstone. Handbook of Applied

Cryptography. CRC Press, Boca Raton, Florida 33431, 1997.

236 BIBLIOGRAPHY

[82] Moni Naor and Kobbi Nissim. Communication preserving protocols for

secure function evaluation. In ACM Symposium on Theory of Computing,

pages 590–599, 2001.

[83] P. Ochsenschlger. Verification of cooperating systems by simple homo-

morphisms using the product net machine. In A. Oberweis J. Desel and

W. Reisig, editors, Workshop Algorithmen und Werkzeuge fr Petri Netze,

Berlin, pages 48–53, Humboldt Universitat Berlin, 1994.

[84] Peter Ochsenschlager, Jurgen Repp, Roland Rieke, and U. Nitsche. The SH-

Verification Tool-Abstraction-Based Verification of Co-operating Systems.

Formal Aspects of Computing, The Int. Journal of Formal Methods, 11:1–

24, 1999.

[85] Kazumasa Omote. A Study on Electronic Auctions. Partial fulfillment of

the requirements for the degree of phd, School of Infromation Science Japan

Adanced Institute of Science and Technology, March 2002.

[86] T. Pedersen. A threshold cryptosystem without a trusted party (extended

abstract). In D.W. Davies, editor, Advances in Cryptology - EUROCRYPT

’91, volume 547 of LNCS, pages 522–526. Springer-Verlag, 1991.

[87] Kun Peng, Colin Boyd, Edward Dawson, and Kapali Viswanathan. Ro-

bust, privacy protecting and publicly verifiable sealed-bid auction. In

Fourth International Conference on Information and Communication Se-

curity (ICICS 2002), volume 2513, pages 147–159, Berlin, 2002. Springer-

Verlag. Lecture Notes in Computer Science Volume 2513.

[88] Kun Peng, Colin Boyd, Edward Dawson, and Kapali Viswanathan. Five

sealed-bid auction models. In Proceedings of the Australasian information

security workshop conference (AISW) on ACSW frontiers 2003 - Volume

21, Adelaide, Australia, volume 34 of ACM Conferences in Research and

Practice in Information Technology Series, pages 77 – 86. Australian Com-

puter Society, Inc., 2003.

[89] Bart Preneel. Analysis and Design of Cryptographic Hash Functions. PhD

thesis, Katholieke Universiteit Leuven, 1993.

BIBLIOGRAPHY 237

[90] R.L. Rivest, A. Shamir, and L.M. Adleman. A method for obtaining digital

signatures and public-key cryptosystems. Communications of the ACM,

21:120–126, 1978.

[91] Ronald L. Rivest and Adi Shamir. Payword and micromint: Two simple

micropayment schemes. In Security Protocols Workshop, pages 69–87, 1996.

[92] Pattie Maesor Robert H. Guttman. Cooperative Information Agents II

Learning, Mobility and Electronic Commerce for Information Discovery

on the Internet, volume 1435/1998 of Lecture Notes in Computer Science,

chapter Cooperative vs. Competitive Multi-agent Negotiations in Retail

Electronic Commerce, pages 135–147. Springer Berlin / Heidelberg, 1998.

[93] Ismael Rodriguez and Natalia Lopez. Implementing private vickrey auc-

tions. In SAC ’05: Proceedings of the 2005 ACM symposium on Applied

computing, pages 796–800, New York, NY, USA, 2005. ACM Press.

[94] J. Dunlop A. Tomlinson S. K. Goo, J. M. Irvine and S. Schwiderski-Grosche.

Security requirements for mobile service provision via a digital marketplace

(invited paper). In In Proceedings of the 11th European Wireless Conference

(EW’05), volume 2, pages 573–581. VDE, April 2005.

[95] K Sako. An auction scheme which hides the bids of losers. In Public Key

Cryptology 2000, pages 422–432, Berlin, 2000. Springer-Verlag. Lecture

Notes in Computer Science Volume 1880.

[96] Adi Shamir. How to share a secret. Communications of ACM, 22(11):612–

613, 1979.

[97] Adi Shamir. Identity-based cryptosystems and signature schemes. In Pro-

ceedings of CRYPTO 84 on Advances in cryptology, pages 47–53, New York,

NY, USA, 1985. Springer-Verlag New York, Inc.

[98] L K Shan. Case Study of Application of E-Project Management System for

Construction Industry in Hong Kong. Bsc (hons) in building engineering

and management, Department of Building and Real Estate, The Hong Kong

Polytechnic University, 2003.

238 BIBLIOGRAPHY

[99] Chandrasekar Subramaniam and Michael J. Shaw. The effects of process

characteristics on the value of b2b e-procurement. Information Technology

and Management, 5:161–180, 2004.

[100] Srinivas Talluri and Gary L Ragatz. Multi-attribute reverse auctions in b2b

exchanges: A framework for design and implementation. Journal of Supply

Chain Management, 40(1):52–60, 2004.

[101] J. Teich, H. Wallenius, and J. Wallenius. Multiple-issue auction and market

algorithms for the world wide web. Decision Support Systems, 26:49–66,

1999.

[102] The Internet Engineering Task Force. Network time protocol (version 3)

(rfc 1305). http://www.ietf.org/rfc/rfc1305.txt, March 1992.

[103] The Internet Engineering Task Force. Electronic signature formats for long

term electronic signatures (rfc 3126). http://www.ietf.org/rfc/rfc3126.txt,

September 2001.

[104] The Internet Engineering Task Force. Internet x.509 pub-

lic key infrastructure time stamp protocols (tsp) (rfc 3161).

http://www.ietf.org/rfc/rfc3161.txt, August 2001.

[105] C.P. Thorpe and J.C.L. Bailey. Commercial contracts, A practical guide to

deals, contracts, agreements and promises. Woodhead, Cambridge England,

1996.

[106] Wade Trappe and Lawrence C. Washington. Introduction to Cryptography

with Coding Theory 2nd addition. Pearson Prentice Hall, 2006.

[107] UN/CEFACT-tbg6. Electronic Tendering International Standardization

- Business Requirement Specification. Technical Report ETP032 v2r6,

UN/CEFACT, http://www.etendering-tbg6.net, Jan. 2006.

[108] Masashi Une. The security evaluation of time stamping schemes: The

present situation and studies. In IMES Institute for Monetary and Eco-

nomic Studies, number No.2001-E-18 in IMES Discussion Paper Series.

Bank of Japan, C.P.O BOX 203 Tokyo 100-8630 Japan, 2001.

BIBLIOGRAPHY 239

[109] Masashi Une and TSutomu Matsumoto. A framework to evaluate security

and cost of time stamping schemes. IEICE TRANS. Fundamentals, E85-

A:125–139, 2002.

[110] W. Vickrey. Counterspeculation, auctions, and competitive sealed tenders.

Journal of Finance, 16(1):8–37, March 1961.

[111] Kapali Viswanathan, Colin Boyd, and Ed Dawson. A three phased schema

for sealed bid auction system design. In Information Security and Privacy,

5th Australasian Conference, ACISP’2000, pages 412–426, Berlin, 2000.

Springer-Verlag. Lecture Notes in Computer Science 1841.

[112] Jianying Zhou and Dieter Gollmann. A fair non-repudiation protocol. In

Proceedings of the IEEE Symposium on Research in Security and Privacy,

pages 55–61, Oakland, CA, 1996. IEEE Computer Society Press.