Upcoming SlideShare
×

# Protecting Sensitive Inforation with Database Encryption

2,451 views

Published on

0 Likes
Statistics
Notes
• Full Name
Comment goes here.

Are you sure you want to Yes No
• Be the first to comment

• Be the first to like this

Views
Total views
2,451
On SlideShare
0
From Embeds
0
Number of Embeds
19
Actions
Shares
0
57
0
Likes
0
Embeds 0
No embeds

No notes for slide
• Key - The input is used to drive the encryption and/or decryption, may be a secret (private key) or known (public key) depending on the type of encryption. Encryption Algorithm – The known mathematical program or “recipe” used with the key to generate the encrypted cipher text. Clear Text – The original unencrypted information before the encryption is applied. The clear text information may be binary as well as text Cipher Text – The resulting encrypted information which will appear as random unintelligible data. Initialization Vector – Since the key used for encryption is often not randomly generated, it is vital for most encryption algorithms to use a random generated sequence as an initialization vector (IV) to seed (or start) the encryption algorithm. Think of it this way, if all of the inputs to the encryption algorithm are not random, then the output will not be random either. Of course we use the term random here, not as an academic purist, but as pragmatic application of computer generated entropy. Computers by their nature are predicable, and generating unpredictable entropy is a difficult task. There have been many cases of encryption implementations being found weak, even when the key and algorithm are strong, because the implementation caused the entropy of the initialization vector to be weak. Such examples include a variety SSL implementations, recent DNS BIND software, and Microsoft’s IV implementation in Word and Excel. Symmetric Encryption – Category of encryption algorithms that uses a single shared secret key to both encrypt the clear text and decrypt the cipher text. Examples include DES, 3DES, RC4, Blowfish, AES and many others. See &lt; http://en.wikipedia.org/wiki/Symmetric_cipher&gt; Asymmetric Encryption or Public Key Encryption – A category of encryption algorithms that use a pair of 2 mathematically related keys. One key is kept secret to the “owner” and is called the private key, while the other key is known by others and called the public key. Encryption may be done with either key, and decryption is done with the other key. So that clear text encrypted with the public key must be decrypted with the private key, and visa-a-versa. Encrypting with public key allows information to be sent confidentially, so that only the “owner” of the private key can decrypt the information. Encrypting with the private key, provides integrity, authentication and non-repudiation by allowing everyone with the public key to verify the integrity of the message and prove that only the “owner” of the private key could have properly encrypted the message with the private key. Examples of public key algorithms include RSA, Diffie Hellman, ElGamel, DSA (Digital Signature Algorithm), and Eliptic Curve Algorithm. For additional technical details &lt;http://en.wikipedia.org/wiki/Public-key_cryptography&gt; Secure Hash – A category of encryption algorithm that generates a mathematical “checksum” which can not be easily reversed. For these algorithms, there is no decryption algorithm, and there is no key. The resulting hash (cipher text) output is fixed length and does not depend on the length of the input. A secure hash is similar in concept to a simple checksum such as an XOR of the sequential values in the original clear text, however a strong secure hash algorithm can not be easily reverse engineered so that a different or modified message would NOT come up with the same resulting hash, These algorithms do not provide confidentiality of the original message, but can be use to validate the integrity of the original information. Examples include MD4, MD5, SHA-1, SHA-256, SHA-512, RIPEMD-160. For additional technical details see http:// en.wikipedia.org/wiki/Cryptographic_hash_function
• Real World
• Spectrum of Threats to DB Information (from slide 6) T1 - Theft or Loss of DB System or Storage Media T2 - Theft or Loss of DB Backup Media T3 - Theft or Loss of OS Backup Media T4 - Exploitation of Direct DB Access T5 - DB System Compromise T6 - DBA Insider or DBA Account Compromise T7 - Application or DB User Account Compromise T8 - Application or Middleware OS Compromise T9 - Exploitation of Application with Restricted Account T10 - Exploitation of Application with Unrestricted Account Key Management from previous slide Not Recommended K0 - Storing and Hiding Keys in Software K1 - Auto Decryption by OS or FS K2 - Auto Decryption by DBMS K3 - Key Stored in DB and Readable by DBA Recommended K4 - Key Stored in FS on DB Server and Readable by DBA K5 - Key Stored in FS on DB Server and NOT Readable by DBA Preferred K6 - Key Stored on the Client, Application Or Mid-Tier Server with Minimal Access
• Yes 1 - T1 - Theft or Loss of DB System or Storage Media vs. K1 - Auto Decryption by OS or FS Example Windows EFS Yes 2 - T6 - DBA Insider or DBA Account Compromise T7 - Application or DB User Account Compromise VS. K6 - Key Stored on the Client, Application Or Mid-Tier Server with Minimal Access Yes 3 - T T4 - Exploitation of Direct DB Access Vs. K3 - Key Stored in DB and Readable by DBA Recommended K4 - Key Stored in FS on DB Server and Readable by DBA Partial 4 - T10 - Exploitation of Application with Unrestricted Account Vs. K4 - Key Stored in FS on DB Server and Readable by DBA K5 - Key Stored in FS on DB Server and NOT Readable by DBA Preferred K6 - Key Stored on the Client, Application Or Mid-Tier Server with Minimal Access
• CBC CFB, ECB, OFB PKCS5 = Public Key Cryptography Standard \$5
• Service Master - The root or top level key is a single service master key which is generated automatically when SQL Server is installed. The service master key cannot be directly accessed, created or destroyed, but it can be regenerated and it can be exported so that it can be backed up to a secure location. The key is protected by the Data Protection API (DPAPI) so that only the owner, the SQL Server Service account, may access the service master key. Therefore anyone with access to the SQL Server Service account has access to the service master key, and therefore has access to all encryption keys, and may decrypt all information on the server instance.
• The database master key is used to symmetrically encrypt all keys within a specific database. That includes certificates, asymmetric keys and other symmetric keys. By default, the database master key is stored encrypted with the service master key, and a second encrypted copy is stored encrypted with a password provided at the time the key is generated. This means the key may be opened by the SQL Server account, or by using the password to the database master key. It is recommended that you remove the copy of the database key that is encrypted by the service master key if possible User keys may be symmetric keys, asymmetric keys or certificates.
• ### Protecting Sensitive Inforation with Database Encryption

1. 1. Protecting Sensitive Information with Database Encryption Rochester, NY OWASP Ralph Durkee Durkee Consulting, Inc. [email_address]
2. 2. What is covered <ul><li>Provides specific technical recommendations for: </li></ul><ul><ul><li>When to encrypt information </li></ul></ul><ul><ul><li>How to avoid encryption </li></ul></ul><ul><ul><li>Where in the architecture to encrypt </li></ul></ul><ul><ul><li>Key Management </li></ul></ul><ul><ul><li>Generic architecture and encryption techniques </li></ul></ul><ul><ul><li>Implementation for specific Databases </li></ul></ul><ul><ul><ul><li>Oracle 8g-9g </li></ul></ul></ul><ul><ul><ul><li>Oracle 10-11i </li></ul></ul></ul><ul><ul><ul><li>MS SQL Server 2005 </li></ul></ul></ul>
3. 3. Ralph Durkee <ul><li>Rochester OWASP President since 2004 </li></ul><ul><li>Founder Durkee Consulting since 1996 </li></ul><ul><li>Application Security , development, auditing, PCI compliance, pen testing and consulting </li></ul><ul><li>CIS (Center for Internet Security) – Helped development of benchmark standards – Linux, BIND DNS, OpenLDAP, FreeRadius, Unix, FreeBSD </li></ul><ul><li>SANS Community Instructor and course developer </li></ul><ul><li>Rochester Area Security Consulting, Ethical Hacking and Auditing </li></ul>
4. 4. When? Requirements for Encryption <ul><li>May be used to help meet regulations: </li></ul><ul><li>GLBA to ensure confidentiality of customer records and information </li></ul><ul><li>State Breach Notification Laws - require notification if information was not encrypted </li></ul><ul><li>Regulatory efforts impose stiffer fees and fines in the event that a breach occurs and steps are not taken to appropriately protect sensitive data </li></ul>
5. 5. When? Requirements for Encryption <ul><li>Payment Card Industry, PCI DSS Requirement 3.4 </li></ul><ul><li>Requirement 3: Protect stored cardholder data </li></ul><ul><ul><li>3.4 Render PAN, at minimum, unreadable anywhere it is stored (including data on portable digital media, in logs, and data received from or stored by wireless networks) by using any of the following approaches: </li></ul></ul><ul><ul><ul><li>• Strong one-way hash functions (hashed indexes) </li></ul></ul></ul><ul><ul><ul><li>• Truncation </li></ul></ul></ul><ul><ul><ul><li>• Index tokens and pads (pads must be securely stored) </li></ul></ul></ul><ul><ul><ul><li>• Strong cryptography with associated key management processes and procedures. </li></ul></ul></ul>
6. 6. When? Requirements for Encryption <ul><li>Payment Card Industry, PCI DSS Requirement 3.4 (continued) </li></ul><ul><ul><li>3.4.1 If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed independently of native operating system access control mechanisms (for example, by not using local system or Active Directory accounts). Decryption keys must not be tied to user accounts. </li></ul></ul><ul><li>Payment Card Industry, PCI DSS Requirement 3.5 </li></ul><ul><li>3.5 Protect encryption keys used for encryption of cardholder data against both disclosure and misuse. </li></ul><ul><ul><li>3.5.1 Restrict access to keys to the fewest number of custodians necessary </li></ul></ul><ul><ul><li>3.5.2 Store keys securely in the fewest possible locations and forms. </li></ul></ul>
7. 7. When? Requirements for Encryption <ul><li>PCI DSS Requirement 3.6 </li></ul><ul><li>3.6 Fully document and implement all key management processes and procedures for keys used for encryption of cardholder data, including the following: </li></ul><ul><ul><li>3.6.1 Generation of strong keys </li></ul></ul><ul><ul><li>3.6.2 Secure key distribution </li></ul></ul><ul><ul><li>3.6.3 Secure key storage </li></ul></ul><ul><ul><li>3.6.4 Periodic changing of keys </li></ul></ul><ul><ul><ul><li>• As deemed necessary and recommended by the associated application (for example, re-keying); preferably automatically </li></ul></ul></ul><ul><ul><ul><li>• At least annually. </li></ul></ul></ul>
8. 8. When? Requirements for Encryption <ul><li>PCI DSS Requirement 3.6 (continued) </li></ul><ul><ul><li>3.6.5 Destruction of old keys </li></ul></ul><ul><ul><li>3.6.6 Split knowledge and establishment of dual control of keys (so that it requires two or three people, each knowing only their part of the key, to reconstruct the whole key) </li></ul></ul><ul><ul><li>3.6.7 Prevention of unauthorized substitution of keys </li></ul></ul><ul><ul><li>3.6.8 Replacement of known or suspected compromised keys </li></ul></ul><ul><ul><li>3.6.9 Revocation of old or invalid keys </li></ul></ul><ul><ul><li>3.6.10 Requirement for key custodians to sign a form stating that they understand and accept their key-custodian responsibilities. </li></ul></ul><ul><li>IMPORTANT: PCI States CANNOT store Mag. Strip, PIN or Card Verification Code </li></ul>
9. 9. Why? - Threats, Risks and Rational for Data Encryption <ul><li>Spectrum of Threats to DB Information </li></ul><ul><ul><li>T1 - Theft or Loss of DB System or Storage Media </li></ul></ul><ul><ul><li>T2 - Theft or Loss of DB Backup Media </li></ul></ul><ul><ul><li>T3 - Theft or Loss of OS Backup Media </li></ul></ul><ul><ul><li>T4 - Exploitation of Direct DB Access </li></ul></ul><ul><ul><li>T5 - DB System Compromise </li></ul></ul><ul><ul><li>T6 - DBA Insider or DBA Account Compromise </li></ul></ul><ul><ul><li>T7 - Application or DB User Account Compromise </li></ul></ul><ul><ul><li>T8 - Application or Middleware OS Compromise </li></ul></ul><ul><ul><li>T9 - Exploitation of Application with Restricted Account </li></ul></ul><ul><ul><li>T10 - Exploitation of Application with Unrestricted Account </li></ul></ul>
10. 10. Encryption Terms <ul><li>Encryption Algorithm </li></ul><ul><li>Key </li></ul><ul><li>Clear Text </li></ul><ul><li>Cipher Text </li></ul><ul><li>Initialization Vector </li></ul><ul><li>Secure Hash (0 keys) </li></ul><ul><li>Symmetric Encryption (1 key) </li></ul><ul><li>Asymmetric or Public Key Encryption (2 keys) </li></ul>
11. 11. Real World Public Key Implementations <ul><li>Problems: </li></ul><ul><li>Asymmetric encryption 100 times slower </li></ul><ul><li>Symmetric encryption </li></ul><ul><ul><li>Requires a shared secret </li></ul></ul><ul><ul><li>Doesn’t scale well </li></ul></ul><ul><ul><li>Requires (N*(N-1))/2 keys for N people </li></ul></ul><ul><li>Real World Implementations </li></ul><ul><ul><li>Use a hybrid of symmetric, asymmetric & hash </li></ul></ul><ul><ul><li>Provides both good performance and scalability </li></ul></ul><ul><ul><li>Doesn’t required a pre-shared secret. </li></ul></ul><ul><ul><li>Examples: PGP, SSL/TLS, IPSec, S/MIME </li></ul></ul>
12. 12. Encryption Alternatives <ul><li>Before encrypting information ask: </li></ul><ul><li>Does the sensitive information really need to be stored? </li></ul><ul><li>Can the sensitive information be truncated? </li></ul><ul><li>Can the sensitive information be stored as a salted, secure hash? </li></ul><ul><li>Can the sensitive information be stored only in memory, or stored temporarily and then securely wiped? </li></ul>
13. 13. Home Grown Encryption <ul><li>Bad idea to invent encryption algorithms </li></ul><ul><li>Do not accept proprietary encryption </li></ul><ul><li>Acceptable algorithms are very difficult and require: </li></ul><ul><ul><li>Invented by professional cryptologist </li></ul></ul><ul><ul><li>Subject to years of open analysis and scrutiny </li></ul></ul><ul><li>Many past failures by the brightest and well funded </li></ul><ul><ul><li>MD4 hash by Ronald Rivest </li></ul></ul><ul><ul><li>Helix by Bruce Schneier </li></ul></ul><ul><ul><li>LANMAN Hash by Microsoft </li></ul></ul><ul><ul><li>DVD CSS (Content Scrambling System) </li></ul></ul>
14. 14. Standard Symmetric Algorithms MS SQL Acceptable 128 Block RC2 Oracle DBMS Crypto, MS SQL Strong 1-256 Stream RC4 Oracle DBMS Crypto, MS SQL Strong 256 Block AES-256 Oracle DBMS Crypto, MS SQL Strong 192 Block AES-192 Oracle, MS SQL Acceptable 128 Block 3DES Oracle, MS SQL Weak 56 Block DES DBMS Strength Key Type Algorithm
15. 15. Full DB Encryption <ul><li>Lack of Granular Access Control </li></ul><ul><li>Performance Impact </li></ul><ul><li>Limited Key Management </li></ul><ul><li>Not Recommended </li></ul>Clear Text OS & File System Application Database
16. 16. OS or File System Encryption <ul><li>Same problems as Full DB Encryption </li></ul><ul><li>Lack of Granular Access Control </li></ul><ul><li>Performance Impact </li></ul><ul><li>Limited Key Management </li></ul><ul><li>Not Recommended </li></ul>Clear Text OS & File System Application Database
17. 17. Field Level by DB or Middleware <ul><li>Recommended </li></ul><ul><li>Granular Access Control </li></ul><ul><li>Limited Performance Impact </li></ul><ul><li>Clear text communications should be encrypted </li></ul>Clear Text Application Database ID 1 2 3 4 SSN Table
18. 18. Field Level by the Application <ul><li>Recommended </li></ul><ul><li>Granular Access Control </li></ul><ul><li>Resistant to DB attacks and DBA Insider threats </li></ul><ul><li>Less impact from other weak applications </li></ul><ul><li>Each application implements key management </li></ul>Cipher Text Application Database ID 1 2 3 4 SSN Table
19. 19. Application Level Passwords and Authentication <ul><li>User Passwords stored as salted secure hash </li></ul><ul><ul><li>Salt of 8 or more random characters </li></ul></ul><ul><ul><li>Unique salt for each password </li></ul></ul><ul><ul><li>Stored in clear with password </li></ul></ul><ul><ul><li>Example: \$1\$ i0/B42.e \$ GcsbF4Y0xb0PM2Um8jIoI1 \$ </li></ul></ul><ul><li>Application Passwords </li></ul><ul><ul><li>Used to authenticate applications to other systems. </li></ul></ul><ul><ul><li>Must be retrievable by the application </li></ul></ul><ul><ul><li>Stored with symmetric or public key encryption. </li></ul></ul><ul><ul><li>Same issues as key management </li></ul></ul>
20. 20. Key Management Architectures <ul><li>Not Recommended </li></ul><ul><ul><li>K0 - Storing and Hiding Keys in Software </li></ul></ul><ul><ul><li>K1 - Auto Decryption by OS or FS </li></ul></ul><ul><ul><li>K2 - Auto Decryption by DBMS </li></ul></ul><ul><ul><li>K3 - Key Stored in DB and Readable by DBA </li></ul></ul><ul><li>Recommended </li></ul><ul><ul><li>K4 - Key Stored in FS on DB Server and Readable by DBA </li></ul></ul><ul><ul><li>K5 - Key Stored in FS on DB Server and NOT Readable by DBA </li></ul></ul><ul><li>Preferred </li></ul><ul><ul><li>K6 - Key Stored on the Client, Application Or Mid-Tier Server with Minimal Access </li></ul></ul>
21. 21. Key Management Threat Matrix P4 Y N Y Y2 Y2 Y Y Y Y K6 P4 Y Y Y Y N Y N Y N K5 P4 Y Y Y N N Y3 N Y N K4 N Y Y Y N N Y3 N N N K3 N N N N N N N N N N K2 N N N N N N N N N Y1 K1 T10 T9 T8 T7 T6 T5 T4 T3 T2 T1
22. 22. Key Management Threat Matrix Footnotes –Explanations <ul><li>Yes 1 (T1 vs. K1) - Yes, if … </li></ul><ul><ul><li>Assumed that the key is not stored in clear text on the system </li></ul></ul><ul><ul><li>With weak protection such as MS Windows LANMAN hash. </li></ul></ul><ul><ul><li>Protection is only as good as protection for the key </li></ul></ul><ul><ul><li>See section 3.1 for details </li></ul></ul><ul><li>Yes 2 (T6 & T7 vs. K6) - Yes if … </li></ul><ul><ul><li>Key is not sent to DBMS for decryption </li></ul></ul><ul><li>Yes 3 (T4 vs. K3 & K4) - Yes, If … </li></ul><ul><ul><li>Key is readable only by a single application account and the DBA. </li></ul></ul><ul><ul><li>Account access does not include Admin level access. </li></ul></ul><ul><li>Partial 4 - Yes, in many cases, but not if … </li></ul><ul><ul><li>decryption is automated by the application </li></ul></ul>
23. 23. Encryption for Oracle 8i-11g <ul><li>Oracle DBMS Obfuscation Toolkit (DOTK) </li></ul><ul><ul><li>(Only option for older Oracle 8g & 9g) </li></ul></ul><ul><li>Oracle DBMS_CRYPTO package </li></ul><ul><ul><li>( Recommended Solution ) </li></ul></ul><ul><li>Oracle Transparent Data Encryption (TDE) </li></ul><ul><li>Oracle Advanced Security Option </li></ul><ul><li>Oracle Database Vault </li></ul>
24. 24. Oracle DOTK Checklist <ul><li>Use only the 3DES encryption rather than DES </li></ul><ul><li>Avoid for highly sensitive information, Use DBMS_CYRPTO when available </li></ul><ul><li>Use a randomly generated key of at least 128 bits generated from DES3GetKey(). </li></ul><ul><li>Use a good source of entropy for the random seed used for generating the key such as /dev/random on Unix/Linux systems and CryptGenRandom() on MS windows. </li></ul><ul><li>Use a randomly generated IV (Initialization vector) of 8-16 bytes (64-128 bits) for each encrypted record. </li></ul>
25. 25. Oracle DBMS Obfuscation Toolkit <ul><li>DOTK Encryption Procedure: </li></ul><ul><li>DBMS_OBFUSCATION_TOOLKIT. DES3Encrypt ( input_string IN VARCHAR2, </li></ul><ul><li>key_string IN VARCHAR2, </li></ul><ul><li>encrypted_string OUT VARCHAR2, </li></ul><ul><li>which IN PLS_INTEGER DEFAULT TwoKeyMode, </li></ul><ul><li>iv_string IN VARCHAR2 DEFAULT NULL); </li></ul><ul><li>Also function with output returned </li></ul><ul><li>Also function & procedures with raw parameters </li></ul><ul><li>Default Null IV is Dangerous, should be random! </li></ul>
26. 26. Oracle DBMS Obfuscation Toolkit <ul><li>DOTK Decryption Procedure: </li></ul><ul><li>DBMS_OBFUSCATION_TOOLKIT. DES3Decrypt ( </li></ul><ul><li>input_string IN VARCHAR2, </li></ul><ul><li>key_string IN VARCHAR2, </li></ul><ul><li>decrypted_string OUT VARCHAR2, </li></ul><ul><li>which IN PLS_INTEGER DEFAULT TwoKeyMode </li></ul><ul><li>iv_string IN VARCHAR2 DEFAUTL NULL); </li></ul><ul><li>Also function with output returned </li></ul><ul><li>Also function & procedures with raw parameters </li></ul><ul><li>Need the same IV to decrypt. </li></ul>
27. 27. Oracle DBMS Obfuscation Toolkit <ul><li>DOTK DES3 Generate Key Procedure: </li></ul><ul><li>DBMS_OBFUSCATION_TOOLKIT. DES3GetKey ( </li></ul><ul><li>which IN PLS_INTEGER DEFAULT TwoKeyMode, </li></ul><ul><li>seed_string IN VARCHAR2, </li></ul><ul><li>key OUT VARCHAR2); </li></ul><ul><li>Also function with output returned </li></ul><ul><li>Also function & procedure with raw parameters </li></ul><ul><li>Important to use Random seed. </li></ul>
28. 28. Oracle DBMS Crypto Checklist <ul><li>Use either the AES192 or AES256 algorithm </li></ul><ul><li>Use DBMS_CRYPTO.RANDOMBYTES() to generate random keys, not DBMS_RANDOM </li></ul><ul><li>Use CBC (Cipher Block Chaining) mode. CFB Cipher Feedback Mode and OFB Output Feedback Mode are both ok </li></ul><ul><li>Do not use ECB Electronic Codebook chaining mode (It is weak) </li></ul><ul><li>Use PKCS5 for cryptographic padding rather than null padding </li></ul>
29. 29. Oracle DBMS Crypto Encryption <ul><li>Sample Encrypt function </li></ul><ul><li>DBMS_CRYPTO. ENCRYPT ( </li></ul><ul><li>src IN RAW, </li></ul><ul><li>typ IN PLS_INTEGER, </li></ul><ul><li>key IN RAW, </li></ul><ul><li>iv IN RAW DEFAULT NULL) </li></ul><ul><li>RETURN RAW; </li></ul><ul><li>Also procedure with output as a parameter </li></ul><ul><li>Important to use Random IV. </li></ul><ul><li>Decrypt function & procedure are very similar. </li></ul>
30. 30. Oracle DBMS Crypto Encrypt TYP Parameter <ul><li>TYP parameter specifies algorithms and modifiers </li></ul>CBC, CFB, ECB, OFB Block Cipher chain mode PKCS5, NONE, ZERO Padding forms DES, 3DES, AES128, AES192, AES256, RC4, 3DES_2KEY Crypto algorithm Options Feature
31. 31. Oracle DBMS Crypto Encryption <ul><li>DBMS Crypto Generate Random Bytes: </li></ul><ul><li>DBMS_CRYPTO.RANDOMBYTES ( </li></ul><ul><li>number_bytes IN POSITIVE) </li></ul><ul><li>RETURN RAW; </li></ul><ul><li>Use for Random IV and to generate random keys </li></ul><ul><li>Do not use DBMS_RANDOM, as it’s weak. </li></ul>
32. 32. Encryption for MS SQL Server 2005 <ul><li>Key Management Hierarchy </li></ul><ul><ul><li>Service Master Key </li></ul></ul><ul><ul><ul><li>Root – Top Level Key – symmetric key </li></ul></ul></ul><ul><ul><ul><li>One Service Master key per installation </li></ul></ul></ul><ul><ul><ul><li>Auto-Generated at time of installation </li></ul></ul></ul><ul><ul><ul><li>Can not be directly access, </li></ul></ul></ul><ul><ul><ul><li>Can be regenerated and exported </li></ul></ul></ul><ul><ul><ul><li>Accessed by SQL Server Service account </li></ul></ul></ul>
33. 33. MS SQL Server Key Management Hierarchy <ul><li>Key Management Hierarchy </li></ul><ul><ul><li>Database Master Keys </li></ul></ul><ul><ul><ul><li>Symmetric key </li></ul></ul></ul><ul><ul><ul><li>One Database Master key per Database </li></ul></ul></ul><ul><ul><ul><li>Used to encrypt all user keys in the database </li></ul></ul></ul><ul><ul><ul><li>Copy stored encrypted with Service Master Key </li></ul></ul></ul><ul><ul><ul><li>Also stored encrypted with a password </li></ul></ul></ul><ul><ul><ul><li>Recommend removing copy stored with service master key if possible. </li></ul></ul></ul><ul><ul><li>User Keys </li></ul></ul><ul><ul><ul><li>May be a certificates, asymmetric keys or symmetric key </li></ul></ul></ul><ul><ul><ul><li>Generated as needed by DBA or users </li></ul></ul></ul><ul><ul><ul><li>Stored encrypted with Database Master key </li></ul></ul></ul>
34. 34. MS SQL Server Key Management Hierarchy Protects Protects Service Master Key Database Master Key Protects Certificates Asymmetric Keys Symmetric Keys Database Master Key
35. 35. MS SQL Server Protecting Password <ul><ul><li>Avoid storing passwords if possible </li></ul></ul><ul><ul><li>Use LDAP or Active Directory is possible </li></ul></ul><ul><ul><li>Otherwise use Crypto API to generate secure salted hash: </li></ul></ul><ul><ul><ul><li>CryptGenRandom() generates a salt </li></ul></ul></ul><ul><ul><ul><li>CryptCreateHash() creates hash object </li></ul></ul></ul><ul><ul><ul><li>CryptHashData() generated hash </li></ul></ul></ul>
36. 36. MS SQL Server Checklist <ul><li>Use either the AES192 or AES256 algorithm </li></ul><ul><li>Use randomly generated keys and passwords </li></ul><ul><ul><li>generated by MS SQL Server, </li></ul></ul><ul><ul><li>or via CryptGenRandom() from MS Crypto API </li></ul></ul><ul><li>Avoid storing keys or passwords in software </li></ul><ul><li>Remove the service key encrypted copy of the database master, if possible to reduce risk. </li></ul>
37. 37. Summary <ul><li>Database Encryption is increasingly an important and more often required security control </li></ul><ul><li>Effective layer of defense if properly implemented </li></ul><ul><li>Protecting Keys hard to do, and is most common weakness </li></ul><ul><li>Key Management and Encryption requirements needs to be defined early in application requirements </li></ul><ul><li>Use these guidelines during the architecture, design and implementation of encryption. </li></ul>
38. 38. Resources & References <ul><li>Recommended MS SQL Server References </li></ul><ul><li>Protect Sensitive Data Using Encryption in SQL Server 2005 </li></ul><ul><li>http://www.microsoft.com/technet/prodtechnol/sql/2005/sqlencryption.mspx </li></ul>
39. 39. Resources & References (2) <ul><li>Recommended Oracle References </li></ul><ul><li>Encrypt Your Data Assets - Scenario and example of DBMS_CRYPTO usage. http://www.oracle.com/technology/oramag/oracle/05-jan/o15security.html </li></ul><ul><li>[Kornbrust] 2005 BlackHat Presentation on how to circumvent Oracle DB Encryption . - http://www.blackhat.com/presentations/bh-usa-05/bh-us-05-kornbrust.pdf </li></ul><ul><li>Oracle Security Guide 16 “Developing Applications Using Data Encryption” http://download.oracle.com/docs/cd/B14117_01/network.101/b10773/apdvncrp.htm#1006258 </li></ul>
40. 40. Thank You ! <ul><li>Questions? </li></ul>