Data Security Essentials <DRAFT VERSION> <Work in Progress>

1. Java One 2013 Data Security Essentials <DRAFT VERSION> <Work in Progress> Manish Maheshwarimmaheshwari@verisign.com Anirban Mukherjee amukherjee@verisign.com

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

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

4. Data Security Considerations for the Cloud

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

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

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

8. Cloud Data Security: Encryption Layers • Different Layers of Encryption (Lower to Higher) • Block Storage / Disks • File and API • Databases • Applications • Higher-level encryption protects better but is harder • Key question: Who has the key ? They have access • Only Disks and VM images encrypted • Provider can still see disk and VM content • Files and APIs encrypted • Provider can see API flows and files uploaded • … and so on

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)

10. Cryptographic Concepts and Applications

11. Basic Conceptual Terms (1/2) • Cryptography • Deals with making communications and storage secure • Encryption/Decryption • Encryption: clear-text message to undecipherable ciphertext • Decryption: cipher-text back to cleartext • Secret key is the basis of security • Types of encryption • Symmetric algorithms • use only a secret key • Asymmetric or Public-key algorithms • use public/private key pairs • private portion is secret, public portion is “public”

12. Basic Conceptual Terms (2/2) • 1-way Hash functions • Also known as a message digest or fingerprint functions • Variable-length input string -> fixed-length binary sequence • Digital Signatures • Data Origin Authentication and Data Integrity Assurance • Uses Public-key/Asymmetric Cryptography and 1-way hashes • Trust • Certified Authenticity of real-world identity • Involves Trusted 3rd Parties who certify • Key Security • Secure storage of secret keys

13. 1-way Hashes: Overview • Message digest or fingerprint • Variable-length input string converted into a short fixed-length binary sequence • Reverse operation is infeasible as is crafting collisions • Note: MD5 is not considered secure today. Only for illustration.

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

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 collisions • Mitigation • Use random salts • Use stronger versions e.g. SHA-256 upwards • 2-Factor authentication

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

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

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 • Can protect against social engineering attacks in some cases • Symmetric key ciphers are efficient • Relatively inexpensive to produce a strong key • Smaller keys for the same level of protection • Comparatively faster and inexpensive encryption/decryption

19. Symmetric Crypto: Details • Algorithms • TDEA, 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

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 means ? • 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 ?

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

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 Public Key, Decrypt with Private Key • Anyone can encrypt but only private key owner can decrypt • Infeasible to compute Private Key from Public Key

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 • Typically used in authentication handshake • Authenticity <=> possession of private key • Symmetric Key Exchange (e.g. DH, RSA key exchange) • SSL, PGP, SSH • Digital Signatures (RSA/SHA-x, DSA, ECDSA)

24. Asymmetric Crypto: Uses • Secure Communications • Data is received only by the right party • No interception/diversion aka Man-in-the-middle • Authentication • Client and Server challenges, Auth Tokens • Symmetric Key exchange during session establishment • SSL, PGP, SSH • Mechanisms • Digital Signatures • Digital Certificates • SSL/TLS, Other PKI systems • Signatures + Chain of Trust

25. Digital Signatures: Overview • Actual data remains in plaintext but signature is attached • Signing involves only private key, verification involves only public key • Data origin authentication, Data integrity assurance • Valid only for a time interval

26. Digital Signatures: Details • Algorithms • RSA/SHA-x, DSA, ECDSA (Elliptic Curve) • Applications • PGP Signed Email, SSL Certificate Signatures, DNSSEC • Attacks • Man-in-the-Middle • Signature forgery by exploiting weak hash functions • Private key compromise • Mitigation • Certificates with Chain of Trust infrastructure • Strong hashes and strong encryption, Secure private key storage

27. Digital Certificates: Signatures + Chain of Trust • SSL/TLS • Chain of Trust with Certificate Authorities • DNSSEC also has Chain of Trust but no certs

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

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

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 ?

31. Recent Trends in Cloud Data Security

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

33. Creation Destruction Storage Usage Distribution 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

34. Cloud Encryption Gateways 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 SaaS PaaS IaaS Encryption Gateway

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, IaaS involved in the interaction • Not platform-agnostic

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

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

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

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