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.

<Issuer, Subject, Delegation, Authority, Validity> 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