A Security Mechanism For Component-Based Systems

1. The Product-Line Architecture Research Group Empirical Software Engineering Lab A Security Mechanism For Component-Based Systems Mark Grechanik, Dewayne E. Perry, and Don Batory

2. Component-Based Systems • They are built from various components based on some existing architecture • Components and program clients may be located on different computers and interact via some component infrastructure • A Java program client invokes methods of some Enterprise JavaBean (EJB) interface via an EJB infrastructure • A C++ program invokes method of a CORBA-based component via a Mico CCM infrastructure The University of Texas at Austin

3. Large-Scale Component-Based Systems • A generic representation of component-based systems is a clique • Circles mean components of a software system • Arrows mean channels by which messages that invoke interface methods are passed We need a scalable security mechanism for large-scalecomponent-based systems! C1 Cn C2 … C3 C4 The University of Texas at Austin

4. Partitioning Component-Based Systems • Enterprises partition their computing environments based on different criteria to secure the flow of information C1 Cn C2 … C3 C4 The University of Texas at Austin

5. Partitioning Component-Based Systems • Enterprises partition their computing environments based on different criteria to secure the flow of information • Geographic locations of departments • Security policies regulating the flow of information between different departments • VPN uses a protocol called IPSec that encrypts application messages on the IP level • Unencrypted communications between applications within the same security partition The University of Texas at Austin

6. A Challenge • A company purchases and installs two or more applications produced by competing companies within a single security partition and even on the same computer • These applications use the same generic components • It is possible for these applications to interfere with one another by means of using these generic components • Competing companies often demand that their applications should run in their own security partitions • Prevent other competing applications from eavesdropping on them to understand their interworkings The University of Texas at Austin

7. What About VPN? • Installation and configuration of a VPN is a serious technical exercise • Once installed it is rarely reconfigured • Reconfiguring VPN every time a different application is installed and run is impractical • When a component-based system should be partitioned within a single computer, VPNs and similar security systems cannot even be used The University of Texas at Austin

8. How to Secure a Partitioned Component-Based System? • Programmers add separate security mechanisms (e.g., encryption) to existing applications • Invocations of methods exposed by component interfaces are encrypted and decrypted The University of Texas at Austin

9. Complexity of Security Solutions • Encrypting and decrypting communications even for small-size computing systems results in a significant performance drawback • A fundamental problem of applying standard security mechanisms based on encrypting algorithms to component-based systems is that the resulting secure systems are nonscalable The University of Texas at Austin

10. The Problem • How to adapt security partitions to business requirements without affecting the scalability and while preserving security properties of the resulting component-based system • Our goal is to provide a security mechanism that enables users to change partitions dictated by the business needs dynamically and securely The University of Texas at Austin

11. Software Fortresses • Software fortresses is an approach for modeling large enterprise systems as sets of self-contained entities • Each entity is called a fortress • It makes its own decisions about the underlying platform, data storage, and security mechanisms and policies The University of Texas at Austin

12. Software Fortress Architecture • Software fortress architecture is an enterprise architecture consisting of a series of • self-contained • mutually suspicious • marginally cooperating software fortresses • These fortresses interact through carefully crafted and meticulously managed treaty relationships • All communications that originated inside a fortress and are designated to entities located inside the same fortress are approved by default The University of Texas at Austin

13. Security of Software Fortresses • The walls of a fortress are collectively called a security perimeter of the system inside a fortress • All communication requests come into the fortress through approved channels called drawbridges • Treaties are the formal agreements between fortresses that define how fortresses work together The University of Texas at Austin

14. Our Hypothesis • In component-based systems a large percentage of components service requests of clients within the same security perimeter • Based on multiple observations • GUI components and their clients are almost always located within the same security perimeter • In general, components and their clients are rarely separated by security boundaries The University of Texas at Austin

15. Empirical Study • We analyzed the source code for medium to large-scale projects that were developed in seven different companies by different groups of engineers • We partitioned the project by security perimeters identifying each software fortress • Then we calculated the percentage of the channels that do not cross any security perimeter The University of Texas at Austin

16. Clustering The University of Texas at Austin

17. Linearity The University of Texas at Austin

18. Summary of Our Empirical Study • The percentage of channels that are located within security perimeters is high and close to 80% on average • The correlation coefficient for the dependency between the number of channels and the percentage of these channels that do not cross any security perimeters is 0.75 • It suggests a strong tendency for components to interact with larger percentage of their clients within the same security perimeters as the number of their clients grows • These experimental results effectively confirms our hypothesis that a large percentage of components service requests of clients within the same security perimeter The University of Texas at Austin

19. Our Solution • We explore the knowledge about the locality of components within a software fortress • If two interacting components are located within the same security perimeter then we do not need to allocate keys and use encryption to secure their interaction • We explore the key pattern of interactions between components via a component infrastructure • We only allocate one key for each fortress to communicate with component infrastructure • We offer a protocol that ensures the consistency of communications between components The University of Texas at Austin

20. F1 A Star Topology Fm The number of fortresses, m is much smaller than the number of components, n m << n The University of Texas at Austin

21. Core Strategy • Instead of creating a key to enable secure communications between each possible pair of components, let’s utilize the star topology of the component deployment model • Since each component and its clients interact with the component infrastructure directly, we create a key for each fortress thereby reducing the number of keys to nf instead of nc The University of Texas at Austin

22. CASSIA • Component Adaptive Scalable Secure Infrastructure Architecture (CASSIA) is a comprehensive scalable security solution for large-scale component-based applications • Basic idea: if two communicating components are located within the same security perimeter, then no encryption and decryption of communications are necessary The University of Texas at Austin

23. CASSIA Algorithm and Configuration <fortress name=”A”> <component ID=”1”/> <component ID=”2”/> </fortress> <fortress name=”B”> <component ID=”3”/> </fortress> <treaty> <fortress name=”A”/> <fortress name=”B”/> <protocol>OpenSSL<protocol/> </treaty> CASSIA( Ci, Cj, boolean encrypt ) Begin Fi = Fortress( Ci ); Fj = Fortress( Cj ); if( Fi != Fj ) then Tij = Treaty( Fi, Fj ); Pij = Protocol( Tij ); if( encrypt == true ) then encrypt( Ci, Cj, Pij ); else decrypt( Ci, Cj, Pij ); endif endif End The University of Texas at Austin

24. Implementation • We implemented the CASSIA adaptive algorithm for Mico CORBA Component Model (CCM) • MICO recursively expands to MICO Is CORBA • MICO has been branded as CORBA compliant • OpenSSL is used as a low-level cryptographic protocol • We maintain a configuration table within Mico CCM in an XML format • Keys are located in a protected storage and maintained using our protocol The University of Texas at Austin

25. Case Study • We implemented the Pet Store application for MicoCCM based on the Java Pet Store demo that is a sample application developed by the Java BluePrints program at Java Software, Sun Microsystems • We produced five implementations of the Pet Store application • Its first implementation consisted of twelve components • We increase the number of interfaces in each subsequent implementation approximately twice • We tested each implementation four times with different number of channels crossing security boundaries The University of Texas at Austin

26. Throughput of CASSIA The University of Texas at Austin

27. Average Time Per Transaction The University of Texas at Austin

28. Speedups With CASSIA The University of Texas at Austin

29. Overhead of CASSIA The University of Texas at Austin

30. Conclusions • We conducted an empirical study where we found that 80% of interactions between components and their clients occur within the same protected security boundaries • We successfully implemented CASSIA, a novel scalable security mechanism for component-based systems • We conducted CASSIA’s performance evaluation case study that confirms its scalability and showed its very small overhead • We proposed and implemented a Secure COmponent Protocol (SCOP) that incorporates our scalable security mechanism into a component infrastructure The University of Texas at Austin