A Meta-Object Protocol for Secure Composition of Security Mechanisms Alexandre M. Braga*, Ricardo Darab† and Cecília M. F. Rubira‡ Abstract. This paper outlines a Meta-Object Protocol for secure composition of cryptography-aware meta objects. This MOP intends to be language independent so that it can be easily constructed over simple facilities for meta object composition. We have partially implemented the MOP described below over a free, reflective flavor for the Java programming language. The interesting design issues of this implementation are discussed below.
1.
Introduction
In many applications, cryptography-based security is a non-functional requirement; that is those requirements related to how well an application accomplishes its purpose. Security, distribution, persistence, and fault tolerance are other examples of non-functional requirements that are usually independent of application functionality. Cryptography-based security services [iso98] (confidentiality, authentication, data integrity, and non-repudiation) are usually implemented upon basic security mechanisms (encryption, digital signatures, and other types of electronic fingerprints like authentication codes and integrity checksums). The composition of mechanisms is often a means for achieving more complex security requirements [BDR99b]. Computational reflection in the object model [Mae87] can be used to implement the security requirements in a transparent and non-intrusive manner, that is, without interfering in application's original structure. The reflection mechanism encourages modular descriptions of software systems by introducing a new dimension of modularity: the separation of base-level and meta-level computations. Reflection allows the creation of meta objects that implement the cryptographic mechanisms and that control and extend the behavior of application objects located at the base level. This paper is organized as follows. Section 2 describes rules for crypto service composition. Section 3 gives advice on how to avoid naive compositions. Section 4 discusses MOP’s additional features. Concluding remarks are in Section 5.
2.
Secure Composition of Meta Objects
The meta-object protocol used by this experiment [OGB98,OB98a] allows dynamic meta level reconfiguration through both replacement and composition of meta objects during program execution. A special meta object, called a composer, is responsible for combining meta objects’ behaviors. A composer delegates services to its components according to a well-known semantics. For example, when components are stored on a list, a composer can use sequential delegation. Although this feature makes protocol design extremely flexible, it is potentially harmful for securityaware meta objects. A policy for meta level reconfiguration should be adopted in order to avoid naive replacements as well as incorrect combination of cryptography-aware meta objects. The cryptographic mechanisms for data integrity, authentication, and digital signatures are mutually exclusive and relate to each other as follows: authentication fingerprints support both sender (origin) authentication and data integrity; digital signatures support not only non-repudiation, but also sender authentication and data integrity. Encryption is orthogonal to other cryptographic
[email protected], CPqD – Center for Research and Development in Telecom, Brazil.
[email protected], State University of Campinas, Brazil. ‡
[email protected], State University of Campinas, Brazil. * †
mechanisms and can be combined to any of them. The ways cryptography-aware meta objects are composed are limited by the above relationships. We have identified two kinds of composition [DBR99a]. A (simple) composition permits orthogonal meta objects to compose their behaviors sequentially. On the other hand, a selective composition allows composition of mutually exclusive meta objects in such a way that when one is turned on, the others are turned off, similarly to a multiplex.
Authentication Checksums
Integrity Codes
Digital Signatures
Simple Composition
Selective Composition
Encryption
1
3
3
3
1
1
Authentication Checksums
3
1
1
2
1
1
Integrity Codes
3
2
1
2
1
1
Digital Signatures
3
1
1
1
1
1
Simple Composition
1
1
1
1
1
1
Selective Composition
1
1
1
1
1
1
Candidate
Encryption
Configuration
When a cryptography-aware meta object is asked for reconfiguration, (that is, when a change in meta object’s behavior is requested) it can follow either a conservative or a non-conservative approach. In the conservative way, the weakening of cryptographic features on an object's meta configuration is not allowed. In this approach, the meta configuration can either remain the same or be self-strengthened. In the non-conservative approach, the weakening of meta configurations is also allowed. We have adopted a conservative approach for meta-level reconfiguration, so that a meta object for signature cannot be replaced by neither an authentication-aware meta object nor an integrity-aware one. Similarly, an integrity-aware one cannot replace an authentication-aware meta object. Meta objects of the same type cannot replace each other either. For example, similar meta objects for encryption, based upon different algorithm implementations, cannot replace each other. On the other hand, a single encryption-aware meta object can compose itself with any meta object for signature, authentication or integrity.
Current Configuration
Table 1: Summary of Reconfiguration policy Applicability
Table 1, extracted from [Bra99b], summarizes the contexts in which the four rules for reconfiguration, stated below, are applicable. For instance, the current meta configuration, implementing encryption, cannot be replaced by another of the same type (the candidate configuration), so the intersection cell marks rule 1. On the other hand, a current meta configuration for signature, when asked for reconfiguration, can compose itself with an encryption meta object, rule 3. This minimum set can be easily extended to support more interesting policies. Starting from the most conservative, the rules we propose are the following: 1. The current meta configuration is not replaced. 2. A selective composition of both current and candidate configurations replaces the current one. 3. A composition of both current and candidate meta configurations replaces the current one. 4. The candidate meta configuration replaces the current one.
3.
Avoiding Naive Compositions
Another relevant issue in secure composition of cryptography-aware meta objects is the order in which cryptography mechanisms should be composed to each other (as well as to other nonfunctional aspects, such as distribution, fault tolerance, and persistence). Transparency in the order of composition should be achieved and preserved as a rule of thumb. Unfortunately, cryptographic mechanisms impose very strong constraints on their composition. The misplacement of a cryptography transformation, relating to either cryptographic functions or other requirements, can weaken security in the whole scheme. An interesting and more detailed example related to fault tolerance and security can be found in [FP96,SW96]. The composition of both encryption and integrity checking can be implemented by computing integrity codes either before or after encryption. In the first case, transmission errors can be detected before decryption. In the second, when the data structure is unknown, small transmission errors can only be detected after both decryption and integrity verification. Similarly to the previous case, composition of both encryption and authentication mechanisms can be implemented by computing authentication codes before or after data encryption. However, if secret-key cryptography is used for encryption, then most of authentication codes are redundant and useless, except for granting an extra degree of integrity checking. A detailed explanation on both secret- and public-key technologies, ass well as other cryptography-related topics, can be found in [MvOV96,Sch96]. As before, the composition of encryption and digital signatures can also be implemented in two different ways, according to the order in which encryption and signature are computed over data. When encryption is applied first, verification of signatures can only be done after decryption, since, in principle, signatures have no apparent structure. This apparent difficulty can be easily overcome by attaching to the encrypted data a known header before sign it. On the other hand, if a signature is applied over non-encrypted data, then signature verification must expose the encrypted content. This may be unacceptable when different parties are responsible for decryption and signature verification. Usually, a better strategy is to sign an integrity code of data instead of data itself. However, the combination of weak integrity codes and signatures can potentially decrease the security of digital signature protocols. Our implementation [BDR99a] applies encryption before any other cryptography related transformation, so that we can always verify fingerprints before decryption. Cryptographic services are usually non-functional requirements related to communication and persistence requirements, but orthogonal to these. The tower of meta objects can be as high as the number of non-functional requirements. The decision concerning which position cryptography will occupy in this tower is not simple. Aspects such as requirement composition or chaining must be considered very carefully. For instance, since cryptography is orthogonal to persistence and communication, which can, in turn, stay at meta-level, cryptography should be accomplished at the meta level of these, that is, at a meta-meta level. However, if fault tolerance (replication) is another requirement, it can be accomplished either above or below encryption [FP96,SW96].
4.
MOP’s additional features
The a-priori negotiation, concerning both usage of and agreement on cryptographic algorithms as well as the generation, exchange, and storage of keys, may or may not be handled at the meta level. This decision depends on the degree of control over the cryptographic services the application programmer intends to have. For instance, application programmers may be interested on what kind of service is being used at a given moment, maintaining the ability of turning channel’s security on and off. The ability to manage distinct simultaneous instances of keys, and keep track of channels with different degrees of security, determines the final number of active meta objects. How easily
this task can be accomplished depends on the power of MOP’s composition mechanism. There are situations in which the result of an (intercepted) operation should be encrypted, authenticated or verified for non-repudiation. How easily this can be accomplished also depends on MOP’s flexibility on offering features for both interception and modification of operations’ results. For implementation’s simplicity, we have attached meta configurations to objects' classes, which had their static (class) methods’ arguments, as well as its results, intercepted and transformed [BDR99a]. There are at least two approaches for adding cryptography-based security to third-party components, depending on whether MOP is applied statically or dynamically: (i) performing behavioral changes dynamically over executable code; in this case, a hook (well-known) interface must be available; (ii) working over source code, potentially performing some preprocessing. On the other hand, when both meta and base levels are co-designed, a meta level can work as an objectoriented framework and the inversion of control, which characterizes such frameworks, takes place. We have used our small security framework for adding some cryptography features do a third-party software, achieving interesting, different degrees of transparency for different modules of the system, ranging from completely transparent (without recompilation) addition to ad hoc, highly intrusive addition of security [Bra99a].
5.
Concluding Remarks
Practice has shown that high coupling, due to use of explicit references, among cryptography-aware objects and functional objects leads to reduction of both reuse and understandability. Specific applications, specially those in which cryptography plays a non-functional role, could benefit from a combination with computational reflection mechanisms in a way that both readability of application code and component reuse are increased. The composability of cryptographic mechanisms among each other, as well as with other non-functional requirements, is also facilitated by a meta-object protocol in which meta objects could be easily composed. We have partially implemented the features described above over a free, reflective variation for the Java programming language and have obtained some interesting results [Bra99a,Bra99b].
5. References [BDR99a] Alexandre Melo Braga, Ricardo Dahab, and Cecília M. F. Rubira. A Meta-Object Library for Cryptography. Technical Report IC-99-06, Institute of Computing, State University of Campinas, 1999. Campinas, São Paulo, Brazil. [BDR99b] Alexandre Melo Braga, Ricardo Dahab, and Cecília M. F. Rubira. Composing Cryptographic Services: A Comparison of Six Cryptographic APIs. Technical Report IC-99-05, Institute of Computing, State University of Campinas, 1999. Campinas, São Paulo, Brazil. [Bra99a] Alexandre M. Braga. Reflective MiMi: A Reflective Security Wrapper to the MiMi E-Commerce Tool. Technical Report TUV-1841-99-12, Technical University of Vienna, Information System Institute, July 1999. [Bra99b] Alexandre M. Braga. Análise Comparativa e Proposta de Extensão à Arquitetura Criptográfica Java. Master Thesis, Institute of Computing, State University of Campinas, 1999. Campinas, São Paulo, Brazil. [FP96] Jean-Charles Fabre and Tanguy Pérennou. Friends: A Flexible Architecture for implementation of Fault Tolerant and Secure Distributed Applications. In Andrzej Hlawczka, João Gabriel Silva, and Luca Simoncini, editors, Second European Dependable Computing Conference (EDCC-2), volume 1150 of LNCS, pages 3-20, Taormina, Italy, October 1996. Springer. [iso98] Information Technology - Vocabulary – part 8: Security. ISO/IEC 2382-8, 1998. [Mae87] Pattie Maes. Concepts and Experiments in Computational Reflection. In OOPSLA’87, volume 22 of ACM SIGPLAN Notices, pages 147-155, December 1987.
[MvOV96] Alfred J. Menezes, Paul C. van Orschot, and Scott A. Vanstone. Handbook of Applied Cryptography. CRC Press, 1996. [OB98a] Alexandre Oliva and Luiz Eduardo Buzato. Composition of Meta Objects in Guaraná. Technical Report IC-98-33, Institute of Computing, State University of Campinas, September 1998. Campinas, São Paulo, Brazil. [OGB98] Alexandre Oliva, Islene Calciolari Gracia, and Luiz Eduardo Buzato. The Reflective Architecture of Guaraná. Technical Report IC-98-14, Institute of Computing, State University of Campinas, September 1998. Campinas, São Paulo, Brazil. [Sch96] Bruce Schneier. Applied Cryptography. John Wiley and Sons, 2nd edition, 1996. [SW96] Robert J. Stroud and Zhixue Wu. Using Metaobject Protocols to Satisfy Non-Functional Requirements. In Chris Zimmermann, editor, Object-Oriented Meta-Level Architectures and Reflection, chapter 3, pages 31-52. CRC Press, 1996.
