JavaOne 2013 India - Data Security Essentials for Cloud Computing

1. Data Security Essentials
for Cloud Computing
Anirban Mukherjee
amukherjee@verisign.com
Java One 2013
JavaOne 2013
08-May-2013
Manish Maheshwari
mmaheshwari@verisign.com

2. Speakers
Manish
Software Architect, Verisign
Anirban
Software Architect, Verisign
Verisign Public 2

3. Agenda
• Data Security Considerations for the Cloud
• Basic Cryptographic Concepts and Applications
• 1-way hashes and digests
• Secure Credential Storage
• Symmetric Key Cryptography
• Data Confidentiality – in storage and in transit
• Asymmetric Key Cryptography
• Authentication and Secure Communications
• Recent Trends in Cloud Security
• HSMs for Safe Key Storage
• Encryption Gateways into the Cloud
Verisign Public 3

4. Data Security Considerations
for the Cloud
Verisign Public 4

5. Cloud Data Security: Context
• Data Security is crucial for Enterprises
• Data Protection is vital for Reputation
• Concerns on Data Security are a deterrent to broader
adoption of Cloud Computing
• Data moves out of Enterprise boundaries
• Trust on Cloud providers
• Shared infrastructure
• Yet benefits of Cloud Computing are compelling
• Need for comprehensive and non-intrusive data security
Verisign Public 5

6. Top Cloud Data Security Issues: Gartner
• Breach notification and data residency
• Data management at rest
• Data protection in motion
• Encryption key management
• Access controls
• Long-term resiliency of the encryption system
Verisign Public 6

7. Cloud Data Security: Who is responsible ?
“Encryption of sensitive data is generally a good security practice,
and AWS encourages users to encrypt their sensitive data before it
is uploaded to Amazon S3.”
– Amazon Web Services: Overview of Security Processes
• Who is responsible for the overall security ?
• Different levels of providers
• Shared infrastructure can make extent of breach higher
• APIs allow many admin functions to be carried out
• Malicious entities can look for weaknesses in the API
• Can gain broad access to shared infrastructure
Verisign Public 7

8. Cloud Data Security: Encryption Layers
• Different Layers of Encryption
• Block Storage / Disks
• File and API
• Databases
• Applications
Applications
Databases
File, API
Disks
• Higher-level encryption can protect better but is harder
• Key question: Who has the key ? They have access
• Only Disks encrypted by provider
• Provider can see disk content
• Files and APIs encrypted by provider
• Provider can see API flows and file content
• … and so on
Verisign Public 8

9. Cloud Data Security: Broad Concerns
• Is server based encryption sufficient ?
• Encryption Gateways on the client/enterprise side
• How secure are the encryption keys ?
• Stored in the Cloud - Secured VM, HSM
• Stored by Client/enterprise (Encryption Gateways)
Verisign Public 9

10. Cryptographic Concepts and
Applications
Verisign Public 10

11. Basic Conceptual Terms (1/2)
• Cryptography Provisions
• Authentication, Confidentiality, Non Repudiation, Integrity
• Deals with making communications and storage secure
• Encryption/Decryption
• Encryption: clear-text message to cipher-text
• Decryption: cipher-text back to clear-text
• Types of encryption algorithms
• Symmetric Key
• Asymmetric Key
Verisign Public 11

12. Basic Conceptual Terms (2/2)
• 1-way Hash functions
• Also known as a message digest or fingerprint functions
• Data Integrity
• Digital Signatures
• Uses Public-key/Asymmetric Cryptography and 1-way hashes
• Data Origin Authentication and Data Integrity Assurance
• Digital Certificates and Public Key Infrastructure
• Digitally Signed Public Keys
• Infrastructure for the Web of Trust
• Key Security
• Secure storage of secret keys
Verisign Public 12

13. 1-way Hashes: Overview
• Message digest or fingerprint
• Variable-length input string
converted into a short fixed-length
binary sequence
• Easy to compute
• Infeasible to reverse
• Infeasible to craft collisions
Note: MD5 is not considered secure today.
Only for illustration.
Verisign Public 13

14. 1-way Hashes: Uses
• Used for storage of
credentials like passwords
• 1-way encryption
• Not feasible to compute
password from the hash
• Not feasible to compute other
passwords producing same hash
• Also used in
• Digital Signatures
• File integrity checks
Verisign Public 14

15. 1-way Hashes: Details
• Algorithms
• MD5 (128 bits), SHA-1(160 bits), SHA-256 (256 bits), SHA-512
(512 bits)
• Attacks
• Pre-computed dictionary attacks/ Rainbow attacks
• Hash Collision
• Mitigation
• Use random salts
• Use stronger versions e.g. SHA-256 upwards
• 2-Factor authentication
Verisign Public 15

16. 1-way Hashes: Upshot for Cloud
• If your cloud provider is able to send you your password
for Forgot Password, …
• Apps hosted by you on provider’s infra should use 1-
way hashes with salt for storing passwords in the
database
Verisign Public 16

17. Symmetric Crypto: Overview
Secret Key
Plaintext Ciphertext Plaintext
Encryption
Decryption
• Same key is used for encryption and decryption
• Parties need a mechanism to exchange the shared
key securely
• Key must be secret and safely stored
Verisign Public 17

18. Symmetric Crypto: Uses
• Basis for Data Confidentiality
• Vital for secure storage and secure transmission
• Prevents attackers from being able to make sense of disk data or
network packets they illegitimately accessed
• Symmetric key ciphers are efficient
• Relatively inexpensive to produce a strong key
• Smaller keys for the same level of protection
• Comparatively inexpensive encryption/decryption
Verisign Public 18

19. Symmetric Crypto: Details
• Algorithms
• 3DES, AES-x (x=128,192,256), RC4
• Attacks
• Cryptanalysis
• Key compromise
• Mitigation
• Rotate/Rollover keys every N years
• Secure Key Storage
• Restricted filesystem/VM, HSM
Verisign Public 19

20. Symmetric Crypto: Upshot for Cloud
• Secure way to store uploaded data, sensitive personal
information in databases, VM images, emails etc.
• To infrastructure provider and SaaS provider
• What is encrypted and using what mechanism?
• How and where are secret keys stored ? Are they rotated ?
• Is there a way that only I can use the secret key without the
provider having access to it ?
• For apps hosted by you
• Are you encrypting sensitive data stored in databases, Text
Search indexes etc.
• How secure is your secret key ?
Verisign Public 20

21. Comparable Crypto Strengths
• Smaller Keys are more
efficient
• Faster generation
• Faster encrypt/decrypt
• Smaller encrypted output
• Longer keys have higher
crypto strength
• For same algorithm
• Symmetric Keys are
stronger for same size
Verisign Public 21

22. Asymmetric Crypto: Overview
Public Key Private Key
Plaintext Ciphertext Plaintext
Encryption Decryption
• Public Key is well-known and published to all
• Private Key is secret and must be stored safely by owner
• Encrypt with one Key, Decrypt with another Key
• Infeasible to compute Private Key from Public Key
Verisign Public 22

23. Asymmetric Crypto: Overview
• Key generation, encryption/decryption are expensive
compared to symmetric keys
• Used to encrypt small amounts of data, mostly for authentication
• Rarely used for encryption of regular data which is voluminous
• Private key must be securely stored similar to symmetric
keys
Verisign Public 23

24. Asymmetric Crypto: Uses
• Secure Communications
• Data origin authentication
• No interception/diversion aka Man-in-the-middle
• Symmetric Key exchange during session establishment
• SSL, PGP, SSH
• Mechanisms
• Digital Signatures
• Digital Certificates
Verisign Public 24

25. Digital Signatures: Overview
• Builds on Hashing and Asymmetric Crypto
• Actual data remains in plaintext but signature is attached
• Data origin authentication, Data integrity assurance
Verisign Public 25

26. Digital Signatures: Details
• Algorithms
• RSA/SHA-x, DSA, ECDSA (Elliptic Curve)
• Applications
• PGP Signed Email, SSL Certificate Signatures, DNSSEC
• Attacks
• Signature forgery by exploiting weak hash functions
• Private key compromise
• Mitigation
• Strong hashes and strong encryption, Secure private key storage
Verisign Public 26

27. Digital Certificates: Signatures + Chain of Trust
• Builds on Digital Signatures and PKI
• Certificate is a "Digitally Signed Public Key"
• Chain of Trust with Certificate Authorities
• DNSSEC also has Chain of Trust but no certs
Verisign Public 27

28. Digital Certificates: Details
• Certificate is public and valid for a
time interval (typically years)
• Certifies that Public Key identifies
Subject
• DNS hostname, Email address etc.
• Affixed with CA signature
• Verifier configures Trust Anchor
• a node in the Chain of Trust
• root always trusted
• Root CA is ultimate authority
• Self-signed certificate trusted by clients
Verisign Public 28

29. Digital Certificates: Details
• Attacks
• Private key compromise (anywhere in Trust Chain)
• Fraudulent yet cryptographically valid certs
• Digital Signature forgery typically via Hash collisions
• Mitigation
• Use reputed CAs
• Strong encryption and hash functions
• Secure Key Storage
• Certificate Revocation
Verisign Public 29

30. Asymmetric Crypto: Upshot for Cloud
• To Cloud Providers
• Are they using valid non-expired SSL certificates and strong
encryption ?
• Server certs and client certs (if applicable)
• Are their domains DNSSEC enabled ?
• Protection against DNS Cache Poisoning Attacks
• Do they renew certificates and roll over DNSSEC keys ?
• For your hosted apps
• Is HTTPS used for all confidential exchanges ?
• Are signed emails used especially for input emails that trigger
workflow actions ?
• Is certificate-based client authentication implemented properly ?
Verisign Public 30

31. Recent Trends in Cloud Data
Security
Verisign Public 31

32. Hardware Security Modules
• Secure and tamper-resistant storage for high-value keys
• Traditionally used for CAs, DNSSEC signers
• Now being considered for more uses in the Cloud
• Very difficult to access/steal keys from the device
• Various FIPS levels
• May Respond to tamper attempts
• Highly secure ones can self-destruct keys
• Often JCE KeyStore provider is supplied by vendor
• Can use JCE KeyStore abstraction directly from Java apps
• If not, need to use a JCE PKCS#11 Provider
• Uses JNI to invoke the native PKCS#11 API libraries
Verisign Public 32

33. Hardware Security Modules
• Key stays within the HSM
• Cryptographic operations
occur within the hardware
• signing
• encryption/decryption
• Cryptographic black box
• input data goes in
• cryptographically
transformed data comes out
Storage
Creation
Destruction
Usage Distribution
Verisign Public 33

34. Cloud Encryption Gateways
SaaS
PaaS
IaaS
Encryption
Gateway
SaaS forms
PaaS API
Cloud DB
JDBC
• Intercept and transform sensitive data before it goes out
• Replace it with a random token or strongly encrypted value
• Must be of same size and type, else things will break
• Do reverse operation for data coming back into premises
• Real-time crypto operation on every request/response
Verisign Public 34

35. Cloud Encryption Gateways
• Enterprise owns encryption key or token vault
• Data stored in Cloud provider’s datastores is mangled
• Data stores include databases, Text Search indexes
• Sensitive data not compromised
• Field-based operation
• Can specify the sensitive fields
• Only those will be transformed
• Cloud platform aware
• Gateway needs to do transformations specific to the SaaS, PaaS
involved in the interaction
• Not platform-agnostic
Verisign Public 35

36. Cloud Encryption Gateways – Format Preservation
• Format preserving encryption
• Usually encryption produces longer ciphertext than plain-text
• logical data type may change too
• e.g. 1234567812345670 (16 digit number) ->
lqRcvPnCqUJc3p4nSUjLZw==, (24 char base64 encoded string)
• Size and datatype mismatch in transformation will break things
• Database column type and length
• Application data types and length
• Ciphertext is in same format (type and length) as input plaintext
• Input: 10 digit numeric id, Output: a different 10 digit numeric id
• Input: 30 character address, Output: 30 character mangled string
Verisign Public 36

37. Cloud Encryption Gateways – Function Preservation
• Function preserving encryption
• Just format preservation may not be sufficient
• What about
• Wildcard matches
• Sort orders
• Need encryption/tokenization that is order-preserving
• More generally function-preserving
• Claims of such encryption have been made
• Possibility of reduced encryption strength
• Not yet clear if strength is within acceptable limits
Verisign Public 37

38. Conclusion
• Many pieces to the Cloud Data Security puzzle
• Innovative solutions are emerging based on well-proven
building blocks
• Comprehensive approaches involving all parties are
the need
• News of breaches causes discomfort
• It may take a while before comfort levels are reached
Verisign Public 38

39. References
• NIST Special Publication 800-57 Recommendation for
KeyManagement – Part 1: General (Revision 3)
• MD5 considered harmful today: Creating a Rogue CA
Certificate
• Six security issues to tackle before encrypting cloud data
• http://www.computerweekly.com/news/2240180087/Six-security-issues-
to-tackle-before-encrypting-cloud-data
• An Illustrated Guide to Cryptographic Hashes
• http://www.unixwiz.net/techtips/iguide-crypto-hashes.html
Verisign Public 39

40. Thank You
© 2013 VeriSign, Inc. All rights reserved. VERISIGN and other trademarks, service marks, and
designs are registered or unregistered trademarks of VeriSign, Inc. and its subsidiaries in the United
States and in foreign countries. All other trademarks are property of their respective owners.