/
Andrew Prout, William Arcand, David Bestor, Chansup Byun, Bill Bergeron, Matthew Hubbell, Andrew Prout, William Arcand, David Bestor, Chansup Byun, Bill Bergeron, Matthew Hubbell,

Andrew Prout, William Arcand, David Bestor, Chansup Byun, Bill Bergeron, Matthew Hubbell, - PowerPoint Presentation

jane-oiler
jane-oiler . @jane-oiler
Follow
351 views
Uploaded On 2018-10-31

Andrew Prout, William Arcand, David Bestor, Chansup Byun, Bill Bergeron, Matthew Hubbell, - PPT Presentation

2012 IEEE High Performance Extreme Computing Conference 10 12 September 2012 Scalable Cryptographic Authentication for High Performance Computing This work is sponsored by the Department of the Air Force under Air Force contract FA872105C0002 Opinions interpretations conclusions and reco ID: 705820

user authentication keyd cryptographic authentication user cryptographic keyd daemon virtual pki specific server request smartcard key pkcs trust keys

Share:

Link:

Embed:

Download Presentation from below link

Download Presentation The PPT/PDF document "Andrew Prout, William Arcand, David Best..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.


Presentation Transcript

Slide1

Andrew Prout, William Arcand, David Bestor, Chansup Byun, Bill Bergeron, Matthew Hubbell, Jeremy Kepner, Peter Michaleas, Julie Mullen, Albert Reuther, Antonio Rosa2012 IEEE High Performance Extreme Computing Conference10 - 12 September 2012

Scalable Cryptographic Authentication for High Performance Computing

This work is sponsored by the Department of the Air Force under Air Force contract FA8721-05-C-0002. Opinions, interpretations, conclusions and recommendations are those of the author and are not necessarily endorsed by the United States Government.Slide2

What is the LLGridThe Problem: External services authenticationThe Solution: Cryptographic authenticationResults

OutlineSlide3

LLGrid is a ~500 user ~2000 processor systemWorld’s only desktop interactive supercomputerDramatically easier to use than any other supercomputerHighest fraction of staff using (20%) supercomputing of any organization on the planet

Foundation of Supercomputing in Massachusetts

LLGrid System Architecture

LAN Switch

Network

Storage

Resource Manager

Configuration

Server

Compute Nodes

Service Nodes

Cluster Switch

To Lincoln LAN

Users

LLANSlide4

All jobs run on LLGrid

LLGrid Usage

1 10 100 1000

Total Job duration (seconds)

1 100 10000 1M

Classic Supercomputing

Interactive

Supercomputing

Processors used by Job

TX-2500 (952 Cores)

TX-X (220 Cores)

TX-3d (540 Cores)

Desktop Computing

CPU-time <20 minutes

Classic Supercomputing

Wall-clock time >3 hours

Interactive Supercomputing

Between desktop and classic supercomputing

Shortens the “time to insight”

Ten development turns/day instead of one turn/week

Desktop ComputingSlide5

What is the LLGridThe Problem: External services authenticationThe Solution: Cryptographic authenticationResults

OutlineSlide6

As the line between a shared supercomputer and a “really powerful personal computer” blurs, users expect to have access to network resources (storage, svn, cvs, etc).

Challenges withInteractive Supercomputing

Challenge: Users expect seamless access to other network resources from the HPC.Slide7

However these commands raise security concerns.They store passwords as plain-text on the HPC central storage.

Password synchronization has made this password very sensitive.

Challenges with

Interactive Supercomputing

Challenge: Ensure seamless access without putting the user’s “one common password” at risk.

“S3cr3t”Slide8

What is the LLGridThe Problem: External services authenticationThe Solution: Cryptographic authenticationResults

OutlineSlide9

Cryptographic authentication of clients using X509 PKI certificates has long been part of the SSL and TLS standards.The root of trust will certify that a specific keypair belongs to a specific user or process.Cryptographic Authentication

User

ServerSlide10

Cryptographic authentication of clients using X509 PKI certificates has long been part of the SSL and TLS standards.The root of trust will certify that a specific keypair belongs to a specific user or process.Cryptographic Authentication

User

Server

Connection RequestSlide11

Cryptographic authentication of clients using X509 PKI certificates has long been part of the SSL and TLS standards.The root of trust will certify that a specific keypair belongs to a specific user or process.Cryptographic Authentication

User

Server

Connection Request

Authentication Request

ASlide12

Cryptographic authentication of clients using X509 PKI certificates has long been part of the SSL and TLS standards.The root of trust will certify that a specific keypair belongs to a specific user or process.Cryptographic Authentication

User

Server

Connection Request

Authentication Request

A

ASlide13

Cryptographic authentication of clients using X509 PKI certificates has long been part of the SSL and TLS standards.The root of trust will certify that a specific keypair belongs to a specific user or process.Cryptographic Authentication

User

Server

Connection Request

Authentication Request

Signed Authentication Response

and copy of PKI certificate

A

ASlide14

Cryptographic authentication of clients using X509 PKI certificates has long been part of the SSL and TLS standards.The root of trust will certify that a specific keypair belongs to a specific user or process.Cryptographic Authentication

User

Server

Connection Request

Authentication Request

Signed Authentication Response

and copy of PKI certificate

A

A

ASlide15

Cryptographic authentication of clients using X509 PKI certificates has long been part of the SSL and TLS standards.The root of trust will certify that a specific keypair belongs to a specific user or process.Cryptographic Authentication

User

Server

Connection Request

Authentication Request

Signed Authentication Response

and copy of PKI certificate

A

A

A

Access Granted: Welcome Andy!Slide16

Cryptographic authentication depends on both the security of the user’s private key and access to it.Storing the private key on central storage is little different than storing a user’s password.

Challenges with

Cryptographic Authentication

Challenge: Where to store the private key?Slide17

Cryptographic authentication depends on both the security of the user’s private key and access to it.Storing the private key on central storage is little different than storing a user’s password.

Challenges with

Cryptographic Authentication

No guarantee the key won’t be lost, copied or left unprotected.Slide18

One traditional solution is to store the key on the client system and forward authentication requests back to the user’s system.

Could be on the client system or in a smart card.

Challenges with

Cryptographic AuthenticationSlide19

Challenges withCryptographic Authentication

Forwarding requests back doesn’t work forsemi-interactive computing or background jobs.

Poof!

One traditional solution is to store the key on the client system and forward authentication requests back to the user’s system.

However this fails if the user disconnects from the HPC.Slide20

Challenges withCryptographic Authentication

Poof!

Connecting smart cards to the HPC is not practical.

Some network-attached key storage devices exist, but their practical benefit in this scenario is questionable.Slide21

Challenges withCryptographic Authentication

Poof!

We implemented a virtual smart card to run on each node.

Allows for keys to be used on any node, connected or disconnected.

Allows for different keys on each node.Slide22

Uses the smart card communication API: PKCS#11.Authenticates users and allows authorized users to perform cryptographic operations.Protects private keys from being copied, even by authorized users of the key.High throughput capability & low latency.Physical smart cards have a latency approximately 800-900ms.

Virtual Smart Card DefinedSlide23

We created the keyd daemon to be the brains of our virtual smartcard.Runs as it’s own user account.The keyd Daemon: A Virtual Smartcard

KeydSlide24

We created the keyd daemon to be the brains of our virtual smartcard.Runs as it’s own user account.Has access to all the keys.

The keyd Daemon: A Virtual Smartcard

KeydSlide25

We created the keyd daemon to be the brains of our virtual smartcard.

Runs as it’s own user account.Has access to all the keys.

We then created a library that conformed to the PKCS#11 standard and could talk to this daemon.

Loaded by applications running as a HPC user.

The keyd Daemon: A Virtual Smartcard

Keyd

PKCS#11Slide26

We created the keyd daemon to be the brains of our virtual smartcard.

Runs as it’s own user account.Has access to all the keys.

We then created a library that conformed to the PKCS#11 standard and could talk to this daemon.

Loaded by applications running as a HPC user.

Connects through a unix socket.

User credentials passed through the socket

Secure, provided you trust your linux kernel.

The keyd Daemon: A Virtual Smartcard

Keyd

PKCS#11Slide27

We created the keyd daemon to be the brains of our virtual smartcard.

Runs as it’s own user account.Has access to all the keys.

We then created a library that conformed to the PKCS#11 standard and could talk to this daemon.

Loaded by applications running as a HPC user.

Connects through a unix socket.

User credentials passed through the socket

Secure, provided you trust your linux kernel.

The SVN client can then load the PKCS#11 library and use the keys to authenticate to the SVN server.

The keyd Daemon: A Virtual Smartcard

Keyd

PKCS#11Slide28

We created the keyd daemon to be the brains of our virtual smartcard.

Runs as it’s own user account.Has access to all the keys.

We then created a library that conformed to the PKCS#11 standard and could talk to this daemon.

Loaded by applications running as a HPC user.

Connects through a unix socket.

User credentials passed through the socket

Secure, provided you trust your linux kernel.

The SVN client can then load the PKCS#11 library and use the keys to authenticate to the SVN server.

Other applications can be enabled in the future.

The keyd Daemon: A Virtual Smartcard

Keyd

PKCS#11Slide29

The SVN server was configured to accept the LLGrid’s root of trust.The SVN client on the LLGrid was configured to load the keyd daemon PKCS#11 library.One configuration entry: ssl-pkcs11-provider=libkeyd_pkcs11

Configuring SVN for TLS Client Auth

SVN User

SVN Server

Connection Request

Authentication Request

Signed Authentication Response

and copy of PKI certificate

A

A

A

Keyd DaemonSlide30

What is the LLGridThe Problem: External services authenticationThe Solution: Cryptographic authenticationResults

OutlineSlide31

Keypair generation and X509 PKI certificate creation is performed during user account creation.LLGrid Adminstrators act as the root of trust.We developed scripts that execute parallel key generation across nodes in the cluster.

X509 PKI Certificate Enrollment

Nodes

Time (seconds)

Keypair & Certificate Generation

Each certificate asserts both the user identity and the node identity to meet the guidelines to be used for either server or client TLS authentication.Slide32

Created a general purpose key storage and certificate management solution for HPC.Keys are not managed by the end-user, ensuring a low risk of compromise requiring revocation.Demonstrated that it can be used to enable single sign-on integration to systems outside of the HPC.

Mitigated security concerns over passwords being stored on the LLGrid central storage.Avoided the issue of periodic password changes impacting batch processing.

ResultsSlide33

Future work will look to use these PKI certificates to secure inter-node web services communication.Certificates are valid for both TLS client or server authentication.Future WorkSlide34

Questions?