I'm trying to understand this page from Microsoft http://technet.microsoft.com/en-us/library/ms189586.aspx.
According to the documentation "...they provide a higher level of security than symmetric encryption". I get that you first encrypt the data using symmetric and then encrypt that key using another method (symmetric or asymmetric) in order to avoid having to re-encrypt the data plus the speed benefits.
What I don't get is why choosing asymmetric over symmetric for that 2nd level is any more secure? Is it just because asymmetric can be then encrypted by the database master key? Is it possible to have one user encrypt data to another user on the same database then? I don't see what other advantage you would have within a database.
Given the absence of context on the referenced page I would assume they mean:
In a symmetric key regime anyone who has the shared secret key can encrypt or decrypt anything. In asymmetric key use, there is no single shared secret.
As Wikipedia notes, the "…requirement that both parties have access to the secret key is one of the main drawbacks of symmetric key encryption…"
added in response to comment:
Suppose I have a datum D that I want to encrypt with a symmetric shared key. I compute S(D) to get D'. If you have the key needed to decrypt D', you also have the key to compute E ⇔ E' where E and E' are any arbitrary plain- and cypher-text.
Contrariwise in asymmetric crypto, if I have used my secret key to compute P(D) to get D'' all you have available to you is my public key which allows you to compute Q(D'') → D but P(x) is not available to you so you can't create new cyphertext. You can't use my private key because you don't have it. You cannot give away my secret or use it yourself because you never had it. This is what makes shared key (symmetric) cryptography fundamentally less secure than public key (asymmetric) crypto.
Related
I'm absolutely new to topics like data encryption/decryption with MS SQL Server.
I have no problem with data encryption/decryption, but I cannot understand why the following example is given as a 'best practice'? Why should I protect the symmetric key with certificate if I can encrypt/decrypt data directly with symmetric key?
USE SOMEDB
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '***';
GO
CREATE CERTIFICATE [some_cert] WITH SUBJECT = 'Key Protection';
GO
CREATE SYMMETRIC KEY [some_sem_key] WITH
KEY_SOURCE = 'My key generation bits. This is a shared secret!',
ALGORITHM = AES_256,
ENCRYPTION BY CERTIFICATE [some_cert];
GO
The short answer - so that you don't have to share the symmetric key's password in order for those who would use it to encrypt/decrypt to be able to do so.
Exposition - what your example code doesn't show is how the key is used. In the case of a symmetric key that is encrypted by a certificate, it's
OPEN SYMMETRIC KEY [some_sem_key]
DECRYPTION BY CERTIFICATE [some_cert];
SELECT EncryptByKey(Key_GUID('some_sem_key'), 'Top Secret');
That's on the assumption that the certificate's private key itself is protected via a database master key (which your example shows, but just putting that out there as the certificate's can also be protected via a password which defeats this argument). Access can be controlled via GRANT'ing or revoking permissions on the certificate. Further, if the certificate is somehow compromised, rotating the protection is as easy as:
create certificate [some_cert2] WITH SUBJECT = 'Key Protection';
go
OPEN SYMMETRIC KEY [some_sem_key]
decryption by certificate [some_cert];
ALTER SYMMETRIC KEY [some_sem_key]
add encryption by certificate [some_cert2];
ALTER SYMMETRIC KEY [some_sem_key]
drop encryption by certificate [some_cert];
Contrast that with the method necessary if the symmetric key is protected via a password:
OPEN SYMMETRIC KEY [some_sem_key]
DECRYPTION BY PASSWORD = 'Sup3rSecurePassword!!!';
SELECT EncryptByKey(Key_GUID('some_sem_key'), 'Top Secret');
In that usage, you'd have to put disseminate Sup3rSecurePassword!!! everywhere it needs to be used (i.e. applications, individuals who have need to use, etc).
Credential rotation is mostly the same:
OPEN SYMMETRIC KEY [some_sem_key]
decryption by password = 'Sup3rSecurePassword!!!'
ALTER SYMMETRIC KEY [some_sem_key]
add encryption by password = 'M0r3SecurePassword!!!'
ALTER SYMMETRIC KEY [some_sem_key]
drop encryption by password = 'Sup3rSecurePassword!!!'
But the access control story is not. Possession of the password is the only thing controlling access to secrets protected with that symmetric key.
Your symmetric key is used because it's a lot faster and more resource-efficient than an asymmetric key for encrypting your data.
That means you can get away with the (relatively negligible) overhead of encrypting data with it "in real time".
Encrypting with a symmetric key uses less CPU and produces smaller encrypted data so it uses less storage.
However, it's still a single key.
To mitigate the inherent security risks of leaking a single master key, it's secured using a slower but far more secure certificate.
In short: the certificate protects the key(s) that is (are) used to encrypt the data.
I am using Active Directory to generate an ECDSA certificate of 256 bits and I need it to have the key encipherment key usage but even as I can see the configuration choosen has that option the certificate doesn't have it. What am I missing?
This is how my key usage tab looks:
But this is how the resulting certificate looks:
I've tried changing the allow encryption data option but the result is the same, is there somewhere else to force this key usage?
Thanks
In ECC, key encipherment is no longer used for online key encryption (e.g. in TLS), key agreement is used instead.
I have two databases . I copied all the data from one table and inserted into another database table . I have created symmetric key on second database but when i try to run the query as follow
OPEN SYMMETRIC KEY SecureSymmetricKey DECRYPTION BY PASSWORD = N'StrongPassword';
select DecryptByKey(columname) as DocSSN from tablename
CLOSE SYMMETRIC KEY SecureSymmetricKey;
but allway return null value.
You need to follow the steps described in Create Identical Symmetric Keys on Two Servers. You will have to re-encrypt all the data on both servers/databases with a newly created symmetric key that uses the given known key material. Creating a key copy after the fact is not possible.
Sharing symmetric keys between servers/databases is a very bad practice. You should encrypt with different keys on each database.
We are in a situation where symmetric key and certificates are deleted, Is there any way can we decrypt the data?
We tried decrypting the data with same script which was used for creating the master key , certificate and symmetric keys.
Thanks
Vivek
By definition: NO
If it would be possible, it would mean the entire cryptography feature in SQL Server was useless. Can you define what we lost the symmetric key and database certificate means? Your only chance is if your understanding of 'lost' is incorrect and you still have the keys somewhere. SQL Server will refuse to drop keys if there is still data encrypted with them. Also it would worth defining what you understand by 'database certificate'.
When using symmetric key to encrypt data, it uses a GUID for encryption. The GUID is generated automatically at the time of creatiion of symmetric key. So if u are trying to decrypt the data using newly generated symmetric key (same as old one), it will use the new GUID and as a result you cant decrypt it.
You can see this by using the following query: (Key_Guid is changing)
CREATE SYMMETRIC KEY KeyTest WITH ALGORITHM = TRIPLE_DES ENCRYPTION BY PASSWORD = 'EncryptPwd'
select * from sys.symmetric_keys
DROP SYMMETRIC KEY KeyTest
CREATE SYMMETRIC KEY KeyTest WITH ALGORITHM = TRIPLE_DES ENCRYPTION BY PASSWORD = 'EncryptPwd'
select * from sys.symmetric_keys
How many encryption keys can there be in a SQL Server database?
Can there be one encryption key for ColumnX and another encryption key for ColumnY and another for ColumnZ?
How can this be implemented?
You can create multiple encryption keys (millions) and use separate keys for separate columns. Adding multiple keys is critical for any scenario that requires periodic key rotation. To encrypt data you use ENCRYPTBYKEY and pass in the key name of the desired encryption key, see How to: Encrypt a Column of Data. You decrypt data using DECRYPTBYKEY. Note that you do not specify what decryption key to use, the engine knows. But you have to properly open the decryption key first, see OPEN SYMMETRIC KEY.