1. Materials Microcharacterization Collaboratory Security and Instrument Safety James A. Rome ORNL

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

3. MMC security challenges zDiversity of platforms at facilities and at users zBroad, diverse user group wSome proprietary information zInability to require users to install lots of security HW/SW, especially if it isn’t free zMultiple security venues: wOnline instrument operation and control wData analysis and archiving wVideo conferencing

4. Basic site protection We think that most resources should be behind a firewall provided that it is zTransparent enough to not “get in the way” zFast enough to handle the throughput zCheap enough to be affordable The Checkpoint Firewall-1 meets these requirements z$2995 for 25 users (behind the firewall) z40 Mbps throughput

5. 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. zSSL provides encryption zSmall user learning curve zComing 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.

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

7. Scale of the collaboratory The scalability of security solutions is always an issue. zThe MMC will have no more than a few hundred users wCan handle certificates and authorizations manually if necessary zThe researchers are generally “trustworthy” folks wNo need for big revocation lists

8. Authentication Many excellent authentication schemes exist, but most are not available on all platforms zSmart cards and tokens zKerberos and ssh zX.509 certificates zBiometrics zOne-time passwords (S-key)

9. MMC authentication Our solution is to use SSL client certificates zThis public key is his identity for the MMC zThe MMC will issue and sign the certificates wEntrust WebCA handles this for $1/certificate wDownloaded to the user’s web browser online zIn Netscape 4.0 these certificates and the corresponding keys can be extracted and used for other purposes wS/MIME for secure E-mail

10. Authentication conclusions The client certificate scheme has numerous advantages zPlatform independent zCheap zUser friendly — not even a uid/pwd to type zCan be used as the basis for other authorization But, zThe user must protect his keys and Browser

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

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

13. 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

14. SPKI certificates have 5 parts zISSUER: The public key of the issuing party both as a name for the issuer and a means to verify the certificate zSUBJECT: The public key receiving authority via this certificate zAUTHORITY: The specific authorization(s) delegated by this certificate (may be delegated to another subject) zVALIDITY: At least an expiration date, but perhaps also a means of online verification (such as a URL) zSIGNATURE: Signature of the issuer (and optionally) the subject to accept the authority granted) “ says that has attribute ”

15. SPKI trust model If a verifier is principal “Self”, then the only 5- tuple he or she can trust is of the form 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.

16. 5-tuple reduction Ignoring the signature field, a SPKI certificate can be represented as a 5-tuple: I can delegate the issuing authority to you: + = where D1 >D2 A = intersection (A1,A2) V = intersection (V1,V2)

17. PolicyMaker Sometimes, credentials don’t grant the exact needed, A. Instead, one has a policy which, in effect, accepts 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.

18. 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. zLBNL (Larsen has agreed to provide a certificate engine for us to use by the end of this FY) zWe propose to store the certificates as Cookies on the user’s Web browser zWe will create policy engines to combine multiple input certificates into single device certificates

19. Implementation — Year One zPut sites behind firewall to stop most Internet- based attacks zImplement and issue the SSL2 Client certificates zSurvey the sites to determine their needs zImplement secure Web servers to provide encrypted access to researcher’s E-notebooks zObtain authority certificates from LBNL

20. Implementation — Year Two zRequired SPKI certificates must be determined and created zA certificate acquisition process must be created and implemented wWhat certificates does a user need? wWhere are they obtained? zPolicyMaker engines created, integrated, tested zPilot deployment at a few sites

21. Implementation — Year Three zDeploy the infrastructure across the MMC zProvide cross-realm delegation (if desired) zImplement SPKI security for data analysis tools zFix problems as they arise