The JWE standard defines a concept called Key Management Mode. According to the RFC, there are five: Direct Encryption, Key Encryption, Direct Key Agreement, Key Wrapping, Key Agreement with Key Wrapping.
What's the difference between them and what's the point of having so many?
JWE always encrypts plaintext using a symmetric encryption key called CEK (Content Encryption Key). An issuer and recipient don't always have a pre-shared key they can use as the CEK, so they must use some form of public-key cryptography in order to securely share or agree on a CEK to use. Key Management Modes specify how the CEK is determined.
JWE always provides confidentiality (ensure only recipient can decrypt data), and integrity (ensure data was not altered by a third-party during transit). Depending on the Key Management Mode, it can also provide authentication (ensure data comes from issuer it claims to be).
JWE also supports tokens intended for multiple recipients where each recipient may use a different Key Management Mode. In this scenario, the JWE cannot use compact serialization and must use JSON serialization. Additionally, regardless of the number of recipients, JWE uses a single CEK to encrypt the plaintext. Thus, there is no need to include a different copy of the ciphertext for each intended recipient.
The following are the supported Key Management Modes by JWE:
1. Direct Encryption:
Used when:
Issuer and recipient have a pre-shared symmetric key.
How it works:
Let the pre-shared symmetric key be the CEK.
Issuer encrypts plaintext with CEK.
Recipient decrypts ciphertext with CEK.
Properties:
Confidentiality.
Integrity.
Authentication (assuming only issuer and recipient have knowledge of CEK).
Supported by multi-recipient JWE: No.
Example JOSE header: { "alg": "dir", "enc": "A256GCM" }
2. Key Encryption:
Used when:
Scenario A:
Issuer and recipient do not have a pre-shared symmetric key.
Issuer has knowledge of a recipient's public RSA key.
Scenario B:
Issuer wants to send a single JWE to multiple recipients.
Issuer and at least one of the recipients do not have a pre-shared symmetric key. Instead, the issuer has knowledge of a public RSA key for that recipient.
How it works:
Issuer randomly-generates a CEK.
Issuer encrypts plaintext with CEK.
For each intended recipient:
Issuer encrypts CEK with recipient's public key.
Issuer includes encrypted CEK + ciphertext in JWE.
Recipient decrypts encrypted CEK with its private key.
Recipient decrypts ciphertext with CEK.
Properties:
Confidentiality.
Integrity.
Supported by multi-recipient JWE: Yes.
Example JOSE header: { "alg": "RSA-OAEP", "enc": "A256GCM" }
3. Direct Key Agreement
Used when:
The issuer and recipient do not have a pre-shared symmetric key.
Issuer has knowledge of a recipient's public EC key (EC key pairs cannot be used directly to encrypt/decrypt data).
How it works:
Issuer randomly-generates an ephemeral EC public/private key pair.
Issuer derives CEK using ephemeral private key and recipient's public key.
Issuer encrypts plaintext with CEK.
Issuer includes ephemeral public key + ciphertext in JWE.
Recipient derives CEK using ephemeral public key and its private key.
Recipient decrypts ciphertext with CEK.
Properties:
Confidentiality.
Integrity.
Supported by multi-recipient JWE: No.
Example JOSE header: { "alg": "ECDH-ES", "enc": "A256GCM", "epk": { ephemeral public key }, "apu": "(issuer)", "apv": "(recipient)" }
4. Key Wrapping
Used when:
The issuer wants to send a single JWE to multiple recipients.
The issuer and at least one of the recipients have a pre-shared secret.
How it works:
Issuer randomly-generates a CEK.
Issuer encrypts plaintext with CEK.
For each intended recipient:
Let the pre-shared secret be the wrapping key or a password used to derive a wrapping key.
Issuer encrypts CEK with the wrapping key.
Issuer includes encrypted CEK + ciphertext in JWE.
Recipient finds its corresponding encrypted CEK and decrypts it with the wrapping key.
Recipient decrypts ciphertext with CEK.
Properties:
Confidentiality.
Integrity.
Authentication (assuming only issuer and recipient have knowledge of shared secret).
Supported by multi-recipient JWE: Yes.
Example JOSE header: { "alg": "A256KW", "enc": "A256GCM" }
5. Key Agreement with Key Wrapping
Used when:
The issuer wants to send a single JWE to multiple recipients.
The issuer and at least one of the recipients do not have a pre-shared symmetric key. Instead, the issuer has knowledge of a public EC key for that recipient (EC key pairs cannot be used directly to encrypt/decrypt data).
How it works:
Issuer randomly-generates a CEK.
Issuer encrypts plaintext with CEK.
For each intended recipient:
Issuer randomly-generates an ephemeral EC public/private key pair.
Issuer derives a wrapping key using ephemeral private key and recipient's public key.
Issuer encrypts CEK using wrapping key.
Issuer includes encrypted CEK + ephemeral public key + ciphertext in JWE.
Recipient finds its corresponding ephemeral public key and derives wrapping key using it and its private key.
Recipient finds its corresponding encrypted CEK and decrypts it using the derived wrapping key.
Recipient decrypts ciphertext with CEK.
Properties:
Confidentiality.
Integrity.
Supported by multi-recipient JWE: Yes.
Example JOSE header: { "alg": "ECDH-ES+A256KW", "enc": "A256GCM", "epk": { ephemeral public key }, "apu": "(issuer)", "apv": "(recipient)" }
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'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.
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.