Materials Microcharacterization Collaboratory

Security and Instrument SafetyJames A. RomeORNL

Aspects of security

Site protectionStrong user authenticationFine-grained authorizationData integrityDisclosure protection via encryptionInstrumentation control protocolsInter-site communication

MMC security challenges

Diversity of platforms at facilities and at users

Broad, diverse user groupSome 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 controlData analysis and archivingVideo 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 throughputCheap 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 encryptionSmall user learning curveComing ability to use client public key as

the basis for all user interactionsMany 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 tokensKerberos and sshX.509 certificatesBiometricsOne-time passwords (S-key)

MMC authentication

Our solution is to use SSL client certificatesThis public key is his identity for the MMCThe MMC will issue and sign the

certificatesEntrust WebCA handles this for $1/certificateDownloaded 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 independentCheapUser friendly — not even a uid/pwd to typeCan be used as the basis for other

authorizationBut,

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 thatThe user has received (and passed) trainingA reservation has been made for a time slotA payment may be required

Additional information is required about the userIs 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 trustedA is the authority to be grantedV 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 needsImplement 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