Introduction “… Is there such a thing anymore


“… Is there such a thing anymore as a
software system that doesn’t need to be secure?

Almost every software controlled system
faces threats from potential adversaries, from Internet-aware client
applications running on PCs, to complex telecommunications and power systems accessible
over the Internet, to commodity software with copy protection mechanisms.
Software engineers must be cognizant of these threats and engineer systems with
credible defenses, while still delivering value to

Customers. Security concerns must inform
every phase of software development, from requirements engineering to design,
implementation, testing and deployment…”

article marked a surfacing need in the IT community: security is not just about
securing protocols and communication lines, it is also about software. Indeed,
the need of securing software is even more pressing than the need of securing
communication. Almost, exploits of software security bugs are constantly among
the headlines .It has also clearly emerged that security concerns must be
tackled from the very beginning because looking at them as an afterthought
often leads to problems.

Part of this challenge has been answered,
and what is still missing is capturing the high-level security requirements,
without getting suddenly bogged down into security solutions. We find out that
at certain stage a leap is made: we have a system with no security features
consisting of high-level functionalities, and then the next refinement shows
encryption, access control, authentication and the like.

In this paper we propose a solution that is
based on augmenting the framework to take into account security considerations.
Our decision to augment the language has been mainly driven by a major case
study, the modelling of the Secure Electronic Transactions. The industrial
relevance of the case study is clear but the topic is challenging also for
technical reasons. At first because the proposal is accompanied by a massive documentation
spanning from high-level business description to bit-oriented programming
guide. However, if we look to the documentation we find out that the business
case is described in a totally informal way and the programming guide is fairly
operational, in many points a good example of bit-oriented programming. The
objective of our protocol is to provide issuers with the ability to
authenticate cardholders during an online purchase without involving the third
party VISA or MasterCard. We define a new transaction flow involving
cardholder, merchant, payment gateway and card issuer, and allowed parties to identify
themselves to each other and exchange information securely using digital
certificate. For some implementation reasons, the cardholder is not requested to
have his digital Certificate, he use the password code to be authenticated by
the card issuer.

                                        SECURITY REQUIREMENTS OF

 A. Information
confidentiality – All information during the transactions has the request of
being kept confidential. For instance, account number and user name may be
embezzled by others who have access to them business opportunity may be lost if
order and payment information of your customer’s are obtained by
competitors.  Thus, encryption is required
in the E-C information transmission.


Data integrity- E-C should provide medium to identify data integration,
ensuring the Web data do not be altered in transmission.


C. Authentication
of participants- The parts involved may have never met each other. So to make
the transaction successful, the first step is to identify the two parts, which
is the essential prerequisite of transactions.


Non-repudiation -The transaction must have such services that enable one Party
to prevent another party denying having taken a particular action, e.g. sending
order/payment information, confirmation of order/payment. Both consumer and
merchant also require this service.


End-user implementation Requirement