Security Trust for the Grids Syed Naqvi IT

Security & Trust for the Grids Syed Naqvi IT Security Group naqvi@enst. fr 22 November 2005 Security & Trust for the Grid

From tele-communicare to Telecommunications www. enst. fr 22 November 2005 Security & Trust for the Grid 2

In 1904 … Edouard Estaunié “J'ai dû ajouter un mot nouveau à un glossaire déjà trop riche …” “I needed to add a new word to an already too rich glossary …” Courtesy of Bibliothèque Nationale de France

Security Research Projects … European Projects (IST & ITEA) National (RNRT) – – – – – ICARE : Trusted Infrastructures, PKIs SWAP : WAP Security MMQo. S : Security, Mobility and Qo. S ANAIS : Security of Professional Mobile Radio INFRADIO : Security on a campus and of infospheres in meshed networks EPIS : Smart card security E 2 E with IPv 6 RESODO : Security of domestic networks AQUAFLUX : Mediametry Watermarking ARTUS : Augmented reality marking 22 November 2005 – AMBIENCE : Security in a mobile world, ambient intelligence – BRIC : Audiovisual watermarking – SEINIT : Infospheres Security – BUGYO : Telecom Infrastructure protection – ACIP : Critical Infrastructure protection – DESEREC : Security of Large scale Resilient networked systems – SECOQC : Security of Quantum Networks – EURONGI : Trust in the next generation of Internet – VIPBOB : Cryptographic protocol with biometric data. Security & Trust for the Grid 4

www. seinit. org 22 November 2005 Security & Trust for the Grid 5

Introduction 22 November 2005 Security & Trust for the Grid

Need of Encryption Receiver Sender Plaintext Defence from: Plaintext, P Key K Encryption Method Ek(P) Passive Intruder, only listens Active Intruder, Can change message Active Intruder, Can insert message Ciphertext, C Plaintext, P Decryption Method Dk(C) Key K Ciphertext, C Network 22 November 2005 Security & Trust for the Grid 7

Encryption • Text is converted to ciphertext by use of an algorithm and key – Algorithm is publicly known – Key is held private • Three Main Categories – Secret Key (symmetric cryptosystem) • single key is used to encrypt and decrypt information – Public/Private Key (asymmetric cryptosystem) • two keys are used: one for encryption (public key) and one for decryption (private key) – One-way Function (hash functions) • information is encrypted to produce a “digest” of the original information that can be used later to prove its authenticity 22 November 2005 Security & Trust for the Grid 8

Symmetric Key Encryption 22 November 2005 Security & Trust for the Grid 9

Asymmetric Key Encryption 22 November 2005 Security & Trust for the Grid 10

Hash Function 22 November 2005 Security & Trust for the Grid 11

Certificates – X. 509 Standard Version Serial Number Signature Algorithm x 509 v 3 Bodypart X. 509 version 3 Certificate Issuer Name Validity Signature Algorithm Subject Name Subject Public Key Signature of CA Issuer Unique ID (v 2) Digital Signature Subject unique ID (v 2) Extensions (v 3) 22 November 2005 Security & Trust for the Grid 12

22 November 2005 Security & Trust for the Grid 13

Kerberos Tickets Domain Authentication and Resource Access 1. Request a ticket for TGS Authentication 2. Return TGT to client Service (AS) 3. Send TGT and request for ticket to \App. Serv Kerberos client 4. Return ticket for \App. Serv Ticket Granting Service (TGS) 5. Send session ticket to \App. Serv 6. (Optional) Send confirmation of identity to client (KDC) \App. Serv 22 November 2005 Security & Trust for the Grid 14

Security & Trust Challenges 22 November 2005 Security & Trust for the Grid

Security & Trust for the Grid 16

Technology Evolution Customer • Static Cooperation Orders, Payments Computer Invoice, Price notices, updates Vendor Computer – Electronic Data Interchange (EDI) • Dynamic Cooperation – Internet • Dynamic Collaboration – Peer-to-Peer (P 2 P), Web Services (WS) • Dynamic Resource Sharing – Computational Grid 22 November 2005 Security & Trust for the Grid 17

22 November 2005 Security & Trust for the Grid 18

Lorch M. , Kafura D. , Grid Community Characteristics and their Relation to Grid Security, Technical Report TR-03 -20, Computer Science, Virginia Tech. , June 2003 … more than half of the grid community members believe that existing grid security solutions do not provide adequate services for collaborative grid communities. The reasons given ranged from the lack of an underlying threat model to the complexity and expense of inter-site trust relationships that are currently required. Connor D. , Grid Computing Hits Security Gridlock, Network World Fusion online magazine, 06 October 2002 … adoption of global grids, where companies share hardware and software resources to accomplish a computational goal, has been slowed because of security concerns and a lack of standards. 22 November 2005 Security & Trust for the Grid 19

Challenges • • Interoperability Trust Management Dependability/Trustworthiness Usability Robustness/Resilience/Survivability Secure Delegation Bootstrapping Mobility 22 November 2005 Security & Trust for the Grid 20

22 November 2005 Security & Trust for the Grid 21

Challenges • • Interoperability Trust Management Dependability/Trustworthiness Usability Robustness/Resilience/Survivability Secure Delegation Bootstrapping Mobility 22 November 2005 Security & Trust for the Grid 22

Problems • There is no benchmark to facilitate the development of grid security solutions • The range of existing grid simulators (Optor. Sim, Chicago. Sim, Sim. Grid, Grid. Sim, EDGSim, Grid. Net, …) does not provide any support for the simulations of security services – Attack pattern, response time, recovery delay, … • Developers are used to rely on the future patches – Fix the vulnerabilities AFTER their exploitation 22 November 2005 Security & Trust for the Grid 23

Problems • However, there are some GENUINE problems too! – The scale of the grid does not permit us to exactly identify all the risks associated with it. – We can not foresee the exact level of the grid security services due to the dynamic nature of its applications. – There is no widely accepted and deployed technique that can measure the quality of grid security services. – Different countries have different electronic/cyber laws (e. g. copyright, intellectual property rights, …), which makes it difficult to deal with security breaches in transfrontier grid applications. 22 November 2005 Security & Trust for the Grid 24

Observations … … in the evolution of computational grids, security threats were overlooked in the desire to implement a distributed high performance computational system. … the main reason for the vulnerability is the fact that grid technology has been little used except by a certain kind of public (mainly academics and government researchers). This public benefit greatly from being able to share resources on the grid, and have no intention of harming the resource owners or fellow users. Thus there was no need to address security in depth! 22 November 2005 Security & Trust for the Grid 25

State of the Art 22 November 2005 Security & Trust for the Grid

The GLOBUS Project • Security – to provide authentication, delegation and authorization • Information Services – to provide information about Grid services • Data Management – involves accessing and managing data • Resource Management – to allocate resources provided by a Grid 22 November 2005 Security & Trust for the Grid 27

Security – Authentication • Grid Security Infrastructure (GSI) – Based on public-key encryption technology (using X. 509 certificates) and SSL. – Define uniform authentication and authorization mechanisms that allow collaborating sites to accept credentials while retaining local control. – Each user has a Grid id, a private key, and a certificate signed by a Certificate Authority (CA). 22 November 2005 Security & Trust for the Grid 28

Security – Delegation • GSI supports a number of features that a grid user requires – – Authentication using a single-sign-on mechanism. Delegation through proxies. Integration with local security systems. Trust based relationships • The GSI implementation in Globus adheres to the IETF GSS-API standard 22 November 2005 Security & Trust for the Grid 29

Security – Authorization • GSI handles authentication, but authorization is a separate issue • Authorization issues: – Management of authorization on a multiorganization grid is still an interesting problem. – The grid-mapfile doesn’t scale well, and works only at the resource level, not the collective level. – Large communities that share resources exacerbates authorization issues, which has led us to CAS… 22 November 2005 Security & Trust for the Grid 30

UNICORE Security • Mutual Authentication (between Gateway/NJS and User) using X 509 Certificates. • No proxy certificates, no generalised delegation. • Authorisation performed by the NJS using the UUDB Interface. (So authorisation is (potentially) moved away from the target system. ) • Separation of consigner and endorser: only a user can endorse a job; an NJS or a user can consign a job. 22 November 2005 Security & Trust for the Grid 31

UNICORE Security • The signed AJO is sent to an NJS as a serialised Java object, via UPL (each Abstract. Job component is signed). • This model ensures no tampering with multi-Vsite jobs by intermediate NJSs. • The user’s private key never leaves the encrypted keystore on his/her workstation. • At no point is any private key which could be used to impersonate the user (for any lifetime) ever created on a remote resource. 22 November 2005 Security & Trust for the Grid 32

Secure Highly Available Resource Peering (SHARP) • A “policy server” controls when, where, and to what extent users can access grid resources. • Provides a construct to represent cryptographically protected resource “claims” promises or rights to control resources for designated time intervals together with secure mechanisms to subdivide and delegate claims across a network of resource managers. 22 November 2005 Security & Trust for the Grid 33

Secure Highly Available Resource Peering (SHARP) • “resource peering”: sites may trade their resources with peering partners or contribute them to a federation according to local policies. • Separation of claims into “tickets” and “leases” allows coordinated resource management across the system. • Introduces mechanisms for controlled, accountable “oversubscription” of resource claims as a fundamental tool for dependable, efficient resource management. 22 November 2005 Security & Trust for the Grid 34

SHARP Security • ensures accountability – Protects sellers • Makes sure everyone gets paid • No one is unfairly held accountable – Protect buyers • Sold Resources are available with high probability • But not – Confidentiality: Easy to see what my seller was issued and who else held the ticket – Authentication : Part of negotiation process – Trust : Tracking seller’s overbooking practices left to applications 22 November 2005 Security & Trust for the Grid 35

Kerberos • Some Grids use a Kerberos GSS-API. – As far as tools and APIs go, this is not visible. (That’s the point of GSS-API!) – However, it is NOT interoperable with GSI based versions of the Globus Toolkit – Various differences of Kerberos vs. GSI: • The security files created “under the covers” are different • Different commands to login, logout, etc. 22 November 2005 Security & Trust for the Grid 36

Security Management = Babel Tower ? 22 November 2005 Security & Trust for the Grid 37

Our Vision … 22 November 2005 Security & Trust for the Grid

• Grid-specific Security Solutions – Keeping in mind the particular nature of the grid. – Huge bunch of nodes, dynamic creation of VOs, … • Virtual Paradigm for the Grid Security Services – To absorb the heterogeneity of the underlying security architectures. – Implementation independent set of security services that can provide complete abstraction of its underlying technologies. • Configurable set of the Security Services – To enable different users to invoke the set of security services that matches their requirements. – This is an extension of the vision of OGSA Security Model. • OGSA Security Model defines security as services – we can extend this vision to security as configurable services. • Strictly follow the standard security practices – To come out of the undeclared ‘state of emergency’ – To handle the security issues with more organized pattern • Risks analysis, evaluation criteria, simulations, … 22 November 2005 Security & Trust for the Grid 39

Virtualization • The secure interoperability between VOs demands interoperable solutions using heterogeneous systems. • Virtualization permits each participating end-point to express the policy it wishes to see applied when engaging in a secure conversation with another end-point. • Policies can specify supported authentication mechanisms, required integrity and confidentiality, trust policies, privacy policies, and other security constraints. 22 November 2005 Security & Trust for the Grid 40

Security of the Ambient Intelligence : ecology of virtual ontologies (V 2 V) Management of global security, Transparency A virtual community Security of non functional properties : architecture, mobility, configurability, Qo. S, … Logical entities Security of functional objects : centralized trusted infrastructures (PKI, DNS, …) Responsibility, Accountability Physical entities 22 November 2005 Security & Trust for the Grid 41

Pluggability/Configurability • Pluggable Security Services (PSS) requirements include: – – – – – Definition of standard and flexible interfaces Integration at application layer Coordinated invocation of services Usable by users and services Simultaneous use of multiple services Support for future enhancement Optimization for various communication links Provision of real-time invocation features Use of standard programming interfaces 22 November 2005 Security & Trust for the Grid 42

PSS Architectural Overview 22 November 2005 Security & Trust for the Grid 43

Coordination Service Architecture 22 November 2005 Security & Trust for the Grid 44

• Application/Client Interface – Authenticates user/application – Facilitate communications Security Broker • Configuration Daemon – Accepts machine independent, abstract configuration request – Interacts with the coordination service • Security Services Handler – Absorbs the diversity of security mechanisms • Protocol Mapping – Contains the list of supported protocols • Security Architecture Interface – Consists of socket modules to plug various security services. 22 November 2005 Security & Trust for the Grid 45

VIPSEC : VIrtualized and Pluggable SECurity Services VIPSEC Model Local Resources n tio a ic nt er e th rv Au Se Mapping Server User Attribute Server CA Access Policy n tio a riz er o th rv Au Se Target Resources Target Domain User Domain 22 November 2005 Security & Trust for the Grid 46

• In this architecture – New users or groups may be introduced quickly (scalability) as the security services layer harmonizes (virtualizes) the diverse security mechanisms of participating nodes and there is no restriction of specific communication or security requirement. – The handling of privileges provided to a group or individual can be easily managed as it employs role based access control (RBAC). – Isolation of applications layer from the core security architecture layer enhances the protection of the private data including authentication data. – Agreed security features could be implemented by making corresponding adjustments in the security broker layer. – The intermediary architecture could be employed to delegate actions; however, there is a need to shun the cloning of credentials as they could be exploited. – The attribute server could be employed to place limits on the overall amount of resources consumed by particular user or group. These limits are generally defined in the access policy of the target domain. – The confidence of the resource providers can be gained by offering them a number of pluggable security services. They can easily incorporate additional security features that assure them that their resources could neither be exploited nor be misused; and in the case of any misuse a chain of accountability could be established. 22 November 2005 Security & Trust for the Grid 47

Security Policy • Local Security Policy (PL) – Application policy, Access Control Policy, Data Integrity Policy, Authentication Policy, Encryption Policy • Global Security Policy (PG) – Defines general security policy – Provides abstraction (virtualization) of all PLs • Features – – Flexible policy-based access control mechanisms Inter-domain access control policies Secure group communication Delegation mechanisms to support scalability to large numbers of resources and users 22 November 2005 Security & Trust for the Grid 48

Trust Management • The problematic is: – How different nodes can trust unknown infrastructure with their private data ? – How a computing infrastructure can trust a node which is seeking access to its resources ? • Definition of trust relationships between two nodes when there exist – Direct trust relationships within a single domain – Indirect trust relationships across multiple domains • Dynamic establishment of trust relationships where any node can join and leave anytime and anywhere 22 November 2005 Security & Trust for the Grid 49

• To establish trust among different nodes: – Instead of having a single value representing the trustworthiness of a node, the value should be broken into separate attributes – Each attribute represents a confidence, and each confidence represents a characteristic of a node from which trust can be synthesized • There are varying forms of trust: – – We can trust a node to be accurate We can trust a node to complete tasks reliably We can trust nodes to return data quickly … • These attributes form a virtual plane to link the resources, users (individuals and services) and the applications – This relationship signifies that there is not a fix form of trust among the various entities – It allows the greatest flexibility from one entity to the other. 22 November 2005 Security & Trust for the Grid 50

• From the Functional Point of View: – These attribute certificates will be used in compliment with identity certificates – Like identity certificates are used to verify the identity of an entity in a highly anonymous environment, the attribute certificates will be used to determine the trustworthiness of an entity in an uncertain environment 22 November 2005 Security & Trust for the Grid 51

Security Bootstrapping • The Resurrecting Duckling Policy Model – Secure Transient Association • exchange of a shared secret during physical contact (pairing) representing a master-slave relation between the devices. – Default Policy • the master device can access all services of the slave device; no other device is allowed to use services. – Shortcomings … • pair-wise master-slave relations between devices introduce dependencies between devices that limit the usability and are prone to loss of devices. • the model does not suggest how the credentials to represent these relations could be described in the policy in an authentic way. 22 November 2005 Security & Trust for the Grid 52

• Our approach to address these shortcomings – ownership model • builds real peer-to-peer security relations between all devices owned by the same user and thereby strictly defines what devices that are trusted – security policy • defines relations to other devices, assigns rights to security relations, and supports authentic key exchange. – Privacy of information and resources • use of pseudonyms and secure service discovery protocols are emphasized – to provide the presence of devices only on a need-to-know basis – Usability • the important aspect is the ‘ease of use’ because a user can not be expected to configure everything. • We consider security bootstrapping as a first step towards the ambitious goal of self-configuration in the dynamic networked systems. 22 November 2005 Security & Trust for the Grid 53

Security Negotiations • Establishment of secure session between the endpoints – allows the endpoints to negotiate security requirements – supports end-to-end and/or hop-to-hop security associations – broadens applicability to general networked environments • Security negotiations are carryout by the Security Broker – mediates between applications and the security services – employs a security services handler to absorb the heterogeneity of the underlying security services and to provide a homogeneous interface to the upper layer. • Invocation of a set of optimal security services is possible 22 November 2005 Security & Trust for the Grid 54

Security of the Security Architecture • Determines if the security architecture can meet the security demands of an active and determined attack • The various steps we have taken to assure the security of the security architecture: – – – – Basic Design and Documentation Module Interfaces Authorized Roles and Services Physical Security Software Security Operating System Security Self Testing 22 November 2005 Security & Trust for the Grid 55

Extension of OGSA • The Open Grid Services Architecture (OGSA) security model casts security functions as OGSA services – allows well-defined protocols and interfaces to be defined for these services; – permits an application to outsource security functionality by using a security service with a particular implementation to fit its current need. • We extend the OGSA concept of ‘Security as Services’ to ‘Security as Pluggable Services’ – permits the evolution of security infrastructure with less impact on the resource management functionalities – permits the users and stakeholders to configure the security architecture according to their requirements and satisfaction level. 22 November 2005 Security & Trust for the Grid 56

• We add some handler modules into OGSA container to extend its functionalities – the service request comes into the container through service interface – then passes the security services handlers one after the another until it invokes the implementation of that security service – after service execution, the response may also tunnel through some other security services handlers before it gets to client side – a handler may communicate with a corresponding Grid Monitoring and Managing Services (GMMS) during the procedure & send monitoring information to that GMMS according to Web Services Level Agreement (WSLA) • Handler modules develop as plug-ins for OGSA container – handlers can be inserted or removed from the container at any moment. – plug-in mechanism brings high flexibility • we can customize needed handlers in the container to fit different scenarios • we can specify different handlers in service deployment stage in order to do different monitoring functions 22 November 2005 Security & Trust for the Grid 57

Extension of GSI • The Grid Security Infrastructure (GSI) does not attempt to – discover middleboxes; and – negotiate security with them • As a result – security gaps could surface • particularly in cases where some grid resources and nodes exist in a local network behind a firewall – adaptability of GSI becomes limited making it hard to port it to lightweight devices with limited capabilities • We extend the GSI to enable it to adapt environments with varying conditions that incorporates greater flexibility, adaptability, and customizability. 22 November 2005 Security & Trust for the Grid 58

Formal Security Evaluation • Independent (third party) attestation of a developer’s security claims against a defined security evaluation criteria. • Evaluations result in independent measure of assurance, therefore build confidence in security. • Secures development process and yields better product. • Comprehensive security solutions cannot be evaluated by simple examination! 22 November 2005 Security & Trust for the Grid 59

CC for Grid Security Architecture • Both CC and Computational Grids have emerged by the late 1990 s. • However, the Grid community lacks experience in the exercise of CC! • Perhaps, because security features were overlooked in the early Grid endeavors … • The growing size and profile of Grid oblige its designers to incorporate adequate security solutions. • The assessment of these solutions require excellent evaluation criteria. • CC is the best available criteria for these assessments. 22 November 2005 Security & Trust for the Grid 60

CC Evaluation – Case Study • We have prepared a formal Protection Profile (PP) – Target of Evaluation (TOE) : Health Grid – Common Criteria (CC) version 2. 1 – Evaluation Assurance Level (EAL) = 4 • EAL 4 – minimum Strength of Function (SOF) = HIGH • SOF-high Naqvi S. , Riguidel M. , ‘Evaluation of Grid Security Solutions using Common Criteria’, In the Proceedings of the Computing in High Energy Physics 2004 (CHEP’ 04), Interlaken - Switzerland, September 27 - October 01, 2004. pp 854 -857 (ISBN 9290832452) 22 November 2005 Security & Trust for the Grid 61

G 3 S Grid Security Services Simulator 22 November 2005 Security & Trust for the Grid

G 3 S • G 3 S : Grid Security Services Simulator – Open source code – Developed in Java – Provides simulations features for the Grid security functionalities – Some pervasive features are also included – Can be integrated on the top of Grid. Sim 22 November 2005 Security & Trust for the Grid 63

Grid. Sim Core Document. Exchange 22 November 2005 Security. Policy Trust. Management Security & Trust for the Grid Attack 64

22 November 2005 Security & Trust for the Grid 65

Conclusions 22 November 2005 Security & Trust for the Grid

Grid Security – Medieval Period • Security threats were overlooked in the desire to implement a high performance distributed computational system. • Grid community was composed of ‘Good Guys’ : Academics & Public Researchers. • This community was interested to share resources on the grid, and had no intention of harming the resource owners or fellow users. • Grid users were the ‘known’ and ‘trusted’ persons of the resource providers. • Applications running over these Grids and data being exchanged were not ‘interesting’ for the attackers! 22 November 2005 Security & Trust for the Grid 67

Grid Security – Medieval Period • The pioneer Grid security solution – GSI – was a good start. • GSI was meant to provide ‘basic’ security. • In-depth security was perhaps not required for the community composed of ‘good guys’ • Other security initiatives include: SHARP: Secure Highly Available Resource Peering Sandbox, … • BUT all these initiatives were based on the security solutions of the existing distributed applications with some modifications. 22 November 2005 Security & Trust for the Grid 68

Today: There is SOME Confusion! • We all agree that: Grid is DIFFERENT from other Distributed Technologies (like CORBA, Clusters, Pervasive Computing, …) • Then the Grid Security should also be different from the other existing security technologies ? ? ? • We say that: Grid Security should be based on CURRENT standards • But it should not be implied that Grid Security should be based on EXISTING solutions! 22 November 2005 Security & Trust for the Grid 69

There is SOMETHING missing • For the Grid Security: – We are not following the standard security practices (requirements analysis, simulations, evaluations, …) – It seems that we are only looking for quick solutions. – We are interested to develop these solutions but are reluctant to do research on new security paradigms. – This ‘Crash Approach’ or the ‘State of Emergency’ may be acceptable for sometime BUT we can not envision a good future based on the current attitude. • It may be the time for the RENAISSANCE of the Grid Security approach! 22 November 2005 Security & Trust for the Grid 70