Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Data Security Essentials for Cloud Computing - JavaOne 2013

JavaOne 2013 India - Data Security Essentials for Cloud Computing

  • Loggen Sie sich ein, um Kommentare anzuzeigen.

Data Security Essentials for Cloud Computing - JavaOne 2013

  1. 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. 2. Speakers Manish Software Architect, Verisign Anirban Software Architect, Verisign Verisign Public 2
  3. 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. 4. Data Security Considerations for the Cloud Verisign Public 4
  5. 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. 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. 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. 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. 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. 10. Cryptographic Concepts and Applications Verisign Public 10
  11. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 31. Recent Trends in Cloud Data Security Verisign Public 31
  32. 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. 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. 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. 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. 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. 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. 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. 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. 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.

×