EGEE Security Basics for the User Guy Warner NeSC Training Team

1
EGEE Security Basics for the User Guy
WarnerNeSC Training Team
An Induction to EGEE for GOSC and the NGS NeSC,
8th December 2004
2
Acknowledgements
Some of the slides in this presentation are based
on / motivated by

• The presentation given by Carl Kesselman at the
  GGF Summer School 2004. This presentation may be
  found at
• http//www.dma.unina.it/murli/GridSummerSchool200
  4/curriculum.htm
• Lectures given by Richard Sinott and John Watt at
  the University of Glasgow. These lectures may be
  found at
• http//csperkins.org/teaching/2004-2005/gc5/
• The presentation given by Simone Campana of CERN
  at First Latinamerican Grid Workshop, Merida,
  Venezuela. This presentation may be found at
• http//agenda.cern.ch/fullAgenda.php?idaa044965

3
Approaches to Security 1
The Poor Security House
4
Approaches to Security 2
The Paranoid Security House
5
Approaches to Security 3
The Realistic Security House
6
Approaches to Grid Security

• The Poor Security Approach
• Use unencrypted communications.
• No or poor (easily guessed) identification means.
• Private identification (key) left in publicly
  available location.
• The Paranoid Security Approach
• Dont use any communications (no network at all).
• Dont leave computer unattended.
• The Realistic Security Approach
• Encrypt all sensitive communications
• Use difficult to break identification means.
• Keep identification secure at all times (e.g.
  encrypted on a memory stick).
• Only allow access to trusted users.

7
The Risks of Poor User Security

• Launch attacks to other sites
• Large distributed farms of machines, perfect for
  launching a Distributed Denial of Service attack.
• Illegal or inappropriate data distribution and
  access sensitive information
• Massive distributed storage capacity ideal for
  example, for swapping movies.
• Damage caused by viruses, worms etc.
• Highly connected infrastructure means worms
  spread faster than on the internet in general.

8
Authentication and Authorization
Mongolian Yak Inspector

• Authentication
• Are you who you claim to be?
• Authorisation
• Do you have access to the resource you are
  connecting to?

9
Aspects of Grid Security

• Resources being used may be valuable the
  problems being solved sensitive
• Dynamic formation and management of virtual
  organizations (VOs)
• Large, dynamic, unpredictable
• VO Resources and users are often located in
  distinct administrative domains
• Cant assume cross-organizational trust
  agreements
• Different mechanisms credentials
• Interactions are not just client/server, but
  service-to-service on behalf of the user
• Requires delegation of rights by user to service
• Services may be dynamically instantiated

slide based on presentation given by Carl
Kesselman at GGF Summer School 2004
10
Grid Security Infrastructure (GSI)

• Developed by Globus. All elements of the Globus
  Toolkit are built on top of this basic
  infrastructure.
• A toolkit for the purposes of
• Secure communication
• Security across organizational boundaries, thus
  prohibiting a centrally-managed security system.
• Supporting "single sign-on" for Grid users,
  including delegation of credentials.
• Introduces X.509 Proxy Certificates (an extended
  X.509 certificate)
• every user/host/service has a certificate.
• certificates are signed by trusted (by the local
  sites) certificate authorities.
• every Grid transaction is mutually authenticated.

11
The Trust Model
slide based on presentation given by Carl
Kesselman at GGF Summer School 2004
12
Delegation
Delegation The act of giving an organisation,
person or service the right to act on your
behalf.

• A Site delegates responsibility for the users
  that may access its resources to the
  managers/management system of a VO.
• A VO delegates its rights to a user.
• A user delegates their authentication to a
  service to allow programs to run on remote sites.

13
Use Delegation toEstablish Dynamic Distributed
System
slide based on presentation given by Carl
Kesselman at GGF Summer School 2004
14
Goal is to do this with arbitrary mechanisms
ComputeCenter
X.509/SSL
Kerberos/ WS-Security
Rights
VO
ComputeCenter
SAML Attribute
slide based on presentation given by Carl
Kesselman at GGF Summer School 2004
15
Public Private Key
Alice
Bob
Life Savings
Life Savings
Life Savings
16
Public Key Infrastructure (PKI)

• PKI allows you to know that a given key belongs
  to a given user.
• PKI builds off of asymmetric encryption
• Each entity has two keys public and private.
• Data encrypted with one key can only be decrypted
  with other.
• The public key is public.
• The private key is known only to the entity.
• The public key is given to the world encapsulated
  in a X.509 certificate.

slide based on presentation given by Carl
Kesselman at GGF Summer School 2004
17
An illustration of how PKI works

• Assume our message can be converted to a number
  in the range 1-9 (a 0 value represents an empty
  message)
• For this example use the value 4
• Encrypt the message by multiplying by 3 and
  working in modulo 10
• 4 x 3 12 2 mod 10
• To decrypt we cant divide by 3 because working
  modulo 10 only supports the integers 0-9.
• Instead to decrypt the message multiply by 7
  while working modulo 10
• 2 x 7 14 4 mod 10
• Why Does this work?
• 3 x 7 21 1 mod 10 , hence , 1/3 7 mod 10

18
Certificates

• Similar to passport or drivers license Identity
  signed by a trusted party

slide based on presentation given by Carl
Kesselman at GGF Summer School 2004
19
Certificate Authorities

• A small set of trusted entities known as
  Certificate Authorities (CAs) are established to
  sign certificates
• A Certificate Authority is an entity that exists
  only to sign user certificates
• Users authenticate themselves to CA, for example
  by use of their Passport or Identity Card.
• The CA signs its own certificate which is
  distributed in a secure manner.
• EGEE recognizes a given set of CAs

https//lcg-registrar.cern.ch/pki_certificates.htm
l
slide based on presentation given by Carl
Kesselman at GGF Summer School 2004
20
Certificate Request
User send public key to CA along with proof of
identity.
User generatespublic/privatekey pair.
CA confirms identity, signs certificate and sends
back to user.
CertificateRequest Public Key
Public
Certificate Authority
Private Key encrypted on local disk
slide based on presentation given by Carl
Kesselman at GGF Summer School 2004
21
Inside the Certificate

• Standard (X.509) defined format.
• User identification (e.g. full name).
• Users Public key.
• A signature from a CA created by encoding a
  unique string (a hash) generated from the users
  identification, users public key and the name of
  the CA. The signature is encoded using the CAs
  private key. This has the effect of
• Proving that the certificate came from the CA.
• Vouching for the users identification.
• Vouching for the binding of the users public key
  to their identification.

22
Certificate Validity

• The public key from the CA certificate can then
  be used to verify the certificate.

?
slide based on presentation given by Carl
Kesselman at GGF Summer School 2004
23
Certificates and Delegation
24
Mutual Authentication Pt1

• Two parties, lets call them A and B, have
  certificates and they both trust the CAs that
  signed them.
• Mutual Authentication is the process by which
  they prove to each other that they are who they
  say they are.
• The process is
• B establishes As identity.
• A establishes Bs identity.
• A can trust B and B can trust A.

25
Mutual Authentication Pt2

• A sends their certificate
• B verifies signature in As certificate
• B sends to A a challenge string
• A encrypts the challenge string with his private
  key
• A sends encrypted challenge to B
• B uses As public key to decrypt the challenge.
• B compares the decrypted string with the original
  challenge
• If they match, B verified As identity and A can
  not repudiate it.

B
A
26
User Authorisation to Access Resource
slide based on presentation given by Carl
Kesselman at GGF Summer School 2004
27
Authorisation Requirements

• Detailed user rights centrally managed and
  assigned
• User can have certain group membership and roles
• Involved parties
• Resource providers.
• Keep full control on access rights.
• The users Virtual Organisation.
• Member of a certain group should have same access
  rights independent of resource.
• Resource provider and VO must agree on
  authorisation
• Resource providers evaluate authorisation granted
  by VO to a user and map into local credentials to
  access resources

28
User Responsibilities

• Keep your private key secure.
• Do not loan your certificate to anyone.
• Report to your local/regional contact if your
  certificate has been compromised.
• Do not launch a delegation service for longer
  than your current task needs.

If your certificate or delegated service is used
by someone other than you, it cannot be proven
that it was not you.
29
Summary