1 respuesta
Respuesta de caim
1
¿Encriptar la base de datos por completo? ¿Esa es la idea? Creo necesario que visites Oracle Metalink, para el entendimiento de varios "paquetes" proveídos para los efectos. Aún así, te adjunto algunas notas.
This document explains selective Data Encryption available in the Oracle RDBMS
at a conceptual level with references to articles providing more technical
details, necessary to get an overview and develop a mindset when being
confronted with security requirements. The details are covered in the referenced
notes, remember that not all features were available when data encryption was
first introduced into the Oracle database.
SCOPE & APPLICATION
-------------------
DBA's, Application Developers, Security Managers
Selective Data Encryption
=========================
Oracle9i provides secure stored data encryption using industry-standard DES
and Triple DES algorithms.
Overview
========
Among other security technologies, Oracle protects data in E-business systems
through strong, standards-based encryption. Oracle has supported encryption of
network data though Oracle Advanced Security since Oracle7. Oracle9i also
supports protection of selected data via encryption within the database.
Although encryption is not a substitute for effective access control, one can
obtain an additional measure of security by selectively encrypting sensitive
data before it is stored in the database. Examples of such data could include:
- Credit card numbers
- National identity numbers
- passwords for applications whose users are not database users *)
- Trade secrets
- quarter end profits
*) passwords are usually hashed with a one way scheme, but
it may be necessary to encrypt plain text passwords
To address the need for selective data encryption, Oracle9i provides a PL/SQL
package to encrypt and decrypt stored data.
1- The package DBMS_OBFUSCATION_TOOLKIT, supports bulk data encryption using the
Data Encryption Standard (DES) algorithm, and includes procedures to encrypt
and decrypt using DES.
2- In addition to single DES, DBMS_OBFUSCATION_TOOLKIT supports Triple DES
(3DES) encryption, in both two and three key modes, for those who demand the
strongest commercial available level of encryption.
3- The Toolkit also supports the MD5 secure cryptographic hash to ensure data
integrity.
4- The Toolkit provides a Federal Information Processing Standard (FIPS) 140-certified
random number generator for generating secure encryption keys.
Licensing
=========
The package, DBMS_OBFUSCATION_TOOLKIT, is provided in both Standard Edition and
Enterprise Edition. It does not require additional licensing. Note that the
Advanced Security Option (ASO) that supports Network Encryption does require a
license.
Choice of Algorithms
====================
Oracle currently supports DES and Triple DES (3DES) only. They are regarded as the
industry standard choice of encryption of sensitive information. The Data
Encryption Standard (DES), has been a worldwide encryption standard for over
twenty years. The banking industry has also adopted DES-based standards for
transactions between private financial institutions, and between financial
institutions and private individuals. When industry demands warrants Oracle may
decide to incorporate other encryption algorithms such as AES; no plans to
support AES are available as of this time.
Note that we do support AES in our Advanced Security Option, that among other
features allows for a broad range of available network encryption algorithms.
DES Structure
=============
For detailed information about the DES algorithm, please refer to the extensive
documentation available elsewhere.
DES is a symmetric key cipher: the same key is used to encrypt data as well as
decrypt data. DES encrypts data in 64-bit blocks using a 56-bit key. The DES
algorithm ignores 8 bits of the 64-bit key that is supplied. However, developers
must supply a 64-bit key to the algorithm.
Triple DES (3DES) is a far stronger cipher than DES because of the longer key
length, it can be done in several ways; the most common and secure one is also
the one that is implemented by Oracle: encryption; decryption and encryption
steps in outer CBC mode. Being the fairly common choice, it allows for inter-
operability with other implementations available with third party products.
DES and Triple DES Security
===========================
DES has long been the leading encryption method throughout both government and
industry for a long time. It is extremely well scrutinized and even the long
term objection that some of the rationales behind the detailed structure had
not been made public was softened by some recent publications. The key length
however remains a point of concern; with the advent of faster CPU's a brute force
attack becomes ever more feasible. Hence for the most secure encryption needs,
always use Triple DES in three key mode, this has an effective key length of 168 bits.
ECB and CBC
===========
The DBMS_OBFUSCATION_TOOLKIT supports DES in ECB mode. Triple DES was implemented
in CBC mode. With ECB (Electronic Code Book), each 64 bit block is
encrypted independently; with CBC (Cipher Block Chaining) a feedback mechanism
is added so that every block of encrypted information depends on all previous
blocks. This provides an added level of security over ECB since all messages
encrypt differently. CBC requires an IV (Initialization Vector) that does not
need to be secret but just different for any message that is encrypted with the
same key.
Last Line of Defense
====================
It is important to understand that the DBMS_OBFUSCATION_TOOLKIT is just that:
A toolkit upon which an application developer must expand in order to achieve
specific security needs. Specific details of the implementation such as padding
up to 8-byte boundaries are left to the application developer, note the references
provide examples to these particular challenges. The toolkit is best suited to
selectively encrypt the most sensitive data in the database. Encryption inside the
database must also be regarded as a last line of defense: it typically protects you
against the possibility that your network, operating system and database security
measures such as firewalls and several authentication and authorization measures have
already failed and some malicious party is able to get to your data. Implementing
a secure scheme for store and retrieval of encrypted data goes much further than the
mere technical details.
In itself the triple DES in CBC mode is a generally accepted, industry standard
encryption algorithm. It is your specific implementation and how you manage encryption
keys that may easily compromise your real security, for example most cryptanalysis is
done by finding weak keys or poorly-stored keys, rather than through brute force
analysis (cycling through all possible keys).
Key Management
==============
The secrecy of encrypted data is dependent on the existence of a secret key
shared between the communicating parties. Providing and maintaining such secret
keys is known as "key management". Key management, including both generation and
secure storage of cryptographic keys, is one of the most important aspects of
encryption. If keys are poorly chosen or stored improperly, it is far easier for
a malefactor to break the encryption. Rather than using an exhaustive key search
attack (that is, cycling through all the possible keys in hopes of finding the
correct decryption key, also known as 'brute force attack'), cryptanalysts
typically seek weaknesses in the choice of keys, or the way in which keys are stored.
Remember that encryption is something that is easily done wrong and very hard to
get right. Once you have chosen a secure algorithm, consider that as the first
step in achieving security requirements. The next main problem is key management.
Imagine, when a corporation wants to protect credit card information from rogue DBAs,
it makes no sense to trust the DBAs with the encryption keys. In the real world,
key management is the hardest part of cryptography.
Key storage is one of the most important, yet difficult aspects of encryption
and one of the hardest to manage properly. To recover data encrypted with a
secret key, the key must be accessible to the application or user seeking to
decrypt data. The key needs to be easy enough to retrieve that users can access
encrypted data when they need to without significant performance degradation.
The key also needs to be secure enough so that it is not easily recoverable by an
unauthorized user trying to access encrypted data he is not supposed to see.
In the Oracle9i Supplied PL/SQL Packages and Types Reference, in the chapter on
DBMS_OBFUSACATION_TOOLKIT, three options available to a developer are discussed:
* Store the key in the database
* Store the key in the operating system
* Have the user manage the key
Generating Keys
===============
Key generation is an important aspect of encryption. Typically, keys are generated
automatically through a random-number generator. Provided that the random number
generation is cryptographically secure, this can be an acceptable form of key
generation. However, if random numbers are not cryptographically secure, but have
elements of predictability, the security of the encryption may be easily compromised.
Good keys are random bit strings: you can generate a secure 64 bit key with the
DESGetKey procedure of the dbms_obfuscation_toolkit. It tests against the known
weak keys although ever hitting upon one is very unlikely. For a Triple DES key,
use the DES3Getkey procedure or use DESGetKey three times.
Note: Do not use DBMS_RANDOM as it is unsuitable for cryptographic key generation.
Care must be taken by the application developers to ensure the secure generation
and storage of encryption keys used with the package. Furthermore, the
encryption and decryption done by the DBMS_OBFUSCATION_TOOLKIT takes place on
the server, not the client. If the key is passed over the connection between the
client and the server, the connection must be protected using Oracle Advanced
Security. Otherwise the key is vulnerable to capture over the wire.
References & Suggested Reading
==============================
Oracle9i Supplied PL/SQL Packages and Types Reference,
Chapter on DBMS_OBFUSCATION_TOOLKIT
<Note:102902.1>
Encrypting Data using the DBMS_OBFUSCATION_TOOLKIT package
<Note:166884.1>
How to use DBMS_OBFUSCATION_TOOLKIT.DES3Encrypt and DES3Decrypt
procedures
<Note:225214.1>
New IV Parameter to DES3Encrypt and DES3Decrypt Enhances
Interoperability
<Note:197400.1>
Example code encrypting credit card numbers
<Note:228636.1>
Meaning of the "WHICH" parameter in the procedures:
DES3Decrypt AND DES3Encrypt
<Note:197040.1>
dbms_obfuscation_toolkit.DESDecrypt compatibility problem
<Note:123091.1>
Wrapper for DBMS_OBFUSCATION_TOOLKIT, cope with 8-byte
input limitation
dbms_obfuscation_toolkit.
Espero ayude, y me cuentas.
Saludos,
CAIM
¿De dónde eres?
This document explains selective Data Encryption available in the Oracle RDBMS
at a conceptual level with references to articles providing more technical
details, necessary to get an overview and develop a mindset when being
confronted with security requirements. The details are covered in the referenced
notes, remember that not all features were available when data encryption was
first introduced into the Oracle database.
SCOPE & APPLICATION
-------------------
DBA's, Application Developers, Security Managers
Selective Data Encryption
=========================
Oracle9i provides secure stored data encryption using industry-standard DES
and Triple DES algorithms.
Overview
========
Among other security technologies, Oracle protects data in E-business systems
through strong, standards-based encryption. Oracle has supported encryption of
network data though Oracle Advanced Security since Oracle7. Oracle9i also
supports protection of selected data via encryption within the database.
Although encryption is not a substitute for effective access control, one can
obtain an additional measure of security by selectively encrypting sensitive
data before it is stored in the database. Examples of such data could include:
- Credit card numbers
- National identity numbers
- passwords for applications whose users are not database users *)
- Trade secrets
- quarter end profits
*) passwords are usually hashed with a one way scheme, but
it may be necessary to encrypt plain text passwords
To address the need for selective data encryption, Oracle9i provides a PL/SQL
package to encrypt and decrypt stored data.
1- The package DBMS_OBFUSCATION_TOOLKIT, supports bulk data encryption using the
Data Encryption Standard (DES) algorithm, and includes procedures to encrypt
and decrypt using DES.
2- In addition to single DES, DBMS_OBFUSCATION_TOOLKIT supports Triple DES
(3DES) encryption, in both two and three key modes, for those who demand the
strongest commercial available level of encryption.
3- The Toolkit also supports the MD5 secure cryptographic hash to ensure data
integrity.
4- The Toolkit provides a Federal Information Processing Standard (FIPS) 140-certified
random number generator for generating secure encryption keys.
Licensing
=========
The package, DBMS_OBFUSCATION_TOOLKIT, is provided in both Standard Edition and
Enterprise Edition. It does not require additional licensing. Note that the
Advanced Security Option (ASO) that supports Network Encryption does require a
license.
Choice of Algorithms
====================
Oracle currently supports DES and Triple DES (3DES) only. They are regarded as the
industry standard choice of encryption of sensitive information. The Data
Encryption Standard (DES), has been a worldwide encryption standard for over
twenty years. The banking industry has also adopted DES-based standards for
transactions between private financial institutions, and between financial
institutions and private individuals. When industry demands warrants Oracle may
decide to incorporate other encryption algorithms such as AES; no plans to
support AES are available as of this time.
Note that we do support AES in our Advanced Security Option, that among other
features allows for a broad range of available network encryption algorithms.
DES Structure
=============
For detailed information about the DES algorithm, please refer to the extensive
documentation available elsewhere.
DES is a symmetric key cipher: the same key is used to encrypt data as well as
decrypt data. DES encrypts data in 64-bit blocks using a 56-bit key. The DES
algorithm ignores 8 bits of the 64-bit key that is supplied. However, developers
must supply a 64-bit key to the algorithm.
Triple DES (3DES) is a far stronger cipher than DES because of the longer key
length, it can be done in several ways; the most common and secure one is also
the one that is implemented by Oracle: encryption; decryption and encryption
steps in outer CBC mode. Being the fairly common choice, it allows for inter-
operability with other implementations available with third party products.
DES and Triple DES Security
===========================
DES has long been the leading encryption method throughout both government and
industry for a long time. It is extremely well scrutinized and even the long
term objection that some of the rationales behind the detailed structure had
not been made public was softened by some recent publications. The key length
however remains a point of concern; with the advent of faster CPU's a brute force
attack becomes ever more feasible. Hence for the most secure encryption needs,
always use Triple DES in three key mode, this has an effective key length of 168 bits.
ECB and CBC
===========
The DBMS_OBFUSCATION_TOOLKIT supports DES in ECB mode. Triple DES was implemented
in CBC mode. With ECB (Electronic Code Book), each 64 bit block is
encrypted independently; with CBC (Cipher Block Chaining) a feedback mechanism
is added so that every block of encrypted information depends on all previous
blocks. This provides an added level of security over ECB since all messages
encrypt differently. CBC requires an IV (Initialization Vector) that does not
need to be secret but just different for any message that is encrypted with the
same key.
Last Line of Defense
====================
It is important to understand that the DBMS_OBFUSCATION_TOOLKIT is just that:
A toolkit upon which an application developer must expand in order to achieve
specific security needs. Specific details of the implementation such as padding
up to 8-byte boundaries are left to the application developer, note the references
provide examples to these particular challenges. The toolkit is best suited to
selectively encrypt the most sensitive data in the database. Encryption inside the
database must also be regarded as a last line of defense: it typically protects you
against the possibility that your network, operating system and database security
measures such as firewalls and several authentication and authorization measures have
already failed and some malicious party is able to get to your data. Implementing
a secure scheme for store and retrieval of encrypted data goes much further than the
mere technical details.
In itself the triple DES in CBC mode is a generally accepted, industry standard
encryption algorithm. It is your specific implementation and how you manage encryption
keys that may easily compromise your real security, for example most cryptanalysis is
done by finding weak keys or poorly-stored keys, rather than through brute force
analysis (cycling through all possible keys).
Key Management
==============
The secrecy of encrypted data is dependent on the existence of a secret key
shared between the communicating parties. Providing and maintaining such secret
keys is known as "key management". Key management, including both generation and
secure storage of cryptographic keys, is one of the most important aspects of
encryption. If keys are poorly chosen or stored improperly, it is far easier for
a malefactor to break the encryption. Rather than using an exhaustive key search
attack (that is, cycling through all the possible keys in hopes of finding the
correct decryption key, also known as 'brute force attack'), cryptanalysts
typically seek weaknesses in the choice of keys, or the way in which keys are stored.
Remember that encryption is something that is easily done wrong and very hard to
get right. Once you have chosen a secure algorithm, consider that as the first
step in achieving security requirements. The next main problem is key management.
Imagine, when a corporation wants to protect credit card information from rogue DBAs,
it makes no sense to trust the DBAs with the encryption keys. In the real world,
key management is the hardest part of cryptography.
Key storage is one of the most important, yet difficult aspects of encryption
and one of the hardest to manage properly. To recover data encrypted with a
secret key, the key must be accessible to the application or user seeking to
decrypt data. The key needs to be easy enough to retrieve that users can access
encrypted data when they need to without significant performance degradation.
The key also needs to be secure enough so that it is not easily recoverable by an
unauthorized user trying to access encrypted data he is not supposed to see.
In the Oracle9i Supplied PL/SQL Packages and Types Reference, in the chapter on
DBMS_OBFUSACATION_TOOLKIT, three options available to a developer are discussed:
* Store the key in the database
* Store the key in the operating system
* Have the user manage the key
Generating Keys
===============
Key generation is an important aspect of encryption. Typically, keys are generated
automatically through a random-number generator. Provided that the random number
generation is cryptographically secure, this can be an acceptable form of key
generation. However, if random numbers are not cryptographically secure, but have
elements of predictability, the security of the encryption may be easily compromised.
Good keys are random bit strings: you can generate a secure 64 bit key with the
DESGetKey procedure of the dbms_obfuscation_toolkit. It tests against the known
weak keys although ever hitting upon one is very unlikely. For a Triple DES key,
use the DES3Getkey procedure or use DESGetKey three times.
Note: Do not use DBMS_RANDOM as it is unsuitable for cryptographic key generation.
Care must be taken by the application developers to ensure the secure generation
and storage of encryption keys used with the package. Furthermore, the
encryption and decryption done by the DBMS_OBFUSCATION_TOOLKIT takes place on
the server, not the client. If the key is passed over the connection between the
client and the server, the connection must be protected using Oracle Advanced
Security. Otherwise the key is vulnerable to capture over the wire.
References & Suggested Reading
==============================
Oracle9i Supplied PL/SQL Packages and Types Reference,
Chapter on DBMS_OBFUSCATION_TOOLKIT
<Note:102902.1>
Encrypting Data using the DBMS_OBFUSCATION_TOOLKIT package
<Note:166884.1>
How to use DBMS_OBFUSCATION_TOOLKIT.DES3Encrypt and DES3Decrypt
procedures
<Note:225214.1>
New IV Parameter to DES3Encrypt and DES3Decrypt Enhances
Interoperability
<Note:197400.1>
Example code encrypting credit card numbers
<Note:228636.1>
Meaning of the "WHICH" parameter in the procedures:
DES3Decrypt AND DES3Encrypt
<Note:197040.1>
dbms_obfuscation_toolkit.DESDecrypt compatibility problem
<Note:123091.1>
Wrapper for DBMS_OBFUSCATION_TOOLKIT, cope with 8-byte
input limitation
dbms_obfuscation_toolkit.
Espero ayude, y me cuentas.
Saludos,
CAIM
¿De dónde eres?
