[Day04] 資料儲存安全(SQL加密函數)

2017 iT 邦幫忙鐵人賽

DAY 4

Security

資料安全與簡單加密演算法見面會系列第 4 篇

2017鐵人賽 sql server

StanleyJui

2016-12-19 20:24:11

29769 瀏覽

分享至

昨天我們開始戍衛京師周邊的任務，先試著用雜湊演算法(hash)將欄位PAN(Primary account number)賦予不可讀性(unreadable)及不可逆性(not reversible)，但如果想要資料是可逆(reversible)的，也就是說有一天想轉回原來的資料時，這個時候就很適合套加密演算法(encrypt)替資料加密。

加密演算法(Encrypt Algorithm)

先淺淺的認識Encrypt algorithm，加密演算法是用1~N把金鑰(key)作為事先約定好的參數，將明文透過取代、置換及數學運算流程產生成密文，加密後的密文，也可以依照加密時選擇的金鑰(key)解密成明文。

我們來試試SQL Server中的加密函數。

簡單加密函數

如果想要單純使用金鑰加密，在T-SQL中內建了一種加密函數(EncryptByPassPhrase)，她是使用Triple DES(TDEA) 演算法，也許可以符合我們的需求。

DECLARE @TDEAKey nvarchar(128);  
SET @TDEAKey = '0123456789ABCDEF';  
--加密  
DECLARE @ciphertext varbinary(max)
= EncryptByPassPhrase(@TDEAKey, '3123456789012345')  
SELECT @ciphertext
--解密
DECLARE @plainttext varchar(16) 
= CONVERT(varchar(16),DecryptByPassphrase(@TDEAKey, @ciphertext))  
SELECT @plainttext

執行結果:

最大的缺點就是金鑰不容易隱藏，很容易在T-SQL被野生捕獲。
SQL Server還有另一種把加密金鑰儲存在憑證或透過其他金鑰保護的作法，我們來試試憑證這種。

建立Master KEY、建立憑證、建立資料加密金鑰

在進行加密之前，我們得先在資料庫中建立加密金鑰、儲存加密金鑰的憑證以及DMK(Database Master key)。

1.建立MASTER KEY

CREATE MASTER KEY  
ENCRYPTION BY PASSWORD = 'imMKpassword1' 
GO

2.建立憑證

CREATE CERTIFICATE [Cert]  
WITH SUBJECT = '測試憑證' 
GO

3.建立金鑰

CREATE SYMMETRIC KEY AES256key 
WITH ALGORITHM = AES_256 ENCRYPTION 
BY CERTIFICATE [Cert]  
GO

加密資料

--1.開啟憑證、金鑰 
OPEN SYMMETRIC KEY AES256key DECRYPTION BY CERTIFICATE [Cert] 
GO
--2.欄位加密 
INSERT INTO cardholder 
VALUES
((EncryptByKey(Key_GUID('AES256key'),'4123456789012345')),N'大衛王','101','1299'), 
((EncryptByKey(Key_GUID('AES256key'),'4223456789012346')),N'查理曼','101','1299') 
GO
--3.關閉金鑰 
CLOSE ALL SYMMETRIC KEYS 
GO

觀察寫入資料表結果:

SELECT * FROM cardholder 
GO

加密和雜湊後的資料都是不可讀(unreadable)的狀態。

加密結果

加密函數預設是採動態初始向量(IV)的方式，同一個明文加密後可能有不同結果，我們來實際驗證看看。

OPEN SYMMETRIC KEY AES256key DECRYPTION BY CERTIFICATE [Cert] 
GO 
SELECT EncryptByKey(Key_GUID('AES256key'),'4223456789012346') 
SELECT EncryptByKey(Key_GUID('AES256key'),'4223456789012346')

果然不同!

如果需要查詢資料，看起來必須將加密欄位解密後再來和條件比對。

查詢加密資料

--1.開啟憑證、金鑰  
OPEN SYMMETRIC KEY AES256key DECRYPTION BY CERTIFICATE [Cert] 
--查詢不到
SELECT * FROM cardholder 
where pan = CONVERT(VARBINARY(MAX),EncryptByKey(Key_GUID('AES256key'),'4223456789012346')) 

--查詢的到  
select * from cardholder 
WHERE CONVERT(varchar,DecryptByKey(pan)) = '4223456789012346'

第一段把條件加密後進資料庫查詢不到資料，
第二段則把資料解密後和條件比較則可以正確查詢到第二筆資料!

msdn說明:

加密演算法會定義資料轉換，讓未經授權的使用者無法輕鬆地反轉資料轉換。 SQL Server 可讓管理員和開發人員在數種演算法中進行選擇，包括 DES、Triple DES、TRIPLE_DES_3KEY、RC2、RC4、128 位元 RC4、DESX、128 位元 AES、192 位元 AES 和 256 位元 AES。

小結:

SQL Server 2016之後，因為其他演算法已經陸續被破解，AES之外的演算法都不建議使用。
可以針對加密金鑰設定使用權限。
嗯，在效能上把資料先解密再來和條件比對似乎不是很理想。

風險

雖然我們把資料成功加解密了，但加密所使用的金鑰和加密後的資料都放在同一台機器(DB Server)，就像金庫的密碼和金鑰沒有分人保管，難免有球員兼裁判之嫌，此時獨立安全的Key management更顯得重要。

其他的解決方案:

EKM(Extensible Key Management) HSM?
SQL Server 2016 Always always encrypted

有關 PA DSS Requirement 2:Protect stored cardholder data，在章節 2.3對於PAN的說明。

Render PAN unreadable anywhere it is stored (including data on portable digital media, backup media, and in logs) by using any of the following approaches:
• One - way hashes based on strong cryptography(hash must be of the entire PAN)
• Truncation(hashing cannot be used to replace the truncated segment of PAN)
• Index tokens and pads (pads must be securely stored)
• Strong cryptography with associated key - management processes and procedures.

Notes:
• It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of a PAN. Where hashed and truncated versions of the same PAN are generated by a payment application, additional controls should be in place to ensure that hashed and truncated versions cannot be correlated to reconstruct the original PAN.
• The PAN must be rendered unreadable anywhere it is stored, even outside the payment application(for example, log files output by the application for storage in the merchant environment)