# Presentation: 098140

## Materials Microcharacterization Collaboratory

**Security and Instrument Safety**
**James A. Rome**
**ORNL**

## Aspects of security

- Site protection
- Strong user authentication
- Fine-grained authorization
- Data integrity
- Disclosure protection via encryption
- Instrumentation control protocols
- Inter-site communication

## MMC security challenges

- Diversity of platforms at facilities and at users
- Broad, diverse user group
- Some proprietary information
- Inability to require users to install lots of security HW/SW, especially if it isn’t free
- Multiple security venues:
- Online instrument operation and control
- Data analysis and archiving
- Video conferencing

## Basic site protection

- We think that most resources should be behind a firewall provided that it is
- Transparent enough to not “get in the way”
- Fast enough to handle the throughput
- Cheap enough to be affordable
- The Checkpoint Firewall-1 meets these requirements
- $2995 for 25 users (behind the firewall)
- 40 Mbps throughput

## Harmonization

- Because of the diversity of our sites and users, we propose to use Web-based remote access and Web-based remote applications wherever possible.
- SSL provides encryption
- Small user learning curve
- Coming ability to use client public key as the basis for all user interactions
- Many of the MMC facilities are already online with a large base of users.

## Quick and dirty solutions

- We need to get things up and running ASAP because the “nice” solutions will take some time to implement.
- Several sites use Timbuktu (encrypted tunnels)
- General control of the stage and focus of a microscope are straightforward and can be harmonized behind a Web interface
- Site-specific features may have to be “out of band” for a while

## Scale of the collaboratory

- The scalability of security solutions is always an issue.
- The MMC will have no more than a few hundred users
- Can handle certificates and authorizations manually if necessary
- The researchers are generally “trustworthy” folks
- No need for big revocation lists

## Authentication

- Many excellent authentication schemes exist, but most are not available on all platforms
- Smart cards and tokens
- Kerberos and ssh
- X.509 certificates
- Biometrics
- One-time passwords (S-key)

## MMC authentication

- Our solution is to use SSL client certificates
- This public key is his identity for the MMC
- The MMC will issue and sign the certificates
- Entrust WebCA handles this for $1/certificate
- Downloaded to the user’s web browser online
- In Netscape 4.0 these certificates and the corresponding keys can be extracted and used for other purposes
- S/MIME for secure E-mail

## Authentication conclusions

- The client certificate scheme has numerous advantages
- Platform independent
- Cheap
- User friendly — not even a uid/pwd to type
- Can be used as the basis for other authorization
- But,
- The user must protect his keys and Browser

## Authorization

- Traditionally, enforced by file access restrictions.
- File access controls alone are not flexible enough for the MMC
- File access controls may be good enough for protecting data
**Fine-grained authorizations require authorization certificates**

## Authorization scenario

- To use an online facility, we need proof that
- The user has received (and passed) training
- A reservation has been made for a time slot
- A payment may be required
- Additional information is required about the user
- Is the work proprietary?
- Is the user a student, staff, or researcher?
- What site resources does the user need?
- These have nothing to do with file access controls

## SPKI Certificates

- Rather than binding a public key to an identity, what is really wanted is to bind a public key to an action or authorization. This is the goal of SPKI (simple public key infrastructure).
-   http://www.clark.net/pub/cme/spki-reqts.html
-   http://www.clark.net/pub/cme/html/spki.txt
-   http://theory.lcs.mit.edu/~rivest/publications.html

## SPKI certificates have 5 parts

**ISSUER**: The public key of the issuing party both as a name for the issuer and a means to verify the certificate
**SUBJECT**: The public key receiving authority via this certificate
**AUTHORITY**: The specific authorization(s) delegated by this certificate (may be delegated to another subject)
**VALIDITY**: At least an expiration date, but perhaps also a means of online verification (such as a URL)
**SIGNATURE**: Signature of the issuer (and optionally) the subject to accept the authority granted)
*“**<issuer> says that <subject> has attribute <auth>”*

## SPKI trust model

- If a verifier is principal “Self”, then the only 5-tuple he or she can trust is of the form
- <Self, X, *,  A, V>
- where
- 	X is the subject asking to be trusted
- 	A is the authority to be granted
- 	V includes the present time
*I.e., you are the only authority you can really trust to issue a certificate.*

## 5-tuple reduction

- Ignoring the signature field, a SPKI certificate can be represented as a 5-tuple:
*<Issuer, Subject, Delegation, Authority, Validity>*
- I can delegate the issuing authority to you:
- <me, you, D1, A1, V1> + <you, your_user, D2, A2, V2> =
-        <me, your_user, 0, A, V>
- where           D1 >D2	A = intersection (A1,A2)	V = intersection (V1,V2)

## PolicyMaker

- Sometimes, credentials don’t grant the exact <auth> needed, A. Instead, one has a policy which, in effect, accepts <auth>s A1,A2,A3 to be used instead of A.
- PolicyMaker *(**ftp://research.att.com/dist/mab/policymaker.ps**)*allows the formulation of these more complicated (non-intersection) policies.
- Example: you might need authorization from 3 out of 5 Vice Presidents to obtain authorization for a check of $300,000.

## MMC authorization certificates

- We propose to use SPKI certificates to instantiate the bindings between a user’s public key (from his browser client certificate) and each authorization.
- LBNL (Larsen has agreed to provide a certificate engine for us to use by the end of this FY)
- We propose to store the certificates as Cookies on the user’s Web browser
- We will create policy engines to combine multiple input certificates into single device certificates

## Implementation — Year One 

- Put sites behind firewall to stop most Internet-based attacks
- Implement and issue the SSL2 Client certificates
- Survey the sites to determine their needs
- Implement secure Web servers to provide encrypted access to researcher’s E-notebooks
- Obtain authority certificates from LBNL

## Implementation — Year Two

- Required SPKI certificates must be determined and created
- A certificate acquisition process must be created and implemented
- What certificates does a user need?
- Where are they obtained?
- PolicyMaker engines created, integrated, tested
- Pilot deployment at a few sites

## Implementation — Year Three

- Deploy the infrastructure across the MMC
- Provide cross-realm delegation (if desired)
- Implement SPKI security for data analysis tools
- Fix problems as they arise