security on grid: user interface, internals and apis simone campana lcg experiment integration and...

Security on Grid: User Interface,

Internals and APIs

Simone CampanaLCG Experiment Integration and Support

CERN IT

First Latinamerican Grid Workshop, Merida (VE) – 15-20 November 2004 - 2

Overview

• Glossary• Encryption

• Symmetric algorithms • Asymmetric algorithms: PKI

• Certificates• Digital Signatures • X509 certificates

• Grid Security• Basic concepts • Grid Security Infrastructure • Proxy certificates• Command line interfaces

• Virtual Organisation• Concept of VO and authorization• VOMS, LCAS, LCMAPS

• C/C++ interfaces (GSS-API, GSS Assist)


Overview








Glossary

• Principal• An entity: a user, a program, or a machine

• Credentials• Some data providing a proof of identity

• Authentication• Verify the identity of the principal

• Authorization• Map an entity to some set of privileges

• Confidentiality• Encrypt the message so that only the recipient can understand it

• Integrity• Ensure that the message has not been altered in the transmission

• Non-repudiation• Impossibility of denying the authenticity of a digital signature


Overview

• Glosary• Encryption







Cryptography

• Mathematical algorithm that provides important building blocks for the implementation of a security infrastructure

• Symbology• Plaintext: M

• Cyphertext: C

• Encryption with key K1 : E K1(M) = C

• Decryption with key K2 : D K2(C) = M

• Algorithms

• SymmetricSymmetric: K1 = K2

• AsymmetricAsymmetric: K1 ≠ K2

K2K1

EncryptionEncryption DecryptionDecryptionM C M


Symmetric Algoritms

• The same key is used for encryption and decryption

• Advantages:• Fast

• Disadvantages:• how to distribute the keys?• the number of keys is O(n2)

• Examples:• DES• 3DES• Rijndael (AES)• Blowfish• Kerberos

A B

ciao

3$r ciao

A B

ciao

3$r ciao

3$r

3$r


Public Key Algorithms

• Every user has two keys: one private and one public:

• it is impossible to derive the private key from the public one;

• a message encrypted by one key can be decripted only by the other one.

• No exchange of secrets is necessary

• the sender cyphers using the public key of the receiver;

• the receiver decripts using his private key;

• the number of keys is O(n).• Examples:

• Diffie-Helmann (1977)• RSA (1978)

B’s keys

public private

A’s keys

public private

A B

ciao

3$r ciao

A B

ciao

cy7 ciao

3$r

cy7


Overview








One-Way Hash Functions

• Functions (H) that given as input a variable-length message (M) produce as output a string of fixed length (h)• the length of h must be at least 128 bits (to avoid birthday attacks)

1. given M, it must be easy to calculate H(M) = h

2. given h, it must be difficult to calculateM = H-1(h)

3. given M, it must be difficult to find M’ such that H(M) = H(M’)

• Examples:• SNEFRU: hash of 128 or 256 bits;• MD4/MD5: hash of 128 bits;• SHA (Standard FIPS): hash of 160 bits.


Digital Signature

• A calculates the hashhash of the message

• AA encrypts the hash using his privateprivate key: the encrypted hash is the digital signaturedigital signature.

• A sends the signed message to B. • B calculates the hash of the

message and verifiesverifies it with the one received by A and decyphered with A’s publicpublic key.

• If the two hashes are equal, the message wasn’t modified and A cannot repudiate it.

B

This is some

message

Digital Signature

A

This is some

message

Digital Signature

This is some

message

Digital Signature

Hash(A)

A’s keys

public private

Hash(B)

Hash(A)

= ?


Digital Certificates

• A’s digital signature is safe if:1. A’s private key is not compromised

2. B knows A’s public key

• How can B be sure that A’s public key is really A’s public key and not someone else’s?• A third party guarantees the correspondence between public key

and owner’s identity, by signing a document which contains the owner’s identity and his public key (Digital Certificate)

• Both A and B must trust this third party

• Two models:• X.509: hierarchical organization;• PGP: “web of trust”.


PGP “web of trust”

A

B

C

D

E

F

• F knows D and E, who knows A and C, who knows A and B.• F is reasonably sure that the key from A is really from A.


X.509

The “third party” is called Certification AuthorityCertification Authority (CA).

• Issue certificates for users, programs and machines

• Check the identity and the personal data of the requestor• Registration Authorities (RAs) do the actual validation

• CA’s periodically publish a list of compromised certificates• Certificate Revocation Lists (CRL)

• They contain all the revoked certificates yet to expire• Online Certificate Status Protocol (OCSP).

• CA certificates are self-signed


X.509 Certificates

• An X.509 Certificate contains:

• owner’s public key;

• identity of the owner;

• info on the CA;

• time of validity;

• Serial number;

• digital signature of the CA

Public keyPublic key

Subject:Subject:C=CH, O=CERN, C=CH, O=CERN, OU=GRID, CN=Andrea Sciaba OU=GRID, CN=Andrea Sciaba 89688968

Issuer: C=CH, O=CERN, Issuer: C=CH, O=CERN, OU=GRID, CN=CERN CAOU=GRID, CN=CERN CA

Expiration date: Expiration date: Aug 26 08:08:14 Aug 26 08:08:14 2005 GMT2005 GMT

Serial number: 625 (0x271)Serial number: 625 (0x271)

CA Digital signatureCA Digital signature

Structure of a X.509 certificate


Overview








GRID Security: the players

• Large and dynamic population•Different accounts at different sites •Personal and confidential data•Heterogeneous privileges (roles)•Desire Single Sign-On

UsersUsers

• “Group” data • Access Patterns • Membership

““Groups”Groups”

SitesSites• Heterogeneous Resources• Access Patterns • Local policies• Membership

GridGrid


The Risks

• Launch attacks to other sites• Large distributed farms of machines

• Illegal or inappropriate data distribution and access sensitive information

• Massive distributed storage capacity

• Disruption by exploiting security holes• Complex, heterogeneous and dynamic environment

• Damage caused by viruses, worms etc.• Highly connected and novel infrastructure


The Grid Security Infrastructure (GSI)

• every user/host/service has an X.509 certificate;

• certificates are signed by trusted (by the local sites) CA’s;

• every Grid transaction is mutually authenticated:

1. A sends his certificate;

2. B verifies signature in A’s certificate;

3. B sends to A a challenge string;

4. A encrypts the challenge string with his private key;

5. A sends encrypted challenge to B

6. B uses A’s public key to decrypt the challenge.

7. B compares the decrypted string with the original challenge

8. If they match, B verified A’s identity and A can not repudiate it.

AA BBA’s certificateA’s certificate

Verify CA signatureVerify CA signature

Random phraseRandom phrase

Encrypt with A’ s private keyEncrypt with A’ s private key

Encrypted phraseEncrypted phrase

Decrypt with A’ s public keyDecrypt with A’ s public key

Compare with original phraseCompare with original phrase

Based on X.509 PKI:

VERY IMPORTANTVERY IMPORTANT

Private keysPrivate keys must be stored only:

in protectedprotected places

ANDAND

in encryptedencrypted form


Certificate request … more details

• Egee/LCG recognizes a given set of CAs• https://lcg-registrar.cern.ch/pki_certificates.html

• How do you request a certificate depends on your CA• The certificate request is created together with the

certificate private key (encrypted by a pass phrase)

• For GILDA, have a look at the Demo Video:• https://gilda.ct.infn.it/video/Certification/Allproxy.html (Flash)• https://gilda.ct.infn.it/video/Certification/AllCertproxy.ram (Real)


Certificate Request

Private Key encrypted on

local disk

CertRequest

Public Key

ID

Cert

User generatespublic/private

key pair.

User send public key to CA along with proof of

identity.

CA confirms identity, signs certificate and sends back to user.


Certificate Information

• To get cert information run grid-cert-info

[scampana@grid019:~]$ grid-cert-info -subject

/C=CH/O=CERN/OU=GRID/CN=Simone Campana 7461

• Options for printing cert information-all -startdate-subject -enddate-issuer -help


X.509 Proxy Certificate

• GSI extension to X.509 Identity Certificates• signed by the normal end entity cert (or by another proxy).

• Enables single sign-on• Support some important features

• Delegation• Mutual authentication

• Has a limited lifetime (minimized risk of “compromised credentials”) • It is created by the grid-proxy-init command:

% grid-proxy-initEnter PEM pass phrase: ******

• Options for grid-proxy-init:• -hours <lifetime of credential>• -bits <length of key>• -help


grid-proxy-init

• User enters pass phrase, which is used to decrypt private key.

• Private key is used to sign a proxy certificate with its own, new public/private key pair.

• User’s private key not exposed after proxy has been signed

User certificate file

Private Key(Encrypted)Pass

Phrase

User Proxycertificate file

• Proxy placed in /tmp, read-only by user• the private key of the Proxy is not encrypted:• stored in local file: must be readable only by the owner;• proxy lifetime is short (typically 12 h) to minimize security risks.

• NOTE: No network traffic!


Proxy again …

• grid-proxy-init ≡ “login to the Grid”• To “logout” you have to destroy your proxy:

• grid-proxy-destroy• This does NOT destroy any proxies that were delegated from this

proxy.• You cannot revoke a remote proxy• Usually create proxies with short lifetimes

• To gather information about your proxy: • grid-proxy-info• Options for printing proxy information

-subject -issuer-type -timeleft-strength -help


Delegation and limited proxy

• Delegation = remote creation of a (second level) proxy credential• New key pair generated remotely on server• Clients signs proxy cert and returns it

• Allows remote process to authenticate on behalf of the user• Remote process “impersonates” the user

• The client can elect to delegate a “limited proxy”• Each service decides whether it will allow authentication with a limited proxy• Job manager service requires a full proxy• GridFTP server allows either full or limited proxy to be used


Long term proxy

• Proxy has limited lifetime (default is 12 h)• Bad idea to have longer proxy

• However, a grid task might need to use a proxy for a much longer time • Grid jobs in HEP Data Challenges on LCG last up to 2 days

• myproxy server:• Allows to create and store a long term proxy certificate:• myproxy-init -s <host_name> -d -n

• -s: <host_name> specifies the hostname of the myproxy server• -d: server to use the subject of the certificate as the default username• -n: avoids the use of a passphrase to access to the long-term proxy

– so the WMS can perform the renewals automatically.

• myproxy-get-delegation -s <host_name>• Get a new proxy from the MyProxy server

• myproxy-destroy

• A dedicated service on the RB can renews automatically the proxy• contacts the myproxy server


GSI environment variables

• User certificate files:• Certificate: X509_USER_CERT (default:

$HOME/.globus/usercert.pem)• Private key: X509_USER_KEY (default: $HOME/.globus/userkey.pem)• Proxy: X509_USER_PROXY (default: /tmp/x509up_u<id>)

• Host certificate files:• Certificate: X509_USER_CERT (default:

/etc/grid-security/hostcert.pem)• Private key: X509_USER_KEY (default:

/etc/grid-security/hostkey.pem)

• Trusted certification authority certificates:• X509_CERT_DIR (default:

/etc/grid-security/certificates)


Overview








Virtual Organizations and authorization

• Grid users MUST belong to Virtual Organizations• What we previously called “Groups”• Sets of users belonging to a collaboration• List of supported VOs:

• https://lcg-registrar.cern.ch/virtual_organization.html

• VOs maintain a list of their members• The list is downloaded by Grid machines to map user certificate

subjects to local “pool” accounts

• Sites decide which VOs to accept

..."/C=CH/O=CERN/OU=GRID/CN=Simone Campana 7461" .dteam"/C=CH/O=CERN/OU=GRID/CN=Andrea Sciaba 8968" .cms"/C=CH/O=CERN/OU=GRID/CN=Patricia Mendez Lorenzo-ALICE" .alice...

/etc/grid-security/grid-mapfile


On the side: user Registration in a VO

• Import your certificate in your browser• If you received a .pem certificate you need to convert it to PKCS12 • Use openssl command line (available in each egee/LCG UI)

• openssl pkcs12 –export –in usercert.pem –inkey userkey.pem –out my_cert.p12 –name ’My Name’

• Sign the usage guidelines for the VO • You will be registered in the VO-LDAP server (wait for notification)

• Gilda (and other VO): • You receive already a PKCS12 certificate (can import it directly into web

browser)• For future use, you will need usercert.pem and userkey.pem in a directory

~/.globus on your UI• Export the PKCS12 cert to a local dir on UI and use again openssl:

• openssl pkcs12 -nocerts -in my_cert.p12 -out userkey.pem• openssl pkcs12 -clcerts -nokeys -in my_cert.p12 -out usercert.pem


VOMS, LCAS, LCMAPS

• Virtual Organization Membership Service• Extends the proxy info with VO membership, group, role and capabilities

• Local Centre Authorization Service (LCAS)• Checks if the user is authorized (currently using the grid-mapfile)• Checks if the user is banned at the site• Checks if at that time the site accepts jobs

• Local Credential Mapping Service (LCMAPS)• Maps grid credentials to local credentials (eg. UNIX uid/gid, AFS tokens,

etc.)• Currently uses the grid-mapfile (based only on certificate subject)• In the near future will map also VOMS group and roles

"/VO=cms/GROUP=/cms" .cms"/VO=cms/GROUP=/cms/prod" .cmsprod"/VO=cms/GROUP=/cms/prod/ROLE=manager" .cmsprodman


Overview








Security APIs in egee/LCG

• Currently, there are no API developed specifically by egee/LCG

• The existing API come from other projects• Authentication

• Globus GSS-API, GSS Assist, COG Kits

• Authorization• LCAS plugins

• LCMAPS plugins

• VOMS API

• The documentation is generally poor• Some development is on the way. Check CHEP 2004:

• http://indico.cern.ch/contributionDisplay.py?contribId=78&sessionId=23&confId=0


API: GSS-API and GSS Assist

• GSS-API (Generic Security Services Application Programming Interface) is a generic API for client-server authentication (RFC-2743, 2744)

• Traditionally, interfaces to Kerberos• Globus interfaced it to GSI• Communication is kept separate• Unfortunately, rather complicated to use

• GSS-API as user interface to GSI• C API• Java API

• The Globus GSS Assist routines are designed to simplify the use of the GSSAPI


GSS-API

1. The client initiates a context and prepares a token for the server

2. The token is sent to the server 3. The server interprets the token and

prepares a new one to be sent to the client 4. The token is sent to the client 5. Iterate process until authentication process

succeeds or fails

1. The client wraps a message for the server and sends it

2. The server receives the message and unwraps it

3. The server sends a confirmation message to the client (MIC)

4. The client verifies the MIC


GSS-API data types

• Integers OM_uint32

• Strings typedef struct gss_buffer_struct {

size_t length;

void *value;

} gss_buffer_desc, *gss_buffer_t

• Names gss_name_t

• OIDs typedef struct gss_OID_desc_struct { OM_uint32 length;

void *value;

} gss_OID_desc, *gss_OID

• OID sets typedef struct gss_set_desc_struct { size_t count;

gsss_OID elements;

} gss_OID_set_desc, *gss_OID_set

• Credentials gss_cred_id_t

• Contexts gss_ctx_id_t


More on data types

• Strings are used for character strings and tokens• Names are an opaque representation of a principal• Object Identifiers (OIDs) are used for

• Security mechanisms• Quality of Protection (QOP) values• Name types

• GSS_C_NT_HOSTBASED_SERVICE (service@host)• GSS_C_NT_USER_NAME (username)• Etc.

• GSS_C_NO_OID for default or null value

• Status codes• OM_uint32 major-status: generic GSS-API routine errors• OM_uint32 minor-status: mechanism-specific errors

• Tokens• Context level tokens: used for context establishment• Per-message tokens: used for data protection (cryptographic tag, encrypted

message)


Name manipulation

• Convert a string to a name and vice versa• gss_import_name(), gss_display_name()

• Compare, duplicate names• gss_compare_name(), gss_duplicate_name()

• Generate a Mechanism Name, a mechanism-specific representation of a name

• gss_canonicalize_name()

• Export a MN in a format suitable for comparison• gss_export_name

• Destroy a name• gss_release_name()


Credential management

• Acquire an existing credential by name• gss_acquire_cred()• If name is GSS_C_NO_NAME , default credential is used

• Obtain information about a credential• gss_inquire_cred(), gss_inquire_cred_by_mech()• name, lifetime, usage (INITIATE, ACCEPT, BOTH), mechanisms

supported

• Destroy a credential handle• gss_release_cred()


Context management

• Establish a secure context• gss_init_sec_context(), gss_accept_sec_context()

• Retrieve residual duration or other info about context• gss_context_time(), gss_inquire_context()

• Export a context from a process to another by means of an interprocess token

• gss_export_sec_context(), gss_import_sec_context()

• Destroy a secure context• gss_delete_sec_context


Confidentiality and integrity

• Generate a cryptographic message integrity code (MIC) for a message to transfer to the peer application

• gss_get_mic()

• Verify the received message against the received MIC• gss_verify_mic()

• Embed the MIC in the (possibly encrypted) message• gss_wrap()

• (possibly decrypt and) verify the embedded MIC• gss_unwrap()


Globus extensions

• Credential import and export• To pass credentials from a process to another or storing them• Export to 1) an opaque buffer, or 2) a file in GSI native format• gss_import_cred(), gss_export_cred()

• Delegation at any time• A lot more flexible than standard GSS-API delegation

• Delegation at times other than context establishment

• Possible to delegate credentials different than those used for context establishment: even for different mechanisms!

– Ex.: delegate a Kerberos credential over a context established with GSI

• gss_init_delegation(), gss_accept_delegation()


GSS Assist

• Simpler functions for• Credential handle creation

major_status = globus_gss_assist_acquire_cred(&minor_status,

GSS_C_INITIATE, /* or GSS_C_ACCEPT */

&credential_handle);

• Context establishmentmajor_status = globus_gss_assist_init_sec_context(&minor_status, credential_handle, &context_handle, (char *) server_princ, GSS_C_DELEG_FLAG|GSS_C_MUTUAL_FLAG, &ret_flags, &token_status, globus_gss_assist_token_get_fd, (void *) &socket_fd, globus_gss_assist_token_send_fd, (void *) &socket_fd);

• Little documentation• http://www.globus.org/security/gss_assist.html

Pointers to functions to send and receive tokens using sockets


The Risks

http://proj-lcg-security.web.cern.ch/proj-lcg-security/RiskAnalysis/risk.html


Further Information

GridGrid

• LCG Security: http://proj-lcg-security.web.cern.ch/proj-lcg-security/

• LCG Registration: http://lcg-registrar.cern.ch/

• Globus Security: http://www.globus.org/security/

BackgroundBackground

• GGF Security: http://www.gridforum.org/security/

• GSS-API: http://www.faqs.org/faqs/kerberos-faq/general/section-84.html

• GSS-API: http://docsun.cites.uiuc.edu/sun_docs/C/solaris_9/SUNWdev/GSSAPIPG/toc.html

• IETF PKIX charter: http://www.ietf.org/html.charters/pkix-charter.html

• PKCS: http://www.rsasecurity.com/rsalabs/pkcs/index.html

security on grid: user interface, internals and apis simone campana lcg experiment integration and...

Documents