Quel est le meilleur moyen de crypter les SSN dans SQL Server 2008?

Question

Je suis en train de développer une nouvelle application web utilisant .NET 3.5 et SQL Server 2008 qui devra stocker quelques numéros de sécurité sociale. J'ai fait une première lecture sur le cryptage de la base de données et c'est un peu confus. Je ferais bien de crypter les SSN en utilisant une clé asymétrique, car de cette façon l'application publique ne serait pas capable de récupérer l'une des données une fois qu'elle a été cryptée. Je pensais que seule l'interface d'administration serait capable de déchiffrer et d'afficher les données. Mais il semble que SQL Server protège uniquement les données à l'aide d'une clé symétrique? Alors, quel est le meilleur moyen de crypter les SSN dans SQL Server 2008? Points bonus si vous liez un bon tutoriel ou deux.

Answer 1

Vous ne voulez vraiment pas utiliser le cryptage asymétrique car il est très lent. Au lieu de cela, vous voudrez protéger une clé symétrique avec une clé asymétrique, puis gardez la clé symétrique à portée de main. Pour être honnête, je voudrais rester avec ce qui est dans SQL Server plutôt que de concevoir des choses vous-même. Un très bon début est ici http://dotnetslackers.com/articles/sql/IntroductionToSQLServerEncryptionAndSymmetricKeyEncryptionTutorial.aspx

Answer 2

Si vous cryptez des données, vous devez vous demander qui va les déchiffrer. Si vous utilisez un système de chiffrement asymétrique (par exemple RSA), le chiffrement utilise la clé publique et le déchiffrement utilise la clé privée correspondante; "asymétrie" vient du fait que la clé privée ne peut pas être recalculée à partir de la clé publique (bien que les deux clés soient mathématiquement liées entre elles).

Le chiffrement asymétrique a tendance à avoir un surcoût. Une première remarque est que ce chiffrement doit avoir une part aléatoire, car tout le monde peut chiffrer (la clé publique est, oui, publique): si le processus de chiffrement est déterministe, n'importe qui peut chiffrer tous les SSN possibles (il y a moins d'un milliard d'entre eux, ce qui est un très petit nombre pour un ordinateur moderne) et correspondent aux valeurs cryptées. Par conséquent, il doit y avoir un peu aléatoire ajouté pendant le cryptage, et le SSN crypté est plus grand que le SSN en clair.

Les systèmes de chiffrement asymétriques connus utilisent des structures mathématiques qui ont leur propre coût. Fondamentalement, pour le système de cryptage RSA, avec une clé "assez forte", un message crypté aura une longueur d'au moins 128 octets. Certains systèmes de cryptage font mieux; tout en restant fidèle aux sentiers battus de la recherche académique, je pourrais le faire en 41 octets environ (avec El-Gamal sur la courbe elliptique du NIST K-163). Plus petit semble plus difficile.

Il n'est donc pas étonnant qu'un système de base de données donné n'inclue pas une telle fonctionnalité par défaut.

Pour votre problème, vous devez d'abord définir (et écrire), aussi clairement que vous pouvez:

• ce sont les données que vous souhaitez protéger
• qui entre les données
• Qui est censé lire les données de retour

et alors seulement vous devriez vous demander si le chiffrement est un outil approprié pour cela. Le cryptage est bon lorsque l'attaquant envisagé peut mettre la main sur les données stockées brutes. Cela signifie que l'attaquant a contourné les protections du système d'exploitation. À ce stade, quel que soit le système d'exploitation, l'attaquant le sait également. Si la base de données est hébergée sur une machine et qu'il existe une interface permettant d'obtenir le SSN déchiffré, alors cette machine "sait" comment obtenir les données, tout comme l'attaquant ... D'un autre côté, si l'hôte Le système d'exploitation de la machine est considéré comme assez résilient, alors le cryptage ne semble pas du tout nécessaire.

cryptage Symmetric sur la base de données peut résoudre un problème plus faible, dans lequel l'attaquant obtient une copie du disque dur après. Le système hôte connaît la clé de chiffrement symétrique, mais il la connaît uniquement en RAM. Un attaquant volant le disque dur n'aura pas cette clé.

Answer 3

Si vous devez stocker des SSN et que vous voulez qu'ils soient cryptés, je recommande d'utiliser un mécanisme de cryptage à clé symétrique comme 3DES ou AES. Avoir la clé de cryptage est une dérivation d'une phrase de passe que seules les personnes autorisées à accéder aux données savent et qu'elles doivent saisir chaque fois qu'elles accèdent aux données.

Ex: (10+ Character Pass Phrase) -> SHA-1 => KEY.

Ne vous embêtez pas compter sur la base de données elle-même pour faire le cryptage (bien que certainement se pencher sur des fonctionnalités telles que TDE ou quel que soit l'OS hôte vous exécutez support pour disque complet ou le chiffrement de fichiers comme secondaire sur -tout mécanisme de sécurité), utilisez plutôt les bibliothèques cryptographiques intégrées de .NET et tout langage de programmation que vous utilisez pour lire et écrire dans la base de données. Cela vous donne l'avantage de ne pas avoir à stocker une clé publique et privée ou de générer ces clés (ce qui est coûteux en calcul) et elles sont relativement grandes, donc le stockage est plus cher (relativement), vous ne pouvez pas non plus Vous devez vous inquiéter de la compromission de la clé lorsqu'un utilisateur non autorisé accède à la machine exécutant votre code (à l'exclusion des attaques MITM survenant lorsqu'un utilisateur entre la phrase secrète). Deuxièmement, il garantit que lorsqu'il est accédé, la seule façon dont ils peuvent être déchiffrés est par un utilisateur qui est autorisé (connaît le mot de passe). En fonction de votre budget (temps, effort, ressources), vous pouvez ajouter une authentification multifacteur où la clé de cryptage est dérivée à la fois d'une phrase de passe et d'un jeton que les utilisateurs autorisés auraient comme une carte à puce. Troisièmement, le cryptage et le décryptage des données à l'aide d'un algorithme de cryptage à clé symétrique sera beaucoup plus rapide.