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 isnt 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 users 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.h
  tml

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)
• ltissuergt says that ltsubjectgt has attribute
  ltauthgt

15
SPKI trust model

• If a verifier is principal Self, then the only
  5-tuple he or she can trust is of the form
• ltSelf, X, , A, Vgt
• 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
• ltIssuer, Subject, Delegation, Authority,
  Validitygt
• I can delegate the issuing authority to you
• ltme, you, D1, A1, V1gt ltyou, your_user, D2, A2,
  V2gt
• ltme, your_user, 0, A, Vgt
• where D1 gtD2 A intersection
  (A1,A2) V intersection (V1,V2)

17
PolicyMaker

• Sometimes, credentials dont grant the exact
  ltauthgt needed, A. Instead, one has a policy
  which, in effect, accepts ltauthgts A1,A2,A3 to be
  used instead of A.
• PolicyMaker (ftp//research.att.com/dist/mab/polic
  ymaker.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 users 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 users 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 researchers 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