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

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

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

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