Post on 14-Feb-2016
description
Materials Microcharacterization Collaboratory
Security and Instrument SafetyJames A. RomeORNL
Aspects of security
Site protectionStrong user authenticationFine-grained authorizationData integrityDisclosure protection via encryptionInstrumentation control protocolsInter-site communication
MMC security challenges
Diversity of platforms at facilities and at users
Broad, diverse user groupSome 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 controlData analysis and archivingVideo conferencing
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 throughputCheap enough to be affordable
The Checkpoint Firewall-1 meets these requirements
$2995 for 25 users (behind the firewall)40 Mbps throughput
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 encryptionSmall user learning curveComing ability to use client public key as
the basis for all user interactionsMany of the MMC facilities are already online with a large base of users.
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
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
Authentication
Many excellent authentication schemes exist, but most are not available on all platforms
Smart cards and tokensKerberos and sshX.509 certificatesBiometricsOne-time passwords (S-key)
MMC authentication
Our solution is to use SSL client certificatesThis public key is his identity for the MMCThe MMC will issue and sign the
certificatesEntrust WebCA handles this for $1/certificateDownloaded 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
The client certificate scheme has numerous advantages
Platform independentCheapUser friendly — not even a uid/pwd to typeCan be used as the basis for other
authorizationBut,
The user must protect his keys and Browser
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
Authorization scenario
To use an online facility, we need proof thatThe user has received (and passed) trainingA reservation has been made for a time slotA payment may be required
Additional information is required about the userIs 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
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
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
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 trustedA is the authority to be grantedV includes the present time
I.e., you are the only authority you can really trust to issue a certificate.
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)
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.
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
Put sites behind firewall to stop most Internet-based attacks
Implement and issue the SSL2 Client certificates
Survey the sites to determine their needsImplement secure Web servers to provide
encrypted access to researcher’s E-notebooks
Obtain authority certificates from LBNL
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
Deploy the infrastructure across the MMC
Provide cross-realm delegation (if desired)
Implement SPKI security for data analysis tools
Fix problems as they arise