Security & Trust for the Grids Syed Naqvi IT Security Group [email protected].

Security & Trust for the Grids

Syed Naqvi

IT Security [email protected]

22 November 2005 Security & Trust for the Grid 2

From From tele-communicaretele-communicare to to TelecommunicationsTelecommunicationswww.enst.fr

Edouard EstauniéEdouard Estaunié

“I needed to add a new word to an already too rich glossary …”

“J'ai dû ajouter un mot nouveau à un glossaire déjà trop riche …”

Courtesy of Bibliothèque Nationale de France

In 1904 …


National (RNRT)National (RNRT)– ICARE : Trusted Infrastructures, PKIs

– SWAP : WAP Security

– MMQoS : Security, Mobility and QoS

– ANAIS : Security of Professional Mobile Radio

– INFRADIO : Security on a campus and of infospheres in meshed networks

– EPIS : Smart card security E2E with IPv6

– RESODO : Security of domestic networks

– AQUAFLUX : Mediametry Watermarking

– ARTUS : Augmented reality marking

European Projects (IST & ITEA)European Projects (IST & ITEA)– 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 Research Projects …


www.seinit.org

Introduction


SenderSenderReceiverReceiver

Plaintext, PPlaintext, P Plaintext, PPlaintext, P

KeyKeyKK

Ciphertext, CCiphertext, C

EncryptionEncryptionMethod Method

EEkk(P)(P)

KeyKeyKK

Ciphertext, CCiphertext, C

NetworkNetwork

DecryptionDecryptionMethod Method DDkk(C)(C)

Passive Passive Intruder, Intruder,

only listens only listens

Active Active Intruder, Intruder,

Can insert Can insert messagemessage

Active Active Intruder, Intruder,

Can change Can change messagemessage

Defence from:Defence from:

Plaintext

Need of Encryption


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


Symmetric Key Encryption


Asymmetric Key Encryption


Hash Function


Certificates – X.509 Standard

X.509X.509version 3version 3CertificateCertificate

x509 v3 Bodypartx509 v3 Bodypart

VersionVersion

Serial NumberSerial Number

Signature AlgorithmSignature Algorithm

Issuer NameIssuer Name

ValidityValidity

Subject NameSubject Name

Subject Public KeySubject Public Key

Issuer Unique ID (v2)Issuer Unique ID (v2)

Subject unique ID (v2)Subject unique ID (v2)

Extensions (v3)Extensions (v3)

Signature AlgorithmSignature Algorithm

Signature of CASignature of CA

DigitalDigitalSignatureSignature


Kerberos Tickets

AuthenticationAuthentication

Service (AS)Service (AS)

TicketTicket

GrantingGranting

Service Service (TGS)(TGS)

(KDC)(KDC)

KerberosKerberosclientclient

\\AppServ\\AppServ

1. Request a ticket for TGS1. Request a ticket for TGS

2. Return TGT to client2. Return TGT to client

3. Send TGT and request for ticket to \\AppServ3. Send TGT and request for ticket to \\AppServ

4. Return ticket for \\AppServ4. Return ticket for \\AppServ

5. Send session ticket to \\AppServ5. Send session ticket to \\AppServ

6. (Optional) Send confirmation of identity to client 6. (Optional) Send confirmation of identity to client

Domain Authentication and Resource AccessDomain Authentication and Resource Access

Security & Trust Challenges

Security & Trust for the Grid 16


Technology Evolution

• Static Cooperation– Electronic Data Interchange (EDI)

• Dynamic Cooperation– Internet

• Dynamic Collaboration– Peer-to-Peer (P2P), Web Services (WS)

• Dynamic Resource Sharing– Computational Grid

ComputerComputer ComputerComputer

CustomerCustomer VendorVendorOrders, Payments

Invoice, Pricenotices, updates


… 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.

… 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.

Lorch M., Kafura D., Grid Community Characteristics and their Relation to Grid Security, Technical Report TR-03-20, Computer Science, Virginia Tech., June 2003

Connor D., Grid Computing Hits Security Gridlock, Network World Fusion online magazine, 06 October 2002


Challenges

• Interoperability• Trust Management• Dependability/Trustworthiness• Usability• Robustness/Resilience/Survivability• Secure Delegation• Bootstrapping• Mobility


Problems

• There is no benchmark to facilitate the development of grid security solutions

• The range of existing grid simulators (OptorSim, ChicagoSim, SimGrid, GridSim, EDGSim, GridNet, …) 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


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.


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!

State of the Art


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


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 acceptcredentials while retaining local control.

– Each user has a Grid id, a private key, and a certificate signed by a Certificate Authority (CA).


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


Security – Authorization

• GSI handles authentication, but authorization is a separate issue

• Authorization issues:– Management of authorization on a multi-

organization 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…


UNICORE Security

• Mutual Authentication (between Gateway/NJS and User) using X509 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.


UNICORE Security

• The signed AJO is sent to an NJS as a serialised Java object, via UPL (each AbstractJob 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 toimpersonate the user (for any lifetime) ever created on a remote resource.


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.


• “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.

Secure Highly Available Resource Peering (SHARP)


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


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.


Security Management = Babel Tower ?

Our Vision …


• 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, …


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.


A virtual community

Logical entities

Physical entities

Security of functional objects : centralized trusted infrastructures (PKI, DNS, …)Responsibility, Accountability

Security of non functional properties : architecture, mobility, configurability, QoS, …

Security of the Ambient Intelligence : ecology of virtual ontologies (V2V)Management of global security, Transparency


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


PSS Architectural Overview


Coordination Service Architecture


Security Broker• Application/Client Interface

– Authenticates user/application– Facilitate communications

• 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.


VIPSEC Model

VIPSEC : VIrtualized and Pluggable SECurity Services

CACA

UserUser

Local Local ResourcesResources

Authentic

ation

Authentic

ation

Server

Server

Attribute Attribute ServerServer

Mapping Mapping ServerServer

Authorizatio

n

Authorizatio

n

Server

Server

Access Access PolicyPolicy

Target Target ResourcesResources

User DomainUser Domain Target DomainTarget Domain


• 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.


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


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


• 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.


• 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


• 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.

Security Bootstrapping


• 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.


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


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


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.


• 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


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.


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!


CC for Grid Security Architecture

• Both CC and Computational Grids have emerged by the late 1990s.

• 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.


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

• EAL4

– 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)

G3SGrid Security Services Simulator


G3S

• G3S : 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 GridSim


DocumentExchange SecurityPolicy TrustManagement Attack

Core

GridSim

Conclusions


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!


• The pioneer Grid security solution – GSI – was agood 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 PeeringSandbox, …

• BUT all these initiatives were based on the security solutions of the existing distributed applications with some modifications.

Grid Security – Medieval Period


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!


• 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!

There is SOMETHING missing

Security & Trust for the Grids Syed Naqvi IT Security Group [email protected].

Documents

Transcript of Security & Trust for the Grids Syed Naqvi IT Security Group [email protected].