Formalization of Design Patterns for Security andDependability

Cuauhtémoc CastellanosTélécom-ParisTech

36 rue Barrault75013 Paris, France

Castella@Telecom-Paristech.fr

Thomas VergnaudTHALES Communications &

Security1 avenue Augustin Fresnel91767 Palaiseau, France

Thomas.Vergnaud@Thalesgroup.com

Etienne BordeTélécom-ParisTech

36 rue Barrault75013 Paris, France

Etienne.Borde@Telecom-Paristech.fr

Thomas DeriveTHALES Communications &

Security1 avenue Augustin Fresnel91767 Palaiseau, France

Thomas.Derive@Thalesgroup.com

Laurent PautetTélécom-ParisTech

36 rue Barrault75013 Paris, FranceLaurent.Pautet@Telecom-

Paristech.fr

ABSTRACT

In critical systems, failures or attacks based on software mis-conceptions can have catastrophic consequences. In orderto avoid those situations, such systems need security anddependability (S&D) constraints. Usually S&D design pat-terns shape S&D mechanisms. Security and dependabilityexperts identify S&D mechanisms to reach S&D objectivesand manually apply them to the system architecture. Ourcontribution consists in studying S&D design patterns ap-plication. We formalize these S&D design patterns as modeltransformations, preconditions and postconditions to auto-mate their integration. Finally, we illustrate this processwith a Software Defined Radio case study to which we applythe red/black (R/B) architecture security design pattern.

Categories and Subject Descriptors

D.2.11 [Software]: Software EngineeringSoftware Architec-ture [patterns]; C.0 [Computer Systems Organization]:GENERAL—Modeling of computer architecture, System ar-chitectures

Keywords

critical embedded systems, security, dependability, designpattern, model transformations, component based softwareengineering

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.ISARCS’13, June 17–21, 2013, Vancouver, BC, Canada.Copyright 2013 ACM 978-1-4503-2123-5/13/06 ...$15.00.

1. INTRODUCTIONNowadays, Critical Embedded Real-Time Systems (CERTS)

play a leading role in various application domains such astelecommunications, energy, aircraft and railway.By definition, the services provided by a CERTS are submit-ted to stringent temporal requirements: a service executionmust satisfy a strict deadline between the solicited momentand the moment when the result is available. In CERTS,the respect of these deadlines is as important as the qualityof the provided services.Failure or vulnerability occurrences in this kind of systemscan lead to catastrophic consequences, such as risking hu-man lives, National safety, or financial interests. In order toavoid these consequences, specifying security and depend-ability (S&D) properties to these systems is mandatory.

These properties are fulfilled by integrating dedicated mech-anisms to the system. As presented in figure 1, use of sev-eral S&D mechanisms in response to accidental or maliciousevent can lead to S&D property violations. For example,a security breach can be used to block some dependabilitymechanisms (solid arrows on figure 1). A failure may causea security breach, that enables someone to enter the system(dotted arrows on figure 1).

Figure 1: Accidental and malicious event composi-tion.

These mechanisms must be correctly integrated in the sys-tem. They can be abstracted in design patterns but are

usually integrated manually by security or dependability ex-perts.

This paper presents our approach to automatically inte-grate S&D properties in a model driven context. We proposea unified formalization of S&D design patterns and a con-figuration model for these patterns. Once a pattern is wellformalized, it can be modeled and reused in different Com-ponent Based Software Engineering (CBSE) models. Its ap-plication can be anticipated and verified in a model analysistool-chain.

The paper is organized as follows. Section 2 presents theconcepts on which our approach relies. Section 3 explainsthe problems of formalizing S&D design patterns. Section 3presents the design pattern formalization approach. Sec-tion 5 presents the technological choices. Section 6 shows asecurity pattern implementation in a Software Defined Ra-dio case study, using our approach. To conclude we brieflypresent perspectives to go further in this approach by com-posing S&D patterns in a safe and secure software model.

2. BACKGROUNDThis section presents the context of our work, and the

existing related works.

2.1 Security and dependability mechanismsSecurity and dependability are characterized by well-defined

properties [6] [9]. These properties are ensured in systems byS&D mechanisms. They have been abstracted by securityor dependability experts in design patterns. Security designpatterns have been widely described in literature, such asin [26] and [23]. Dependability design patterns also havebeen described in literature, such as in [19] and [25].

Design patterns are proven solutions to identified prob-lems in a given context [17]. They have been first use inObject-Oriented Programming languages to improve reuseand interoperability by separating the code into modules.As they were first software oriented, the traditional soft-ware design patterns impact software architecture and be-haviour [17]. Contrary to object oriented design patterns,S&D design patterns impact different aspects of the systems,like the mechanisms they abstract.They impact the software and hardware architecture. Forexample, some of them control communications by trusteddevices. Some others communicate using specific protocols,their integration impact behavioral or data aspects.A side effect of their impact is they might have hardware orsoftware required architecture or ressources specificities.

2.2 Model Driven Engineering and S&DModel driven engineering (MDE) consists in reducing sys-

tems into abstractions called models. The purpose of com-ponent based models is to separate the functional and non-functional concerns. A model is made to reach particulargoal, like verifying specific non-functional properties such asdeployment. The main idea when working with models is tosimplify the analysis by keeping only the needed aspects ofthe systems in the models.

MDE allows defining development processes that refineeach step from requirements to code. Concretely in CBSEapproach this is traduced by three differents levels of ab-straction. The first level is the declarative model, that con-tains all the functional concerns of the system. The secondlevel is the implementation model, where each declaration

are specified for particular implementation. The last level isthe instance model, which specify the number of implemen-tation type, and the bindings to the platform resources.This refinement process allows reasonning about how thesystem is built. S&D mechanisms impact the instantiationmodel that has low abstraction level as they are mainly in-tegrated manually in legacy systems today.

Different works have tried to model security and depend-ability non-functional requirements in a MDE context. Insecurity, the UMLsec [8] profile is a UML profile dedicatedto security.The authors of [21] present a modeling language for model-driven development of secure distributed systems based onUML. They specify information related to access control inthe overall design of an application.Their approach does not automate design patterns integra-tion in the system, but focuses on model based security anal-ysis.

The [7] approach adds dependability non-functional prop-erties to the UML-MARTE [3] modeling language to easeanalysis using stochastic Petri net models for performanceand dependability assessment.Their approach focuses on model based dependability anal-ysis. They do not make automatic dependability design pat-terns integration.

In their work the authors of [10] present a methodologybased on component meta-model to capture the domain con-cept and they use security patterns to integrate security so-lution. They combine a component based meta-model witha security pattern to produce a security UML profile. Theyhave automated integration of RBAC [16] security policy.They apply a security policy based on role to an embeddedsystem. This security policy fits much to information sys-tem where connections are dynamic with a large number ofusers. Their approach is based on generated UML-profileto specific domain of application. They do not automatedependability design pattern integration either.

2.3 Design patterns formalization techniquesDesign patterns are nowadays used in component based

software engineering context.Component based software engineering (CBSE) is a concep-tion technique which consist in separating the software infunctional elements. Each element is called a component.A component is defined by its provided or required services.This technique emphasizes the separation of concerns to pro-duce loosely coupled applications.

One of our objectives is to formalize both security anddependability design patterns, and integrate them automat-ically in a CERTS modeling CBSE language. There are dif-ferent ways of describing design patterns. Literature presentsthree types of pattern description. They can be describedthrough diagrams, they ease comprehension on pattern ar-chitecture. They are often represented in UML [4] diagrams,which constraint their use with UML like languages. Theycan be described by literal forms. It eases the pattern pur-pose understanding and which objectives it aims. But theydo not explain in an unambiguous maner how to implementit. They can also be described in formal descriptions. Iteases analysis, but makes their descriptions difficult to un-derstand.

The following presents formalization techniques of object

oriented design patterns. S&D design patterns scope is notlimited to software architectural or behavioral features.

2.3.1 Parametrized modeling techniques

The authors of [22] define a design patterns formalizationusing parametrized models. In their work a design patternis declared as a set of elements interacting with each oth-ers. These interactions describe the design pattern architec-ture. Behavioral aspects of each elements can be describedby UML-statecharts.

The authors have formalized architectural design patternsfrom the object oriented programming paradigm. So theyused an UML-profile to ensure compatibility. Parametrizedmodel ensures the variability of patterns but enforce the useof UML profiles. This can be used to specifies S&D infor-mation that cannot be deduced from the functional modelsuch as deployment constraints.

2.3.2 Transformation model techniques

The authors of [20] formalize design patterns through modeltransformations. In their approach they formalize structuraldesign patterns and behavioral design patterns. To imple-ment their transformations, they use the language VDM++with the object calculus as a semantic framework. VDM++is an object oriented formal method for the development ofcomputer based system. Our goal is to integrate automati-cally S&D design pattern in a model. This can be traducedby model transformations that integrate S&D design pat-tern instances : S&D mechanisms. Model transformationsadd, supress or reorganize elements in a model. It can beused to generate a new model containing instances of S&Dmechanisms.

2.3.3 Formal modeling techniques

The authors of [14] propose specification methods basedon first order logic, temporal logic, temporal logic of action,process calculus and prolog. Their conclusion is that dif-ferent formalisms are suitable to specify different aspects ofdesign patterns. Their design patterns are represented interms of object-oriented primitives in a predicate-like for-mat.

The authors of [27] have developed a language called BPSLto formally specify architectural and behavioral design pat-tern aspects. He uses first order logic as formal basis tospecify the structural aspect of design patterns and tempo-ral logic of action for behavioral ones. In its approach theauthor generates Java skeleton code from BPSL specifica-tions. Predicates can be used to specify constraints that theinput model must fulfill to integrate a S&D design pattern,and the output model must verify.

2.3.4 Conclusion on formalization techniques

All these presented approaches have defined design pat-terns formalization techniques, but they are applied on tra-ditional object oriented design patterns (such as adapter de-sign pattern). S&D design patterns impact more than soft-ware architecture. As precised before, they impact other as-pects such as hardware architecture and deployment. Theirapplications needs information that the architects must spec-ify in the model through modeling properties, such as de-ployment constraints.Such constraint has to be defined in an unambiguous maner

to allow analysis on design patterns integration and automa-tisation.

2.4 Software Defined RadioSoftware defined radio (SDR) is a radio communication

system where components that used to be implemented inhardware are instead implemented by software means. Awaveform is the functional part that receive and transmitdata of a SDR device. This makes software defined wave-forms portable to generic hardware platforms.SDR are used in multiple domains such as avionic, aerospace,military, mobile phones. They face stringent real-time con-straints, limited resources and energy consumption constraints.Depending on the domain where they are used, they canmeet security or dependability concerns, or both.

In the case of a mono-channel radio, SDR meets securityconcerns. For example, the waveform has to transmit datathrough air to other radios. These data may be confidential.Thus a radio encrypts these data to ensure confidentialityproperty.In the case of a radio with multiple waveforms, dependabil-ity concerns are added and security concerns evolve. The ra-dio waveforms have to be confidential from the public worldbut also between each others. Different waveforms sharethe same platform services and physical resources. This im-plies that platform services and physical resources are singlepoints of failure: if a fault propagates to the platform ser-vices from a waveform, all the others waveforms are down.

Our SDR case study is defined as follows. It is a radio withtwo waveforms that share a unique hardware platform. Fig-ure 2 presents the architecture of one of the two waveforms.Each waveform protocol layer is separated into four macrocomponents: appli, ipcs, rlc, mac. Management componentmgt controls the overall components and a functional secu-rity component frequence hop controls frequency hopping toavoid collision or interferences.

Figure 2: Case study waveform architecture.

3. PROBLEMOnce a CERTS system functional architecture is made,

the system must reach security and dependability objectives.In order to reach the S&D objectives experts identify solu-tions that could be integrated in the system to satisfy theseobjectives. These solutions are proven solutions to identi-fied security or dependability problems: it can be design

patterns. Experts decide how design patterns are applied tothe system and apply them manually.

Security or dependability design patterns modify the sys-tem architecture by adding, removing or reorganizing it’s el-ements. Modifying a system to apply a S&D design patterncan be really hard and according to the number of elementsimpacted can improve its complexity.

Moreover, to reach one security or dependability objectivemultiple solutions are available, but not all are applicable.Experts know why they are applicable or not. Automatingsolution integration must identify if a solution is applicableby a selection of pattern to apply.

We want to automate correct security and dependabilitysolutions integration in model driven engineering context.To automate design patterns integration, we first need tomodel S&D design patterns.

S&D design patterns reorganize, create and/or suppresselements from the input model when they are applied. Ap-plying design patterns may need additional information thatcan’t be deduced from the initial model, but have to be spec-ified by users. Reorganizing or creating/suppressing issue onhow to transform the model to apply design patterns.

Correct integration of a given solution is validated bypresence of the expected security or dependability proper-ties. But its integration has reorganized the model architec-ture and could have impacted the functional properties, andalso other non-functional properties such as performance orquality of service. Correct automatic integration of suchsolutions reduces human faults occurrences and conceptiontime.

4. APPROACHIn this section we will describe gradually the implemen-

tation of our approach. We firstly present an approachoverview. Then we detail each concept in subsections andillustrate them through a simple exemple. This example isa simple redundancy pattern. It create a new instance ofthe targeted element on a different computation node. Theexample is presented in ATL.

CBSE expresses different aspects of the system in models:software and hardware architecture and deployment. So weassume that the functionnal and hardware architectures areknown. Then, integrating a S&D design pattern consists inreorganizing target elements or sets of elements of an inputmodel to generate a new model containing instances of theS&D design patterns. Figure 3 presents this process.This process is organized in four steps. A model containingS&D pattern properties is the input of the process. The firststep is to model the design pattern properties in propertiesin the CBSE language.The second step is to validate if the design pattern is applica-ble through valdidation of preconditions P

−. S&D patternproperties are aspects of the design pattern that have tobe modeled because they cannot be deduced from the func-tional model.The next step integrates the target pattern by model trans-formations T .The final step validates the postconditions P

+. If postcon-ditions are verified the resulting model of the transformationis valid.

4.1 Design pattern properties modelingFirst, some parts of the design patterns has to be modeled

Figure 3: S&D design pattern integration process.

to define the targeted elements or configure the patterns.These are the patterns variable parts. They are informa-tion for applying correctly the pattern and that cannot bededuced from the system model. They can be referencesto a specific model element on which some elements of theapplied patterns have to be deployed on. This informationcan be modeled as properties that parametrize the modeltransformation step.

For example, in the case of the simple redundancy, oneparameter to model is the target computation node whereto deploy the new instance of the target element.

4.2 PreconditionsBefore applying a design pattern we have to check if the

pattern can be applied by verifying preconditions. Theseconditions are constraints the system must fulfill to insurethe pattern can be applied. Preconditions are these con-straints that the system must fulfilled. Preconditions tra-duce hardware or software resources needs, architectural re-quirements or they can check if the pattern properties arewell defined in the model.

Multiple constraints types can be defined, we have iden-tified four types. The first ones are resources constraints.They represent particular software or hardware resourcesneeds to apply a design pattern. The second ones are ar-chitectural constraints. They requires some specific organi-zation of software or/and hardware architecture that mustbe met to ensure a S&D property. The third ones are de-ployment constraints which specifies if components must ormust not be deployed on the same computation node. Thelast ones are constraints on S&D design pattern parameters.They verify if all the information required to apply the pat-tern has been provided.We propose to express these types of constraints in OCL[2] even they could be expressed in first order logic. OCLenables their validationby model analysis.

For example, in the case of a simple redundancy, we needat least two computation nodes. One to deploy the originaland the other for the replica. Let’s call processor the com-putation node defined in the CBSE meta-model MM by aclass ProcessorInstance. Listing 1 expresses this constraint.It gets all the objects of ProcessorInstance class and countsthem in the input model.

helper def : hasAtLeast2Processors () : Boolean =MM!ProcessorInstance.allInstanceFrom(’IN’).size() >= 2;

Listing 1: Precondition example: There must be atleast 2 processors.

4.3 Model transformationsOnce the preconditions are verified, a pattern is applied

by creating, removing or reorganizing the current modelarchitecture. This architecture knowledge is embedded inmodel transformation rules that modify the model to ap-ply a S&D design pattern. These transformation rules arepattern matching rules: they match a set of elements withsome constraints and they produce a corresponding set ofelements.

In the example of the simple replication the transforma-tion rule is the following in listing 2. The keyword frommeans the matched elements in the input model. Here, thematched element is the ComponentInstance class elementwhich specifies replication.The keyword to refers to the elements that are generated inthe output model if the rule is matched. This part creates asecond identical component instance as the one in the frompart.The first copy c1 has the same characteristics as c. Com-ponent c2 is deployed on another processor. This secondprocessor is specified by a pattern parameter embedded inthe model for the transformation rules. They are used hereto correctly apply a pattern. For simplification reasons, con-nections between component instance are not presented inthis example.

rule simple replication {fromc : MM!ComponentInstance(c.isSimpleReplication() and thisModule.

hasAtLeast2Processor())

to

c1 : MM!ComponentInstance(ownedComponent <− c.ownedComponent,targetProcessor <− c.targetProcessor),

c2 : MM!ComponentInstance(ownedComponent <− c.ownedComponent,targetProcessor <− c.simpleReplicationProperty.

secondProcessor)

}

Listing 2: Transformation rule example: duplicationof one component.

4.4 PostconditionsPostconditions are constraints that validate correct design

patterns instantiation. Correct integration of a design pat-tern results in different aspects. First, the expected securityor dependability properties must be present in the system.Secondly, the system must keep its functional abilities. Fi-nally, other non-functional properties (such as performanceor quality of service) have to be maintained in acceptableconditions.In this paper we focus only on the verification of security anddependability properties. Verifying the functionnal proper-ties and other non functionnal properties is out of scope ofthis work.

Verifying Design patterns correct integration imply ver-ifying all the aspects they impact. Verifying deployment,software or hardware architecture constraints can be doneby respecting first order logic constraints on the model.

S&D properties must be persistent through out the con-ception process, so postconditions must be verifiable at anytime of the system conception. For traceability motivation,information specifying which pattern has been applied, andwhich element it has been created has to be maintained.

Postconditions are expressed through ATL queries. In thepresented example, one of the postconditions is that repli-cas are not deployed on the same node. Listing 3 presentsan example of query traducing the later postcondition. Thequery starts by getting the element where the simple dupli-cation has been applied. After it gets the replica throughthe original element. Finally, it compares the two deploy-ment nodes. If they are on the same node the query returnfalse.

query differentDeployment =let c1 : MM!ComponentInstance =MM!ComponentInstance.allInstances().

duplicationHasBeenAppliedOn() in

let c2 : MM!ComponentInstance = c1.replica inc1.targetProcessor <> c2.targetProcessor;

Listing 3: Query example: replica must not bedeployed on the same node.

5. TECHNOLOGICAL CHOICESThis section presents the technological choices we have

made to implements this approach.

5.1 Component based modeling languageTo model our case study and design patterns parameter we

use AADL modeling language. AADL [5] stands for ”Archi-tecture Analysis & Design Language”. AADL is an architec-ture modeling language that enables to define software andhardware components. These components are aggregatedfollowing specific rules. It is also possible to annotate com-ponents to describe their characteristics.AADL is strongly typed and has three abstraction levels ofcomponents. First level is the component types level. It rep-resents the functional aspects. The second one is the compo-nent implementation level. It is a refinement of componenttypes to a dedicated aggregation of components and plate-form. These two levels form the AADL declarative model.The last level is the component instances level. At this levelall communications, deployment bindings and componentsassembly are explicit. This level can be generated from thedeclarative model.

5.2 Model transformation languageMultiple model transformation languages exists with dif-

ferent transformation logics [13].We have explored the use of the QVT-o: the operational partof the OMG standard QVT [1]. QVT-o has an imperativeexecution logic, so each match operation and appropriaterule are explicit. We need a language that can match easilysets of model elements, and our choice is ATL.

5.3 Applying S&D design patterns with RAM-SES framework

RAMSES [12] stands for Refinement of AADL Models forSynthesis of Embedded Systems. It is a model transforma-

tion and code generation tool. It interfaces with OSATE2 1

and use its instantiation functionalities. RAMSES has theability from an instantiated model to generate the declara-tive model. The declarative model generated is semanticallythe same as the instanciated model. We use this functional-ity to integrate S&D design patterns to AADL models.

Figure 4 presents the process used to apply a design pat-tern to an AADL model. First OSATE parses, validatesand instantiates the declarative model. The instantiationstep resolves all connections and match them into end toend connections. All the binding to hardware componentare resolved too. Connections and bindings resolution easesthe design pattern application by making links between ele-ments explicit.Once the instantiation models is generated we apply thedesign pattern to it by doing an uninstantiation transfor-mation. Uninstantiation transformation consists in gettingback the declarative model from the instanciation model.But just doing the uninstantiation transformation we getsemantically the same declarative model as in input. In-stead of that, we use ATL superimposition [12] mechanismto replace ATL transformation rule we need to apply thespecified pattern. When several transformation modules aresuperimpose on top of eachother. it results in a transforma-tion module that contains the union of all transformationrules and all helpers. Where it is possible for a transforma-tion module to override rules and helpers from the transfor-mation modules underneath.

Figure 4: S&D design pattern integration process inRAMSES.

6. APPLICATIONThis section presents an implementation of our approach

in a SDR case study. We apply to this case study a R/Barchitecture security patterns. First we present the SDRarchitecture and the security property we want to apply toit. Then we explain the R/B design pattern and its for-malization. Finally we apply it to the SDR and explain theresulting model.

1OSATE2 is a tool platform for AADL. It enables AADLmodels instantiation, editing and validating.

6.1 Software defined radio case studyOur case study is a multi-channel SDR. We want to sat-

isfy waveform confidentiality to hide over the air transmitteddata.Software defined radio has a security design pattern to en-sure such confidentiality property: it is the R/B architecturepattern.

Confidentiality have the following definition in [11]: “letI some information and X a set of unauthorized entities toaccess to I. Confidentiality of X to I is respected if no one ofX can access to I”. The information that we have to protectare those received from and transmitted by the waveform.

In CERTS, communication channels are defined staticallyto ensure determinism. In a CBSE context, communica-tion channels are defined by provided and required services.We assume that components have no interaction with othercomponents except with the specified ones. This means, iftwo components are not connected they cannot exchangeinformation.

Listing 4 presents one of the two waveforms. Its architec-ture has been modeled in AADL [5].The components that compose the waveform are modeledas processes in the subcomponent section (lines 14-19). Theconnection part contains all the connections between theprocesses it self, and the system which has communicationports. Properties part contains the properties that annotatethe components. In this case it contains the properties toapply the R/B pattern describe in section 6.2.Through these properties (from line 39 to 49), we specifythat we want to separate the sec, mac and rlc processes ona public side, and the other on the secret side. The bypassproperties (line 49) specifies connections that has to pass tothe encryption module without encryption.

system waveformfeaturesrx in : in event data port;tx out : out event data port;

5 mgt out : out event data port;flows

reception flow : flow sink rx in;transmission flow : flow source tx out;mgt phy : flow source mgt out;

10 end waveform;

system implementation waveform.waveform1subcomponents

appli : process processes::appli process.waveform1;15 ipcs : process processes::ipcs process.waveform1;

rlc : process processes::rlc process.waveform1;mac : process processes::mac process.waveform1;sec : process processes::sec process.waveform1;mgt : process processes::mgt process.waveform1;

20 connectionsrx1 : port rx in −> mac.rx in;rx2 : port mac.rx out −> rlc.rx in;rx3 : port rlc.rx out −> ipcs.rx in;rx4 : port ipcs.rx out −> appli.rx in;

25 tx1 : port appli.tx out −> ipcs.tx in;tx2 : port ipcs.tx out −> rlc.tx in;tx3 : port rlc.tx out −> mac.tx in;tx4 : port mac.tx out −> tx out;

30 mgt1 : port mgt.appli out −> appli.mgt in;mgt2 : port mgt.ipcs out −> ipcs.mgt in;mgt3 : port mgt.rlc out −> rlc.mgt in;mgt4 : port mgt.mac out −> mac.mgt in;mgt5 : port mgt.sec out −> sec.mgt in;

35 mgt6 : port mgt.phy out −> mgt out;

sec cnx : port sec.sec out −> mac.sec in;propertiesRBArch::SecurityLevel => ‘‘public’’ applies to sec;

40 RBArch::SecurityLevel => ‘‘public’’ applies to mac;RBArch::SecurityLevel => ‘‘public’’ applies to rlc;RBArch::SecurityLevel => ‘‘secret’’ applies to appli;RBArch::SecurityLevel => ‘‘secret’’ applies to ipcs;RBArch::SecurityLevel => ‘‘secret’’ applies to mgt;

45

RBArch::RB Arch => ‘‘RB1’’;RBArch::redSide => ‘‘secret’’;RBArch::blackSide => ‘‘public’’;RBArch::bypass => (reference(mgt3, mgt4, mgt5, mgt6));

50 end waveform.waveform1;

Listing 4: Software defined radio waveform inAADL.

6.2 R/B architectureThe R/B architecture ensures the confidentiality property

of data flow between two sets of components. R/B’s mainobjective is to avoid hidden channel that access the confi-dential unencrypted data. To do so the actors manipulatingthese data are separated into two sets, the ones who canaccess it, the ones who cannot.

Figure 5 presents its architecture, with physical isolationbetween red and black sets. The red part is the secure part,where confidential data are not encrypted. The black partisthe unsecured part, data must be encrypted. The data flowcan be bi-directional. Between this two sets, an encryp-tion component controls the data flow. In SDR to ensurea maximum confidentiality, the three part are deployed onseparated nodes. For functional needs some data have to betransferred from one side to another. These data can onlyflow in one direction to avoid hidden channel, they are calledbypasses [24].

Figure 5: R/B traditional architecture.

Because of lesser security level, one may wants to deploythe red and black sets on the same nodes, and maintain theisolation for the encryption module. The red and black setsof components are isolated in different partitions.In another case of lesser security level, one may want thatthe control of the flow is ensured only by a logical compo-nent. So all components are deployed on the same node, butare isolated in different partitions.

6.3 Pattern targets and parametersThe R/B pattern target two differents security levels. One

has high confidentiality needs, the other has not. Applyingthis patterns between AADL process components is the onlyway to use it. So this pattern has to be applied on AADLsystem.

To apply R/B design pattern, additional information hasto be given. The red and black side security level must bespecified. The security level properties have to be specifiedin the model too and the channels that can be bypassed haveto be referenced.

Listing 5 presents the AADL property set that defines theR/B design pattern properties.

property set RBArch isSecurityLevelType : type aadlstring;SecurityLevel : RBArch::SecurityLevelType

4 applies to (system, processor, process, thread, memory, flow);

RB arch applied : aadlstring applies to (system);RB arch : aadlstring applies to (system);blackSide : RBArch::SecurityLevelTypeapplies to (system);

9 redSide : RBArch::SecurityLevelTypeapplies to (system);

bypass : list of Reference (connection)applies to (system);

end RBArch;

Listing 5: AADL Property set to apply R/B designpattern.

6.4 PreconditionsPreconditions are OCL helper for maintainability and read-

ability. A helper can be seen as a method. It has a contextwhich defined the kind of element the helper is applied to.It has a name, input parameters and an output parameterwhich is a boolean. The helper returns true if its precondi-tions is valid.

All the preconditions are called from one helper that ver-ifies all conditions with a logical operator.

6.4.1 Specification of security level

Preconditions presented in listing 6, verify that the twosecurity level are applied to component instances. It is aproperty verification.

helper context AADLI!SystemInstance2 def : hasDefinedSides() : Boolean =

self.getBlackPropertyAssociation().oclIsUndefined()=falseandself.getRedPropertyAssociation().oclIsUndefined()=false ;

Listing 6: Precondition: do parameters are defined?

6.4.2 Verification of the specification of bypasses

Listing 7 shows the verification of the specification of by-passes from the red component set to the black one or theopposite. Bypasses are not encrypted channels, so they haveto be unidirectional and all in the same direction: from redto black or black to red.

To verify it, we identify all the connections from one direc-tion to another and the opposite way in two different sets ofconnections. If the bypasses are well specified then at leastone set has to be empty to ensure one-way communications.

helper context AADLI!SystemInstancedef : bypassAreValid() : Boolean =let bypasses : Sequence(AADLI!ConnectionReference) =self.getBypassConnections()

5 −> collect(e|e.getAssociatedConnectionReference()) in

let red : AADLI!PropertyAssociation =self.getRedPropertyAssociation() in

let black : AADLI!PropertyAssociation =self.getBlackPropertyAssociation() in

10 let red2BlackBypasses : Sequence(AADLI!Connection) =bypasses −> select ( e | e.connectionSrcInSecurityLevel(

red) ande.connectionEndInSecurityLevel(black)) in

let black2RedkBypasses : Sequence(AADLI!Connection)=

bypasses −> select ( e | e.connectionSrcInSecurityLevel(black) and

15 e.connectionEndInSecurityLevel(red)) in

black2RedkBypasses.isEmpty() xor red2BlackBypasses.isEmpty();

Listing 7: Precondition: Do all bypasses have thesame direction flow ?

6.4.3 Verification of computation resources

Listing 8 presents a resource precondition. This one veri-fies that at least two processors instances are defined in thesystem. If not, then the R/B design pattern is not applica-ble, because the red and black sides have to be physicallyisolated.

helper context AADLI!SystemInstancedef : hasSufficientProcessor () : Boolean =self.systemImplementation.ownedProcessorSubcomponent.size

() >= 2;

Listing 8: Precondition: Is there sufficientcomputation resources ?

6.4.4 Verification of possible deployment

Listing 9 presents a precondition that verifies if at leasttwo sets of processor instances exist, and each set has adifferent security level. If two sets of processor instancesexist then a deployment configuration may exist, becauseThe red part and the black part have to be deployed ondifferent processor instance.

helper context AADLI!SystemInstance2 def : hardwareAreTagged (): Boolean =

let cpu : Sequence(AADLI!ComponentInstance) =AADLI!ComponentInstance.allInstancesFrom(’IN’)−>select( e | e.category=#processor) in

let red : AADLI!PropertyAssociation =7 self.getRedPropertyAssociation() in

let black : AADLI!PropertyAssociation =self.getBlackPropertyAssociation() in

let redCpu :Sequence(AADLI!ComponentInstance) =cpu −> select( e | e.hasSecurityLevel(red)) in

12 let blackCpu :Sequence(AADLI!ComponentInstance) =

cpu −> select( e | e.hasSecurityLevel(black)) in

not redCpu.isEmpty() and not blackCpu.isEmpty();

Listing 9: Precondition: does a deploymentconfiguration exists ?

6.5 Transformation rulesThe main transformation rule is partially decribe in the

listing 10. We only show the most relevant part of the rulefor simplicity. At line 3 preconditions are evaluated in thehelper isApplicableRB(). At line 6, 7 and 8 all the connec-tions that make a security level change are collected accord-ing to their direction. The encryption module is added tothe system at line 17 by an explicit call to the createInfos-ecModule rule. And finally the RB Arch property is changeto RB Arch applied at line 20 to specify that the transfor-mation has been applied. At this step no validation has yetbeen done.

rule System Instance withRB{from

s : AADLI!SystemInstance (s.category = #system and s.isApplicableRB())

using5 {

bypassConnections : Sequence (AADLI!Connection) = s.getBypassConnections();

red2BlackConnections : Sequence(AADLI!Connection) = s.getInterSecurityLevelConnections(s.getRedPropertyAssociation(), s.getBlackPropertyAssociation()) −> collect(e|e.connection).excluding(bypassConnections);

black2redConnections : Sequence(AADLI!Connection)= s.getInterSecurityLevelConnections(s.getBlackPropertyAssociation(), s.getRedPropertyAssociation()) −> collect(e|e.connection).excluding(bypassConnections);

}10 to

type : AADLBA!SystemType (name <− s.systemImplementation.type.name),

impl : AADLBA!SystemImplementation (15 name <− s.systemImplementation.name,

ownedProcessorSubcomponent <− impl.getSubcomponentsInstances(’processor’),

ownedDeviceSubcomponent <− impl.getSubcomponentsInstances(’device’).append(thisModule.createInfosecModule(impl,red2BlackConnections, black2redConnections,bypassConnections)),

ownedVirtualProcessorSubcomponent <− impl.getSubcomponentsInstances(’virtual processor’),

ownedProcessSubcomponent <− impl.getSubcomponentsInstances(’process’),

20 ownedPropertyAssociation <− s.mapOwnedPropertyAssociationList()−>union(s.mapSubcomponentsReferenceList()).excluding(s.getRBproperty()).append(thisModule.addAppliedRBProperty(s.getRBproperty().name))

)}

Listing 10: R/B architecture transformation rule.

6.6 PostconditionsPostconditions verify presence of S&D properties expected

by design pattern instantiation. But design pattern instan-tiation impacts other non-functional properties such as per-formance and quality of services. Verifying a correct integra-tion should verify these properties to. For example, verifyschedulability or memory consumption. But this is out ofscope of this work.

6.6.1 Verify that black and red side have no directconnection

Listing 11 presents a postcondition that ensure there isno direct connection from the red side to the black side. Todo so the postcondition verifies all the connections from oneside to another by iterating on whole system connectionsand verifying they have their source in on level and theirdestination to the other. If the sets of connections are empty,then there is no direct connections from black side to red sideand red to black side.

helper context AADLI!SystemInstance def :verifyAllCommunicationChannels () : Boolean =

let red : AADLI!PropertyAssociation = self.getRedPropertyAssociation() in

3 let black : AADLI!PropertyAssociation = self.getBlackPropertyAssociation() in

let red2BlackConnections : Sequence(AADLI!Connection)= self.getInterSecurityLevelConnections(red, black)−>

collect(e|e.connection) inlet black2redConnections : Sequence(AADLI!Connection)

= self.getInterSecurityLevelConnections(black, red)−>

collect(e|e.connection) inred2BlackConnections−>isEmpty() and

black2redConnections−>isEmpty();

Listing 11: Postcondition: verify that no directconnection exists between red and black sides.

6.7 Result after transformationListing 12 shows the result of R/B transformation. A de-

vice component type called infosecRB1 has been added (line9), it is the encryption module. The rx2 tx3 have been sepa-rated in two connections that pass in the encryption module(lines 12, 13, 18 and 19). The bypass connections mgt3,mgt4, mgt5, mgt6 have also been separated into two con-nections that pass through the infosec device (lines 24-31).The RBArch::RB Arch => “RB1”; property has changed toan RBArch::RB Arch applied => “RB1”; one (line 42). Itmeans that the R/B design pattern has been applied. Theother properties have been kept to allow postconditions re-play if necessary.

system implementation waveform.waveform1subcomponents

3 appli : process processes::appli process.waveform1;ipcs : process processes::ipcs process.waveform1;rlc : process processes::rlc process.waveform1;mac : process processes::mac process.waveform1;sec : process processes::sec process.waveform1;

8 mgt : process processes::mgt process.waveform1;infosecRB1 : device infosec.impl;

connections

rx1 : port rx in −> mac.rx in;rx2 : port mac.rx out −> infosecRB1.rx2 in;

13 rx2−infosecRB1 : port infosecRB1.rx2 out−> rlc.rx in;rx3 : port rlc.rx out −> ipcs.rx in;rx4 : port ipcs.rx out −> appli.rx in;tx1 : port appli.tx out −> ipcs.tx in;tx2 : port ipcs.tx out −> rlc.tx in;

18 tx3 : port rlc.tx out −> infosecRB1.tx3 in;tx3−infosecRB1 : port infosecRB1.tx3 out −> mac.tx in;tx4 : port mac.tx out −> tx out;

mgt1 : port mgt.appli out −> appli.mgt in;23 mgt2 : port mgt.ipcs out −> ipcs.mgt in;

mgt3 : port mgt.rlc out −> infosecRB1.bypass mgt3 inmgt3−infosecRB1 : port infosecRB1.bypass mgt3 out −>

rlc.mgt in;mgt4 : port mgt.mac out −> infosecRB1.bypass mgt4 in;mgt4−infosecRB1 : port infosecRB1.bypass mgt4 out −>

mac.mgt in;28 mgt5 : port mgt.sec out −> infosecRB1.bypass mgt5 in;

mgt5−infosecRB1 : port infosecRB1.bypass mgt5 out −>

sec.mgt in;mgt6 : port mgt.phy out −>infosecRB1.bypass mgt6 in;mgt6−infosecRB1 : port infosecRB1.bypass mgt6 out −>

mgt out;

33 sec cnx : port sec.sec out −> mac.sec in;properties

RBArch::SecurityLevel => ‘‘public’’ applies to sec;RBArch::SecurityLevel => ‘‘public’’ applies to mac;RBArch::SecurityLevel => ‘‘public’’ applies to rlc;

38 RBArch::SecurityLevel => ‘‘secret’’ applies to appli;RBArch::SecurityLevel => ‘‘secret’’ applies to ipcs;RBArch::SecurityLevel => ‘‘secret’’ applies to mgt;

RBArch::RB Arch applied => ‘‘RB1’’;43 RBArch::redSide => ‘‘secret’’;

RBArch::blackSide => ‘‘public’’;RBArch::bypass => (reference(mgt3, mgt4, mgt5, mgt6));

end waveform.waveform1;

Listing 12: Software defined radio waveform inAADL.

7. CONCLUSION AND FUTURE WORKSTo integrate automaticaly S&D patterns, we have defined

a S&D design pattern formalization. First design patternproperties has to be modeled to configure model transfor-mation. Then preconditions must be validated on the inputmodel to verify if the model transformation is applicable.If preconditions are valid, the model is transformed in anew one containing instances of S&D design pattern : S&Dmechanisms.Once the model is transformed, postconditions verify if theS&D mechanisms integration is valid.

We could use UML-MARTE [3] to model the system andthe design pattern properties. But, like UML, its seman-tic is more loosely typed than AADL. In model transfor-mations, matching elements on strongly typed language iseasier. UML-MARTE does not define a modeling process,while AADL through its strongly typed semantic imposesone. Using AADL forces the use of a conception processwhich can be used in UML-MARTE, but not the contrary.

In order to validate our approach, we have applied an ar-chitectural pattern that creates and reorganizes the systemarchitecture: the R/B architecture pattern.Some patterns have behavioral constraints or add specificbehaviours to system elements. These patterns requires tobe able to verify behavioral constraints and to express be-

haviour in the modeling language. AADL has a behavioralannex that allow defining modes and behaviour on compo-nents. But we have started by the architectural patterns.We plan to applied behavioral patterns soonly.

Postconditions validate patterns integration. But as S&Ddesign patterns impact the whole system, they may im-pact other non-functional properties as quality of service,resource consumption, or properties not scope by the pat-tern such as schedulability. For now we do not verify theseothers non-functional properties to focus on the S&D pat-tern properties.

Other S&D design pattern are behavioral, such as the isa live [25] pattern or have both architectural and behavioralaspect as the watch dog pattern [15].Integration validation of these kind of patterns needs behav-ioral analysis which can only be done by specific techniques.We plan to formalize behavioral patterns to study how theycan be integrated automatically.

The R/B architecture design pattern has been appliedlonely. To validate the approach to dependable patterns, wehave applied with success the triple modular redundancy [18](TMR) design pattern through this technique.In order to generalize the approach, we will formalize otherS&D design patterns. Another next objective is to studysecurity and dependability design pattern composition toautomate multiple S&D design patterns integration.

8. REFERENCES[1] Meta object facility (mof) 2.0

query/view/transformation specification.

[2] Object constraint language (ocl).

[3] Uml-marte.

[4] Unified modeling language - infrastructure.

[5] Aadl standard, 2011.

[6] A. Avizienis, J.-C. Laprie, B. Randell, andC. Landwehr. Basic concepts and taxonomy ofdependable and secure computing. Dependable andSecure Computing, IEEE Transactions on, 1:11,october 2004.

[7] S. Bernardi, J. Merseguer, and D. Petriu. Adependability profile within MARTE. Journal ofSoftware and Systems Modeling, 10(3):313,336, 2011.

[8] B. Best, J. Jurjens, and B. Nuseibeh. Model-basedsecurity engineering of distributed informationsystems using umlsec. In ICSE, pages 581–590, 2007.

[9] M. Bishop. What is computer security? SecurityPrivacy, IEEE, 1(1):67 – 69, jan.-feb. 2003.

[10] R. Bouaziz, B. Hamid, and N. Desnos. Towards abetter integration of patterns in securecomponent-based systems design. In B. Murgante,O. Gervasi, A. Iglesias, D. Taniar, and B. Apduhan,editors, Computational Science and Its Applications -ICCSA 2011, volume 6786 of Lecture Notes inComputer Science, pages 607–621. Springer BerlinHeidelberg, 2011.

[11] J. Briffaut. Formalisation et garantie de proprietes desecurite systeme : application a la detectiond’intrusions. PhD thesis, Orlean’s University, 2007.

[12] F. Cadoret, E. Borde, S. Gardoll, and L. Pautet.Design patterns for rule-based refinement of safetycritical embedded systems models. In ICECCS, pages67–76, 2012.

[13] K. Czarnecki and S. Helsen. Classification of modeltransformation approaches. In Proceedings of the 2ndOOPSLA Workshop on Generative Techniques in theContext of the Model Driven Architecture, 2003.

[14] J. Dong, P. Alencar, and D. Cowan. Design PatternsFormalization Techniques, chapter 5, FormalSpecification and Verification of Design Patterns,page 94. IGI-Publishing, 2007.

[15] B. P. Douglass. Real-Time Design Patterns: RobustScalable Architecture for Real-Time Systems.Addison-Wesley Longman Publishing Co., Inc.,Boston, MA, USA, 2002.

[16] D. F. Ferraiolo and D. R. Kuhn. Role-based accesscontrols. CoRR, abs/0903.2171, 2009.

[17] E. e. a. Gamma. Design Patterns - Elements ofReusable Object-Oriented Software. Addison-Wesley,1994.

[18] H. Gawand, R. Mundada, and P. Swaminathan.Design patterns to implement safety and faulttolerance. International Journal of ComputerApplications, 18(2):6–13, March 2011.

[19] R. S. Hanmer. Patterns for Fault Tolerant Software.John Wiley & Sons, December 14, 2007.

[20] K. Lano. Design Patterns Formalization Techniques,chapter 8, Formalising Design Patterns as ModelTransformation, page 94. IGI-Publishing, 2007.

[21] T. Lodderstedt, D. A. Basin, and J. Doser. Secureuml:A uml-based modeling language for model-drivensecurity. In UML, pages 426–441, 2002.

[22] D. Maplesden, J. Hosking, and J. Grundy. DesignPatterns Formalization Techniques, chapter 2, Avisual Langauge for Design Pattern ModelingInstantiation, page 20. IGI-Publishing, 2007.

[23] K. M. Nobukazu YOSHIOKA, Hironori WASHIZAKI.A survey on security patterns. Progress inInformatics, 5:35–47, 2008.

[24] J. Rushby. Separation and integration in mils (themils constitution). Technical report, Computer ScienceLaboratory SRI International, February 2008.

[25] T. Saridakis. A system of patternsfor fault tolerance.2002.

[26] M. Schumacher, E. B. Fernandez, D. Hybertson,F. Buschmann, and P. Sommerlad. Security Patterns -Integrating Security and Systems Engineering. JohnWiley & Sons Inc., New York, USA, 2006.

[27] T. Taibi. Design Patterns Formalization Techniques,chapter 1, An Integrated Approach to Design PatternsFormalization, page 94. IGI-Publishing, 2007.