Loukmen Regainia
email: ⇤loukmen.regainia@udamail.fr

Sébastien Salva
email: sebastien.salva@udamail.fr

Cédric Bouhours
email: ‡cedric.bouhours@udamail.fr

A classification methodology for security patterns to help fix software weaknesses

Keywords: software weakness, Security patterns, Security principles, Classification

Security patterns are generic solutions that can be applied since early stages of software life to overcome recurrent security weaknesses. Their generic nature and growing number make their choice difficult, even for experts in system design. To help them on the pattern choice, this paper proposes a semiautomatic methodology of classification and the classification itself, which exposes relationships among software weaknesses, security principles and security patterns. It expresses which patterns remove a given weakness with respect to the security principles that have to be addressed to fix the weakness. The methodology is based on seven steps, which anatomize patterns and weaknesses into set of more precise sub-properties that are associated through a hierarchical organization of security principles. These steps provide the detailed justifications of the resulting classification and allow its upgrade. Without loss of generality, this classification has been established for Web applications and covers 185 software weaknesses, 26 security patterns and 66 security principles.

I. INTRODUCTION

Most of the security experts/practitioners admitted that applying the Maginot line syndrome in the software development life cycle (i.e. adding a line of defenses after the development stage) is a bad strategy. Instead, security has to be thoroughly considered throughout the software life cycle. Security at the design stage can be performed by means of security patterns, which are specific patterns helping in designing secure applications. These patterns represent general and reusable solutions to recurring security problems [START_REF] Yoder | Architectural patterns for enabling application security[END_REF]. Since 1997, the number of security patterns is continuously growing and around 170 security patterns are available at the moment [START_REF]Security patterns repository[END_REF]. As patterns are often presented with an abstract point of view, they may be differently interpreted according to a given context. As a consequence, the choice of the good security pattern against a security problem is sensitive and somehow perilous [START_REF] Yskout | Does organizing security patterns focus architectural choices?[END_REF], [START_REF] Alvi | A Natural Classification Scheme for Software Security Patterns[END_REF]. As designers cannot be experts in any field, they clearly lack of guidance during the design phase.

Hence, with the stated goal to guide designers towards good practices, some papers [START_REF] Alvi | A Comparative Study of Software Security Pattern Classifications[END_REF] proposed to classify patterns into categories related to security concepts also known as principles, e.g., Authorization, Fault tolerance or Access control. Despite the benefits brought by these studies, this kind of classification remains insufficient because security principles are mostly abstract and lead to imprecise categories from which designers still have to take a decision on the Research supported by the industrial chair on Digital Confidence (http://confiance-numerique.clermont-universite.fr/index-en.html) patterns to implement. This is why other works proposed to classify security patterns according to vulnerabilities [START_REF] Anand | Vulnerability-Based Security Pattern Categorization in Search of Missing Patterns[END_REF], [START_REF] Alvi | A Natural Classification Scheme for Software Security Patterns[END_REF]. For a given security pattern, these classifications provide the vulnerabilities that are mitigated with the application of this pattern. But, they do not precise if several patterns are required. Furthermore, these classifications are established by directly comparing the textual descriptions of patterns with those of the vulnerabilities. As these descriptions are generic and have different levels of abstractions, the categorization of a pattern with a vulnerability can be done only when there is an evident link between both. Many patterns may be lost in the process.

From these observations, we propose another kind of classification of security patterns. But, first and foremost, we propose a methodology of classification, i.e. a list of successive steps, which lead to the classification itself. The primary contributions of this paper can be summarized by the following points:

• we present a classification, which establishes relationships among security weaknesses, security principles and security patterns, expressing which patterns remove a given weakness with respect to the principles that have to be addressed to fix the weakness. We focus on weaknesses provided by the Common Weakness Enumeration (CWE) database because a weakness is an error or a root cause that may lead to a vulnerability in a specific technology, version or language. A weakness represents a known error that a designer wish to avoid; • our classification reveals the combinations of patterns that should be chosen to remove a given weakness. In addition, our classification also gives the relations among these patterns. Indeed, studies about the inter-pattern relations have been proposed in [START_REF] Yskout | A system of security patterns[END_REF], [START_REF] Fernandez | Classifying security patterns[END_REF]. We leverage these results and include them in the classification. For instance, these inter-pattern relations offer the advantage to make apparent the conflicting or alternative patterns; • we propose a methodology, built on seven steps, which anatomizes patterns and weaknesses into sets of more precise sub-properties that are connected by means of a hierarchical organization of security principles. Actually, these steps provide the detailed justifications of the resulting classification. Since patterns and weaknesses are still presented with texts, some of these steps are manually done. But, other steps, in particular the construction of the final classification, are automatically performed. As a consequence, this methodology can be followed again to classify new security patterns or weaknesses, without the need to re-investigate all the patterns and weaknesses considered in the classification. Without loss of generality, we have limited our classification to the field of Web applications since only for this kind of application, we picked out 185 software weaknesses and 26 security patterns. For the classification, we also organized 66 security principles. In addition, for some weaknesses, we portrayed the classification with Security Activity Graphs (SAG) [START_REF] Ardi | Towards a structured unified process for software security[END_REF] organizing the principles and patterns related to a weakness in a tree form. This classification is stored in a database available in [START_REF]Security pattern classification[END_REF].

The paper is organized as follows: Section II starts by presenting some security pattern classifications and introduce our motivations. In the next section, we recall some security concepts used throughout the paper. We get to the heart of the matter, i.e. the presentation of our classification methodology in Section IV. We give a short presentation of the classification in Section V. We traditionally conclude the paper and outline some perspectives in Section VI.

II. RELATED WORK

The growing number of security patterns available in the literature makes the choice of the most appropriate ones, for overcoming a security problem, very difficult. In order to ease this task, many taxonomies and classifications were proposed in the literature. Alvi et al. outlined 24 of these classifications and established a comparative study to point out their positive and negative aspects [START_REF] Alvi | A Comparative Study of Software Security Pattern Classifications[END_REF]. They chose 29 classification attributes (purpose, abstraction levels, life-cycle, etc.) and compared the classifications against a set of desirable quality criteria (navigability, completeness, usefulness, etc.). They observed that several classifications were built in reference to a unique classification attribute, which appears to be insufficient. They indeed concluded that the use of multiple attributes enables the pattern selection in a faster and more accurate manner.

In order to highlight the key challenges in pattern classification, Bunke et al. presented a systematic literature review of the papers dealing with security patterns between 1997 and 2012. In addition, they listed a set of classification criteria and established a comparison between design patterns and security pattern classifications [START_REF] Bunke | Organizing security patterns related to security and pattern recognition requirements[END_REF]. They finally proposed a classification based upon the application domains of patterns (software, network, user, etc.).

The classifications proposed in [START_REF] Anand | Vulnerability-Based Security Pattern Categorization in Search of Missing Patterns[END_REF], [START_REF] Alvi | A Natural Classification Scheme for Software Security Patterns[END_REF] give another point of view by helping designers in the choice of patterns to fix software vulnerabilities and weaknesses. This choice of categorization seems quite interesting and meaningful since security vulnerabilities are often known by designers and are the natural causes of attacks on software systems. Alvi et al. proposed a vulnerability based scheme putting together security patterns and weaknesses documented in the CWE database [START_REF] Alvi | A Natural Classification Scheme for Software Security Patterns[END_REF]. They considered that the CWE weaknesses are appropriate to document flaws added through the design phase and they manually linked security patterns to CWE weaknesses from their textual descriptions. Anand et al. proposed another security pattern catalog composed of 12 families of vulnerabilities and identified some missing security patterns [START_REF] Anand | Vulnerability-Based Security Pattern Categorization in Search of Missing Patterns[END_REF]. They focused on vulnerabilities because they considered that the CWE database is bigger than the scope of their work. They grouped software vulnerabilities into families and manually collected relationships between families and security patterns from the pattern textual descriptions and their vulnerability family definitions. We observed that these two classifications lack of navigability among patterns though, which is an important property defined as the ability to guide the choice of designers among related patterns [START_REF] Alvi | A Comparative Study of Software Security Pattern Classifications[END_REF]. More precisely, we noticed that some patterns for the same vulnerability family are compatible together (for example, Audit interceptor and Secure logger for log vulnerabilities [START_REF] Yskout | A system of security patterns[END_REF]) and that others are conflicting in the sense that implementing conflicting patterns leads to inconsistencies in an application. As a consequence, a designer may be confused about the use of patterns.

As in [START_REF] Alvi | A Natural Classification Scheme for Software Security Patterns[END_REF], we propose a pattern classification expressing which patterns can be used to remove a weakness of the CWE database. But similarities end here. Indeed, our classification aims at proposing a more precise and accurate mapping between patterns and weaknesses. It is more accurate in the sense that we translate the meaning of the patterns and weaknesses into smaller properties, i.e. strong points and mitigations respectively. We establish relations among these properties with respect to security principles, which show the meaning of these relations. The principles are organized into a tree structure, which enables the generation of interdependences among the security patterns that overcome the same weakness. In addition, the classification is completed with the relationships among pattern themselves, expressing for example the conflicts or the dependence among patterns. This is why we claim that the proposed classification is more precise. Another strong contribution of this paper lies in the presentation of the methodology used to build this classification. This one is composed of seven manual and automatic steps, which offer the advantage to justify the pattern classification and reduces the efforts required to add new patterns or weaknesses to the classification.

III. BACKGROUND

Our classification methodology is mainly based upon four security concepts: security patterns, weaknesses associated with their related mitigations, and security principles. We recall basics on these concepts below.

A. Security patterns

A security pattern is a generic solution to a recurrent security problem, which is characterized by a set of structural and behavioral properties [START_REF] Fernandez | Security patterns and secure systems design[END_REF]. It can be presented textually or with schema (UML diagrams). The quality of a pattern and its classification can be established with strong points, which correspond to sub-properties of the pattern [START_REF] Harb | Using an Ontology to Suggest Software Design Patterns Integration[END_REF]. Strong points are manually extracted from the forces and consequences of a security pattern.

In addition, a security pattern can be documented to express its relationships with other patterns. Yskout et al. proposed the following annotations between two patterns p 1 and p 2 [START_REF] Yskout | A system of security patterns[END_REF]: • "depend"means that the implementation of p 1 requires the implementation of p 2 ; • "benefit" expresses that implementing p 2 completes p 1 with extra security functionalities or decreases the development time. However, p 1 can be correctly implemented despite the absence of p 2 ; • "impair" means that the functioning of p 1 can be obstructed by the implementation of p 2 ; • "alternative" expresses that p 2 is a different pattern fulfilling the same functionality as p 1 ; • "conflict" encodes the fact that if both p 1 and p 2 are implemented together then it shall result in inconsistencies.

Such annotations may noticeably help combine patterns and not to devise unsound composite patterns.

For example, Figure 1 portrays the UML class diagram of the pattern "Authorization enforcer" whose purpose is to check whether client applications are authorized to request a Web application. This security pattern structures an application in such a way that the authorization logic is centralized and decoupled from the functional logic of the application [START_REF] Steel | Core Security Patterns: Best Practices and Strategies for J2EE, Web Services, and Identity Management[END_REF]. It benefits from the presence of a front controller (Security Base Action) offering a centralized entry point and from the presence of the pattern "Authentication enforcer", which encapsulates the authentication mechanism. It uses the "Authentication Provider" whose role is to check the client credentials. With regards to its forces and consequences, the pattern "Authorization enforcer" is characterized by the following strong points:

1) Minimize the decoupling between authorization and business logics; 2) URL based access control for Web applications; 3) Centralized authorization; 4) Systematic verification of client request permissions; 5) Promotes separation of responsibility; 6) Providing the application with authorization mechanism. This pattern is related to three other patterns: it is an alternative to the pattern "Container managed security", and benefits from the patterns "Secure service facade" and "Authentication enforcer".

B. CWE weaknesses and mitigations

The CWE database [START_REF]Common weakness enumeration[END_REF] provides an open catalog of software weaknesses. At the moment, this database includes around 700 software weaknesses but this number is still growing. A weakness is documented with a panoply of information, including a full description, its causes, detection methods, and a mapping between the weakness and CAPEC attack patterns or vulnerabilities. Furthermore, the CWE database provides, for each weakness, a set of potential mitigations. The latter summarize the actions to be done in order to overcome a weakness. A mitigation is identified by an id (MIT-ID) and is characterized by three important elements: a textual description, a strategy that corresponds to the basic security principle targeted by the mitigation, and its life cycle phase (requirements, design, implementation, etc.). Nevertheless, these elements are not supplied for all the mitigations of the database. In this work, we only consider mitigations that are fully documented for a better accuracy in the classification.

C. Security principles

A security principle is a desirable property, structure or behavior of software that aims at reducing the impact and the likelihood of a threat realization [START_REF] Viega | Building Secure Software: How to Avoid Security Problems the Right Way, Portable Documents[END_REF]. They represent an insight on the nature of close security tasks whose contexts are not taken into consideration. Saltzer and Schroeder firstly proposed a set of eight best practices for system security [START_REF] Saltzer | The protection of information in computer systems[END_REF], which were widely expanded in the last decades to form security principles [START_REF] Viega | Building Secure Software: How to Avoid Security Problems the Right Way, Portable Documents[END_REF], [START_REF] Meier | Web application security engineering[END_REF]. Below, we present some security principles used throughout the paper:

1) Access control: This security principle collects the mechanisms allowing the identification/authentication of entities (users or services), the definition and the verification of their access rights and the accounting [START_REF] Scambray | Improving Web Application Security[END_REF]. In particular, it includes the AAA (Authentication, Authorization and Accounting) principles.

2) In depth defense: Inspired from a military strategy, this security principle aims at protecting a system with a layered set of security mechanisms. It includes sub-principles and mechanisms that can be combined together in a layered form such as: "Complete mediation" (input validation and canonicalization), "Perimeter security" (e.g. firewalls), "Intrusion detection and prevention", "Network and core trust zones definition" (e.g., demilitarized zones, sand boxes or chroot jails) [START_REF] Stytz | Considering Defense in Depth for Software Applications[END_REF].

3) Fault tolerance : From a safety point of view and in order to ensure an acceptable availability, Fault tolerance aims at enabling an application to continue operating normally (or in a reduced way) and enhancing the manageability of failures in the application or in some of its parts. Fault tolerance comprises the principle "Exception management" to prevent the disclosure of internal information of the application in the case of a failure [START_REF] Meier | Web application security engineering[END_REF]. "Repartition" is another subprinciple of Fault tolerance whose purpose is to avoid the whole application failure in the case of a dysfunction of one of its parts. 4) Sensitive data : This principle addresses the prevention of sensitive data disclosures. For instance, it is constituted of these two well-known principles: "Encryption" (referring to encryption methods of data) and "Privacy" (referring to privacy protection) [START_REF] Meier | Web application security engineering[END_REF].

5) Configuration management: In software systems, it is advised to protect configuration items and to control item changes. The principle of "Configuration management" expresses this need. It can also be implemented by other principles, which are related to configurable elements: "Configuration protection", "Privilege management" or "Fail-safe defaults" [START_REF] Meier | Web application security engineering[END_REF].

6) Security simplification: As software sophistication increases, so does the risk to add security vulnerabilities. This principle refers to the "keep it simple stupid" (KISS) concept. It includes several sub-principles, e.g., the "Economy of mechanisms", "Psychological acceptability" [START_REF] Saltzer | The protection of information in computer systems[END_REF] or "Open design" (avoid security by obscurity).

IV. THE CLASSIFICATION METHODOLOGY

Our methodology aims at inferring relationships among a security weakness, security principles and security patterns, expressing which set of patterns fixes the weakness and the relations among the patterns. Without loss of generality, we applied the following methodology on Web application weaknesses, but it can also be applied on other kinds of applications on condition that the dedicated weaknesses, mitigations and patterns are being well documented.

The mapping from a weakness to a set of security patterns is inferred with several steps, summarized in Figure 2. These steps aim at finding successive concrete links among security concepts. On the one hand, we look for the mitigations that avoid exploiting a given weakness. On the other hand, we anatomize security patterns to collect a set of strong points, which represent sub-properties of the pattern. Intuitively, we connect both sides by means of the notion of security principles because these give the objectives targeted by the mitigations and strong points that have to be joined.

The methodology outlined in Figure 2 is actually divided into 7 manual and automatic steps, presented in Figure 3. In the first step, we collect the security principles we are interested in and organize them into a hierarchy. Steps 2 to 5 establish several different mappings from weaknesses to mitigations, from mitigations to security principles, from security patterns to strong points and finally from strong points to security principles. In Step 6, these mapping are automatically inter-connected. We obtain a database Db f from which the classification is automatically extracted in Step 7. Finally, for sake of readability, we depict pattern combinations with s, as illustrated in Figure 3 (right side). In our case, a SAG has a tree structure whose root node is labeled by a weakness. The other nodes are labeled by principles and the leaves by patterns. Relationships between two nodes can be defined using logic operations.

Our methodology offers the advantage to build a classification that can be easily updated. Indeed, if a new weakness is added to the CWE database, only the steps 2 and 3 have to be followed. In the same way, if a new security pattern is proposed in the literature, only the steps 4 and 5 have to be done. The re-generation of the whole classification, which includes new weaknesses or patterns is automatically performed. Each step is detailed below and illustrated with the weakness CWE-285: Improper Authorization.

A. Step 1: hierarchical organization of security principles

For this stage, we collected 66 security principles related to Web applications found in the literature and organized them into a tree, which reflects a hierarchy of principles from the most abstract (those nearest the top) to the most concrete ones (those nearest the bottom). Indeed, as presented in Section III, a security principle can be considered as the realization of other security principles, or as a subordinate principle of another one. This arrangement is represented by the tree depicted in Figure 4. This organization was manually established in relation to the nature of each security principle, often described with text. The proposed organization is not exhaustive but covers the security patterns and mitigations considered for this classification. We chose to organize security principles in this way to later generate inter-dependences among security patterns that completely or partially overcome a given weakness. In addition, this hierarchical organization shall give a complete overview (from the most abstract to the most concrete principles) on the nature of the security mechanisms that are required to remove a weakness and, in the same time, that are provided by security patterns.

We encoded this information in a database denoted DB 1 .

B. Step 2: weakness and mitigation extraction

In this step, we automatically extracted the weaknesses related to Web applications from the CWE database, and for each weakness, its potential mitigations. The result is stored in a database denoted DB 2 , which gathers information about 185 CWE weaknesses and 65 mitigations.

For example, the weakness CWE-285: Improper Authorization is commonly found in Web applications and occurs when an application does not correctly manage authorization checks. When the application does not have a correct authorization mechanism, it exposes several vulnerabilities, e.g., denial of service or arbitrary code execution. This weakness can be fixed by means of several mitigations. Due to lack of room, we only expose some of them here:

C. Step 3: mapping between mitigations and security principles

This step aims at establishing relations between mitigations and security principles. It was manually done by interpreting the strategies found in mitigations. Indeed, the meaning of a mitigation strategy is often very close or comprised into some security principle definitions. As a strategy may cover several security principles, we have to consider a many-tomany relation here.

Mitigations are usually described with concrete mechanisms given with a low abstraction level. Hence, we observed that mitigations are often associated with the most concrete security principles in reference to the hierarchical organization of Figure 4. This step gives a database DB 3 associating 65 mitigations and 66 security principles.

For example, the weakness CWE-285 can be fixed with the mitigation Divide the software into anonymous, normal, privileged, and administrative areas, which is related to two security principles:

• Least common mechanisms: so that a failure in an area does not affect another area; • Privilege separation: so that a privilege given in an area is not valid in the other area. A spoofed identity does not give the possibility to compromise all the authorization in the application.

D. Step 4: mapping between patterns and strong points

We established two relations among patterns and strong points:

1) the first one is a many-to-many relation between security patterns and strong points, each pattern being characterized by a set of strong points that can be shared with other patterns. For example, the patterns "Authorization enforcer" and "Container managed security" share the strong point "Providing the application with authorization mechanism". This relation is established by manually extracting the strong points of each pattern from its textual description (forces and consequences of the pattern); 2) the second relation is related to the annotations "depend", "benefit", "impair" or "alternative" defined among patterns [START_REF] Yskout | A system of security patterns[END_REF]. With P a set of patterns, this relation is defined as a mapping from P 2 to the annotation set {"depend", "benef it", "impair", "alternative"}, which provides for every pair of patterns (p1, p2) an annotation about the relationship between p1 and p2.

To summarize, these relations provide connections among patterns and between patterns and strong points. These are encoded into the database DB 4 , associating 26 security patterns and 36 strong points.

E. Step 5: mapping between strong points and security principles

As introduced in [START_REF] Wassermann | Security patterns[END_REF], security patterns are classifiable w.r.t. security principles, like most of the security techniques. Instead of directly looking for a relation between patterns and security principles, we focus on the strong points, which are more precise sub-properties themselves satisfied in patterns. Hence, this step aims at establishing a many-to-many relation between strong points and principles. This step was manually done since strong points and principles are mostly presented with textual documents. During this step, we observed that the abstraction level of strong points better fit with the most concrete principles exposed in our hierarchical organization of Figure 4. This relation is materialized with the database DB 5 .

For example, the strong point "Minimize the decoupling between authorization and business logics" of the pattern "Authorization Enforcer" has a security objective also found in the principle "Economy of mechanism", which is a subprinciple of "Security simplification".

F. Step 6: data consolidation

This automatic step integrates the databases DB 3 , DB 4 , and DB 5 into a single one. On the one hand, DB 3 stores the relations among CWE weaknesses, their potential mitigations and the related security principles. On the other hand, DB 4 and DB 5 store the relations among security patterns, strong points and principles. It is manifest that the security principle hierarchy becomes the central point that interconnects weaknesses with security patterns. We automatically performed this step with the tool Talend1 , which produces the final database DB f .

G. Step 7: classification extraction

The database DB f holds all the information required to extract a pattern classification. We have chosen to catalog the combinations of patterns that prevent attackers from exploiting a given weakness. This step automatically collects these combinations of patterns for every weakness found in DB f . More precisely, for a given weakness, we extracted:

• the information about the weakness (name, identifier, description, etc.); • the complete hierarchy of security principles Sp related to a weakness, i.e. the arrangements of principles from the most abstract ones to the most concrete principles.

The principles of Sp are associated with the weakness according to its potential mitigations given by the CWE database. The latter does not precise if one of the proposed mitigations is sufficient to fix the weakness or if all the mitigations have to be applied. As a consequence, we suppose that all the security principles have to be applied in order to overcome the weakness; • for every principle sp in Sp, the set of patterns P sp , the set of patterns P 2 sp not in P sp that have relations with any pattern of P sp , and the nature of these relations defined for couples of patterns by the annotations in {"depend", "benef it", "impair", "alternative", "conf lict"}. Figure 5 shows an example of data extraction achieved for the weakness CWE-285. The tabular provides the security principles and their levels in the tree of Figure 4 (col. 3-5), the related security patterns (col. 6) and the relations among patterns (col. [START_REF] Yskout | A system of security patterns[END_REF][START_REF] Fernandez | Classifying security patterns[END_REF]. Strong points and mitigations can also be extracted.

For sake of readability, we propose to portray this classification with SAGs, organizing the security principles and patterns related to a weakness. SAGs are semi-automatically drawn by these steps:

1) a weakness has its own SAG whose root is labeled by the weakness identifier. The root node is linked to the most abstract principles found in Sp connected together with the AN D operator, since we consider that all the security principles have to be ensured to remove the weakness. The security principles are themselves connected, from the most to the less abstract ones, by keeping the hierarchical organization defined in Step 1; 2) as our classification provides the relations among patterns (as explained in Step 4), we propose, in this final step, to complete the SAG with new nodes encoding these relations. Actually, we replace these relations with logic operators to infer a Boolean expression from all these relations. Given a security principle sp in Sp and a couple of patterns (p 1 , p 2 ) of the set P sp , if we have: The final SAG depicts the combinations of patterns, which overcome a weakness. We believe that these SAGs offer a good point of view on the potential solutions and can help choose the most appropriate one with regard to the application context. Figure 6 depicts the final SAG obtained for the weakness CWE-285. It shows that designers can implement either "Authorization Enforcer" or "Container managed security" and should implement all the other patterns (PBAC, RBAC, Least privileges, etc.) in order to fix the weakness. The SAG also shows the security principles applied here. The classification is built on 185 weaknesses, 26 security patterns and 66 principles. Due to lack of room, the complete list is available, with the classification, in [START_REF]Security pattern classification[END_REF]. Presented in tabular form, as illustrated in Figure 5, it enables multiattribute based decisions insofar as patterns can also be classified according to shared strong points, supported security principles, related weaknesses, mitigations and inter-patterns relationships.

The proposed classification complies with several quality criteria defined in [START_REF] Alvi | A Comparative Study of Software Security Pattern Classifications[END_REF]. Among them, we have noted Navigability, Unambiguity and Usefulness classification. Navigability, which is defined as the ability to direct designers among related patterns, is satisfied since the classification provides relationships among patterns and SAGs that illustrate the different choices of pattern combinations. Unambiguity is taken into account since the classification is clearly defined by means of the methodology steps, which provide relations among security properties. All these steps justify the classification. We believe that the classification can be used in practice since it is based upon the CWE database (weaknesses, mitigations) and security principles. In addition, SAGs can help designers in their pattern combination choices without ambiguity. A variety of statistical information can be extracted from the classification. For instance, Figure 7 shows the number of partly fixed weaknesses per pattern. Keeping in mind, that the set of patterns taken into consideration is not exhaustive, 4 patterns seems to emerge for partly fixing a large part of the 185 weaknesses covered by the classification: "Input Guard", "Output Guard", "Pathname Canonicalization" and in particular "Application firewall", which can overcome 109 weaknesses. This kind of information shows that, completed with more patterns, our classification and methodology would guide designers on good practices. For instance, in our context, one can deduce that these 4 patterns have to be used with Web applications. Unfortunately, the classification also reveals that 26 security patterns is insufficient to fix all the Web application weaknesses. Indeed, 30 weaknesses are not yet associated with security patterns. Hence the need to complete the current classification.

VI. CONCLUSION

In this paper, we presented a classification methodology putting together software weaknesses, security principles and patterns in order to help designers in the choice of the best pattern combination to fix a given weakness. This methodology is composed of some manual steps subdividing weaknesses and patterns into detailed security properties. Then, these are automatically associated together with respect to security principles. We organized the latter into a hierarchy to precisely express the security objectives of these properties. The resulting classification is stored into a database available in [START_REF]Security pattern classification[END_REF]. This database can be upgraded with new patterns and weaknesses without the need of re-writing the whole classification. We also proposed to portray this classification by means of Security Activity Graphs showing, without ambiguity, combinations of patterns and their relations.

In future research, we will continue investigating the specific issues raised by security pattern classification. Indeed, their heterogeneous nature and sometimes their ambiguous descriptions leave several problems open. For instance, we intend to investigate whether text mining techniques could help to partially automate some steps of the methodology (steps 2 to 5). We also intend to complete the classification with the attack patterns provided by CAPEC (Common Attack Patterns Enumeration and Classification) to provide another point of view on the pattern use. Indeed, it should be possible to extract Attack Defence Trees (ADT) [START_REF] Kordy | Attack-defense trees[END_REF] depicting the defences in terms of security patterns that designers may use to protect a software system against attacks.

Figure. 1 .

 1 Figure. 1. Authorization enforcer pattern

Figure. 2 .

 2 Figure. 2. The proposed mapping metamodel

Figure. 3 .

 3 Figure. 3. Classification methodology

Figure. 5 .

 5 Figure. 5. Extraction of the pattern classification for the weakness CWE-285

  Figure. 6. CWE-285 Security patterns tree

Figure. 7 .

 7 Figure. 7. Number of fixed weaknesses per pattern

  (p 1 depend p 2 ) or (p 1 benef it p 2 ), we use the expression (p 1 AN D p 2 ); • (p 1 impair p 2 ), we use (p 1 XOR p 2 ) since the presence of p 2 can decrease the efficiency of p 1 ;

•

https://www.talend.com


Loukmen Regainia
email: loukmen.regainia@udamail.fr

Cédric Bouhours
email: cedric.bouhours@udamail.fr

Sébastien Salva
email: sebastien.salva@udamail.fr

A Systematic Approach to Assist Designers in Security Pattern Integration

Keywords: Model, UML, Security Patterns, Verification

The last decade has witnessed significant contributions in software engineering to design more secure systems and applications. Software designers can now leverage specific patterns, called security patterns as reusable solutions to model more secure applications. But, despite the advantages offered by security patterns, these are rarely used in practice, because choosing and employing them for devising less vulnerable applications, is still a difficult and error-prone task. In this work, we propose an original approach to guide designers for checking whether a set of security patterns is correctly integrated into models and if vulnerabilities are yet exposed despite their use. This approach relies upon the analysis of the structural and behavioral properties of security patterns and on formal methods to check if these properties hold in the application model completed with patterns. We also provide a metric computation to assess the integration quality of patterns. Afterwards, we check whether the vulnerabilities, which should be removed by the use of patterns, are not exposed in the model. We illustrate this approach on an example of Web application, the Moodle education platform.

I. INTRODUCTION

Despite the indisputable improvements recently made in modeling, coding and testing, software engineering is still regarded as a complex field. One reason for this complexity is well-known: software engineering must not only address the functional aspects of an application, but also have to cover other aspects such as security. Indeed, providing secure models and code is recognized as an important factor of quality, but on the other hand, devising them is a difficult task.

To solve this issue, a large set of papers and tools have been proposed to help the integration of security in the software engineering steps [START_REF] Mouratidis | When security meets software engineering[END_REF] [START_REF] Flechais | Integrating security and usability into the requirements and design process[END_REF]. Among them, the pattern community proposed the notion of security patterns as reusable solutions to security issues in the modeling stage [START_REF] Yoshioka | A survey on security patterns[END_REF]. Specifically, a pattern represents a structure, a behavior, or some intents that have to be applied in models to meet security properties or to prevent threats (sometimes partially). At present, the security pattern base holds hundreds of available patterns, more and less detailed and compatible with each other. Many of them are indeed described with text only, their contextualization (a.k.a. instantiation) being left to designers. Furthermore, the impact of their composition is often unknown. Hence, the choice of the relevant patterns and their inclusion in models is yet onerous and error-prone, even for experts. This paper focuses on these difficulties and proposes an approach for helping designers to integrate the appropriate patterns and to design more secure applications. This approach corresponds to a sequential process, whose main benefits are twofold: measuring the integration quality of security patterns in models, and checking if these models are yet vulnerable to attacks despite the use of patterns.

More precisely, the designer initially chooses a list of vulnerabilities that must not be found in the application model and a set of security patterns that should correct these vulnerabilities or prevent attackers from exploiting them. The proposed formal method-based process firstly aims at helping the designer to integrate each pattern in the application model: we check whether the structural and behavioral properties of the pattern hold in the model by means of a method based on OCL (Object Constraint Language) queries and a verification technique. The former tries to locate the pattern shape in the model and returns a coefficient of disclosure. The verification technique checks whether some behavioral properties of the security pattern, expressed with LTL (Linear Temporal Logic) formulas, hold in the model. Then, quality metrics are computed to evaluate the integration quality of each pattern and of all the patterns in the model. If these metrics are low, the model should be revisited. In a second stage, the process also checks whether each vulnerability can be detected in the model by means of a verification technique. Actually, despite the use of security patterns, a vulnerability may be still present on account of several reasons, e.g., the use of an incomplete or wrong list of security patterns, or the composition of several patterns in the model that may induce a vulnerability. Vulnerabilities are formally expressed with LTL properties that are given to a model-checker. If any property is satisfied in the model, the designer is then warned that the latter still includes vulnerabilities and requires modifications.

We illustrate the benefits of this approach by applying it on a case study, based on Moodle education platform and on the vulnerability Code injection, which is a well known flaw allowing to inject code that is then interpreted by the application [START_REF]Common weakness enumeration[END_REF].

The paper is structured as follows: we briefly present the background and motivations in Section II. The approach is described in Section III. Its illustration on a Web application example is given in Section IV. Finally, we draw conclusions and perspectives for future work in Section V.

II. BACKGROUND

As the number of available security patterns is continuously growing, choosing the appropriate ones, to design more secure applications, is more and more tedious and error-prone. To help designers in this task, several papers proposed classifications and taxonomies to organize security patterns. Based on the STRIDE threat management methodology, Munawar et al. presented an organization of 97 security patterns on three architectural layers (Core, Exterior, Perimeter) [5]. In addition, Alvi et al. proposed in [START_REF] Alvi | A Natural Classification Scheme for Software Security Patterns[END_REF] a natural scheme for classifying security patterns. They associated their classification to the phases of software life cycle, i.e., security objectives in the requirement phase, security properties in the design phase, and attack patterns in the implementation phase.

The above papers provide classifications to help designers in the choices of security patterns. But, they do not help check whether patterns are correctly included in models. They also do not ensure that models are indeed more secure.

For the first point, Konrad et al. introduced in [START_REF] Konrad | Using Security Patterns to Model and Analyze Security Requirements[END_REF] a security pattern template to ease pattern integration. They exposed the difficulties related to the lack of comprehensive and formal description and proposed a template composed of Unified Modeling Language (UML) diagrams and LTL properties. Actually, we assume in our approach, that security patterns are indeed described with this kind of template.

In the last decade, several papers also proposed methods to check if UML models meet security requirements, the latter being usually expressed with LTL properties [START_REF] Ahmed | Static verification of security requirements in role based CSCW systems[END_REF]- [START_REF] Al-Lail | An Approach to Analyzing Temporal Properties in UML Class Models[END_REF]. For instance, Tanvir, et al. proposed an approach to verify the impact of using Role Based Access Control (RBAC) in a Computer Supported Cooperative Work (CSCW) [START_REF] Ahmed | Static verification of security requirements in role based CSCW systems[END_REF]. Thereby, they showed how to formally check if an application meets security requirements.

Our approach proposes to consider both above aspects, i.e., pattern integration assistance and verification of security properties on UML models, inside a whole process. We check pattern integration in UML models by considering their structural and behavioral properties. We also define and assess their integration quality with metrics. If these are low, the designer is warned that the UML diagrams of the application should be revisited. Afterwards, we also check, by means of model-checking, that the chosen security patterns actually remove undesired vulnerabilities from the UML models. This step aims to attest that the chosen patterns are effective against undesired vulnerabilities, or to warn designers to chose other patterns.

III. MODEL SECURING WITH PATTERN INTEGRATION AIDED BY FORMAL TECHNIQUES

In this section, we present our approach to assist designers to integrate security patterns in models for devising more secure applications, as illustrated in Figure 1. In this paper, we assume having a UML model M of the application, a vulnerability set V , which must not be exploited by attackers in the application, and a security pattern set Sp = {Sp 1 , ..., Sp k }, which should prevent the vulnerabilities of V = {V 1 , ..., V l } from being exploited. We also assume having a base of generic formal properties P Vi and P Spj describing V i and Sp j . The approach illustrated in Figure 2 aims at checking whether each pattern Sp j is correctly integrated on M and if M still has the vulnerability V i despite the use of Sp.

As the patterns are described in a generic, abstract form, the first step for the designer is to instantiate every pattern

Designer

Model

Vulnerability Security Pattern wants to protect his against a in using

Figure. 1. Context of the proposed approach

to the context of his model. Instantiating a pattern consists in adapting each constituting element to the specific context of a model. It is a complex step, which requires expertise in order to not damage the pattern. Hence, this step has to be verified:

1) Given a pattern Sp j , we check if the structural and behavioral properties of Sp j hold in the model M . For the structural properties, we use the approach and tool we developed in [START_REF] Bouhours | Detection of generic micro-architectures on models[END_REF]. Given the pattern Sp j and its generic description, the tool automatically derives a set of OCL queries encoding the structure of the pattern. Then, we call an executor of procedural OCL queries [START_REF] Millan | An ocl extension for checking and transforming uml models[END_REF]. After the execution, all micro-architectures, subsets of the model, looking like the pattern are listed and a coefficient of disclosure C Spj , ranging between 0 and 1, is given. The one with the highest coefficient is taken into account to locate where the pattern has been integrated in the model. If the designer does not agree, two cases are possible. On one hand, the pattern instantiation is incorrect and should be modified. On the other hand, the context is specific enough to justify a change in the structure. In any case, if the designer does not consider that the pattern is structurally integrated, the next step cannot be reached. 2) This step consists in checking whether some behavioral properties of Sp j hold in M . We provide, with the pattern, a set of generic behavioral properties P Spj , described in LTL. These rules describe the sequential message exchanges between the methods and the temporal states of the objects. These properties are generic and should be manually instantiated by the designer.

Once instantiated, M is automatically translated into a Promela (PROtocol MEta LAnguage) specification with the HugoRT tool [START_REF] Merz | Model checking timed uml state machines and collaborations[END_REF] and we check if this specification satisfies the previous LTL formulas with the modelchecker Spin [START_REF] Holzmann | Spin Model Checker, the: Primer and Reference Manual[END_REF]. This indicates whether the pattern integration into the model respects behavior imposed by the pattern. 3) Quality metrics are now computed to measure the integration quality of the pattern Sp j of Sp into the model M with regard to the coefficient of disclosure C Spj and the LTL property set P Spj provided with Sp j . Intuitively, the closer C Spj is to 1 and the larger the set P Spj , the more accurate the estimation of the pattern integration is. We define the mapping m : P Sp → {0, 1} by m(p) = 1 iff M |= p, and m(p) = 0 otherwise. The estimation range of a pattern Sp j integration is between 0 and n = Card(P Spj ) + 1 and this first integration metric is defined as:

0 ≤ m(Sp j ) = pi∈P Sp j m(p i ) + C Spj ≤ n
Afterwards, we compute the overall integration quality of the security pattern set Sp = {Sp 1 , ..., Sp k } using an utility function U . With this aim, we take Simple Additive Weighting (SAW) [START_REF] Yoon | Multiple attribute decision making: An introduction (quantitative applications in the social sciences)[END_REF] which allows to adjust the integration estimations of each pattern having different ranges by a weight representing user preferences and priorities. In our case U is defined as:

U = 0 ≤ k i=1 m(Sp i )/(Card(P Spi ) + 1).w i ≤ 1
with w i ∈ R + 0 and k i=1 w i = 1, w i being the weight of Sp i to represent designer preferences. The closer U is to 1, the greater the estimation that security patterns Sp 1 , ..., Sp k are correctly integrated into M . A good integration quality U can be reached with few properties. With a small number of properties, the pattern is not well documented / defined. In contrast, if the pattern integration is defined with large property sets and U is close to 0, this means that a mistake has been made during the instantiation or that the context is specific enough to justify a change in the structure of the pattern. 4) The last step of our approach starts when the designer considers that the pattern is integrated with a sufficient quality. For the vulnerability V i ∈ , we have a set of generic LTL properties P Vi describing V i , i.e., undesired behavior that should never happens. Once more, the designer has to instantiate these properties in accordance with the model M . The Spin tool is now called to check that the Promela specification of M will never satisfy the undesired behavior expressed by P Vi . If the presence of a vulnerability is detected, a counter-example is returned by Spin to detail the origin of the violation of the property. Hence, guided by the counter-example, the designer has to ensure that the chosen patterns are effective against the vulnerability or that the combination of patterns does not induce flaws.

IV. CASE STUDY

In this section, we describe, with more details, the steps of the proposed approach through a Web application example, the Moodle education platform [START_REF]Overview of the moodle question engine[END_REF], and precisely on its exam (quiz) functionality. The UML class diagram of this functionality is given in Figure 3 and its sequence diagram in Figure 4.

A user is identified with an id and accesses the service with a request of the form "GET /moodle/quiz/attempt.php?id=123". The identifier is used by the quizEngine as a parameter to get information about the user profile so that he/she has only one opportunity to pass an exam. An SQL database is used to get the user profile information and creates an exam session with regard to the requested id. It is well-known that this kind of Web applications is usually exposed to threats related to input ports 'passing illegal data', and especially injection attacks [START_REF]Common weakness enumeration[END_REF]. For instance, an attacker may exploit a vulnerability to pass an exam many times by spoofing or forging identities stored in database through SQL injection attacks. We have chosen to take as example here a familiar vulnerability called CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'), which is the main reason of SQL Injection attacks and one of the most recurrent vulnerabilities [START_REF] Owasp | Owasp testing guide v3.0 project[END_REF].

In order to secure the Web application, we have chosen to 5. This pattern is indeed presented as a solution to prevent attackers from exploiting the above vulnerability [START_REF] Steel | Core Security Patterns: Best Practices and Strategies for J2EE, Web Services, and Identity Management[END_REF]. The intent of this security pattern is to validate every user input request before using it as a parameter by a dynamically loadable validation logic [START_REF] Steel | Core Security Patterns: Best Practices and Strategies for J2EE, Web Services, and Identity Management[END_REF].

According to the Intercepting Validator security pattern documentation, its behavior is highlighted most notably by the following properties:

1) a validation logic for every data-type used in the application, 2) a single mechanism to validate all data-types, 3) the separation of the validation logic from the presentation logic,

A. Security pattern integration

We instantiated the Intercepting Validator security pattern on the model of the Moodle QuizEngine application by adapting its structural and behavioral properties in concordance with the diagrams in Figures 3 and4

B. Security pattern instantiation assessment

In this step, we check if the structural and behavioral properties of the security pattern hold in the application model (steps 1, 2 of the approach).

Firstly, we use the method we developed in [START_REF] Bouhours | Detection of generic micro-architectures on models[END_REF] to extract the pattern structural properties, expressed with OCL queries. Then, we call the tool Neptune [START_REF] Millan | An ocl extension for checking and transforming uml models[END_REF] to return a list of pairs (v, coef ) with v a vertex of the model that is also a vertex of the pattern and coef a coefficient of disclosure. With the class diagram of Figure 6, the tool provides the class "SecBase" For the behavioral properties, we assume having a set of generic LTL properties describing the Intercepting Validator pattern. We assume having three generic properties here, given in Table I col2 have to be manually instantiated to meet the QuizEngine application model. These ones are given in Table I col3.

For example, the property "A validation logic for every data-type used in the application" given above, is formalized with the LTL formula p 1 , which means "For every Client input, we do not validate data until the creation of the matching validator (SQL, XML, LDAP, etc.)".

p 1 : (Clientinput(Data) →!V alidate(data) U createV alidator(Data.type))
This generic formula is instantiated with respect to the QuizEngine application context, found in the sequence diagram of Figure 7. The instantiation of the property implies the good choice of the events matching the facts addressed by the generic LTL formula. For example, the fact Clientinput(Data) corresponds to the state input (the arrival of the request "GET /moodle/quiz/attempt.php?id=123") of the object attempt.php. The LTL formula becomes :

p 1 : (attempt.inState(input) → !secBase.inState(W aitingV al) U inV al.inState (valCreated))
To check whether the LTL formula p 1 , p 2 , p 3 hold in the model of Figure 7, we then performed the two following steps:

1) The UML diagram is translated into a Promela specification, with the HugoRT tool [START_REF] Merz | Model checking timed uml state machines and collaborations[END_REF],

2) The Spin model-checker [START_REF] Holzmann | Spin Model Checker, the: Primer and Reference Manual[END_REF] is called to check whether the Promela specification satisfies the LTL formulas. Namely, Spin checks that the Promela specification never ends in a state corresponding to a counterexample of one of the properties p 1 , p 2 , p 3 . In this example, all the properties of Table I hold. The pattern integration quality can now be straightforwardly estimated by combining the results obtained from the previous steps. Here, the estimation of the pattern integration is given by the metrics 0 ≤ m(Sp 1 ) = 1 + 1 + 1 + 1 ≤ 4 and 0 ≤ U = 1 ≤ 1. The latter shows that the security pattern is well integrated compared to the number of available behavioral properties. In contrast, the metric m(Sp) also reveals that the upper bound of the metric range (n) is low. This means that the number of behavioral properties is modest, and perhaps insufficient to ensure that the pattern is really correctly integrated.

C. Vulnerability exposure assessment

The last step aims at confirming that the security vulnerability is no longer exposed in the application model. We also assume having a set of LTL generic properties expressing behaviors that should never happen. For the CWE-89 vulnerability, taken as example in the paper, its documentation provides the following properties [START_REF]Common weakness enumeration[END_REF]: v 1 : No input validation, v 2 : Bad input validation, v 3 : Privilege escalation, v 4 : Remote information inference. This undesired behavior is formalized with the LTL formulas given in Table II 6, one deduces that the fact invokeTarget(Data) of the generic formulas has to be replaced by the state loadUsage of the object attempt.php. For example, the property No input validation is formulated with the generic LTL formula v 1 in Table II, which intuitively means "for every client input (data) the target is eventually invoked with (data) as parameter". This formula reflects undesired behavior because client inputs always have to be validated before any invocation. The instantiation of the generic formula v 1 gives:

v 1 : (attempt.inState(input) → ♦ quizEngine.inState(loadU sage))
During the generic formula instantiation, we observed that the third property cannot be deduced. Indeed, this property, which is related to privilege escalation through SQL injection cannot be expressed with the events found in the diagram of Figures 6 and7. This means that the application model does not include the required features for exposing this property. Here, the notion of level of access is indeed not represented.

We now call the Spin model-checker to check the absence of vulnerabilities in the QuizEngine application model. We obtain the results listed in Table II col.4. Spin detects the presence of the vulnerability property v 4 , and provides a counter-example. This property means that in the case when the client input is not valid, the generic error messages (whose content is minimal) is not sent to the client. Thus, the client may get a more detailed error message with sensitive information about the application. This information may be used to deduce attack vectors with a remote information inference.

As a consequence, the QuizEngine application still exposes the CWE-89 vulnerability and this step reveals that the Intercepting Validator pattern is insufficient to not expose this vulnerability. After analysis of the counter-example, we deduced that the vulnerability was detected because there is no mechanism, expressed in the security pattern, to generate generic error messages in the case of invalid input messages. Indeed, the Intercepting Validator pattern validates and filters input messages only. Another security pattern is therefore required, for instance the Exception Shielding pattern [5].

In conclusion, all this process helped integrate the security pattern and showed that this one was not sufficient to secure the application against all the threats related to the CWE-89 vulnerability. Either a more appropriate pattern has to be taken, or another pattern has to be combined with Intercepting Validator.

V. CONCLUSION

This paper presents a model-based process for helping designers to devise more secure applications by checking the appropriate use and contextualization of security patterns within UML diagrams. In an initial step, we assume that the designer chooses a list of vulnerabilities that must not appear in the application and a list of security patterns, which should prevent these vulnerabilities from being exploited. The proposed approach then provides several automatic or manual steps to ensure whether security patterns are correctly integrated and if vulnerabilities are still exposed despite the use of security patterns. A coefficient of disclosure is computed for every pattern and assesses if its structure can be found in the application model. Then, a quality metric is computed to estimate the integration quality of the patterns with regard to a set of available properties expressing the pattern behaviors. Theses metrics guide the designer in the correct pattern integration. The last step of the process aims at warning the designer if a vulnerability is still exposed. We have illustrated this approach with an example of Web application, which has to be protected against the CWE-89 vulnerability related to Code Injection.

In the near future, we intend to automate more this process to make its application easier to use for designers. Automation sounds typically not applicable to the entire process but to specific steps, e.g., the choice of the security patterns from vulnerabilities, or the instantiation of LTL properties from the application model. Hence, a designer having a very limited knowledge about security patterns and formal verification could improve the security of its applications anyway. To achieve such an automatic process, an initial step will consist of building an exhaustive base of formal vulnerabilities and security patterns providing the relationship between them.

  to check if the pattern is structurally detectable [SubSet of the Model with disclosure coefficients] Designer generates PROMELA specification with HugoRT [NO] [YES] [PROMELA specification of M] Is cofficient of disclosure acceptable ? Designer uses SPIN to check if LTL properties held Designer uses SPIN to check if LTL properties held Does model respect Pattern properties ?

Figure. 2 .Figure. 3 .

 23 Figure.2. An approach to assist designers to devise more secure applications

Figure. 4 .

 4 Figure. 4. Moodle Quiz engine sequence diagram

Figure. 5 .

 5 Figure. 5. Intercepting Validator class diagramm

  . The pattern classes are firstly added between attempt.php and quizEngine in the QuizEngine class diagram to prevent from SQL Injections through quizEngine, which has access to the database. The resulting class diagram is depicted in Figure 6. The sequence diagram of the QuizEngine application is also extended to include the security pattern behavior. The resulting diagram, given in Figure 7, shows that the messages exchanged between attempt.php and quizEngine are now validated.

Figure. 6 .

 6 Figure. 6. Instantiation of the security pattern: class diagramm

Figure. 7 .

 7 Figure. 7. Instantiation of the security pattern: sequence diagramm

  col.2. These formulas also have to be manually instantiated with respect to the context of the application. The resulting formulas are given in Table II col.3. With the UML diagram of Figure6, one can deduce that the event clientInput corresponds to the arrival of information from attempt.php, and invokeTarget corresponds

	P LTL generic form		LTL instantiated form LTL
	p 1	(Clientinput(Data)	→	(attempt.inState(input))	→	(! secBase	:
		!V alidate(Data) U createV alidator(data.type))		inState (W aintingV alidation) U inV al.inState (validators Created)))
	p 2	(inputV aldiator.isUnique)		(secBase.isUnique ∧ inV al.isUnique)
	p 3	(clientInput(data)∧!ServerV alidate(data)	∧	((attempt.inState(input)∧!secBase.inState(nonvalid)	∧
		♦ServerV alidate(data))	→	♦secBase.inState(nonvalid)) →!attempt.inState(err -page) U
		(!returnGeneric(message) U ServerV alidate(data))	secBase.inState(nonvalid))

  → ♦ (!attempt.inState(err -page))) Yes to the use of the input data in the object quizEngine. With the sequence diagram of Figure

				TABLE II
		CWE-89 VULNERABILITY PROPERTIES
	Vulnerability	LTL generic formula		LTL instantiated formula	Sat
	property
	v 1	(clientInput(data)	→	(attempt.inState(input) → ♦quizEngine.inState(loadUsage)) No
		♦invokeT arget(data))
	v 2	(clientInput(data) → (!V alid(data) →	(attempt.inState(input) → (secBase.inState(nonvalid) →	No
		♦invokeT arget(data)))		♦(quizEngine.inState(loadUsage))))
	v 3	(clientInput(data) ∧ client.right(Min) →	?	?
		♦client.right(Max))
	v 4	(!valid(data) → ♦(!genMessage))		(secBase.inState(nonvalid)

VI. ACKNOWLEDGMENT

Research supported by the industrial chair on Digital Confidence http://confiance-numerique.clermontuniversite.fr/index-en.html


Juliette Chabassier

Robin Tournemenne

About the transfert matrix method in the context of acoustical wave propagation in wind instruments

Keywords: Acoustics, input impedance, transfer matrix, losses Acoustique, impédance d'entrée, matrice de transfer, pertes

The transfer matrix method allows to compute the input impedance of a pipe. This work proposes a unified formulation of the coefficients of the transfer matrices for cones and cylinders. This is done for both models with and without viscothermal losses. The exactly solved equation with the transfer matrix method in the case of the cone with viscothermal losses is exhibited.

Key-

A Webster's horn equation obtention 11

B Equivalent formulation of the cone transfer matrix 13 C Approximated propagation equations for the cone transfer matrix considering visco-thermal losses 13

1 Lossless transfer matrix method

Problem definition

Consider an axisymmetric pipe occupying a domain Ω ⊂ R 3 = (Ox, Oy, Oz) of slowly varying cross section S and rigid walls developing along the x axis, filled with a fluid, see Figure 1. The acoustic pressure p(x, y, z, t) and the three-dimensional flow u(x, y, z, t) can be considered as the solution to Euler three-dimensional equations which are computationally intensive to solve, especially when only the propagating phenomena are of interest. An asymptotic analysis from Euler's equations for a perfect gas in a pipe with a slowly varying section [START_REF] Sjoerd | Webster's horn equation revisited[END_REF] leads to the classical one-dimensional Webster's horn equation. We recall the development of this analysis in the Appendix A. The pressure can then be considered as constant in the sections orthogonal to the x-axis, the orthogonal components of the three-dimensional flow can be neglected in Sound velocity: c = 331.45 T /T 0 m s -1 Density: ρ = 1.2929 T 0 /T kg m -3 Viscosity: µ = 1.708 e -5(1 + 0.0029 t) kg m -1 s -1 Th. cdt.: κ = 5.77 e -3(1 + 0.0033 t) Cal/(ms • C) Spec. heat with cst. p.: C p = 240 Cal/(kg • C) Ratio of specific heats: γ = 1.402 Table 1: Numerical values of air constants used in the model, see [START_REF] Chaigne | Acoustics of Musical Instruments[END_REF]. t is the temperature in Celsius, and T the absolute temperature knowing that T 0 = 273.15 • K. the equations while the axial component can be considered as axisymmetric with an analytic expression of its radial dependancy. Thus we seek in the frequency domain p(x, ω) the acoustic pressure and û(x, ω) the volume flow such that the one-dimensional volumic equations read, for all x ∈ [0, L] and with k = ω/c

         1 S d dx S dp dx + k 2 p = 0 , (1a) jωρ
S û + dp dx = 0 , (1b)
where j is the complex number, ρ the density and c the sound velocity (Table 1 defines the air constants). Where the section S is not discontinuous, it can also be written

     k 2 p + 1 S dS dx dp dx + d 2 p dx 2 = 0 , ( 2a
) jωρ S û + dp dx = 0 , (2b)
Two boundary conditions complete the problem: at the bell x = L, we impose a radiation impedance [START_REF] Dalmont | Radiation impedance of tubes with different flanges: Numerical and experimental investigations[END_REF][START_REF] Lawrence | Digital processing of speech signals[END_REF][START_REF] Chaigne | Acoustics of Musical Instruments[END_REF]:

p(L, ω) û(L, ω) = Z R (ω) , (3)
and at the input of the pipe, we impose

û(0, ω) = λ(ω), (4)
where λ(ω) will be a source term for the system. Since all the considered equations are linear, we can consider without loss of generality λ(ω) ≡ 1. In this work, we are interested in computing the input impedance

Z(ω) := p(0, ω) û(0, ω) , (5)
which is primarily linked to the bore S : x → S(x), which is a coefficient in Equations [START_REF] Caussé | Input impedance of brass musical instrumentscomparison between experiment and numerical models[END_REF]. Finally, the considered problem is the following:

Inria Compute Z(ω) = p(0, ω) û(0, ω) , where (6)
                              1 S d dx S dp dx + k 2 p = 0 , jωρ S û + dp dx = 0 , ∀ x ∈ [0, L] (7a) û(0, ω) = 1, (7b) p(L, ω) û(L, ω) = Z R (ω). (7c)

Transfert matrix principle

The transfer matrix method (TMM) consists in writing relations between output and input acoustic variables of simple geometries (eg. cylindrical, conical parts, Bessel or exponential bores . . . ) from the use of the propagation equations [START_REF] Caussé | Input impedance of brass musical instrumentscomparison between experiment and numerical models[END_REF]. Consequently, given a radiation impedance Z R (ω) and discretizing the bore profile in a series of N p parts, it is possible to compute the instrument's input impedance. Let {x i } 0≤i≤Np be the list of positions on the bore's axis defining all the parts (with x 0 = 0 and x Np = L). We also define pi (ω) and ûi (ω) as approximations of the pressure and the volume flow calculated by the TMM at the positions x i . When the TMM is exact, pi (ω) = p(x i , ω) and ûi (ω) = û(x i , ω).

Formally, the relation between the input and the output of one simple geometry can be expressed as a 2×2 matrix T i+1 (ω):

pi (ω) ûi (ω) = a i+1 (ω) b i+1 (ω) c i+1 (ω) d i+1 (ω) pi+1 (ω) ûi+1 (ω) = T i+1 (ω) pi+1 (ω) ûi+1 (ω) . ( 8
)
We then deduce the relation between the input and the output of the pipe:

ζ = p0 (ω)/û L (ω) û0 (ω)/û L (ω) = Np i=1 T i (ω) Z R (ω) 1 . (9)
where ûL (ω) is the volume flow at the pipe end, and finally

Z TMM = ζ(1) ζ (2)
. The global transfer matrix is defined as the product of all the elementary matrices T i . An implicit transmission condition is therefore assumed, which is the continuity of the variables between all parts. In practice, the computation is done only for a discrete set of pulsations {ω j } 1≤j≤Nω .

Transfer matrices for the cylinder and the cone

Cylinder. In the case of an infinite cylinder of section S, the Webster's horn equation of propagation simplifies to the classical one dimensional wave equation

d 2 p dx 2 + k 2 p = 0 , (10)
where k = ω/c.

RR n°9254

An analysis of the solution of this equation shows that the transfer matrix between two positions separated by the distance is:

a i (ω) = a, b i (ω) = b, c i (ω) = c, d i (ω) = d, where            a = cos(k ) , b = jZ c sin(k ) , c = j Z c sin(k ) , d = cos(k ) ,
where Z c = ρc/S. The analysis leading to this formula is notably written in the chapter 2 of [START_REF] Charles | Bore optimisation and impedance modelling of brass musical instruments[END_REF].

Cone. In the case of a cone, it is somehow more delicate to obtain the transfer matrix, see Appendix A of [START_REF] Charles | Bore optimisation and impedance modelling of brass musical instruments[END_REF]. Let us consider a cone part defined by two sections of radii R i and R i+1 normal to the cone's axis and separated by a distance . A change of coordinate is useful to derive the analytical solution. The new axis origin is chosen as the cone apex and is defined so that the new coordinate xi and xi+1 respectively associated with the radii R i and R i+1 satisfy xi < xi+1 (with = xi+1 -xi ), see Figure 2. One gets that the corresponding transfer matrix of a divergent or convergent cone part reads:

a i (ω) = a, b i (ω) = b, c i (ω) = c, d i (ω) = d, where                          a = xi+1 xi cos k - 1 k xi sin k , (12a) b
= xi xi+1 jZ c,i sin k , (12b)
c = j Z c,i xi+1 xi + 1 k 2 x2 i sin k -k x2 i cos k , (12c)
d = xi xi+1 cos k + 1 k xi sin k , ( 12d
) with Z c,i = ρc/(πR 2 i ). R i R i+1 xi xi+1 R i R i+1 xi xi+1

Inria

This formula is exactly the transfer matrix formula that can be found in [START_REF] Mapes-Riordan | Horn modeling with conical and cylindrical transmission-line elements[END_REF]. An equivalent formula is sometimes used in the community (section 7.4.3 from [START_REF] Chaigne | Acoustics of Musical Instruments[END_REF]) and the transition from one formulation to the other can be found in the Appendix B.

Seamless formulation of cone and cylinder transfer matrix

The cone formulation (12) does not converge towards the cylinder formulation when R i → R i+1 because xi and xi+1 go towards infinity. Taking into account the geometrical relations, it is possible to overcome this problem providing one single transfer matrix formula for both cone and cylinder cases:

The transfer matrix of a cone or cylinder part of length with input radius R i and output radius R i+1 is given by:

T i+1 (ω) = a i+1 (ω) b i+1 (ω) c (ω) d i+1 (ω)
where

                                       a i+1 (ω) = R i+1 R i cos k - β k sin k , (13a) (13b)
b i+1 (ω) = R i R i+1 jZ c,i sin k , (13c) (13d)
c i+1 (ω) = j Z c,i R i+1 R i + β 2 k 2 sin k - β 2 k cos k , (13e) (13f)
d i+1 (ω) = R i R i+1 cos k + β k sin k . ( 13g
) β = R i+1 -R i R i , k = ω c , Z c,i = ρc πR 2 i ( 14
)
Notice that this formula does not diverge when R i is equal to R i+1 and that β can be interpreted in the previous definitions as β = 1 xi .

2 Transfer matrix method considering visco-thermal losses

Problem definition and transfer matrix of the cylinder

It is possible to take into account in a one dimensional model the visco-thermal losses induced by the pipe's wall thanks to a simplification of Kirchhoff's theory [START_REF] Kirchhoff | Ueber den einfluss der wärmeleitung in einem gase auf die schallbewegung[END_REF][START_REF] Zwikker | Sound absorbing materials[END_REF][START_REF] Chaigne | Acoustics of Musical Instruments[END_REF]. This model has been derived for cylinders but is also used for slowly varying cross section S. The propagation equations become, for all position x ∈ [0, L] and pulsation ω,

     Z v (ω, x) û + dp dx = 0, (15a)
Y t (ω, x) p + dû dx = 0, (15b)
with

       Z v (ω, x) = jω ρ S(x) [1 -J (k v (ω)R(x))] -1 , (16a)
Y t (ω, x) = jωS(x) ρc 2 [1 + (γ -1)J (k t (ω)R(x))] , (16b)
k v (ω) = jω ρ µ , k t (ω) = jωρ C p κ ,
where R(x) is the section radius, S(x) = πR(x) 2 is the section area, table 1 describes the air constants, and we introduce the function J of a complex variable, which models the dissipative terms, as

J (z) = 2 z J 1 (z) J 0 (z) , ∀ z ∈ C . (17)
J 1 and J 0 are respectively the first kind Bessel functions of first and zero order. The same boundary conditions as in the previous section completes this problem. One can notice that if the dissipative terms are neglected, this model formally tends to the previous Webster's horn equations, which shows the compatibility of the two models. Unfortunately, the function J being non-linear, there is, to the best of our knowledge, no way to derive exact analytical formulas for any other pipe's geometries than for the cylinder, for which Z v and Y t are constant with respect to x.

The exact transfer matrix of a cylinder of section S between two positions distant of is:

           a = cosh(Γ ) , b = jZ c sin(k ) , c = j Z c sin(k ) , d = cos(k ) , where Γ = √ Z v Y t and Z c = Z v /Y t (
which is equal to ρc/S if the losses are neglected). One can observe that this transfer matrix is formally identical to the transfer matrix in the lossless case replacing jk by Γ and Z c by its corresponding definition.

Actual problem definition of the cone transfer matrix

Two empirical strategies exist to derive approximated transfer matrices for the cone considering visco-thermal losses at the pipe's wall. A first empirical approach handles this difficulty for conical parts by approximating them as a succession of cylinders of increasing or decreasing radii [START_REF] Caussé | Input impedance of brass musical instrumentscomparison between experiment and numerical models[END_REF]. A second empirical approach proposes to discretize each conical part in N sub smaller cones, and to use on each subdivision the transfer matrix derived for the cone considering lossless propagation, replacing some parameters by their lossy counterparts evaluated at a chosen intermediate radius Inria R [START_REF] Mapes-Riordan | Horn modeling with conical and cylindrical transmission-line elements[END_REF][START_REF] Charles | Bore optimisation and impedance modelling of brass musical instruments[END_REF]. For a bore initially made of N p conical parts, the total number of actual transfer matrices to compute would be N TMM = N p × N sub .

Since the visco-thermal losses depend non-linearly on the radius, no optimal value for R can be immediately derived. Possible choices are the average radius R = (R i + R i+1 )/2 as in [START_REF] Mapes-Riordan | Horn modeling with conical and cylindrical transmission-line elements[END_REF] (where R i and R i+1 are the input and output radii of the small cone), or any other weighted average. In this report, we choose R = (2 min(R i , R i+1 ) + max(R i , R i+1 ))/3, which seems to be used in some existing implementations of the TMM.

As shown in Appendix C, using the TMM with the approximate matrix obtained with this strategy corresponds to actually solving analytically the following system of equations: compute

Z TMM (ω) = p(0, ω) ǔ(0, ω) , where ∀ i ∈ [1, N TMM ], (19)
                                                      Z i v ǔ + dp dx = 0, Y i t p + dǔ dx = 0, ∀ x ∈ [x i , x i+1 ] (20a)
Z i v = jω ρ S 1 -J (k v (ω)R i ) -1 , (20b)
Y i t = jωS ρc 2 1 + (γ -1)J (k t (ω)R i ) , (20c) p(x
+ i ) = p(x - i ), ǔ(x + i ) = ǔ(x - i ), (20d)
R i = (2 min(R(x i ), R(x i+1 )) + max(R(x i ), R(x i+1 )))/3, (20e)
ǔ(0, ω) = 1, (20f) p(L, ω) v(L, ω) = Z R (ω). ( 20g
)
This problem is different from the continuous problem (15) solved with the FEM. The difference lies in the approximation R inside the function J for every interval [x i , x i+1 ] and amounts to approximating the original equation coefficients with discontinuous ones.

Seamless formulation of cone and cylinder transfer matrix

Finally, we propose a unified formulation for the computation of the transfer matrix T i (ω), equivalent to the ones of the literature [START_REF] Mapes-Riordan | Horn modeling with conical and cylindrical transmission-line elements[END_REF], for cones and cylinders under visco-thermal losses. It reads:

The transfer matrix of a cone or cylinder part of length with input radius R i and output radius R i+1 is given by:

T i+1 (ω) = a i+1 (ω) b i+1 (ω) c i+1 (ω) d i+1 (ω)
where

                         a i+1 (ω) = R i+1 R i cosh Γ i - β Γ i sinh Γ i (21a) b i+1 (ω) = R i R i+1 Z c,i sinh Γ i (21b) c i+1 (ω) = 1 Z c,i R i+1 R i - β 2 Γ 2 i sinh Γ i + β 2 Γ i cosh Γ i (21c) d i+1 (ω) = R i R i+1 cosh Γ i + β Γ i sinh Γ i (21d)
where

Γ i ≡ Γ(ω, R i ) = jω c 1 + (γ -1)J (k t (ω)R i ) 1 -J (k v (ω)R i ) , Z c,i ≡ Z c (ω, R i ) = ρc πR 2 i 1 + (γ -1)J (k t (ω)R i ) -1 1 -J (k v (ω)R i ) and β = R i+1 -R i R i . (22)

A Webster's horn equation obtention

The following appendix is a synthesis of a part of the article [START_REF] Sjoerd | Webster's horn equation revisited[END_REF]. In the acoustic realm of a perfect gas, the pressure p, the fluid velocity ṽ, the density ρ, the entropy s, the sound speed c verify the mass conservation (with no source),

div ρṽ + ∂ ρ ∂t = 0 , (23)
the momentum conservation (with no external force),

ρ ∂ ṽ ∂t = -grad p , (24)
the isentropic flow,

ds dt = 0 , (25)
and the state equations of a perfect gas,

ds = C v dp p -C p dρ ρ , c2 = γ p ρ , γ = C p C v , (26)
where γ, C p and C v are gas constants. Assuming an unsteady time-harmonic perturbation of frequency ω we can study these equations setting p = P + pe jωt , ṽ = v 0 + ve jωt , ρ = ρ + ρ e jωt , s = s 0 + se jωt , c = c + c e jωt . If we neglect the mean flow (v 0 = 0) and suppose the density and the sound speed constant (ρ = c = 0, c, ρ constant) we obtain, after manipulations [START_REF] Rienstra | An introduction to acoustics[END_REF], the classical acoustic wave equation:

∇ 2 p + k 2 p = 0 , ( 27
)
where k = ω/c is the wave number. This rather general equation is studied for a duct of arbitrary cross section S slowly varying along the axis x, see Figure 1. In order to find an approximated one-dimensional model in this context, an asymptotically systematic derivation of the three-dimensional classic problem is utilized ([6, 10, 9]). The duct dimension along the x axis being large compared to the cross section dimensions, a so-called slow variable X = x ≥ 0 is used -the small number is the Helmholtz number, the ratio between the duct diameter and the typical wavelength. Consequently, a variation of X is comparable to a cross section variation. This mathematical shrink of the duct, induces a wavelength contraction, which leads us to use the new wave number κ = k/ . In cylindrical coordinates, the duct radius is described by the function R(X, θ). Consequently, the function

V ol = r -R(X, θ) , ( 28
)
represents the points inside the duct if V ol < 0 and any point on the surface if V ol = 0. On the duct surface (V ol = 0), the gradient ∇V ol is a vector normal to the surface ([9], section A.3).

At the solid wall, we have the boundary condition of vanishing normal velocity:

∇p • ∇V ol = 0 , at V ol = 0 . ( 29
)
Under the new variables, the acoustic wave equation becomes

∇ 2 p + 2 κ 2 p = 0 . (30)
Assuming the asymptotic expansion p(X, r, θ, ) = p0 (X, r, θ) + 2 p1 (X, r, θ) + O( 4) .

Using Eq. ( 29) and (30), it is then possible to demonstrate that the leading order p 0 is solution to Webster's horn equation:

1 S d dx S dp 0 dx + k 2 p0 = 0 , ( 32
)
where S is the cross section area at position x.

The initial model bears two approximations: the gas is perfect and the momentum conservation is dealt thanks to the Material derivative. Under this model, thanks to the asymptotic expansion we know that the error made approximating p by p0 is in O( 2 ). Finally, in this report we consider only the leading order (p ∼ p0 ), consequently, the Webster's horn equation reads

1 S d dx S dp dx + k 2 p = 0 , (33)
at the second order in space, and it is possible to introduce û such that

       jωρ S û + dp dx = 0, (34a)
jωS ρc 2 p + dû dx = 0, (34b)
at the first order in space, where û is called the volume flow.

Inria

B Equivalent formulation of the cone transfer matrix

The transfer matrix found in [START_REF] Mapes-Riordan | Horn modeling with conical and cylindrical transmission-line elements[END_REF] reads

                               a = xi+1 xi cos k - sin k kx i , (35a) b
= xi xi+1 jZ c,i sin k , (35b)
c = j Z c,i xi+1 xi + 1 k 2 x2 i sin k -kx 2 i cos k , (35c)
d = xi xi+1 cos k + 1 kx i sin k , (35d)
Z c,i being the characteristic impedance at the entrance: Z c = ρc/(πR 2 i ). This is equivalent to (using Thales theorem)

                               a = R i+1 R i cos k - sin k kx i , (36a) b
= R i R i+1 j ρc πR 2 i sin k , (36b) c
= j ρc R i R i+1 + 1 k 2 sin k -k cos k , (36c)
d = R i R i+1 cos k + 1 kx i+1 sin k , (36d)
which is equivalent to the formulation found in section 7.4.3 of [3]1 :

                               a = R i+1 R i cos k - sin k kx i , (37a) b
= j ρc πR i R i+1 sin k , (37b)
c = πR i R i+1 ρc 1 + 1 k 2 xi xi+1 j sin k - cos k jk 1 xi - 1 xi+1 , (37c)
d = R i R i+1 cos k + sin k kx i+1 . (37d)
C Approximated propagation equations for the cone transfer matrix considering visco-thermal losses

In this section, the ˜on positions x are removed for ease of reading.

The aim is to prove that the system (20) is indeed leading to the transfer matrices proposed by [START_REF] Mapes-Riordan | Horn modeling with conical and cylindrical transmission-line elements[END_REF]. For the demonstration, we will start from the propagation equations and show that they lead to the given transfer matrix.

The complete system we are analyzing is

∀ i ∈ [1, N TMM ],                                                       Z i v ǔ + dp dx = 0, Y i t p + dǔ dx = 0, ∀ x ∈ [x i , x i+1 ] Z i v = jω ρ S 1 -J (k v (ω)R i ) -1 , p(x i ) = p(x i+1 ), ǔ(x i ) = ǔ(x i+1 ), Y i t = jωS ρc 2 1 + (γ -1)J (k t (ω)R i ) , R i = (2 min(R(x i ), R(x i+1 )) + max(R(x i ), R(x i+1 )))/3, ǔ(0, ω) = 1, p(L, ω) v(L, ω) = Z R (ω).
We differentiate with respect to x the first equation of system (20):

       Z i v dǔ dx + ǔ jωρ 1 -J (k v (ω)R i ) -1 d dx 1 S + d 2 p dx 2 = 0 , (39a)
Y i t p + dǔ dx = 0 , (39b)
using Equation (39b) and the first equation of system (20) in (39a):

       -Z i v Y i t p - dp dx S jωρ 1 -J (k v (ω)R i ) -1 jωρ 1 -J (k v (ω)R i ) -1 - 1 S 2 dS dx + d 2 p dx 2 = 0 , (40a)
Z i v ǔ + dp dx = 0 , (40b)
We define

Γ i = Z i v Y i t :      -Γ 2 i p + 1 S dS dx dp dx + d 2 p dx 2 = 0 , (41a)
Z i v ǔ + dp dx = 0 , (41b)
This system of Equations is similar to the system (2). The differences lies in the coefficient -Γ 2 i which is +k 2 in (2), and the coefficient Z i v which is equal to jωρ/S in (2). We will follow the technique found in the Appendix A of [START_REF] Charles | Bore optimisation and impedance modelling of brass musical instruments[END_REF] to derive the transfer matrix function of the system (41). Yet, we will study the following broader family of systems:

Inria      αp + 1 S dS dx dp dx + d 2 p dx 2 = 0 , (42a) ǔ
= -β(x) dp dx . (42b)
If α and β(x) are respectively equal to k 2 and S(x)/jωρ, this system is the Webster's horn propagation equations [START_REF] Caussé | Input impedance of brass musical instrumentscomparison between experiment and numerical models[END_REF]. If α and β(x) are respectively equal to -Γ 2 i and 1/Z i v , this system is the approximated propagation equations considering visco-thermal losses (41).

In the case of a convergent or divergent cone of slope a whose origin is defined as in Figure 2, S = π(θx)

The solution to this equation is

p(x) = A x e -jδx + B x e jδx , (44)
where δ 2 = α. This can be reformulated as

p = 1 x [(A + B) cos δx -j(A -B) sin δx] , (45)
and Equation (42b) leads to

ǔ = β 1 x 2 [(A + B) cos δx -j(A -B) sin δx] + δ x [(A + B) sin δx + j(A -B) cos δx] . (46)
We have then the following impedance formula

Z(x) = 1 x [(A + B) cos δx -j(A -B) sin δx] β 1 x 2 [(A + B) cos δx -j(A -B) sin δx] + δ x [(A + B) sin δx + j(A -B) cos δx] , (47)
which leads to

A + B A -B = jβ 1 x sin δx -δ cos δx Z(x) -j sin δx β 1 x cos δx + δ sin δx Z(x) -cos δx (48)
The quotient A + B A -B is constant w.r.t x. Consequently, defining Z(x i ) and Z(x i+1 ) respectively as Z 0 and Z 1 , we observe the following equality

A + B A -B = γ 1 Z 0 + γ 2 γ 3 Z 0 + γ 4 = γ 5 Z 1 + γ 6 γ 7 Z 1 + γ 8 . (49)
This leads to the following transfer matrix

Z 0 = [γ 1 γ 7 -γ 3 γ 5 ] Z 1 + γ 1 γ 8 -γ 3 γ 6 [γ 4 γ 5 -γ 2 γ 7 ] Z 1 + γ 4 γ 6 -γ 2 γ 8 = aZ 1 + b cZ 1 + d (50)
Using (48), it finally gives

                               a = jβ(x i+1 ) - 1 x i+1 sin δ + δ cos δ , (51a)
b = j sin δ , (51b)
c = jαβ(x i )β(x i+1 ) - 1 x i x i+1 α + 1 sin δ + x i x i+1 δ cos δ , (51c)
d = jβ(x i ) 1 x i sin δ + δ cos δ , (51d)
where = x i+1 -x i .

In the Webster's horn Equation case, replacing α by k 2 and β(x) by S(x)/jωρ we find

                           a = πθ 2 x i x i+1 ρc x i+1 x i cos k - 1 kx i sin k , b = πθ 2 x i x i+1 ρc x i x i+1 jZ c sin k , c = πθ 2 x i x i+1 ρc j Z c x i+1 x i + 1 k 2 x 2 i sin k -kx 2 i cos k , d = πθ 2 x i x i+1 ρc x i x i+1 cos k + 1 kx i sin k ,
which, after simplification by πθ 2 xixi+1 cρ gives the formula (12), found in [START_REF] Mapes-Riordan | Horn modeling with conical and cylindrical transmission-line elements[END_REF]. Similarly, for the approximated visco-thermal case, replacing α by -Γ 2 i and β(x) by 1/Z i v (x) we find

                         a = -1 Z c (x i+1 ) x i x i+1 x i+1 x i cosh Γ - 1 Γx i+1 sinh Γ , b = -1 Z c (x i ) x i+1 x i x i x i+1 Z c (x i ) sinh Γ , c = -1 Z c (x i ) x i+1 x i 1 Z c (x i ) x i+1 x i - 1 Γ 2 x 2 i sinh Γ + Γx 2 i cosh Γ , d = -1 Z c (x i ) x i+1 x i x i x i+1 cosh Γ + 1 Γx i sinh Γ , observing that -1 Z c (x i+1 ) x i x i+1 = -1 Z c (x i ) x i+1 x i
and simplifying by -1 Z c (x i )

x i+1 x i
, one finds the same expression than [START_REF] Mapes-Riordan | Horn modeling with conical and cylindrical transmission-line elements[END_REF] and eventually the formula (21). This proves that the propagation equations from (20) are the solved equations. Beside, the other Equations from (20) complete the TMM approach: Equation (20e) setting R is arbitrary based on empirical observations, Equation (20d) translates the continuity hypothesis made by the transfer matrix method between two parts, and Equations (20f) and (20g) are the necessary boundary condition closing the problem.

Figure 1 :

 1 Figure 1: Definition of the space variables. S is the slowly varying section of the axisymmetric pipe

Figure 2 :

 2 Figure 2: Definition of the geometrical quantities for a divergent cone and a convergent cones. Notice that xi and xi+1 are negative for the convergent cone.

  200 avenue de la Vieille Tour 33405 Talence Cedex Publisher Inria Domaine de Voluceau -Rocquencourt BP 105 -78153 Le Chesnay Cedex inria.fr ISSN 0249-6399

RR n°9254

In their equation the definition of should be equal to xi+1 -xi RR n°9254