How to have one Master key in Gcloud and create Data Keys to encrypt.
And using the Master Key to decrypt the actual data.?
This is possible in AWS KMS. How to implement the same in Gcloud?
Thanks
By default, Compute Engine encrypts customer content at rest. Compute Engine handles and manages this encryption for you without any additional actions on your part. However, if you want to control and manage this encryption yourself, you can use key encryption keys. Key encryption keys do not directly encrypt your data but are used to encrypt the data encryption keys that encrypt your data.
If making the analogy with AWS "Master key" concept then "key Encryption key (GCP)" is the master key that is use to encrypt the "data encryption key"
AWS: "Plain Text Data"------>"data encryption key"---->"Encrypted data"
"data encryption key"-----> "Master key(AWS)"----> "Encrypted data key"
GCP: "Plain Text Data"------>"data encryption key"---->"Encrypted data"
"data encryption key"----->"key Encryption key(GCP)"----> "Encrypted data key"
As per document-1,You have two options for key encryption keys in Compute Engine:
1- Use Cloud Key Management Service to create and manage key encryption keys. For more information, see Key management. This topic provides details about this option, known as customer-managed encryption keys (CMEK).
2- Create and manage your own key encryption keys. For information about this option, known as customer-supplied encryption keys (CSEK), see Encrypting Disks with Customer-Supplied Encryption Keys.
Encryption: Cloud KMS keys are AES-256 keys. These keys are "key encryption keys" or "Master Keys"(AWS), and they encrypt the "data encryption keys" that encrypt your data.
Cloud KMS allows you to create, import, and manage "cryptographic keys" or "key encryption keys" or "Master Keys"(AWS) and perform cryptographic operations in a single centralized cloud service. You can use these keys and perform these operations by using Cloud KMS directly, by using Cloud HSM or Cloud External Key Manager, or by using Customer-Managed Encryption Keys (CMEK) integrations within other Google Cloud services.
Please note: If you provide your own "encryption keys" or own "key Encryption key" or ""Master key(AWS)" , Compute Engine uses your key to protect the "Google-generated keys" or "data encryption keys" used to encrypt and decrypt your data. Only users who can provide the correct "key Encryption key" can use resources protected by a customer-supplied encryption key.
Related
When encrypting symmetrically with Google Cloud's KMS, Google Cloud automatically chooses the primary key version:
Each symmetric encryption key has a designated primary version which is used at that point in time to encrypt data. In order for a key to be available for use to encrypt data, it needs to have a primary key version which is enabled.
When a key is used to encrypt plaintext, its primary key version is used to encrypt that data. The information as to which version was used to encrypt data is stored in the ciphertext of the data. Only one version of a key can be primary at any given point in time.
The EncryptResponse includes the ciphertext and the version of the key that was used.
If you haven't saved the version of the key at the time of encryption, is it possible to determine the key version later? The key version is stored in the ciphertext, and the KMS service is able to determine the key version to decrypt with, but the DecryptResponse only includes the plaintext, not the key version.
This is not currently possible but we've taken a feature request to provide the version when decrypting. Thanks for the suggestion and thanks for using GCP and Cloud KMS!
I have a requirement to secure the private key which is used for signing a blockchain transaction. While we are evaluating option of using HSM (Hardware Security Module), I was equally wondering about the applicability of Google Cloud KMS. Your help will be highly appreciated if you can answer my following queries :)
Can we save a key in Google Cloud KMS which may have been generated outside?
Assume that I have already saved my private key in Google Cloud KMS, which one of the following is true/possible?
Using an API call, the key stored in KMS is retrieved first and then it can be used to sign the blockchain transaction. But in this case, security can be compromised once the key is outside the KMS.
The key never leaves Google Cloud KMS once stored. Instead, a blockchain transaction can be sent to Google Cloud KMS for signing the transaction using the key managed by it. Here I assume that KMS may provide me some customization features so that I can execute the signing process or KMS may have capability to execute a piece of code.
Google Cloud KMS can't execute specialized tasks (like signing a Blockchain transaction), it just does the encryption/decryption only.
Cloud KMS doesn't store keys for retrieval; instead, it stores keys and keeps them secret. I believe your third bullet is closest to the situation.
In your situation, I would suggest wrapping the blockchain private key with a KMS key and then storing the wrapped private key somewhere. To sign a transaction, the app would use KMS to unwrap the key then sign it in software locally.
Yes, this exposes the calling app to the private key and makes you responsible for that security.
A question: what algorithm would you like signing support for? Google NEXT is next week, look for some announcements from us that you might be interested in.
With my on-prem KMS, I rotate keys monthly. Can I also do that with Cloud KMS? Is there a better recommended frequency compared to my on-prem use? Is data re-encrypted when I rotate a key?
Your desired frequency of key rotation depends on your use case and threat model. You want to limit the amount of very sensitive data encrypted with a single version of an encryption key.
On Google Cloud Platform, Google's Cloud KMS can be set to automatically rotate keys as often as once per day. This means that a new key version is automatically generated, and made the primary version used to encrypt new data. Most customers will typically choose 30 or 90 day rotation periods, based on business requirements.
Data is not re-encrypted when a key is rotated - rather, the new key version is used to encrypt any new data, but old data is not re-encrypted. You can manually do this by decrypting and re-encrypting the data.
For further discussion on key rotation in Cloud KMS: https://cloud.google.com/kms/docs/key-rotation#frequency_of_key_rotation
To set the rotation period on a key, using gcloud run:
gcloud beta kms cryptokeys set-rotation-schedule CRYPTOKEY_NAME \
--location LOCATION --keyring KEYRING_NAME \
--rotation-period ROTATION_PERIOD \
--next-rotation-time NEXT_ROTATION_TIME
in my database i used database column encryption using symmetric key. I followed this tutorial http://blog.sqlauthority.com/2009/04/28/sql-server-introduction-to-sql-server-encryption-and-symmetric-key-encryption-tutorial-with-script/ . it uses symmetric key and it is not visible to others. But a database admin can see the encrypted column by executing query that calling symmetric key.
USE EncryptTest
GO
OPEN SYMMETRIC KEY TestTableKey DECRYPTION
BY CERTIFICATE EncryptTestCert
SELECT CONVERT(VARCHAR(50),DECRYPTBYKEY(EncryptSecondCol)) AS DecryptSecondCol
FROM TestTable
GO
I need a encryption in database level and database admin also should not able decrypt the column. is it possible in database level encryption?
If you don't want a DBA who is a member of the sysadmin role on that instance to have any access to the keys, then you cannot allow the database to do the encryption.
Even if you try using the PASSWORD option of CREATE SYMMETRIC KEY, the DBA can use Profiler to see the password inside of the SQL statements. The DBA certainly has access to the Master Key (and may already have a backup of it).
You will need to have your application do the encryption if you want to hide data from DBA's.
Or you can trust your DBA's with the data they're protecting.
Since this question was asked, SQL Server 2016 has been released and the Enterprise Edition contains a feature called Always Encrypted, which is design with a certificate in a client driver encrypting a column encryption key on the server that performs the encryption. I would recommend putting the "client" on a middleware server like IIS for websites and web services where the certificate can be better protected.
A second solution to encryption beyond the reach of the DBA is to introduce an Extensible Key Management system. Support for this is also an Enterprise only feature. An Extensible Key Management system is a separate expansion board or system interfaced with SQL Server to offload all key management and encryption processing that can be put under the administration of a different team than the DBA.
Third, you can design a solution which includes dropping the private key of the certificate and having it in a location that is not accessible to the DBA. When the private key is dropped from a certificate in an encryption hierarchy, then the data can only be encrypted.
I have a security issue with one of our distributors. I need to prevent them from accessing certain data in our database. Because they administer the database I can't use password controls on the database itself to protect the data. I'm thinking that I need to encrypt the sensitive data in the database and have the encryption key embedded in software that we create. That way the distributor can poke around in the database all they want but the sensitive data will be unintelligible to them. I see how this might be done in MYSQL. There is are ENCODE and DECODE functions that allow me to pass a key in as a parameter. I can embed these keys in a piece of software, lock the software down, and this will allow me to insert and retrieve information. But what about MS SQL. How can I encrypt data so that even someone who is an administrator of the database cannot read that data?
Thank you,
Elliott
For MS SQL there is tons of documentation on encryption, and based on what you said about MYSQL I think you will be most interested in the Cryptographic Functions.
Note that I would be careful on which methods you encrypt with your own key, as a trace on the database or other means could be used to still obtain the key by inspecting the SQL commands you are sending.
There is definitely encrypt/decrypt functionality in MSSQL:
http://blogs.msdn.com/b/lcris/archive/2007/10/03/sql-server-2008-transparent-data-encryption-feature-a-quick-overview.aspx
http://blog.sqlauthority.com/2009/04/28/sql-server-introduction-to-sql-server-encryption-and-symmetric-key-encryption-tutorial-with-script/ [this one is a tutorial]
You probably want the code based one, as opposed to file encryption...
From this article: http://www.sql-server-performance.com/articles/dev/encryption_2005_2_p1.aspx
(Which BTW is the first result for a google search of encrypt data sql server)
Symmetric Keys
A Symmetric Key is a one key that is used for both encryption and decryption. This is a fast, commonly used method for encryption. As with a certificate, many parameters are available when creating Symmetric Keys. In most cases, we only need a limited set of parameters. You can refer to Books Online for all the parameters.
CREATE SYMMETRIC KEY TestSymKey
WITH ALGORITHM = TRIPLE_DES
ENCRYPTION BY CERTIFICATE CertificateTest2
You can specify an encryption algorithm for a symmetric key. DES, TRIPLE_DES, RC2, RC4, DESX, AES_128, AES_192, and AES_256 are the encryption algorithms available for SQL Server data encryption. AES encryption algorithms are currently supported only on Windows 2003. If you are using Windows 2000 or Windows XP, you do not have access to AES encryption algorithms from SQL Server. If you try to use an AES encryption algorithm, you will get an error:
Either no algorithm has been specified or the bit length and the algorithm specified for the key are not available in this installation of Windows.
You can encrypt a Symmetric Key using PASSWORD, SYMMETRIC KEY, ASYMMETRIC KEY, or CERTIFICATE.
The ALTER SYMMETRIC KEY and DROP SYMMETRIC KEY commands are also available to improve maintenance.
After the creation of a Symmetric Key, it is just a matter of using it. There are three functions you can use with Symmetric Keys: Key_GUID, EncryptByKey, and DecryptByKey.
OPEN SYMMETRIC KEY TestSymKey
DECRYPTION BY CERTIFICATE CertificateTest2;
DECLARE #Encryptvalsym varbinary(MAX)
SET #Encryptvalsym = EncryptByKey( key_guid('TestSymKey'),'scott')
SELECT convert(varchar(max),DecryptByKey(#Encryptvalsym))
Before using SYMMETRIC KEY, you need to open it by using the OPEN SYMMETRIC KEY command. To encrypt data you need to pass the GUID of the Symmetric Key. However, to decrypt it you don't have to pass the GUID. Instead, you have to open the encrypted Symmetric Key using the correct decryption method and value.
To increase the security of Symmetric Keys, you can add an authenticator during encryption. You have to use the same value during decryption.
OPEN SYMMETRIC KEY TestSymKey
DECRYPTION BY CERTIFICATE CertificateTest2;
DECLARE #Encryptvalsym1 varbinary(MAX)
SET #Encryptvalsym1 = EncryptByKey(key_guid('TestSymKey'),'scott',1,'SQL Server')
-- Decryption with Symmetric Keys
SELECT convert(varchar(max),DecryptByKey(#Encryptvalsym1,1,'SQL Server'))
I would skip the database centric algorithms and move it to a software managed solution. That way you can completely avoid the key ever being sent over the wire and compromised by a packet sniffing admin. (This is of course assuming you are using default transports for your database connection)
I've used this link as a reference for creating my DataSecurity library. I prefer the software managed scenario because it allows you to go as heavy or as lightweight as the solution requires, and it allows you to manage the keys in a way that compromising your database does not mean that your data gets compromised as well.