A Secure and Extendable Plug-in Framework implementing Specific Design Patterns

Transcription

1 A Secure and Extendable Plug-in Framework implementing Specific Design Patterns Daniel Clark BSc (Hons) Computer Science May 2005 This thesis may be made available for consultation within the University Library and may be photocopied or lent to other libraries for the purposes of consultation Signed

2 Abstract Plug-in frameworks provide an Application Programming Interface (API) allowing individual plugins to extend a system with specific functionality at runtime. Applications providing a plug-in architecture often implement a custom architecture for the application, without using an existing plug-in framework or any re-usable components. This is possibly caused by re-usability constraints, limiting most frameworks to specific programming languages. The scope of this dissertation provides an implementation of a plug-in framework, with specific focus on runtime plug-in licensing as well as compatibility with an extensible set of languages. The provided framework aims to maximise re-usability of components within an application plug-in architecture. i

3 Acknowledgements Many thanks to my project supervisor, Marina De Vos, for taking the time to provide support and guidance throughout the project. ii

4 A Secure and Extendable Plug-in Framework implementing specific Design Patterns submitted by Dan Clark COPYRIGHT Attention is drawn to the fact that copyright of this thesis rests with its author. The Intellectual Property Rights of the products produced as part of the project belong to the University of Bath (see This copy of the thesis has been supplied on condition that anyone who consults it is understood to recognise that its copyright rests with its author and that no quotation from the thesis and no information derived from it may be published without the prior written consent of the author. Declaration This dissertation is submitted to the University of Bath in accordance with the requirements of the degree of Batchelor of Science in the Department of Computer Science. No portion of the work in this dissertation has been submitted in support of an application for any other degree or qualification of this or any other university or institution of learning. Except where specifically acknowledged, it is the work of the author. Signed iii

5 Contents Abstract... i Acknowledgements... ii Contents...iv Chapter 1: Introduction Aim Objectives Dissertation Structure...2 Chapter 2: Literature Review Review Introduction Software Design Patterns Development Languages UML Security & Licensing...10 Chapter 3: Analysis & Requirements Plug-in Model Background Use Case Design Use Case Analysis STRIDEs Analysis Functional Requirements Non Functional Requirements Platform Requirements Data Requirements Target & Development Platform...21 Chapter 4: Design Plug-in Model Plug-in Hierarchy Plug-in Interfaces Design Patterns Extendibility Deployment Events Exceptions Subsystems Static Class Representation Test Plan Summary Implementation Plan Coding Standard...35 Chapter 5: Phase Implementation Unit Testing Identified Limitations...43 Chapter 6: Phase Redesign Implementation Unit Testing Identified Limitations...50 Chapter 7: Phase 3 & System Testing Redesign...51 iv

6 7.2 Implementation Unit Testing System Testing...55 Chapter 8: Requirements Evaluation Functional Requirements Evaluation Non-Functional Requirements Evaluation Insufficient Requirements Design Process Summary Testing Process Summary...61 Chapter 9: Conclusions & Direction for Future Work Conclusion Future Work...64 Bibliography...66 Appendix A: Use Cases...68 A-1: Use Case Template...68 A-2: Use Case Summary...69 A-3: Use Cases...70 Appendix B: STRIDEs Analysis...78 B-1: Threat Identification...78 B-2: Threat Analysis...79 Appendix C: Requirements...80 C-1: Functional Requirements...80 C-2: Non Functional Requirements...85 C-3: Data Requirements...87 C-4: Platform Requirements...88 Appendix D: Framework Design Document...90 D-1: Plug-in Interface Specifications...90 D-2: Plug-in Hierarchy...91 D-3: Design Patterns...92 D-4: Deployment Modelling...97 D-5: Additional Models...99 D-6: Class Definitions Appendix E: Test Plan E-1: White Box Testing E-2: System & Integration Testing E-3: Performance & Security Test Cases E-4: Profiler E-5: Test Scenarios E-6: Test Oracle E-7: Test Plug-ins E-8: Stub Testing E-9: Unit Testing Appendix F: Implementation Details F-1: Implementation Plan F-2: Coding Standard F-3: License Schema Design F-4: Configuration Schema F-5: Configuration Forms F-6: Test Bench Applications Appendix G: System Testing Results G-1: Performance & Security Tests v

7 G-2: White Box Test Results G-3: Profiler Results G-4: Scenario Results G-5: Unit Testing Results Appendix H: Requirements Evaluation H-1: Functional Requirements H-2: Data Requirements H-3: Platform Requirements H-4: Non-Functional Requirements Appendix I: Application Code Exception Classes: PluginCommon.Exceptions Plug-in Interfaces: PluginCommon.Interfaces Repositories: PluginFramework.Repository PluginFramework Core: PluginFramework Licensing Subsystem: PluginFramework.Licensing Loader Subsystem: PluginFramework.Loader Support Classes : PluginCommon.Support vi

8 Chapter 1: Introduction 1 Chapter 1: Introduction Increasingly applications are being extended beyond their original design through the use of plugins, enhancing or providing additional functionality to the user or system. Plug-ins, also commonly referred to as add-ins, extend an existing application by adding new functionality or capabilities to the software system. Functionality is usually very specific, and provided as a shared library which the application can access, dynamically load and use at runtime. Figure 1.1: Eclipse Platform Architecture The use of plug-ins is becoming more diverse, both in terms of the application hosting the plug-ins and within the type of functionality the plug-ins offer. Eclipse, an Integrated Development Environment, was initially designed to be a development environment with support for other programming languages implemented through plug-ins (Figure 1.1). The environment now implements plug-ins for Database Connectivity, Telnet and links to online dictionaries. The Eclipse architecture has been redesigned and changed several times to allow such plug-in diversity. As applications become more diverse, the implementation of each plug-in system becomes further specialised towards the need of each application and often results in a customised design for each. Plug-in commercialisation has been difficult because of the problems surrounding secure distribution of plug-ins. This includes ensuring copyright infringement does not occur through providing copies of the plug-in to other application users, limiting the use of a plug-in to a specific timeframe, and ensuring authenticity of the plug-in. Current frameworks exist for specific platforms (Java from SUN Microsystems), but do not address the needs of specific types of plug-in, instead providing a generic abstract plug-in to cover all cases. Often this provides only a basis for what is needed by the implementing application, with the framework needing much extension and customisation before plug-ins can be developed and a standard between application and plug-in developer produced. Existing plug-in frameworks provide little structure and cohesion in relation to integration with applications, often implementing all classes within a single namespace and attempting to adapt to the needs of every application. The representation of plug-ins within existing frameworks and applications is not well defined in terms of collections and functionality; possibly due to the nature of the application and a requirement for only one type of plug-in. Plug-in models within applications form a pattern (a software design pattern or custom pattern) to which all plug-ins conform. A specific model implementing a specific pattern may be sufficient for one application and one type of plug-in, but under extension of an application, a plug-ins functionality may be extended beyond the realms of the model s original structure.

9 Chapter 1: Introduction Aim This project aims to develop a secure, licensable and extendable framework that also provides for structured plug-ins (based on identification of plug-in functionality and appropriate patterns) within a structured framework. The framework will allow for plug-ins and authenticity information to be provide d dynamically at runtime, as well as integrate to a host application without structural change. It is intended that a prototype framework be provided, forming a base framework for future extension, which will be tested and evaluated within a test-bed application representing expected use. 1.2 Objectives The design and implementation of the framework will be based upon the consideration of several objectives: The framework will provide loading functionality for plug-ins, checking and confirming a plug-in packages physical and structural validity, resolving any dependencies a plug-in may have, and ensuring the plug-in is available to the application through a repository A secure license and authenticity system base will be provided which will license individual plug-ins for use within the framework, ensure that a plug-in can be constrained to a specific time period, and has not been tampered with during transit from an authentic source Plug-in types will be identified and represented appropriately within the framework, involving the use of Software Design Patterns and collective patterns, representing differences in structure, use and functionality A sufficient and suitable API will be provided which allows the application developer or integrator to use and control the framework through a monolithic interface entity The framework will be extendable to future implementations, including new plug-in types and the use of unique framework identifier licensing, based upon the provided licensing entities within this framework, coupling a plug-in to a single installation 1.3 Dissertation Structure This dissertation is structured into 6 main parts, Chapter 2: Literature Review Chapter 3: Analysis and Requirements identifying plug-in and framework requirements Chapter 4: Design of the framework prototype Chapters 5 7: Three-Phase Implementation of Framework and framework testing Chapter 8: Requirements Evaluation Chapter 9: Conclusions and Directions for Future Work The Literature Review (Chapter 2, p.4) identifies appropriate previous work, design and development techniques which are reflected in Analysis & Requirements (Chapter 3, p. 14) and Design (Chapter 4, p. 22). The structure of the dissertation follows a structure similar to the chosen Software Lifecycle, shown in Figure 1.2.

10 Chapter 1: Introduction 3 Requirements Analysis Design Component Redesign Phase 1 Component Redesign Phase 2 Phase 3 & System Testing Evaluation & Conclusion Figure 1.2 shows the software development model chosen, and is split into Requirements Analysis, Design, Implementation & System Testing, and Requirements Evaluation & Conclusions. The software model used is based on the Waterfall Model [42], providing iterative implementation based upon the design. The model has been chosen for development as it provides a linear process, suitable for the prototype framework which is being produced. The implementation takes a 3-Phase approach: Figure 1.2: Software Development Lifecycle Model Requirements Analysis (Chapter 3) and Design (Chapter 4) detail the requirements, constraint and structural design of the system Phase 1 (Chapter 5) provides the initial software framework structure Phases 2 & 3 (Chapters 6 & 7) incrementally develop the framework components and include appropriate Component Re-design based on areas identified in a previous phase Requirements Evaluation (Chapter 8) evaluates the design and implementation against the Analysis & Requirements Conclusions & Future Work Directions (Chapter 9) outlining the contribution of the framework and appropriate future work Additionally, each phase contains Unit Testing covering the implemented components, as well as all previous phases unit tests. System testing is covered within the scope of Phase 3, with appropriate requirements evaluation and conclusions defined based on the unit tests in Requirements Evaluations (Chapter 8), and Conclusions & Future Work (Chapter 9).

11 Chapter 2: Literature Review 4 Chapter 2: Literature Review 2.1 Review Introduction Several areas within the scope of the project need to be investigated before a clear project focus can be established. More specifically, the areas requiring research mainly focus around the ideas given in the project title Software Design Patterns, Plug-in frameworks and security. Research into each of these areas will provide a clear path to follow and give a clear understanding of relevant systems, although no Secure Plug-in framework seems to currently exist. 2.2 Software Design Patterns Software design patterns [1] will be critical to the success of the project and the implementation of the architecture or framework. Software Design Patterns for software are commonly identified solutions to development problems, as well as accepted design techniques [5]. Software design patterns often abstract common software behaviour or structures, and provide well-defined class or interface association. Several different sets of patterns aimed at different system types exist [2], including Real Time Systems, Concurrency or Distributed Systems. They key idea of a Design Pattern from this resource suggests that A Design Pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a re-usable object oriented design. Software Design patterns have foundations laid deeply within experience [3] as well as experience with use. The well-known design patterns have been identified as common patterns within a given context. There is no pre-defined method for using patterns, and a patterns success is partially determined by it s time in use [4] Pattern Classifications Design patterns are classified into 3 types Creational, Behavioural and Structural [1]. Each type contains a subset of patterns which have related structures. In contrast to this, [5] uses a slightly different classification of the design patterns; which contrasts that of the standard approach [1], specifically aimed at the C# language. Here patterns are grouped by intent, the five classifications being Interfaces, Responsibility, Construction, Operations and Extensions. These classifications are aimed directly at the C# language, and may be re-visited during the design stage. Creational Creational design patterns are used to abstract the object instantiation process creating a level of independence between the composure of the objects being created. Two levels of creational patterns exist: those at the Class level, whereby Inheritance is used, and Object level whereby instantiation is delegated to another object. Creational Patterns move the emphasis from a fixed (compile time defined) set of actions or behaviours to smaller behaviours which can be brought together to define objects or creational classes. Creational classes hide the method of creation for the classes, and hide all concrete classes. As a result, it is possible for a creational pattern to control how and when a class gets instantiated which will contribute to some of the needs of the project at a later stage. Some of the key patterns [1][5] within this area are the Abstract Factory pattern, which does not specify concrete classes but can provides factories which create families or related objects, and the Singleton pattern which maintains a single instance of a class without the use of global variables or state.

12 Chapter 2: Literature Review 5 Structural Structural objects combine small objects to make larger structures within an application, or are related to the structure of the objects themselves. Several of the patterns within this classification are used as substitutions for objects, adapt between two different types of object or class to make them compatible, or compose primitive classes into larger classes composed of primitives. Patterns worth highlighting are the Adapter pattern [5], which is responsible for creating a compatible interface between two different classes of object, and the Façade pattern [1], responsible for creating a single interface point with a subsystem containing many classes. Behavioural Behavioural patterns describe object and class interactivity, including algorithms and inter-object responsibilities. Inheritance is used to distribute behaviour between classes, with the focus of behavioural patterns being mainly related to how objects interact, rather than the flow of control that is contrasted throughout the object interactivity. Examples of patterns within this area are Chain of Responsibility [5], Command [6], Interpreter, Iterator, Mediator [5], Memento, Observer, Strategy, Template and Visitor. An interesting pattern which is not well-known [7] has been called State Across a collection, whereby a collection object knows its state, which also applies to each member of the collection, whilst each member object also has its own state. This provides a collective state pattern for a group of objects. MVC The Model View Controller pattern [1], is representative of some UI Applications having a (possibly integrated) Data Model, Control Layer and Views (usually through Forms, Web or dynamic representations). The model layer combines two functions to provide the business logic and high level object interpretations, as well as the connectivity to an underlying data source. The controller manages events and synchronisation between the View and Data Model; and the view displays a representation of the data model itself. This model may represent a suitable model to define plug-in types within the framework Aspect Oriented Software Development Aspect Oriented Software Development (ASOD) is oriented around a series of entities called Concerns. An initial assessment of the ASOD language is provided in [8]. The idea of ASOD is based around separation of structure and function and is compared to the use of UML, which exhibits similar characteristics from a design perspective. The use of ASOD Concerns (specifically in HyperJ) [9] can be implemented as software design patterns in themselves, using a method known as Advanced Separation of Concerns [10][11]. The approach considered here avoids restriction of software evolution, often restricted by normal pattern implementation Software Framework A framework is set of classes for a specific class or application of software that make up a reusable design [1]. A framework can be customised by creating sub-classes of abstract classes from within the framework. It is suggested that a framework dictates the architecture of the application [1] which is not entirely within the direct focus of the project; this is something that should be avoided. Software frameworks can also increase productivity and reuse. This approach is backed [12], also indicating that frameworks utilise the 3 main objectives of Object-Oriented programming, namely being Polymorphism, Data Abstraction and Inheritance. In contrast, whilst frameworks come with high re-usability and modularisation [13], applications will increasingly become framework oriented which will lead to multiple frameworks being integrated which is difficult with poor framework design.

13 Chapter 2: Literature Review 6 A current plug-in framework for Java, the Java Plug-in framework [14], comes as a complete framework and class loader implementation; although this implementation does not scale well to languages other than Java due to the large reliance upon plug-in style and through only few base features being included. A method for documenting frameworks is described in [15], using an abstraction of the patterns used for the framework which help demonstrate purpose, use and the frameworks detailed design. This is referred to as the Pattern Language a set of design cookbooks used to identify object and class relationships Inheritance and Interfaces One important design consideration, alongside the use of patterns, is deciding, outside the scope of the patterns, whether plug-ins and resulting framework objects will be implemented by the user through either Inheritance, Composition, or as a set of interfaces. One method will be selected for use within the Design phase (Chapter 4, p.22) to implement the plug-in structure. Inheritance Class inheritance, also known as white-box inheritance or re-use, is a standard method of sub classing. A parent class may be either concrete or abstract in design; from which a subclass then extends the parent class to inherit the parent classes functionality and properties [1]. Sub-classed objects have a is-a relationship with the parent, such that the child class is a sub-type of the parent. Inheritance is often used to create a specialisation of class. Inheritance has the disadvantage of allowing the internal structure and properties to be modified or overridden by the subclass within some languages. Classically, sub classing is specified statically at compile time. One concern raised with this form of inheritance is that it breaks encapsulation [29], a major change in the parent class will cause the subclasses to require change. Additionally, restriction is based upon the classes a plug-in could extend under this model, such that the plug-in cannot extend any chosen pre-defined or custom class because of the need for static definition within a shared library. Composition Object composition, also known as black-box inheritance or re-use, is an alternative to inheritance. This functionality, which is usually performed at runtime [1], is achieved by composing simpler objects into more complex composed objects through the use of fields or properties. The internal structures of the objects are not exposed or available to the composing class. An instance of the composed classes is kept in the new sub-class, effectively creating a wrapper class around existing classes or objects. Interfaces Interfaces provide a slightly different mechanism by providing typing and polymorphism support. Polymorphism allows subtypes and interfaces to abstract concrete types with specific functions and properties to interact with an object. C# [2][6] allows the use of multiple interfaces for a class, but only one parent class to be extended through single inheritance (compared with multiple inheritance). Interfaces require classes to conform to certain structural specifications, requiring the implementation of methods and properties (if supported in the host language) [31]. Interfaces can be used as a form of polymorphism; an implementing class can be referenced using its interface. 2.3 Development Languages Development languages require careful choice whilst considering which language to implement the framework in. Languages must have support for software frameworks (2.2.3) and design patterns (2.2) through shared libraries, however must also be able to provide controllable cryptography and support a runtime plug-in architecture. Reflective (2.3.1) languages are key to providing runtime plug-in support.

14 Chapter 2: Literature Review Reflection Reflection [16] is the process by which a programs high-level structure can be examined and modified at run-time. Pluggability [17] is described as the ability to remove the static implementation within the source repository (fixed at compile time) and replace components of implementations with the reflection model and allow dynamic implementation at runtime. Reflection relies highly upon Meta-Information available within a (usually) compiled module. Reflection provides computational methods for extracting and analysing this Meta-Information within the provided module at runtime, and can incorporate the module into the programs highlevel structure. Reflection can be closely related to Aspect Orientated Software Development [17] Pluggability can be characterized as a separation of Concerns, discussed earlier. Reflection will provide a key role in the dynamic loading and in the provision of plug-ins; it will therefore be necessary for implementation to occur in a reflection supportive language. Reflective Languages Reflection is not supported by all languages to the extent that components (which may incorporate classes, other types, methods or resources such as embedded files) can be dynamically loaded and incorporated at runtime, however the following set of languages are suggested [13][16]: LISP (and variants) Java (through the Java Virtual Machine) [18].NET Framework [19] (including C#, VB.Net, and C++.Net) Python Ruby IO (Experimental) [20] Aspect Orientated Software development provides reflection through concerns in some aspects of the language; and can be considered under the scope of normal Java for development purposes. Two main languages will be considered for the scope of the project Java and C# Microsoft.NET Framework The Microsoft.NET Framework is an implementation of a Common Language Runtime (CLR), supported by various ECMA Standards [6]. The framework has a clear hierarchy defined within the standard: Assembly Module Type Method Figure 2.1: Assembly Structure The assemblies come in two forms, Executable and Library, the difference being that an Executable assembly contains static entry points and a Portable Execution (PE) header, indicating the presence of.net Executable Code. A library contains one or more modules, containing a series of classes and types organised into one or more namespaces within the application. Reflection is assembly based within the Common Language Runtime [26], not classed based. This has the advantage that if a high percentage of the classes within an assembly are being used, performance (in terms of Input Output) can be better than a class based reflective API. However if the converse is true, then performance can be severely impacted for large assemblies. Serialisation performance is discussed in [28], partially relevant to reflection in terms of dynamic type loading. One of the strongest advantages of the.net Framework CLR is the ability to utilise more than 20 differing languages [19]. Examples of languages include Pascal.NET, C#.Net, C++.NET (Managed and Unmanaged allowing mixtures of Native Code) and Ada.NET. This would allow

15 Chapter 2: Literature Review 8 the third-party plug-ins to be implemented in a constantly expanding number of languages, supported by the.net framework. C# is the most common language used supporting the.net Framework C#.Net C#.Net is described in Standard ECMA-334 [6], based on the standard developed by Microsoft. This standard demonstrates support for most of the CLR constructs and operations are supported from within C#, and through the demonstration of syntax and semantics within the document, it can also be seen that C# produces shorter, smaller source code than most other languages, e.g. VB.Net. C# also supports automated document creation, as detailed in the referenced standard above, which VB.Net does not [19]. Other languages, such as C++ support extra functionality such as Native (Unmanaged) code, the use of which will not be required for this project Mono.Net Runtime Implementation Project A cross-platform and architecture implementation of the.net Framework runtime is underway [21] which allows existing compiled CLR code for the.net Framework to be interpreted (run) on other platforms, aside from Microsoft Windows. The project, at the time of writing, has most of the features compliant with version 1.1 of the.net Framework, and supports many of the features of the.net 2.0 Framework Java Java, an Object Oriented Programming Language developed primarily by SUN Microsystems is a single language which makes use of a Java Virtual Machine (JVM) [18]. The Java Virtual Machine is a byte code interpreter specific to an architecture (and in some cases Operating System). This allows portability between operating systems as each Java Virtual Machine interprets the same compiled byte code specific to the operating system. Some of the features of the Java Class Loader, including lazy class loading and dynamic binding, aid performance within the Java Virtual Machine (JVM) [22]. Unfortunately, the performance gains cannot be utilised when using Reflection as the developer has runtime control over the class loading process, rather than the JVM. As such this will still require a separate implementation of a dynamic / lazy class loading system when loading plug-ins. The Java Core Reflection API, discussed in [17], gives an example implementation of type reflection within the Java language. [23] discusses the use of this Core Reflection API, and how to instantiate objects of unknown type (class) until runtime. Reflection is Java is working on a per-class basis, which can result in more IO activity long-term (throughout the execution of the program C++ Dynamic Class Loader C provides the ability to dynamically load libraries at runtime, through the use of the runtime linker (ld) functions. These series of functions and there use are described in [27]. C++ can dynamically load classes by utilising these functions and returning pointers to factory classes / functions within the runtime-loaded library. Solutions within the C++ realm require the use of function pointers at a low level, and rely upon operating system specific architectures in some cases. Similarly, the document above provides information on using the map keyword to create associative arrays to provide an easier front to the implementation. This approach does not appear easy to use, and may require implementation of memory management functions and other functionality not required in Java or C# Language Review Conclusion The references investigated above relating to Reflection and language implementations show that Java and C# are closely related in terms of their high level implementation, and both are relatively portable. In addition, the.net Framework structure provides a larger scope for the user to

16 Chapter 2: Literature Review 9 program in, which will be considered at the design stage of the project. Clear benefits in implementing the design within the.net Framework can be seen through the availability of reflection and multiple languages; as well as the ability to mix native and interpreted CLR code within a plug-in Runtime Plug-in Changes Runtime plug-in changes can be defined under the area of Hot Swapping. Run-time typing changes can be severely complex [24], and illustrates the complexities associated with changing a dynamically loaded type at runtime. A dynamically loaded class at runtime, used by the application, cannot just be removed arbitrarily, the type or class must first be disused by the application. There are 3 approaches for changing code and types at runtime to overcome some of the typing problems [25]: Version Barrier Types provided by a library cannot be redefined while in use in the program Passive Partitioning If a new library replaces an old one, the two value types concerned must be interoperable in a type safe manner. All new instances of types are created from the new library. Global Update - Old types (from a removed library) can no longer be created, but still exist until garbage collected before the library is removed from memory. New libraries that replace this type may be instantiated during this process. Not all of these approaches are appropriate for the purpose for example it will not always be the case that a plug-in is removed and replaced with a later version at runtime, which this method is targeted at; it is likely that a plug-in will either be removed or added with no relation to other plugins. 2.4 UML UML, the Unified Modelling Language [30], is a class and object modelling specification language which allows the designer to express relationships between classes, methods, packages and subsystems as possible solutions before, during and after implementation [2]. UML will be used throughout the Analysis & Design chapters (Chapters 3 and 4) UML Use Cases Use case diagrams (Figure 2.2), consisting of Actors and Use cases, represent stakeholders associated with the system, the actions and sequences of actions in which interaction with the system occurs. Use casing occurs early in the design process; mainly being used as an analysis technique for existing or similar systems, or it is used to identify a market gap and start to profile a process. Use cases are useful for deriving requirements for a system, by considering potential functions that a user performs within the system. They also help consider test cases for the system, creating test scenarios. Figure 2.2: Example Use Case Class & Association Diagrams Class Diagrams [2] show the classes within the system that is being, or has been, designed. The class diagram in itself does not show any association initially; associations are added to the diagram to illustrate relationships between the classes. This type of diagram does not show sequences or paths through the classes or anything related to the state of the system, but instead show class attributes,

17 Chapter 2: Literature Review 10 operations and properties relevant to the class and system, including Inherited and Extended classes. This is useful to define the structure of the framework, and associated functions and fields within each class Class Collaboration Class collaboration diagrams help understand the group of objects in each use-case realisation [2]. The diagrams show how the objects work together (a simple interaction) to produce the high level functionality expected of the system. Use Cases are mixed with the collaboration diagrams, which can be extended informally to show basic messages and signals being passed between the objects Interaction Sequence Interaction sequence diagrams are a partial alternative to collaboration diagrams as well as an extension to them [2]. Interaction diagrams record the dynamic aspects showing how objects interact, but unlike collaboration diagrams, sequence diagrams have specific focus of time and how the interactions occur over time. An interaction sequence diagram is listed with Objects against a timeline. As the timeline progresses, interactions between the objects are detailed. 4 message flows are given: Procedural (Synchronous), Flat (unknown Synchronisation type), Asynchronous, and Return (from message) Activity Activity diagrams indicate workflows within the system; including workflows between use cases [2]. They can serve two purposes - to determine high-level requirements within the application domain, or to complement the collaboration and sequence diagrams Mapping Patterns to Diagrams Design patterns can be represented in UML and mapped into systems [2], which will constitute a large part of the design of the project. Design patterns can be represented in UML mainly through the use of three of the modelling diagrams Collaborations, Class Diagrams and Interaction Diagrams. Figure 2.3: The Singleton Pattern in UML The collaboration diagram illustrates the role and class relationships at a high level; whilst the class diagram represents the structure of the design pattern within the model itself; which can then be further explained by the use of an interaction diagram to show the interaction between classes. Collaborations diagrams are extended in terms of template collaborations to also list the class roles involved in a specified pattern; which are listed with appropriate notation next to the collaboration name. 2.5 Security & Licensing Security and Licensing are outlined in the objectives as being central to providing plug-in authenticity and verification. The use of encryption and license management need to be sufficiently considered to protect plug-in copyright and authorised use. State charts can also represent system state, and an appropriate point can be taken on the state chart allowing identification of whether the system is secure or not at that point.

18 Chapter 2: Literature Review STRIDE Analysis Model The STRIDE Model [43] provides a process which identifies and analyses threats in a two stage process. STRIDEs identifies 6 threat types: Spoofing Identity, Tampering with Data, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. The two phases of the STRIDE model provide a platform for identifying threats that the framework or host application may be the target of. The identification phase lists potential threats within each area and the analysis phase categories each threat from 1-10 based upon potential damage and 1-10 for the effort to mount the attack. A risk is sufficiently calculated based on damage divided by effort, giving a risk category from A higher risk classification gives a high-risk threat, and must be addressed. The model will be sufficiently used during the Analysis & Requirements phase Encryption Encryption will be required within the project for the security and licensing core parts as it is widely accepted that however the licensing and security process is implemented, secrets such as undisclosed status codes communication protocols can be disassembled or cracked with ease. The resulting framework from this project will need to ensure that a companies Intellectual Property Rights are upheld preventing casual plug-in sharing and copying. Digital Rights Management Digital Rights Management (DRM) [41], is normally aimed at accessible digital content via electronic means. Digital Rights Management empowers the supplier (or licensor) of the copyrighted product (in this case a plug-in) to control its use. Whilst DRM in it s suggested form is not viable within this project (more specifically as content is not being streamed, rather functional components are being licensed), the use of license purchase through a Clearing House model does provide the advantage that licensing and security can be centralised; with the obvious tradeoffs that comes from requiring connectivity with the centralised system. Figure 2.1: Digital Management Rights Model File Encryption Two types of file encryption algorithm are discussed within this section; Symmetric, a cryptographic algorithm which uses both the same key(s) for encryption and decryption, and Asymmetric, which operates on a Public & Private secret key system [32]. Symmetric Symmetric encryption schemes [32] consist of a map: E: M K C, such that for each k K the map E k : M C, m a E( k, m) is invertible (where m M are the plaintexts, and C is the set of cipher texts).

19 Chapter 2: Literature Review 12 This infers the use of symmetric keys which should be known to both the application (i.e. the plugin framework) and the generator (the company generating the licenses for the framework). Examples of Symmetric systems include DES (Data Encryption Standard), Triple DES (a more secure version of DES) and AES (Advanced Encryption Standard). Asymmetric Public Key cryptography systems operate on two keys, the first being a secret private key, retained by the user which can be used for decryption, and the second being a public key which is distributed to other users in a potentially unsecured manner for encryption only. The public key can be distributed to any user requiring the ability to encrypt plaintext to send to the user holding the private encryption key. In this case, the decryption key could be known by the framework and the public key known by the authoritative company responsible for verification and testing. Example implementations are RSA (Rivest, Shamir, Adleman) and ElGamal s (based on exponents) Encryption. XML Encryption XML Encryption, as discussed in [39] provides an alternative to sending encrypted data to the customer and does not rely on Clearinghouse technology as above. The Document Object Model (DOM) is an accepted XML document structure, defined by the World Wide Web Consortium, representing documents in an object-oriented structure. Preliminary testing of the technology and a prototype is provided, although the paper suggests that Though DOM makes it possible to manipulate an XML document easily, it is commonly accepted that DOM has higher costs in time and space than other APIs. A similar idea with a different approach in the paper [40] is suggested, where a set of credentials provides access to specific information domains within the document. The document itself is encrypted with different sub-sections being encrypted under different keys; the main idea being that an encrypted XML document can be selectively disseminated, based upon the key supplied. Whilst both of these papers suggest very different approaches, they both suggest the use of algorithms not currently widely supported within most applications, limiting application portability. File Identification Some programming languages will provide their own identification of classes, packages or assemblies (or other packaging mechanism for which the plug-ins will be deployed). However, consideration of a generic identification mechanism should be researched in the event it is required during the design stage. Hashing Functions are described in [32] to create Message Digests which are responsible for mapping an arbitrary bit string to a finite bit string of length n. The hash function is one-way by design; but various implementations have been shown to be breakable. [32] discusses this in detail, detailing MD5 as one of the latest algorithms to provide a unique digital fingerprint for a file State Management The two types of state design of interest here are localised (looking at state interaction between objects) and object level (looking at the state of the objects as a whole). Two very similar, yet slightly different state transition diagrams (also known as state chart diagrams) are provided by [2][33]. State chart The idea of a state chart diagram, used in UML, is to allow modelling of the state of an object and the legal flow of states throughout a system. The diagrams describe class behaviour at the independent class level rather than an adaptation of the interaction diagram (below), or collaboration diagram, which models the state of the objects and classes working together. System State changes are driven by events, both internally and externally [2], which can pass arguments

20 Chapter 2: Literature Review 13 containing event parameters and values, which are in themselves objects. In a state chart diagram, states are represented in rectangular boxes, and each chart is accompanied by a start and end state. State Transition Diagrams The notion of a state transition diagram does not differ much from the notion of a state chart; other than the inclusion of actions based upon source rather than actions based upon state (from State chart). In this slightly contrasting approach provided in [33], an activity is specified depending on whether entry or exit of the state occurs (as opposed to a unified set of activities while in the state). This approach is taken as a modification to the [34] approach, based on extensions to the finite state machine diagrams. Furthermore, it is suggested that object level state can be represented by a rectangular box on an object lifeline [2], [35].

21 Chapter 3: Analysis & Requirements 14 Chapter 3: Analysis & Requirements 3.1 Plug-in Model Background Applications currently often adopt a customised approach to implementing a plug-in model within an application. This approach often results in a class, module or component within the application providing a loading and storage mechanism for the plug-in. The plug-in results in extended functionality or additional types for the application, common examples are data providers, media player enhancements such as visualisations and effects, and additional brushes for photo editing applications. Figure 3.1: Current Application Plug-in Integration A high-level abstraction of this model is shown in Figure 3.1, where it can be seen that plug-ins are initially isolated from the application in terms of a handling module. This may continue to be the case in some circumstances whereby the plug-in abstracts functionality and provides it to the application through generic casting mechanisms. Alternatively, the plug-in interface may have been customised to such an extent that it can be passed directly to the application for use, and handled as a native type. Plugin Application Plugin Plugin Figure 3.2: Plug-in Integration with Intermediate Framework Figure 3.2 shows a new model with the plug-in handling component removed from the application. The framework decouples the application from the plug-in, allowing the framework to be re-used in other applications. Initially this model (Figure 3.2) seems to provide low-coupling and therefore reduce the effectiveness of plug-ins, however this is not necessarily the case, as it is sufficient to allow the application to continue to define customisations and additional functionality not present within the framework by extending the plug-in model or framework itself. This model allows the framework to be included by importing namespaces into the application, and by calling appropriate load and access functions, allows the application to control the loading and use of plug-ins. The application can be appropriately recompiled and re-use the same framework and associated plug-ins. The framework is also responsible for providing a shared library for use by the application and plug-ins. Extendibility is ensured through the framework by maintaining an interaction level between the application and plug-ins, which the framework will be able to facilitate. The application, through

22 Chapter 3: Analysis & Requirements 15 this model, can still maintain direct communication with plug-ins with additional functionality provided by developing interfaces known both to the application programmer and the plug-in developer. Providing extensions through the proposed model will ensure that security is maintained, with the application being kept isolated from plug-ins until validation of plug-in licenses has occurred. C# Interfaces (Section 2.3.3, p.6) have a simple extension model, such that a base interface can be provided, and appropriate extended interfaces can be defined. This ensures that any extended plugins still implement the base plug-in interface. The design provides appropriate extendibility information (Section 4.5, p.25). 3.2 Use Case Design Use Cases (Section 2.4.1, p.9) are used to derive functional requirements by looking at user interaction with the system, and the way users will use the system to perform different functions. The use case template used for describing use cases provides focus on the following: Identifying the primary actor responsible for triggering the use scenario Scenario Goal associated with the framework and associated Stakeholders Identifying steps to allow the scenario to be successful Additionally, every scenario will be given a unique scenario name and assigned a level, depending on how the use case relates to the system. Three levels will be sufficient to distinguish between scenario types, taken from Summary Goals, User Goals and Sub functions. Actor End Application User Licensor Plug-in Developer Application Parent Company 3 rd Party Plug-in Supplier Framework Profile The parent company target user, who will use the final application An entity, associated with the Parent Company, who validates plug-ins for use within the framework and produces an associated license An entity, the same as or associated with, the 3 rd Party Plug-in Supplier A Software entity, used by the end user, containing the Framework The company responsible for producing and deploying the Application containing the Framework An entity, not necessarily associated with the Parent Company, developing plug-ins for the Application The system being designed, to be incorporate in one or more Applications Table 3.1: Actor Profiles The development of the framework will reference 7 user profiles, shown in Table 3.1. Each of these pro files gives a different perspective on the framework, and also includes associated entities (the framework itself and the Parent Application). The template used to generate the use cases is shown in (Appendix A-1, p.68).

23 Chapter 3: Analysis & Requirements Use Case Analysis A set of use cases is provided in Appendix A-3 (p.70) The high level set of functional requirements for the system can be generated from the use cases, shown below. Figure 3.3: Summary and User Goal Level Use Cases The requirement is provided, and sub-bulleted points provide use cases responsible for the requirement: 1. Plug-ins should be able to be loaded by the user and used by the application, such that a plug-in can be downloaded or ed to the user and the path passed to the application for it to be loaded 1.1. User Requests Application Load Plug-in 1.2. Load Plug-in during Application Use 1.3. Application enumerates Plug-in list 2. The framework should integrate with existing software with no structural change, such that the framework can be added to any existing compatible application 2.1. Parent Company adds Framework to Application 2.2. User causes Application Start-up 3. A framework manager class should be provided to provide a central API access point, so that the application has full control of the framework from a single class rather than control distributed over many classes 3.1. User obtains plug-in 3.2. User requests plug-in unload 4. Plug-ins of different types should be able to be loaded at runtime, whilst the application is running. This will allow the application to extend itself dynamically as determined by the plug User obtains plug-in in definition 4.2. Application enumerates plug-in list