3. …and Duality of Use
• Encryption in transit
– Interesting in elastic / autoscaling environments
• Encryption at rest
– Various solutions
• …and when to do each
5. Network Infrastructure
• “Do I need to encrypt data in transit inside my VPC(s)?”
– It depends on your risk appetite…
• VPC is covered under PCI-DSS etc as a Layer 2 isolated network
– “Are ne’er-do’wells with spades, Stanley knives, laptops and
photomultipliers a risk that you require mitigating, or are they
residual risk that you accept?”
• Inter-AZ links, and inter-datacentre links within a Region, are not something
we state as being encrypted on the wire
• …so you should assume they aren’t
• However, there is likely to be other technology in place to get the most out of
WAN bandwidth, which may also serve as an obfuscation layer
• …eg DWDM
• …but what goes down that WAN pipe won’t be indistinguishable from
whitenoise
• …and therefore doesn’t pass an important strength test applied to Feistel
ciphers
6. Anatomy of a Region
AWS DC AWS DC
AWS DC AWS DC
Availability Zone Availability Zone
8. VPC VGW
• Hardware IPsec termination points
• Data on the VPC side of the VGW is unprotected by the VGW (no
re-encryption)
– If you need VPN termination with onward re-encryption, use EC2 instances with
OpenSWAN, or Marketplace appliances with VPN support
– …or ensure that sensitive traffic is also encrypted at application level (ssh, https,
etc)
• Uses pre-shared symmetric key (AES-256) - may change in future
AWS AZ AWS AZCustomer
10. Encryption in Transit for Elastic Instances
• No shortage of encryption options…
– ssh, etc
• Key management and key propagation management
– More interesting!
– “if newly-minted Instance A needs to talk to newly-minted Instance B and doesn’t
have its public ssh key…”
– Kerberos realm auto-join at Instance create isn’t easy (addprinc needs
passwords…)
– Options with KMS to access encrypted sets of keys stored in S3 or DynamoDB…
• Enter “Directories of Secrets”
• Some early third-party options to examine
– KeyWhiz: http://square.github.io/keywhiz/
– Vault: https://www.vaultproject.io/
– Sneaker: https://github.com/codahale/sneaker
– Lemur: https://github.com/Netflix/lemur
• Heavyweight option: Overlay networking (eg CohesiveFT VNS3)
• Other parties working on further commercial options…
12. AWS Key Management Service
• Designed for Scalability and Throughput
• Uses bespoke AWS hardware + software
• Is a multi-tenant service
• Performs AES-256 operations
• API for crypto command:
– Key Management
• Activate, Deactivate, Create, Delete, Grant access,
Rotate
– Encryption / Decryption
• Customer selects Master Key
• Data Key is managed using envelope
encryption
• All key access actions are logged in
CloudTrail
Customer Master
Key(s)
Data Key 1
Amazon
S3 Object
Amazon
EBS
Volume
Amazon
Redshift
Cluster
Data Key 2 Data Key 3 Data Key 4
Custom
Application
AWS KMS
13. AWS Key Management Service
Reference Architecture
Application or
AWS Service
+
Data Key Encrypted Data Key
Encrypted
Data
Master Key(s) in
Customer’s Account
AWS
Key Management Service
1. Application or AWS service client requests an encryption key to use to encrypt data, and passes a
reference to a master key under the account.
2. Client request is authenticated based on whether they have access to use the master key.
3. A new data encryption key is created and a copy of it is encrypted under the master key.
4. Both data key and encrypted data key are returned to the client. Data key is used to encrypt
customer data and then deleted as soon as is practical.
5. Encrypted data key is stored for later use and sent back to AWS KMS when the source data
needs to be decrypted.
14. S3 (normal mode)
AWS AZ
AWS AZ
AWS AZ
• Data is sent to S3 encrypted
• S3 stores the data unencrypted
• Data travels unencrypted between AZs
• Enforce https:
{
"Statement": [{
"Effect": "Deny”,
"Action": "s3:*",
"Condition": {
"Bool": { "aws:SecureTransport": false }
},
"Resource": "arn:aws:s3:::bucket/*"
]}
}
15. S3 (server-side, user key)
AWS AZ
AWS AZ
AWS AZ
• Data is sent to S3 encrypted
• S3 encrypts data with customer key sent in request
• Data travels encrypted between AZs
• Data at rest is encrypted with customer-owned key
• Customer needs to send key in GET request
Customer needs to trust AWS to forget the key…
16. S3 (server-side encryption)
AWS AZ
AWS AZ
AWS AZ
• Data is sent to S3 encrypted
• S3 encrypts data with AWS owned key
• Data travels encrypted between AZs
• Data at rest is encrypted with AWS-owned key
• Enforce at-rest encryption:
{
"Statement":[{
"Sid":"DenyUnEncryptedObjectUploads",
"Effect":"Deny",
"Principal":"*",
"Action":"s3:PutObject",
"Resource":"arn:aws:s3:::YourBucket/*",
"Condition":{
"StringNotEquals":{
"s3:x-amz-server-side-encryption":"AES256"
} } } ] }
17. S3 (server-side, user key + KMS)
AWS AZ
AWS AZ
AWS AZ
• Data is sent to S3 encrypted
• S3 encrypts data with key sent in request
• Data travels encrypted between AZs
• Data at rest is encrypted with customer-owned key
• Key remains in KMS
IAM
KMS
Object
18. S3 (client-side encryption)
AWS AZ
AWS AZ
AWS AZ
• Client encrypts the data locally with local held key
• Data is sent to S3 encrypted
• Data travels encrypted between AZs
• Data at rest is encrypted with customer-owned key
• AWS never sees the key
19. EBS (normal mode)
AWS AZ
AWS AZ
• Instance sends data to volume via hypervisor module
– Module can encrypt or not, depending on customer choice
– Data travels to the disks and between datacentres, potentially unencrypted
– Data lives unencrypted on Disk
20. EBS (server-side encryption)
AWS AZ
AWS AZ
• Instance sends encrypted data over hypervisor to volume
– Instance OS needs to handle encryption
– Data travels encrypted to the disks and between datacentres
– Data lives encrypted on Disk
– AWS owns key/algorithm/data
– Included in scope of AWS SOC1,
PCI-DSS reports
IAM
KMS
Volume
21. CloudHSM
• Tamper-Proof and Tamper-Evident
– Destroys its stored keys if under attack
• FIPS 140-2 Level 2 certified
• Essential function is “being a Keystore”
• Can also be used to timestamp documents
• You can send data for encrypt / decrypt
• Needs to be backed-up (ideally to HSM on customer premises)
• Can be (and should) be combined in HA clusters
• Doesn’t do Financial Services specialised functions (eg PIN verify)
• Is NOT a key management system
– but can work with some third-party ones
• Communicates via:
– PKCS#11
– JCE
• Some applications need a “plugin”
– SafeNet supply one for Apache
22. CloudHSM Integration with S3, EBS, EC2
• S3
– Integration using SafeNet KeySecure on EC2
– White paper at http://www2.safenet-inc.com/AWS-
guides/SafeNetKMIP_AmazonS3_IntegrationGuide.pdf
• EBS and EC2
– Use SafeNet KeySecure (6.1.2 or later) on EC2, backed by CloudHSM, for key
management
– Install SafeNet ProtectV Manager on EC2 (c1.medium / m1.medium)
– Install ProtectV Client on EC2 instances
– Use ProtectV for EBS volume encryption (ext3, ext4, swap)
– Supported platforms:
• RHEL 5.8, 6.2, 6.3
• CentOS 6.2
• Microsoft Windows 2008, 2012
– Encrypt full EBS-backed EC2 instances, including root volumes
23. Redshift can use CloudHSM, Without
Additional Software
• When using CloudHSM:
– Redshift gets cluster key from HSM
– Redshift generates a database key and encrypts it with the cluster key from the
CloudHSM
– Redshift encrypts data with the database key
– Redshift supports re-encryption
24. RDS Crypto Support
• RDS / Oracle EE can use CloudHSM to store keys for Oracle
keystore
– …so TDE can be HSM-backed
• All RDS database types can use KMS to manage keys used to
encrypt underlying EBS volumes
– So all tables are encrypted at rest
• Note that in-memory database contents (once the database has
been unlocked) are cleartext
– RAM encryption is not something AWS has today, but it has been done in other
contexts
25. Other Services
• Glacier
– Archives have always been encrypted – this is entirely transparent to the user
– Glacier keys are AES256
– AWS holds key/algorithm/data
• Route53
– Supports signed zones
– DNSSEC is being looked-into
• ELB
– Supports SSL termination including onward re-encryption and customer choice of
cipher suite (useful post-POODLE)
– AWS holds keys/algorithm/data
– Unidirectional trust only (no certificate-based authentication of client to server – be
aware of pentests reporting SSL renegotiation issues as per CVE-2009-3555)
• Import/Export
– The pre-Snowball service relies on Truecrypt, with a shared secret between customer
and AWS for exporting data
– Truecrypt has not been broken, but it is no longer maintained. Snowball uses AES-
256, and keys are not stored on the device.
26. SafeNet Product Support for AWS
SafeNet Product AWS Service(s) Supported Notes
ProtectV and Virtual
KeySecure for AWS
EC2 or VPC Instances and EBS
Storage
GovCloud (Beta)
• Requires Safenet KeySecure (HW or Virtual)
• Available in AWS MarketPlace, as well as SafeNet sales channels
Virtual KeySecure for AWS CloudHSM • Available in AWS Marketplace
• CloudHSM supports Virtual KeySecure as the hardware root of trust
for vKS master keys
StorageSecure AWS Storage Gateway • Safenet KeySecure Hardware (optional)
• iSCSI integration (however StorageSecure also supports CIFS,
NFS, FTP, TFTP and HTTP protocols.)
Luna SA 7000 HSM CloudHSM
RedShift
RDS (via 3rd party vendor)
• High availability
• Key synchronization
• Key Management
Luna Backup HSM CloudHSM • Key backup
ProtectApp S3 and EBS volumes • Can be integrated with Amazon S3 Encryption Clients and AWS
SDKs (Java and .Net)
• Requires SafeNet KeySecure (HW or virtual)
• Can be installed on an EC2/VPC instance to protect data stored on
EBS volumes.
ProtectFile EBS volumes and S3 • Requires SafeNet KeySecure (HD or Virtual)
27. Differences between CloudHSM and KMS
CloudHSM
• Single-tenant HSM
• Customer-managed durability and
availability
• Customer managed root of trust
• Generate or import keys
• FIPS 140-2 Validation
• Broad third-party app support
• Symmetric and asymmetric ops
• Fixed price ($16.5k/yr/hsm)
• Broad range of symmetric and
asymmetric algorithms
KMS
• Multi-tenant AWS service
• Highly available and durable key
storage and management
(including key rotation)
• AWS managed root of trust
• Mint and use keys in situ
• Extensive auditing
• Broad support for AWS services
• Symmetric encryption only
• Usage-based pricing ($1/mo/key)
• AES-256
28. Useful Reading
• Encrypting Data at Rest:
https://d0.awsstatic.com/whitepapers/AWS_Securing_Da
ta_at_Rest_with_Encryption.pdf
• AWS Key Management Service Cryptographic Details:
https://d0.awsstatic.com/whitepapers/KMS-
Cryptographic-Details.pdf
29. So:
• Data in transit within an AZ might leave a given datacentre
• Data in transit between AZs will leave a given datacentre
• Data in transit between AWS Regions or between AWS and
customer premises needs to be taken care of, too
– You can run VPNs over Direct Connect and via VPC VGWs, or ensure via
firewalls and proxies that only encrypted protocols pass between your premises
and AWS
• Data at Rest: baseline encryption question is turning into “why not?”
• Key Management of Data at Rest: choices for key management and
control, with varying degrees of complexity
• We have a great story for storage device decommissioning (US DoD
5220.22M)
• Keys can also be deleted (new for KMS!)
30. Discussion Points
• Hard encryption in transit might be excessive, in some contexts
• Find out where you need which kind of encryption – map your view
of risk and need
• Think about the lifetime of your data (example: German expiry of
use of 3DES and resulting requirement for bulk data re-encryption
with stronger algorithm…)
• Sometimes encryption is only required for Compliance reasons
Get your data classification right
Find the balance between your obligations for
executive care, cost and complexity
First, let’s back up and talk about what is a hardware security module, or HSM.
An HSM is a purpose built device that is designed from the ground up to perform secure key storage and cryptographic operations. It is designed to protect the key material that is stored inside it. It is designed with physical and logical mechanisms to protect the keys. The physical protections include tamper detection and tamper response. When a tampering event is detected the HSM is designed to securely destroy the keys rather than risking compromise.
The logical protections include role based access controls that provide separation of duties and allow the “Appliance administrator” to manage the device, for example connecting it to the network and provisioning the IP address, SNMP and syslog destinations. A separate role for the security officer, controls access to and use of the keys and cryptographic operations on the keys. The security model that I’m explaining now is specific to the SafeNet Luna SA HSM, which is the HSM that we use today for the CloudHSM service, but HSMs generally have these properties.
Certification and validation by third parties, such as FIPS 140-2 and common criteria provide assurance by a third party that the HSM vendor designed and built the HSM securely.
Physical control of the device does not grant access to the keys
Tamper resistance/evidence
Separate roles for appliance administrator and security officer
Certified by 3rd parties to comply with security standards
FIPS 140-2
Common Criteria EAL4+