Início / dba / Perguntas / 202262
Accepted
gotqn
Asked: 2018-03-27 02:20:22 +0800 CST

Como podemos descriptografar os dados sabendo a chave simétrica usada para a criptografia?

  • 772

Neste artigo é explicado como descriptografar uma chave simétrica . Por exemplo:

SELECT SK.name, SK.symmetric_key_id, SK.key_length, SK.algorithm_desc,
       KE.crypt_type_desc,
       COALESCE(C.name,AK.name,PSK.name) AS protector_name,
       KE.crypt_property AS encrypted_key,
       COALESCE(DECRYPTBYCERT(C.certificate_id,KE.crypt_property),
                DECRYPTBYASYMKEY(AK.asymmetric_key_id,KE.crypt_property)) AS decrypted_key
  FROM sys.key_encryptions AS KE
  JOIN sys.symmetric_keys AS SK
    ON KE.key_id = SK.symmetric_key_id
  LEFT JOIN sys.certificates AS C
    ON KE.thumbprint = C.thumbprint
  LEFT JOIN sys.asymmetric_keys AS AK
    ON KE.thumbprint = AK.thumbprint
  LEFT JOIN sys.symmetric_keys AS PSK
    ON KE.thumbprint = CAST(PSK.key_guid AS VARBINARY(50));

Ele pode ser testado usando a seguinte consulta:

-- 
CREATE MASTER KEY ENCRYPTION
BY PASSWORD = 'smGK_MasterKeyPassword@';

-- 
CREATE CERTIFICATE [CERT_V001]
WITH SUBJECT = 'User for protecting SM symetric keys.'


--
CREATE SYMMETRIC KEY [SK_SecurityUsers_V001]
WITH ALGORITHM = AES_256 ENCRYPTION
BY CERTIFICATE [CERT_V001]
GO


DECLARE @Email NVARCHAR(128) = '[email protected]';
DECLARE @EmailEncrypted VARBINARY(256);

OPEN SYMMETRIC KEY [SK_SecurityUsers_V001] DECRYPTION
BY CERTIFICATE [CERT_V001];

SELECT @EmailEncrypted = ENCRYPTBYKEY(KEY_GUID('SK_SecurityUsers_V001'),@Email);
SELECT @EmailEncrypted;

CLOSE SYMMETRIC KEY [SK_SecurityUsers_V001];


OPEN SYMMETRIC KEY [SK_SecurityUsers_V001] DECRYPTION
BY CERTIFICATE [CERT_V001];

SELECT CONVERT(NVARCHAR(128), DECRYPTBYKEY(@EmailEncrypted));

CLOSE SYMMETRIC KEY [SK_SecurityUsers_V001];


--DROP SYMMETRIC KEY [SK_SecurityUsers_V001];
--DROP CERTIFICATE [CERT_V001];
--DROP MASTER KEY;

Eu estou querendo saber, isso significa que os dados não estão protegidos?

No artigo é dito que:

No entanto, para chaves protegidas por senha e chave simétrica, isso infelizmente não funciona.

Acho que isso significa que preciso usar um desses tipos de criptografia para ter certeza de que os dados estão protegidos?

sql-server t-sql

1 respostas

  1. Best Answer

    Eu estou querendo saber, isso significa que os dados não estão protegidos?

    Não, é protegido, mas como mostrado no artigo, você precisa ter acesso a todas as chaves para descriptografar os valores. O artigo toma um monte de liberdades e encobre algumas coisas quando se trata da proteção das chaves. Tente fazer isso sem ser um administrador de sistema, saber a senha do DMK ou usar a hierarquia de descriptografia transparente. Você ainda poderia fazê-lo - provavelmente não.

    Os segredos no SQL Server são geralmente protegidos por níveis de criptografia - onde uma chave criptografa a outra que criptografa a outra. Se você puder desenrolar todos esses níveis (sobre os quais, novamente, o artigo nem fala e apenas encobre ), então absolutamente você pode descriptografar os dados. O SQL Server não usa nenhuma criptografia caseira, são todos os algoritmos padrão do setor que são documentados publicamente. Não há nada que impeça alguém de implementar algo para reverter se tivesse todas as chaves. É por isso que o excesso de permissões de provisionamento é uma coisa ruim.

    os dados devem ser criptografados em repouso e quero verificar se o comportamento acima pode dar a uma pessoa que tem acesso ao banco de dados, mas não sabe a senha da chave mestra do banco de dados, a capacidade de criptografar os dados.

    Nesse caso, não, eles geralmente não conseguiriam acessar os dados descriptografados. Existem, no entanto, casos extremos que não impedirão que alguém com acesso administrativo e um conhecimento decente de criptografia possivelmente obtenha os dados.

    É tudo sobre "proteção razoável" em que você deu uma proteção razoável o suficiente aos dados. Se você quisesse que fosse extremamente seguro, precisaria usar um HSM, que outra equipe possui e audita com extrema frequência. Ninguém teria acesso administrativo ao servidor e ninguém teria acesso sysadmin ao SQL Server. Isso provavelmente não vai funcionar - então a proteção "razoável" deve ser suficiente.

    • 1

relate perguntas