# Presentation: 148705

## Security and Certificate Management

- Discussion of AG security in the abstract
- How does the AG approach security
- Using the AG security mechanisms

## What does security mean?

- No one can hear our budget discussion
- I can tell exactly who is hearing our budget discussion
- I won’t get fired if I use AG 2.x
- I won’t get fired, and I can blame ag-dev@mcs.anl.gov  if someone breaks in while I’m using AG 2.x
- I can put my AG Node behind the department firewall and everything will be cool
- Everything is encrypted and password protected
- The script kiddies won’t get me

## AG Threat Model

- A threat model describes...
- ... attackers’ resources
- ... what attacks are expected to be mounted
- ... what attacks we aren’t going to worry about
- Assumptions
- End systems not compromised
- How to ensure this? (classical system intrusion detection mechanisms)
- Attacker has complete control over communications channel
- Steal packets
- Generate packets
- Forge packets

## Passive attacks

- Attacker reads packets from the network
- Packet sniffing from shared LAN (Ethernet, wireless)
- Goal:
- Obtain private information
- Credentials
- Passwords
- Confidential data
- Offline cryptographic attacks
- Multicast
- Anyone can listen in!

## Active attacks

- Spoofing attacks
- Denial of service
- Replay attacks
- Message insertion / deletion / modification
- Man in the middle
- Goals:
- Disruption of service
- Hijacking of data channels
- For fun and profit

## Social Engineering Attacks

- Strong encryption isn’t all there is
- “Hi,I lost my password, can you reset it and tell me what it is?”
- Security of passwords and private keys

## What are we protecting in the Access Grid?

- Media streams
- Audio
- Video
- “Presentations”
- PowerPoint
- HTML slide shows
- MPEG movies
- Visualizations
- Node hardware
- System software

- Shared documents
- Control streams
- Data
- Nuke simulations
- Design documents
- Models
- Shared applications

## From whom?

- Inadvertent lurkers
- the abandoned node problem
- Over-interested third parties
- Everyone but those invited to private meetings
- Hackers intent on destroying our data
- Competitors

## How do we do this?

- Identify users and nodes
- Authenticate them with an authority we trust
- Authorize their access to the resources they request
- Provide them privacy and secure access to their applications and data

## Classic components of computer security

- In the abstract:
*Identification* of users and services
*Authentication* of the identity of these users and services
*Authorization* for access to resources
*Confidentiality* of data (files, streams, control, etc.)
- (*Non-repudiation*)
- More concretely...

## Identification

- Each user identified
- What’s in a name?
- Each server or service identified
- Similar to mechanism used by SSL-secured websites (do you check their certificates?)
- Basis for authorization

## Authentication

- Mechanism by which an assertion of identity is verified
- In the AG, authentication performed each time a client/server transaction occurs
- (Provided by underlying toolkit)

## Authorization

- Determination if the authenticated identity of the requestor is allowed access to a resource
- AG toolkit defines role-based authorization mechanisms
- Access control to venues
- Administrative access to venues, venue servers
- Open to third-party application code as well

## Confidentiality

- Privacy of control connections (SSL)
- Privacy of media streams (media tools + AES/Rijndael)
- Privacy of venue data, other venue app interactions (SSL)

## Stream Security

- Current vic / rat support AES/Rijndael encryption
- Key distribution via venues services mechanisms
- Per RFC1889
- Vague worries...
- Are keys recoverable (in face of many gigabytes of encrypted data)
- Rekeying intervals?
- IETF Secure RTP draft (draft-ietf-avt-srtp-02)

## How are these accomplished?

- Key supporting technology: *Public-key Infrastructure*

## Digression into Cryptography

- Symmetric or shared-key encryption
- The same key is used for encryption and decryption
- High-speed ciphers available
- Key distribution is a problem

## Cryptography, cont.

- Public-key cryptography
- Different keys used for encryption and decryption
- Public key is published
- Private key is held private
- Used to implement message authentication, digital signatures
- Much much slower than symmetric encryption
- Typically used in conjunction with X.509 certs for authentication, key exchange

## SSL

- Secure Sockets Layer
- Key protocol in the AG, uses PKI certificates to authenticate clients and servers for connection-oriented communications
- Public-key crypto used to bootstrap a shared-key cipher for high-speed data communication
- AG uses SSL via the Globus Toolkit

## How are these accomplished?

- Key supporting technology: *Public-key Infrastructure*
- Identity asserted by X.509 *Identity Certificate*
- Contains a  *subject name* and a *public key*
- Also contains the name of the cert’s *issuer*
- Digitally signed by a Certificate Authority (the issuer)
- Signature asserts that the CA believes the holder of the private key has the identity asserted in the certificate
- SSL uses challenge/response mechanism to verify the presenter of a cert holds the private key

## What’s in a Name?

- X.509 names are X.500 *Distinguished Names*
- Sequence of key-value pairs
- Keys come from the set
- CN, common name		O, organization
- C, country			OU, organizational Unit
- L, locality
- ST, state

## Naming, cont.

- For instance:
- O=Grid, O=Globus, OU=mcs.anl.gov, CN=Bob Olson
- C=US, O=Globus, CN=Globus Certification Authority
- DC=net, DC=ES, O=ESnet, OU=Certificate Authorities, CN=ESnet Root CA 1

## PKI in the AG

- Each user has an identity cert
- Each server and service has an identity cert
- Communications use SSL (via Globus ToolkitTM)
- SSL provides mutual authentication on each connection
- Each peer knows identity of the other
- SSL provides confidentiality

## Proxy Certificates

- Mechanism to support single sign-on
- Create short-lived proxy identity certificates from long-lived certificate
- Why?
- Identity cert’s private key is encrypted on-disk with a passphrase
- Proxies kept without passphrases
- Delegation mechanism used in Globus for information access, process startup, etc.
- Restricted proxies

## We’re all set?

- Well..
- “Digitally signed by a Certificate Authority”
-  Verification of this requires the identity certificate of the CA
- How is that verified?
- Chain of certificates leading to a *Root CA Certificate*
- Root CA cert is *self-signed*
- Where does it come from?
- Applications configured with set of CA certificates

## Cert Chain Example

- My DOE Science Grid cert:
- subject: /DC=org/DC=doegrids/OU=People/CN=Robert Olson 516682
- issuer: /DC=org/DC=DOEGrids/OU=Certificate Authorities/CN=DOEGrids CA 1
- Issuer:
- subject: /DC=org/DC=DOEGrids/OU=Certificate Authorities/CN=DOEGrids CA 1
- issuer: /DC=net/DC=ES/O=ESnet/OU=Certificate Authorities/CN=ESnet Root CA 1
- Its issuer:
- subject: /DC=net/DC=ES/O=ESnet/OU=Certificate Authorities/CN=ESnet Root CA 1
- issuer: /DC=net/DC=ES/O=ESnet/OU=Certificate Authorities/CN=ESnet Root CA 1

## PKI in the AG, in practice

- Each user has an identity certificate
- Issued by a CA:
- Globus Project CA (ending service this year)
- Access Grid Developer’s CA (integrated with software)
- Other CAs
- DOE Science Grid
- NCSA
- EUROGRID
- Verisign, Thawte, ...

## Managing Trust

- Each client and server has a set of trusted CA Certificates
- For a connection to be allowed from a peer, both peers must have CA certs for their peer’s identity certificate
- AG software ships with AGDev CA cert, Globus CA cert.
- Additional CA certs may be imported via Certificate Manager

## AG Certificate Manager

- Holds user identity certificates
- Holds trusted CA certificates
- Holds private keys
- Generates certificate requests
- Provides GUI interface for manipulation of certificates

## Authorization, in detail

- The authorization problem:
- Allow access to a resource to only those users to which we wish to allow access.
- Resources might include
- Virtual venues
- Shared files
- Shared applications
- Both static and dynamic policies required
- Give access to any user currently in the venue
- AG uses *Role-based Access Control*

## Role-based Access Control

*Permissions*
- associated with *roles*
- defined in the context of some resource
*Users*
- assigned to roles based on some policy
- identified by a PKI distinguished name

## Roles defined in the AG

- VenueServer.Administrators
- Static role, those users whom can modify a venue server
- Venue.AllowedEntry
- These users are allowed to enter a venue
- Venue.VenueUsers
- Current users in the venue.

## Enforcement of Authorization

- AG Toolkit runtime library determines identity of caller of web service
- (Uses authenticated identity delivered by underlying communication layers)
- At locations where access control decisions are made, toolkit call determines if current user is a member of the required role
- Runtime exception thrown if user not authorized for operation

## Identity Maintenance Alternatives

- Current implementation requires identity certificate on each computer a user uses
- Private key must be copied about along with identity certificate
- Impediment to easy roaming
- Multiple shared nodes
- Multiple computers
- Possible solutions
- Hardware tokens
- Certificate proxying
- Online certificate authorities

## Hardware Tokens

- Certificate and private key held in tamperproof device (memory + low-power CPU)
- Token attached to computer, used to create proxy certificate for use with AG software
- Proof of concept done in past with Globus toolkit, no recent work
- Requires hardware, possibly per-device driver support on target computers
- Possibly more useful in targeted (corporate?) environments

## Certificate Proxying

- User holds identity certificate at “home”
- User delegates a proxy of certificate to a proxy server
- Proxy retrieved by AG software
- NCSA MyProxy
- Online proxy storage for standard identity certificates
- Medium-term expiration proxies kept at central server
- Proxies created via username/password authentication

## Online CA 

- Identity certificates held at an online CA
- Proxies created via username/password authentication
- No requirement for user storage of certs
- Globus CA moving toward this
- Possible integration with Shibboleth or other single sign-on infrastructure

## Certificate Manager Operations

- Importing initial Globus environment
- Requesting certificate
- Retrieving approved cert
- Importing other CA or identity certs

## Importing Globus environment

- Upon first execution of AG code, Certificate Manager (CM) will attempt to import an existing Globus environment
- user cert
- CA certs
- proxy location
- Where possible, integrates properly with other Globus applications on system
- Mostly applicable to Linux systems

## Initial import

- Prompts for private key passphrase:

## Certificate Request

- If no certificate is found, client prompts to request a cert via the AGdev CA:

## User Information

- Prompts for information to enter into certificate:

## Final confirmation

- Verification of data:

## What now?

- The submission will send a *certificate request* document to the AGdev CA.
- A *private key* is created and protected with the password specified by the user
- When the AGdev CA signs the key, a confirmation email is sent and the signed certificate is available for retrieval.

## Retrieving a Certificate

- At the next startup of the AG client, the following window will appear:
- “Not Ready” means the certificate has not been issued yet

## Retrieving, cont.

- Clicking *Update Status* queries the CA server to detect changes in status. When cert is ready, the window will look thus:

## Retrieving, cont.

- Click on the certificate name in the dialog, and press *Import Certificate.* If all goes well, you will be prompted to create a Globus proxy for the new certificate:

## Retrieving, cont.

- And if all is successful, the following dialog appears:

## Importing existing Identity Cert

- Bring up the certificate manager:

## Importing, cont.

## Importing, cont.

- Press *Import*.
- Browse to your identity cert file
- PEM format:
- -----BEGIN CERTIFICATE-----
- MIICHTCCAYagAwIBAgICM64wDQYJKoZIhvcNAQ
- DzANBgNVBAoTBkdsb2J1czEnMCUGA1UEAxMeR2
- -----END CERTIFICATE-----
- If cert file does not contain a private key, browse to your private key file (also PEM)

## Importing, cont.

- A passphrase dialog will open:
- Enter passphrase and press *OK*. If import is successful, certificate will appear:

## Importing, cont.

- Click on the name to view the details.

## Default Identities

- One identity is tagged *(DEFAULT).*
- Default identity is used in connections to servers.
- To change the default, select the identity and press *Set as default identity.*

## Importing existing CA  Cert

- Bring up the certificate manager:

## Importing CA, cont.

## Importing CA, cont.

- Press *Import* and browse to the PEM-formatted CA certificate.
- Also must supply Globus *signing policy* file
- Normally named like the CA cert but ending in .signing_policy
- CA certs often named xxxxxxxx.0 where x is a number or a letter a-f.

## Security: Authentication

- Assumptions:
- Authentication takes place on a transaction between a client and a server
- Client and server each hold an identity cert
- Authentication is *mutual*: After completion, client and server have verified identity of the other party
- Secured communications in AG2 use Globus...
- ...which uses SSL/TLS
- SSL/TLS defines protocol for a secure handshake with mutual authentication.