Crypto Hypervisor Technical Sales Presentation

advertisement
Crypto Hypervisor:
A Secure Platform for Encryption that Fits the
Cloud Model
Insert Your Name
Insert Your Title
Insert Date
Who We Are
Trusted to protect the world’s most sensitive data for
the world’s most trusted brands.
We protect the most
money that moves in
the world, $1 trillion
daily.
We protect the most digital
identities in the world.
We protect the most
classified information
in the world.
FOUNDED
OWNERSHIP
1983
Private
REVENUE
GLOBAL FOOTPRINT
~330m
+25,000
Customers in
100 countries
EMPLOYEES
ACCREDITED
+1,400
Products certified
to the highest
security standard
In 25 countries
A Hardware Security Module is…
…a dedicated Hardware crypto
processor…
…designed for Hardware protection
of the crypto key lifecycle…
…validated to be secure by third
parties…
…a “Trust Anchor”…
Crypto Hypervisor uses Hardware Security
Modules as the hardware platform
Dynamic Crypto Resource
Crypto Hypervisor
Hardware Security Module
4
Crypto Hypervisor Extends the Capability of HSMs to
Fit the Cloud Model
NIST1 Cloud Definition of
Essential Characteristics
Legacy
HSMs
NIST1 Cloud Definition of
Essential Characteristics
Crypto
Hypervisor
On-Demand Self-Service
No
On-Demand Self-Service
Yes
Rapid Elasticity
No
Rapid Elasticity
Yes
Measured Service
Yes
Broad Network Access
Yes
Resource Pooling
Yes
Multi-Tenancy2
Yes
Measured Service
Broad Network Access
Resource Pooling
Multi-Tenancy2
1.
2.
Some
Yes
Some
No
National Institute of Standards and Technology
Multi-Tenancy is an essential characteristic added by the Cloud Security Alliance
5
Crypto Hypervisor:
Designed for operational cloud model
1
On-demand
crypto delivery
6
Apps can now
migrate to cloud
2
Self-service
portal for users
5
Part of “New
VM Rollout
Process”
3
New crypto services
spin up easily
4
Encryption now a
cloud enabler
6
Three things to know about Crypto Hypervisor
Built for the cloud
• Shared resource pooling, rapid elasticity and multitenancy
• Can reduce capital costs up to 95%
Lower TCO
• Take advantage of virtualization
• Deliver high-assurance cryptographic resources in a
fraction of the time
• 5 minutes, not 5 hours
Centralized control
• Strong auditing capabilities
• Compliance in the Cloud
• Ensure enterprise-wide consistency of crypto policy
7
Use Case: Enterprise
BEFORE:
 Encryption protects many apps
 Islands of encryption
 Problems:
 Costly
 Complex mgmt/admin
 Requires expertise to deploy
crypto
 New encrypted app rollout is
inefficient
DNSSEC
SSL
© SafeNet Confidential and Proprietary
Database
Email
AFTER CHv:
 CHv: platform for all encryption
 Consolidated to CHv-managed virtual
HSMs
 Benefits:
 Cost savings (hardware)
 Simplified mgmt/admin
 Policies enforced consistently
 New encrypted app rollout is fast
(minutes vs. hours)
Code Sign
8
Solution Highlights
 Host Trust Link (HTL) securely binds virtual applications to dynamic crypto
resources
 Prevents Stolen VM from Accessing Critical Assets
 Crypto Command Center



Simplifies HSM management, through Abstraction of HSM Hardware
Publish Catalogs for on-demand service
Separation of roles/responsibilities in multi-tenancies
 Built on proven platform



Availability: Five 9’s uptime, robust high availability
Validated Security: FIPS 140-2 Level 3 and CC EAL 4+
HW Trust: Keys remain in Hardware!
 Who/What/When Auditing and Logging

Configurable based on your Organizational needs
 Control: Unique Roles for Security in Multi-tenant Environments.

System administrators: manages physical devices (appliances, expansion cards,
etc.), and provision access to resource catalogues for users.

Consumer/User: manage crypto applications that consume crypto services. Own their
HSM resource when ‘leased’.
9
What’s in the Crypto Hypervisor
SafeNet Luna SA 5.2
HSM
Crypto Command Center Bundle
Includes:
• Crypto Command Center Software
• SafeNet Luna G5
• Local PED II
• PED II Keys
Crypto Command Center
SafeNet PED II
SafeNet Luna G5
Feature: Crypto Command Center
11
What is Crypto Command Center?


System (SW) to automate the provisioning of HSM resources
Abstracts the management of HSMs from the end user

Administrators
•
•
•
•
•

Consumers/Users
•
•
•
•

Manage the crypto for your company
Manage the physical HSM devices
Determine what crypto services are offered
Create a catalog of services for end users
Manage who has access to those services
Manage crypto applications that consume crypto services
Own their HSM resource when ‘leased’
Request and release use of HSM resources from catalogues
Always in control of their keys!
Implements REST-ful API or GUI (web based) interfaces (Next Release)
12
Why Use Crypto Command Center?

Trust
•

Save Money
•

Remove the Management burden
from your Application owners
Scale
•

Leverage the HSM resources to
their Fullest
Ease of Use
•

Centralize your Organizations
Cryptographic Trust
HSM Infrastructure that Scales as
your demand grows
Enforce policy and Governance
•
Provide Cryptographic Trust
Anchors that enforce centralized
corporate policy and governance
13
Crypto Hypervisor Enables Crypto as a Service
either on Premise or in the Cloud!
Consumer
Crypto Admin
Crypto
Command
Center
SSH
Crypto
Application
+
Luna Client
Luna SA
Device Pool
Crypto Command Center Terminology
 Service
• A catalog Item becomes a Service once deployed
Organization
HSM End User
Device Pool
Device – Luna SA - 1
Device – Luna SA - 2
Device – Luna SA - 3
System
Catalog
Clone, High Perf, FIPS2, 2MB
Key Extraction, FIPS2, 1MB
Clone, Low Perf, FIPS2, KCDSA
Service
15
Crypto Command Center - Demo Architecture
Jameson Corp
New York
SJames
Crypto Apps
SA 7000 1 (PED, Cloning)
Clone, High Perf, FIPS3, 2MB
SA 1700 1 (PW, Cloning)
Key Extraction, FIPS2, 1MB
SA 1700 1 (PED, Key Export)
Clone, Low Perf, FIPS2, 2MB
SA 7000 1 (PW, Cloning)
System
Device Type
SA Appliance
Code Signing
HSM
admin
Role
sjames
Capabilities
•Performance (H/L)
•Backup (Clone)
•Authentication (PWD)
•Storage size (2MB)
16
Crypto Command Center – Indirect Login
 Luna G5 is initialized as normal
 Upon first “admin” login to CCC
• RSA-2048 key pair is generated on G5
• AES-256 key is generated on G5
• AES Key used to encrypt Appliance Admin password (stored in DB)
 “admin” registers a device
 When “admin” initializes the device…
• The SO password\PED is supplied during initialization
• The “public” key from the G5 is copied to the SO partition on
the device (Luna SA)
• HA_Init is called on the device (Luna SA)
17
Crypto Command Center – Indirect Login
 Indirect Login procedure…
1.
2.
3.
4.
5.
6.
7.
8.
“Token Wrapper Cert” (TWC) created on G5
TWC sent to Luna SA
Luna SA wraps a “challenge” with TWC
Wrapped “challenge” sent to G5
G5 “unwraps” the challenge with Private Key
G5 generates a challenge response
Challenge response is sent to Luna SA
Luna SA confirms challenge response (valid\invalid)
18
Crypto Command Center – Indirect Login
 No HSM token or domain information is stored in the
database
 Indirect Login occurs when…
• CCC admin initializes a device
• Consumer initializes and releases a service
19
Feature: Host Trust Links
20
Host Trust Link
 What is it?
• “Host Trust Link”
• Works on Virtual Machines and traditional OS systems
 Why Use it?
• Trust
• Virtual Machines are meant to be portable
• HTL protects against a Stolen VM accessing your HSM
resources
• Ease of Use
• Built into HSM client registration process
21
VM is Stolen…VMs with “HTL” Host Trust Link
•
•
•
•
Prevents theft of an at-rest VM image
Connection to the SA is authorized by a one-time token
Includes a step counter that must sync with the SA
NTLS depends on an active HTL connection
HSM Client VM
NTLS
X
Access Denied
Luna SA
Today:
• Stolen VM will not be granted access to
SA partition
• Stolen image does not have OTT,
required to establish HTL Link
HTL … More info
 Can multiple client systems with same HTL security credentials operate
simultaneously?
• No – only first HTL connection will be authorized, all subsequent will be
rejected
 OTT details:
• RNG from FIPS validated HSM
• OTT bound to specific client (leverages client registration details)
• OTT details stored in client system RAM
 Once HTL is established – how is the trust maintained?
• Sync beacon (counter) created by HSM
• Client required to send beacon back to HSM to maintain HTL link
 Sync Beacon details:
• Grace Period (period after beacon has NOT been received)
•
•
•
•
Default 60 seconds
Configurable 0-10+ minutes
Allows for existing OTT to be re-established (within Grace period)
If Grace period surpassed, OTT regen and administrative step for reconnection required
23
HTL … More info
 What is required when a VM is moved, in a trusted
environment:
• Assuming Client registration details are the same (Certs/IP/etc)
• HSM Admin:
• Regen OTT
• Push OTT to new target VM
 HTL and NTLS (network link)
• NTLS requires validated HTL Connection
•
•
Wont start
And Will be actively ‘torn down”
 What does HTL Bind to:
• Client IP
• Client OTT
 Why not Bind to physical Machine attributes:
• Not available via standard mechanisms exposed via VM
24
Host Trust Link
 Configuration required on SA and Client side
 HTL configuration is on a per client basis
• Single client configured for two Luna SA appliances
• Need to configure HTL for both members
25
Host Trust Link
 HTL Setup
•
•
•
•
On SA, configure client to require HTL
On client, configure to require HTL
On SA, generate OTT
On client
• Copy (scp) from Luna SA
• Move to HTL folder
• C:\Program Files\Safenet\LunaClient\htl
• /usr/safenet/lunaclient/htl
26
Feature: Secure Audit Logs
27
Why log?
 Want to be able to Audit all HSM operations
• Who/What/When?
• Was the operation a Success or Failure?
 Want to ensure the Origin of the logs
• Messages come from this HSM
 Want to ensure the Integrity of the logs
• No Alterations
• No Deletions
• No Truncation
Meet Audit and Compliance Mandates
© SafeNet Confidential and Proprietary
28
What Gets Logged – Categories
 Critical
• Tamper, HSM init, Audit init, Zeroize
• Always logged
 HSM Management
• change password, create challenge, change policies
 HSM Access
• Login/Logout
 Key Management
• key creation/deletion
 Key Usage
• use of key for crypto ops (‘First Use Only’ flag)
 External
• CA_LogExternal API messages
 Log Management
• Log management related commands (import/export secret, verify)
© SafeNet Confidential and Proprietary
29
How it works
 “HMAC chain”
• Each log record signed with SHA256 HMAC
• HMAC calculated from
• Previous record HMAC
• Internal log secret
• Log secret is set at manufacture and generated during first powerup
• Current event data
• Most recent HMAC saved to NVRAM
• Logged to internal HSM memory
• Logging Daemon
• Signed log record offloaded to host
© SafeNet Confidential and Proprietary
30
Verification
 Submit sequence of signed log records
• Include HMAC of final message
• HSM recalculates HMAC chain
• Compares to received
 Origin
• Log secret unique to HSM
 Integrity
• HASH chain must match
 Can verify on other HSMs
 Log secret can be exported to another Luna SA to enable log
validation
© SafeNet Confidential and Proprietary
31
Audit Role
 Independent of Security Officer
• Audit config is preserved over HSM init and Factoryreset
• White key for FIPS L3 (Associated with Domain key)
 Audit user:
• Set event categories/conditions
• Sync system time
• Verify logs
 SO:
• Verify system logs
© SafeNet Confidential and Proprietary
32
Audit Logging
 Audit logging is separate from traditional logging
• Audit logging must be initialized and configured
• Can be done anytime
• init, tamper, zeroize, audit role creation are always
logged… log file can’t be accessed unless “audit” role
exists
33
Audit Logging
 Time used for log is UTC
 Audit role has ability to sync time (manually) between
the HSM and CLIENT
 Syslog server can be used
• UDP or TCP supported
• Port can be customized
34
Performance Impact
 Logging requires crypto operations
• Logging serializes command execution
• HMAC calculation
 Tradeoff – performance vs. amount logged
 Reduce impact
• Only log necessary data
• “First Use” modifier for key usage logging
© SafeNet Confidential and Proprietary
35
Other Features
36
Common Client
 Common Client For SA/PCI-E/G5
• One install package
• Choose products/features
• Including remote PED and remote Backup
• Choose APIs
• PKCS#11, Java, JCProv, Microsoft CSP,KSP
• Choose Production or Development
• SDK and samples
37
Common Client
 Enhanced OS Support
•
•
•
•
•
Windows 2008R2, 2012
Linux (RedHat 5, 6, SUSE 10, 11, Debian 6)
Solaris 10,11
AIX 6.1, 7.1
HP-UX 11iv3 (11.31)
38
Remote Backup Improvements
 Backup to remote Backup HSM
 Simplified with remote PED!
 Don’t need to configure backup HSM to be a client of
the partition!
39
Remote Backup Improvements
 Configuration
• Install RBS (Remote Backup Service)
• Part of Luna client install
• Generate RBS cert
• Copy cert to client
• ‘vtl addserver’
• Now backup HSM shows as a network slot
 Backup
• ‘lunacm partition backup’
• Set target slot as remote backup slot
40
Remote Backup – High Level Architecture
Client Server
Luna
CM
1 SSH
Crypto
App
System Admin
PED
Server
4
2
3
1. SSH/RDP to Client
2. Setup rPED to SA and
Login to Partition
3. Setup rPED to RBS
4. Lunacm>par backup
Remote
Backup
Server
PED
Client
RBS
Backup
HSM
41
Other
 JCProv
• Java-PKCS#11 API
 Upgradable PED
• Any PED with FW 2.4.0-3 can be upgraded
• Need to upgrade for Audit logging
• Can’t change between Local and Remote PED
42
Download