Materials microcharacterization collaboratory
1 / 21

Materials Microcharacterization Collaboratory - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Materials Microcharacterization Collaboratory' - marie

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Materials microcharacterization collaboratory

Materials Microcharacterization Collaboratory

Security and Instrument Safety

James A. Rome


Aspects of security
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
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
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


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


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


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




Spki certificates have 5 parts
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
    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.

    5 tuple reduction
    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)


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