Materials Microcharacterization Collaboratory

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 • 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

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

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

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

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

8. 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)

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

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

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

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

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 • 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>”

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

16. 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)

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

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

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

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

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