Goal-Oriented Software Security Engineering: The

Electronic Smart Card Case Study

Riham Hassan Mohamed Eltoweissy 1 Shawn Bohner Sherif El-Kassas

Department of

Computer Science,

Virginia Tech

rhabdel@vt.edu

The Bradley department

of Electrical and

Computer Engineering,

Virginia Tech

toweissy@vt.edu

Department of

Computer Science,

Rose-Hulman Institute

of Technology

bohner@rose-

hulman.edu

Department of Computer

Science, The American

University in Cairo

sherif@aucegypt.edu

Abstract— We advocate goal-oriented software security

engineering to produce highly secure software in a constructive,

provable and cost-effective manner. Our approach is to couple

goal-oriented semi-formal requirements specifications with

formal design and implementation. To this effect, we proposed

FADES (Formal Analysis and Design for Engineering Security)

in [9] as the first goal-oriented software security engineering

approach that provides a systematic and automated bridge

between the goal-directed semi-formal KAOS (Knowledge

Acquisition for autOmated Specifications) framework and the B

formal method to derive formal design and implementation from

security requirements. In this paper, we demonstrate the

applicability of FADES and study its effectiveness through a

generic Electronic Smart Card case study and a comparative

analysis between FADES and strictly applying formal methods.

We use the case study to demonstrate how the goal-oriented

formulation of security requirements in FADES paves the way

for formal design that provably preserves the security properties.

Further, the results of the comparison between FADES and Z

show that FADES achieves better requirements completeness,

consistency and security quality.

Keywords-formal methods, security engineering, goal-oriented

requirements.

I. INTRODUCTION

As computing pervades more of our business and personal lives, security emerges as a key challenge in engineering large-scale software systems. Poor security engineering has been identified as the major source of security vulnerabilities [1]. Security is typically bolted on after the software is put into production and often in an ad-hoc manner.

Candidate techniques proposed to security engineering vary between semi-formal modeling like UML and formal specification techniques [2]. Semi-formal approaches are easy to use and communicate. However, they can only cope with functional requirements, and they support limited forms of specification and analysis [4]. Formal methods are precise and support more sophisticated forms of analysis. However, they are not readily accessible to practitioners and writing formal specifications is often difficult and costly [2].

Our research has shown that the goal-oriented semi-formal methods are more suitable to elicit, analyze and specify security requirements while formal methods would produce more reliable design and implementation. We promote goal-oriented software security engineering as a middle ground between the world of semi-formal security requirements and the world of formal design. Goal-oriented software security engineering addresses the imprecision of semi-formal methods and the complications and cost of formal methods. To this effect, we have proposed the FADES (Formal Analysis and Design for Engineering Security) software security engineering approach in [9] with the goal to produce highly secure software at a reasonable cost.

In a nutshell, FADES integrates the goal-directed requirements-driven KAOS (Knowledge Acquisition for autOmated Specifications) security extension framework [1, 2] with the B formal method [3]. FADES provides means to transform semi-formal security requirements to formal design in a constructive and systematic manner. This addresses the core challenge of software security engineering, which is the transition from semi-formal security requirements specifications to formal design.

Relaxing formality during security requirements analysis facilitates reasoning about security requirements and organizing them in a well-structured format, which is the KAOS goal graph. Employing the B formal method for design and implementation provides correctness-by-construction and enables preserving the security properties specified in the requirements model. Integrating KAOS with B makes FADES comprehensive in handling security requirements at the key stages of development. Moreover, the integration makes FADES more cost-effective than purely applying formal methods to security requirements as evidenced in the evaluation of FADES by both security engineering practitioners and academic and industrial experts in the formal methods for security domain [8, 9].

In this paper, we demonstrate the effectiveness of FADES through applying it to an electronic smart card system. Our rationale for the selection of the case study is that it can serve as a canonical case study used to demonstrate formal methods-

1 Also, with the Center of Excellence in Information Assurance, King

Saud University, SA.

2009 International Conference on Computational Science and Engineering

978-0-7695-3823-5/09 $26.00 © 2009 IEEE

DOI 10.1109/CSE.2009.234

213

2009 International Conference on Computational Science and Engineering

978-0-7695-3823-5/09 $26.00 © 2009 IEEE

DOI 10.1109/CSE.2009.234

213

2009 International Conference on Computational Science and Engineering

978-0-7695-3823-5/09 $26.00 © 2009 IEEE

DOI 10.1109/CSE.2009.234

213

2009 International Conference on Computational Science and Engineering

978-0-7695-3823-5/09 $26.00 © 2009 IEEE

DOI 10.1109/CSE.2009.234

213

2009 International Conference on Computational Science and Engineering

978-0-7695-3823-5/09 $26.00 © 2009 IEEE

DOI 10.1109/CSE.2009.234

213

2009 International Conference on Computational Science and Engineering

978-0-7695-3823-5/09 $26.00 © 2009 IEEE

DOI 10.1109/CSE.2009.234

213

2009 International Conference on Computational Science and Engineering

978-0-7695-3823-5/09 $26.00 © 2009 IEEE

DOI 10.1109/CSE.2009.234

213

2009 International Conference on Computational Science and Engineering

978-0-7695-3823-5/09 $26.00 © 2009 IEEE

DOI 10.1109/CSE.2009.234

213

based approaches and it has been implemented in a number of formal methods. Further, the security requirements involved in the electronic smart card system (integrity, confidentiality, authenticity, etc.) are common among other e-commerce and communication-based systems. Using the case study, we can also provide comparative analysis between FADES and other related methods. In this paper, we have applied FADES to the same set of security requirements as the Z implementation of the electronic smart card in [7] and compared FADES to Z.

In the remainder of the paper, section 2 discusses the goal-oriented paradigm, why and how it is effective for requirements engineering. We then briefly describe FADES as a means to move from semi-formal to formal representations for development in section 3. FADES is then demonstrated and compared to the Z formal method when both are applied to the electronic smart card system in section 4. Finally, the paper concludes with an outline of future work.

II. GOAL-ORIENTED REQUIREMENTS ENGINEERING

Traditional approaches for requirements engineering fall into one of two categories; informal and semi-formal methods like object-oriented analysis and formal methods like B, Z, VDM++, etc. These approaches suffer from serious shortcomings that explain why they are not fully adequate for the critical phase of requirements elaboration and analysis. These shortcomings are outlined as follows [4]:

• Limited scope: The vast majority of techniques lack

support for reasoning about the composite system

made of the software and its environment.

• Lack of rationale capture: formal notations do not

address the problem of understanding requirements in

the context of higher level concerns in the application

domain.

• Poor guidance: Constructive methods for building

correct models/specifications for complex systems in

a systematic, incremental way are by and large non-

existent.

• Lack of support for exploration of alternatives:

Requirements engineering is much concerned with

the exploration of alternative system proposals.

Traditional modeling and specification techniques do

not allow such alternatives to be represented,

explored, and compared for selection.

The above limitations have led to the rise of the new goal-

oriented paradigm for system and software requirements

analysis [4, 5]. The KAOS goal-oriented framework by Van

Lamsweerde and the i* framework [10] represent the state of

the art as mature requirements engineering frameworks in the

goal-oriented requirements engineering paradigm [5].

Van Lamsweerde argues that goals offer the right kind of

abstraction to address such inadequacies; especially for high

assurance systems. Goal-oriented methods are adequate for

requirements engineering that is concerned with the elicitation

of goals to be achieved by the software-to-be (WHY issues),

the operationalization of such goals into specifications of

services and constraints (WHAT issues), and the assignment

of responsibilities for the resulting requirements to agents such

as humans, devices and software available or to be developed

(WHO issues) [6]. Positive/negative interactions with the

other system goals can be captured in goal models and

managed appropriately [2]; exceptional conditions in the

environment that might hinder critical goals from being

achieved can be identified and resolved to produce more

robust requirements [2]; the goals can be specified precisely

and refined incrementally into operational software

specifications that provably assure the higher-level goals [2].

Requirements in fact “implement” goals much the same way

as programs implement design specifications [4].

III. THE FADES APPROACH

FADES is a step towards the development of highly secure software in a cost-effective manner [8]. FADES is goal-oriented software engineering approach [9] that systematically and provably derives formal design specifications and implementation from a set of security requirements modeled using the KAOS security extension framework. The approach effectively integrates the KAOS security extension, which is characterized by the ability to structure security requirements in a near complete and consistent model with the B method, which provides formal guarantees for the correctness of the system development. Our research showed that KAOS is promising in that it could be extended with an extra step of formality in order to fully implement security requirements while preserving the security properties specified in the requirements model. Moreover, extending KAOS with more formality in a development framework like B allows for tracing requirements at the key steps of development. FADES provides means to transform KAOS to B. To the best of our knowledge, FADES is the first security engineering approach that provides a systematic and automated bridge between goal-directed semi-formal security requirements and formal design and implementation. Figure 1 depicts an overview of FADES and the coming sections outline its key stages to produce secure software. For more details about FADES, refer to [8, 9].

Figure 1: The FADES Approach

214214214214214214214214

A. KAOS for Security Requirements Analysis

In the KAOS framework, all requirements are regarded as goal to be achieved by the envisioned system. A goal is, “a prescriptive statement of intent about some systems whose satisfaction requires the cooperation of some of the system agents while agents are active components such as humans, devices, legacy software or software-to-be components” [1]. Goals are “operationalized” into operations performed by agents to achieve these goals.

Goals are organized in a hierarchy obtained from the refinement of higher level goals into lower-level goals using the AND/OR refinement mechanism. The resulting hierarchy is a directed, acyclic-graph. Goal refinement ends when every subgoal is realizable by some individual agent assigned to it [1]. Obstacles are undesirable goals that hinder desired goals from being achieved. Obstacles are then analyzed based on their criticality to the well-being of the whole system and resolution mechanisms are used to generate alternative resolutions [2].

In the security requirements context, attackers are malicious agents in the environment and threats are obstacles intentionally set up by attackers while assets are to be protected against threats [1]. Van Lamsweerde has specified some generic specification patterns for eliciting security goals such as confidentiality, integrity, availability, privacy, authentication and non-repudiation.

B. B for Design and Implementation

B is a method for specifying, designing and coding software systems that integrates formal proof techniques in software development [3]. The basic idea of B development is to start with an abstract model of the system under development while more detailed models are built by refining the initial model. A key merit of this refinement mechanism is the ability to preserve already proven system properties in higher level models. B models are accompanied by mathematical proofs, called proof obligations that guarantee correctness and effectiveness of system development. Software systems with security requirements exhibit a strong need for assured development that allows for adding more details on an abstract system model without violating the already proven security properties.

C. Transforming KAOS to B

The KAOS requirements model is represented in the form of a directed-acyclic graph rooted at the very high level goal of the system and structured in multiple levels. Goals at each level refine the goals at the higher level. The whole system is represented either as a single abstract B machine or multiple abstract B machines related to each other based on the size of the system. Each KAOS entity (passive object) is represented as a B machine included or seen by the system machine(s) and encapsulating its KAOS attributes and operations manipulating the attributes.

Each KAOS operation is represented as a B operation in the system machine and uses the KAOS entities either as parameters or return values. KAOS operations’ preconditions

are directly mapped to a B precondition for the B operation since both KAOS and B preconditions are written in first order-predicate logic.

Agents (active objects) are not directly transformed to KAOS since they are responsible for the runtime behavior of the system. Agents’ behavior is modeled through the transformed KAOS operations. The acceptance test cases derived from the KAOS goal graph as indicated in the next section simulate the agent behavior in executing the KAOS operations that realized the requirements goals.

KAOS goals are not transformed to B since their semantics is encapsulated in the KAOS operations that realize the leaf goals. KAOS goals in the goal graph are used to provide links for requirement traceability.

KAOS domain properties are captured in B as invariants to the B machines that model the KAOS objects and as pre/post conditions to the operations that model KAOS operations. Objects invariants as well as operations preconditions are preserved during the B refinement steps meaning that the domain properties are maintained throughout the software development lifecycle using FADES. For further details about the transformation scheme, refer to [9].

D. Acceptance Testing

FADES provides an extra verification step to show the maintenance of security properties specified in the requirements model in the derived implementation specifications. FADES derives a suite of acceptance test cases through traversing the KAOS goal graph using a depth firth search algorithm (DFS). Each test case is a sequence of calls to operations that achieve a goal at a middle level of the goal graph. The test cases provide security developers with means to assure a reasonable level of completeness and consistency of their implementation with respect to the requirements model. For further details about the derivation of acceptance test cases, refer to [9]

IV. THE ELECTRONIC SMART CARD CASE STUDY

We have demonstrated FADES on a number of case studies from different domains like communication-based systems and electronic payment systems [9]. The case studies are meant to be of reasonable size, large enough to be convincing and small enough to be manageable. In this paper, we use an electronic smart card system to demonstrate FADES. This system is typically used to demonstrate formal methods-based approaches. Further, it has been specified and implemented in a number of formal methods. We have applied FADES to the same set of security requirements as the Z implementation of the electronic smart card in [7].

A. Security Requirements

The system consists of a number of electronic purses containing financial values, each hosted on a smart card. The purses interact with each other through a communication device to exchange money values. The system is a decentralized distributed system; each purse is supposed to ensure the security of all its transactions without the

215215215215215215215215

interference of a central controller. We have followed the n-step protocol in [7] to model a transaction for money exchange between purses. The payee requests the transfer of an amount from the payer.The payer sends the amount requested to the payee if the payer balance is greater than or equal the requested amount. Finally, the payee sends an acknowledgement of receipt to the payer.

The security properties that should be maintained by any transaction for money transfer:

• No value may be created in the system: the sum of all the purses’ balances after any transactions does not increase.

• All values are accounted for in the system: the sum of all purses’ balances and lost components after any transaction does not change.

• Authentic purses: those registered in the communication device with valid card and pin numbers for each purse.

• Sufficient funds: a transfer can occur only if there are sufficient funds in the payer purse.

• Exception logging: if a purse aborts a transfer at a point where value could be lost, the purse should log the transaction details.

B. Elaborating Security Requirements with KAOS

This subsection outlines the elaboration of security requirements for the system with KAOS. The high level goal of this system is to transfer money securely between purses.

The high level goal is refined into three subgoals that provide two alternatives to the secure exchange of money, either to successfully implement the steps of the communication protocol or to abort an unsuccessful transaction so that money is lost securely meaning that the lost money could be traced. TransferMoneySecurely is refined into the following three subgoals namely SecureTransferProtocol, TransactionAborted and MessageLogArchived. For space limitations, we will focus on the refinement of the SecureTransferProtocol goal only. The goal SecureTransferProtocol is refined into four subgoals realizing the steps of the communication protocol for money exchange. We will focus on the refinement of the ExchangeMoney goal as it is the major goal to perform transactions. The goal ExchangeMoney is refined into two subgoals. One goal TransferRequestReceived is concerned with the payer purse and the other goal TransferValueMsgReceived is concerned with the payee purse.

Figure 2 illustrates the goal graph for the ExchangeMoney goal and its subgoals.

Figure 2: ExchangeMoney Goal Refinement

There are two agents namely the communication device and the archive. The communication device is responsible for the mediating the communication between the payer and the payee purses.

Following the operation and agent capture is the identification of possible security threats through KAOS obstacle analysis. We will use the goal TransferRequestReceived defined above as an example to show how obstacle analysis is performed. The request message that holds the payment details might be maliciously intercepted or tampered with while in transit since messages are sent in plain text over an unsecure communication line. Interception does not impact the message content but it threatens the message confidentiality. Tampering with the message might lead a malicious eavesdropper to change the content of the message in order to change the payee information or the requested amount, which threatens the message integrity. Therefore, there are two obstacles generated for the TransferRequestReceived goal namely InterceptedTransferRequest and CorruptedTransferRequest.

To protect the request message confidentiality, we need to encrypt the message with a secret key using any of the standard

216216216216216216216216

encryption algorithms. Message integrity could be protected using digital signatures.

Leaf goals of the goal graph are assigned to agents to achieve them through means of operations specified during the goal operationalization stage. FADES is concerned with the KAOS operations specified for leaf goals since these are the main constructs transformed to B to build the initial B model for further refinement towards design and implementation. The goal operationalization of the electronic smart card goal graph has resulted in a number of operations, and we will take the SendMoneyValue operation as an example for the transformation to B and refinement for design.

The SendMoneyValue operation achieves the TransferRequestReceived goal and its subgoal. The output of the operation is a “Value” message sent to the communication device that forwards it in turn to the payee purse in order to add the money to its balance. The post condition of this operation indicates that the status of the payer purse changes to “ack” meaning that it waits for an acknowledgment of money reception from the payee purse.

Operation SendMoneyValue

Input Message{arg requestMsg}, Purse{arg fromPurse}

Output Message {res msg}

DomPre

DomPost deducted(fromPurse.paymentDetails.Balance) ^ ( cd:

CommunicationDevice)Sending(msg,

cd) ^ fromPurse.Status = “Ack”

ReqPreFor TransferValueMsgReceived

Sending(valueMsg, fromPurse.paymentDetails.toPurse)

C. Transforming KAOS to B

According to the transformation rules in section 3, the ElectronicPurse machine illustrated below represents the system in which each KAOS operation is represented as a B operation. KAOS operations preconditions are mapped to preconditions of their corresponding B operations. The entities PaymentDetails and Message are represented as separate machines included in the system machine.

Only the send operation is illustrated in the abstract B machine due to space limitation. The machine variables represent the state of the machine that mainly includes a set of authentic purses communicating in the system. The machine invariant outlines the types of all variables and states semantic constraints on these variables.

D. Deriving Design and Implementation

The abstract B machines obtained from the transformation are refined using the B refinement mechanism in which one or more design decisions are made in each refinement step. Proof obligations are generated and discharged at each refinement step using the B-Toolkit in order to prove correctness of development.

The first refinement step is classified as data refinement concerned with refining the representation of the machine variables that reflect the system state. We made a design decision to represent the set of electronic purses as an array of purses and the security operations are refined accordingly.

The second refinement step is concerned with refining the purse exception log and message archiving. We made a design decision about modeling the purse exception log as a partial function whose domain is the set of purses and whose range is the exception logs.

The third refinement step makes a design decision about using public key infrastructure for protecting the integrity and confidentiality of messages. The communication device receives a pair of public/private keys for each purse. These keys are used to sign/verify and encrypt/decrypt the transaction messages.

The step to follow is to construct an implementation machine before code generation. The implementation machine is a special refinement step done only once in development after all the design decisions have been made. The B code of the refinement machines and the implementation machine is not shown in the paper due to space limitations.

The final step is to generate C code from the implementation machine. The programming language choice is based on the programming languages available in the B tool being used. Almost all the commercial B tools generate code in C and a few of them generate ADA. The security properties should be maintained by the design decisions and the semantics of the B machines rather than by specific security construct in the programming language to which the implementation machine is translated.

E. Acceptance Testing

The Goal Graph Analyzer tool generates a suite of acceptance test cases derived directly from the KAOS goal graph. The money exchange test case that involves both the Send and Receive operations is given as an example.

217217217217217217217217

The money exchange test case is capable of detecting inconsistency errors in the requirements model. For example, the money exchange test case is able to detect the case of missing the check for sufficient balance before deducting the money from the payer purse. If this check is missing, the sendMoneyValue operation call will fail resulting in the failure of the whole test case.

F. FADES versus Z

This section compares FADES with Z using the electronic smart card system. We have used requirements completeness, consistency and security quality as metrics for the comparison. The security quality metric has been measured by the number of security vulnerabilities detected and resolved in the model.

Both FADES and Z were able to consider and cover all the security requirements specified for the system. However, the goal-orientation of FADES allows for focusing on each specific requirement, its refinement and its relation to other requirements. This tends to raise the probability of building a near-complete requirements model. Further, we expect that with larger and more complicated systems, Z as a formal method might not be as capable as FADES to construct a close-to-complete requirements model. We justify our expectation by the results obtained in our empirical work that compares FADES to other formal methods [8]. Our results showed that KAOS is more effective than formal methods for requirements specifications. Our justification for this result is that requirements are often vague and very hard to specify in strict format like formal methods that have well-specified structure making formal methods like Z more suitable for later development stages like design and implementation [1].

Concerning requirements consistency, both models built with FADES and Z are equally consistent. However, it is more costly in terms of time and effort to build a consistent requirements model using formal languages. Therefore, it might be cost-prohibitive, especially for large systems to employ formal methods in requirements analysis to obtain the same level of consistency as goal-oriented approaches.

As for security quality measured with the number of security vulnerabilities detected in the requirements model, FADES revealed two security breaches that threat the messages confidentiality and integrity. Stepney, on the other hand in [7], detected threats to the message confidentiality only and

introduced an encryption/decryption facility to protect the message while in transit. FADES has enforced the protection of messages integrity through the employment of digital signatures. We expect that if the case study has been larger in size and its security requirements have been more complicated, FADES would have shown more strength in detecting more security vulnerabilities than Z.

CONCLUSION

In this paper, we demonstrated how the FADES approach for goal-oriented software security engineering could be practically applied. We also showed its effectiveness using a credible case study. The electronic smart card system is a good representative of e-commerce and communication-based systems that exhibit high security demands. We have also provided a comparative study between FADES and Z when both are applied to the electronic smart card system. The results of the comparison along with the empirical evidence in [8] demonstrate the effectiveness of FADES over strict application of formal methods in producing highly secured software with favorable cost implications.

Our ongoing research work focuses on expanding the application of FADES to other non-functional aspects such as reliability and safety. We aim at establishing guidelines to the IT community for best practices for secure software engineering using FADES.

REFERENCES

[1] A. van Lamsweerde, “Elaborating Security Requirements by Construction of Intentional Anti-Models”, Proc. ICSE’04: 26th Intl. Conf. on Software Engineering, May 2004.

[2] A. van Lamsweerde and E. Letier, “Handling Obstacles in Goal-Oriented Requirements Engineering”, IEEE Transactions on Software Engineering, Special Issue on Exception Handling, Vol. 26 No. 10, Oct. 2000, 978-1005.

[3] Abrial, J.-R., The B Book: Assigning Programs to Meanings, Prentice-Hall.

[4] Van Lamsweerde, A., and Letier, E., “From Object Orientation to Goal Orientation: A Paradigm Shift for Requirements Engineering”, Proceeding of Radical Innovations of Software and Systems Engineering, LNCS, pg. 325-340, 2004.

[5] J. Mylopoulos, L. Chung, and E. Yu, “From Object-Oriented to Goal-Oriented Requirements Analysis”, Communications of the ACM, 42(1):31–37, 1999.

[6] Van Lamsweerde, A., "From System Goals to Software Architecture." in Formal Methods for Software Architectures. M. Bernardo and P. Inverardi, Springer-Verlag: 25-43, 2003.

[7] Stepney, Susan, Cooper, et. al., “An Electronic Purse Specification, Refinement, and Proof”, Programming Research Group, Oxford University Computing Labarotory, July 2000.

[8] Hassan, R., Eltoweissy, M., Bohner, S., and El-Kassas, S., “Formal Analysis and Design for Engineering Security (FADES),” under review

[9] Hassan, R., “Formal Analysis and Design for Engineering Security (FADES),” Ph.D Dissertation, Virginia Tech, 2009.

[10] J. Mylopoulos, M. Kolp, and J. Castro, “UML for agent-oriented software development: The Tropos proposal”, Proc. of the 4th Int. Conf. on the Unified Modeling Language UML’01, Oct. 2001.

218218218218218218218218