Utilisation du chiffrement avec les bases de données SQL

Le chiffrement se révèle très utile dès que vous souhaitez limiter l’accès aux informations stockées dans une base de données. Dans Adobe AIR, la fonction de chiffrement de base de données peut être utilisée dans plusieurs objectifs. Voici quelques exemples pour lesquels l’utilisation d’une base de données chiffrée peut être utile :

• Cache en lecture seule de données d’application privées et téléchargées depuis un serveur

• Stockage d’application local de données privées synchronisées avec un serveur (données envoyées et chargées depuis le serveur)

• Fichiers chiffrés utilisés en tant que format de fichier pour les documents créés et modifiés par l’application Les fichiers peuvent être réservés à un utilisateur, donc privés, ou conçus pour être partagés par tous les utilisateurs de l’application.

• Toute autre utilisation d’un magasin local de données, par exemple les utilisations décrites à la section Cas d’utilisation des bases de données SQL locales , où les données peuvent être réservées aux personnes disposant d’un accès à l’ordinateur ou aux fichiers de la base de données.

Comprendre la raison pour laquelle vous souhaitez utiliser une base de données chiffrée vous permet de choisir l’architecture de votre application. Le chiffrement risque en particulier d’affecter la manière dont l’application crée, obtient et stocke la clé de chiffrement de la base de données. Pour plus d’informations sur ces considérations, voir Considérations relatives à l’utilisation du chiffrement avec une base de données .

Parallèlement à l’utilisation d’une base de données chiffrée, le magasin local chiffré permet également de préserver la confidentialité des données sensibles. Grâce au magasin local chiffré, vous stockez une valeur ByteArray unique avec une clé String. Seule l’application AIR qui stocke la valeur peut y accéder, et ceci uniquement sur l’ordinateur sur lequel elle est stockée. Avec le magasin local chiffré, il n’est pas nécessaire de créer votre propre clé de chiffrement. Pour ces raisons, le magasin local chiffré convient davantage au stockage aisé d’une seule valeur ou d’un ensemble de valeurs facilement encodé dans un objet ByteArray. Une base de données chiffrée convient mieux aux grands ensembles de données où l’interrogation et le stockage de données structurées sont souhaitables. Pour plus d’informations sur l’utilisation du magasin local chiffré, voir Stockage local chiffré .

Pour utiliser une base de données chiffrée, son fichier doit être chiffré lors de sa création. Lorsqu’une base de données a été créée sans chiffrement, elle ne peut plus être chiffrée par la suite. De la même façon, une base de données chiffrée ne peut pas devenir non chiffrée. Si nécessaire, vous pouvez modifier la clé de chiffrement d’une base de données chiffrée. Pour plus d’informations, voir la section Modification de la clé de chiffrement d’une base de données . Si votre base de données n’est pas chiffrée et que vous souhaitez utiliser le chiffrement de bases de données, vous pouvez créer une nouvelle base de données chiffrée, puis y copier la structure et les données des tables existantes.

La création d’une base de données chiffrée est très similaire à la création d’une base de données non chiffrée, décrite à la section Création d’une base de données . Vous commencez par créer une occurrence de SQLConnection représentant la connexion à la base de données. Vous créez la base de données en appelant la méthode open() ou openAsync() de l’objet SQLConnection, en spécifiant un fichier qui n’existe pas encore pour l’emplacement de la base de données. La seule différence lors de la création d’une base de données chiffrée est que vous fournissez une valeur au paramètre encryptionKey (cinquième paramètre de la méthode open() et sixième paramètre de la méthode openAsync() ).

Un objet ByteArray contenant exactement 16 octets constitue une valeur valide du paramètre encryptionKey .

Les exemples suivants illustrent la création d’une base de données chiffrée. Pour plus de simplicité, la clé de chiffrement est codée en dur dans le code de l’application dans ces exemples. Toutefois, cette technique est fortement déconseillée car elle n’est pas sécurisée.

var conn:SQLConnection = new SQLConnection(); 
     
var encryptionKey:ByteArray = new ByteArray(); 
encryptionKey.writeUTFBytes("Some16ByteString"); // This technique is not secure! 
     
// Create an encrypted database in asynchronous mode 
conn.openAsync(dbFile, SQLMode.CREATE, null, false, 1024, encryptionKey); 
     
// Create an encrypted database in synchronous mode 
conn.open(dbFile, SQLMode.CREATE, false, 1024, encryptionKey);

Vous trouverez un exemple décrivant un moyen conseillé de générer une clé de chiffrement à la section Exemple : Génération et utilisation d’une clé de chiffrement .

Comme la création d’une base de données chiffrée, la procédure qui permet d’ouvrir une connexion à une base de données chiffrée est la même que pour une base de données non chiffrée. Cette procédure est détaillée à la section Connexion à une base de données . Vous faites appel à la méthode open() pour ouvrir une connexion en mode d’exécution synchrone , à la méthode openAsync() pour ouvrir une connexion en mode d’exécution asynchrone . La seule différence est que, pour ouvrir une base de données chiffrée, vous spécifiez la valeur correcte du paramètre encryptionKey (cinquième paramètre de la méthode open() et sixième paramètre de la méthode openAsync() ).

Si la clé de chiffrement fournie n’est pas correcte, une erreur se produit. Dans le cas de la méthode open() , une exception SQLError est renvoyée. Dans le cas de la méthode openAsync() , l’objet SQLConnection distribue un événement SQLErrorEvent , dont la propriété error contient un objet SQLError . Dans les deux cas, l’objet SQLError généré par l’exception a une valeur de propriété errorID 3138. Cet ID d’erreur correspond au message d’erreur « Le fichier ouvert n’est pas un fichier de base de données ».

L’exemple suivant décrit l’ouverture d’une base de données chiffrée en mode d’exécution asynchrone. Pour plus de simplicité, dans cet exemple, la clé de chiffrement est codée en dur dans le code de l’application. Toutefois, cette technique est fortement déconseillée car elle n’est pas sécurisée.

import flash.data.SQLConnection; 
import flash.data.SQLMode; 
import flash.events.SQLErrorEvent; 
import flash.events.SQLEvent; 
import flash.filesystem.File; 
     
var conn:SQLConnection = new SQLConnection(); 
conn.addEventListener(SQLEvent.OPEN, openHandler); 
conn.addEventListener(SQLErrorEvent.ERROR, errorHandler); 
var dbFile:File = File.applicationStorageDirectory.resolvePath("DBSample.db"); 
     
var encryptionKey:ByteArray = new ByteArray(); 
encryptionKey.writeUTFBytes("Some16ByteString"); // This technique is not secure! 
     
conn.openAsync(dbFile, SQLMode.UPDATE, null, false, 1024, encryptionKey); 
     
function openHandler(event:SQLEvent):void 
{ 
    trace("the database opened successfully"); 
} 
     
function errorHandler(event:SQLErrorEvent):void 
{ 
    if (event.error.errorID == 3138) 
    { 
        trace("Incorrect encryption key"); 
    } 
    else 
    { 
        trace("Error message:", event.error.message); 
        trace("Details:", event.error.details); 
    } 
} 

L’exemple suivant décrit l’ouverture d’une base de données chiffrée en mode d’exécution synchrone. Pour plus de simplicité, dans cet exemple, la clé de chiffrement est codée en dur dans le code de l’application. Toutefois, cette technique est fortement déconseillée car elle n’est pas sécurisée.

import flash.data.SQLConnection; 
import flash.data.SQLMode; 
import flash.filesystem.File; 
     
var conn:SQLConnection = new SQLConnection(); 
var dbFile:File = File.applicationStorageDirectory.resolvePath("DBSample.db"); 
     
var encryptionKey:ByteArray = new ByteArray(); 
encryptionKey.writeUTFBytes("Some16ByteString"); // This technique is not secure! 
     
try 
{ 
    conn.open(dbFile, SQLMode.UPDATE, false, 1024, encryptionKey); 
    trace("the database was created successfully"); 
} 
catch (error:SQLError) 
{ 
    if (error.errorID == 3138) 
    { 
        trace("Incorrect encryption key"); 
    } 
    else 
    { 
        trace("Error message:", error.message); 
        trace("Details:", error.details); 
    } 
} 

Vous trouverez un exemple décrivant un moyen conseillé de générer une clé de chiffrement à la section Exemple : Génération et utilisation d’une clé de chiffrement .

Vous pouvez modifier ultérieurement la clé de chiffrement d’une base de données chiffrée. Pour modifier la clé de chiffrement d’une base de données, commencez par ouvrir une connexion à la base de données en créant une occurrence de SQLConnection , puis appelez sa méthode open() ou openAsync() . Lorsque la connexion à la base de données est établie, appelez la méthode reencrypt() en transmettant la nouvelle clé de chiffrement en tant qu’argument.

Comme la plupart des opérations de base de données, le comportement de la méthode reencrypt() varie selon si la connexion à la base de données utilise le mode d’exécution synchrone ou asynchrone. Si vous utilisez la méthode open() pour vous connecter à la base de données, l’opération reencrypt() s’exécute de façon synchrone. Lorsque l’opération est terminée, l’exécution se poursuit avec la ligne suivante du code :

var newKey:ByteArray = new ByteArray(); 
// ... generate the new key and store it in newKey 
conn.reencrypt(newKey);

À l’inverse, si la connexion à la base de données est établie avec la méthode openAsync() , l’opération reencrypt() est asynchrone. L’appel à la méthode reencrypt() commence le processus de rechiffrement. Lorsque l’opération est terminée, l’objet SQLConnection distribue un événement reencrypt . Vous utilisez un écouteur d’événement pour connaître le moment où le rechiffrement se termine :

var newKey:ByteArray = new ByteArray(); 
// ... generate the new key and store it in newKey 
     
conn.addEventListener(SQLEvent.REENCRYPT, reencryptHandler); 
     
conn.reencrypt(newKey); 
     
function reencryptHandler(event:SQLEvent):void 
{ 
    // save the fact that the key changed 
}

L’opération reencrypt() s’exécute dans sa propre transaction. Si l’opération est interrompue ou échoue (par exemple, si l’application est fermée avant la fin de l’opération), la transaction est annulée. Dans ce cas, la clé de chiffrement d’origine demeure en vigueur pour la base de données.

La méthode reencrypt() ne peut pas être utilisée pour supprimer le chiffrage d’une base de données. La transmission d’une valeur null ou d’une clé de chiffrement qui ne correspond pas à un objet ByteArray de 16 octets à la méthode reencrypt() provoque une erreur.

La section Utilisation d’une base de données chiffrée présente plusieurs cas de figure pour lesquels l’utilisation d’une base de données chiffrée peut être nécessaire. À l’évidence, les besoins de confidentialité diffèrent selon les différents cas d’utilisation des applications (les scénarios présentés, ainsi que d’autres). L’architecture du chiffrement dans votre application joue un rôle important sur le contrôle de la confidentialité des données d’une base de données. Par exemple, si vous utilisez une base de données chiffrée pour assurer la confidentialité des données personnelles, même vis-à-vis des autres utilisateurs de l’ordinateur, la base de données de chaque utilisateur a besoin de sa propre clé de chiffrement. Pour une sécurité optimale, votre application peut générer la clé à partir d’un mot de passe saisi par l’utilisateur. Baser la clé de chiffrement sur un mot de passe permet d’être certain que les données demeurent inaccessibles, même si une autre personne utilise le compte de l’utilisateur sur l’ordinateur. À l’extrême opposé, supposons à présent que vous souhaitiez qu’un fichier de bases de données soit lisible par tout utilisateur de votre application, mais pas par les utilisateurs d’autres applications. Dans ce cas, chaque copie installée de l’application doit pouvoir accéder à une clé de chiffrement partagée.

Vous pouvez concevoir votre application, et en particulier la technique utilisée pour générer la clé de chiffrement, en fonction du niveau de confidentialité désiré pour les données de l’application. Voici une liste de quelques suggestions de conception répondant à divers niveaux de confidentialité des données :

• Pour qu’une base de données soit accessible à tout utilisateur autorisé à accéder à l’application sur n’importe quel ordinateur, utilisez une seule clé disponible pour toutes les occurrences de l’application. Par exemple, lors de sa première exécution, l’application peut télécharger la clé de chiffrement partagée sur un serveur en utilisant un protocole sécurisé de type SSL. Elle peut ensuite enregistrer la clé dans le magasin local chiffré pour l’utiliser ultérieurement. Une autre alternative consiste à chiffrer les données par utilisateur sur l’ordinateur, puis de synchroniser ces données à l’aide d’un magasin de données distant, tel qu’un serveur, pour rendre les données portables.

• Pour qu’un seul utilisateur puisse accéder à la base de données sur n’importe quel ordinateur, générez la clé de chiffrement en utilisant un secret propre à l’utilisateur (par exemple un mot de passe). En particulier, n’utilisez pas de valeur associée à un ordinateur particulier (par exemple une valeur stockée dans le magasin local chiffré) pour générer la clé. Une autre alternative consiste à chiffrer les données par utilisateur sur l’ordinateur, puis de synchroniser ces données à l’aide d’un magasin de données distant, tel qu’un serveur, pour rendre les données portables.

• Pour qu’un seul utilisateur puisse accéder à la base de données sur un seul ordinateur, générez la clé à partir d’un mot de passe et d’une valeur générée arbitrairement, appelée salt. Un exemple de cette technique est disponible à la section Exemple : Génération et utilisation d’une clé de chiffrement .

Voici d’autres considérations relatives à la sécurité qu’il est important de ne pas oublier lors de la conception d’une application utilisant une base de données chiffrée :

• Un système est autant sécurisé que ce que peut l’être son lien le plus faible. Si vous utilisez un mot de passe saisi par l’utilisateur pour générer une clé de chiffrement, pensez à imposer une longueur minimale et des contraintes de complexité pour les mots de passe. Un mot de passe court qui utilise seulement des caractères de base est facile à deviner.

• Le code source d’une application AIR est stocké sur l’ordinateur de l’utilisateur en texte brut (dans le cas de contenu HTML) ou dans un format binaire facile à décompiler (dans le cas de contenu SWF). Le code source étant accessible, les deux éléments à ne pas oublier sont :

  • Ne jamais coder en dur la clé de chiffrement dans votre code source

  • Toujours partir du principe qu’un attaquant peut aisément découvrir la technique utilisée pour générer une clé de chiffrement (par exemple un générateur de caractères aléatoire ou un algorithme de hachage particulier)

• Le chiffrement de base de données d’AIR utilise le chiffrement AES (Advanced Encryption Standard) avec le mode CBC-MAC (CCM). Pour être sécurisé, ce chiffrement combine la clé saisie par l’utilisateur avec une valeur salt. Un exemple de cette technique est disponible à la section Exemple : Génération et utilisation d’une clé de chiffrement .

• Lorsque vous choisissez de chiffrer une base de données, tous les fichiers disque utilisés par le moteur de base de données en combinaison avec celle-ci sont chiffrés. Toutefois, le moteur de base de données stocke certaines données temporaires en mémoire cache pour améliorer les performances en lecture et écriture au cours des transactions. Toutes les données qui résident en mémoire ne sont pas chiffrées. Si un attaquant peut accéder à la mémoire utilisée par l’application AIR, par exemple avec un débogueur, les données de la base de données ouverte et non chiffrée sont disponibles.

Cet exemple d’application présente une technique de génération de clé de chiffrement. Cette application est conçue pour assurer le plus haut niveau de confidentialité et de sécurité aux données des utilisateurs. Un point essentiel de la sécurisation des données privées consiste à obliger l’utilisateur à saisir un mot de passe à chaque connexion de l’application à la base de données. Par conséquent, comme nous l’avons vu dans cet exemple, une application exigeant ce niveau de confidentialité ne doit jamais stocker directement la clé de chiffrement de la base de données.

L’application comprend deux parties : une classe ActionScript qui génère une clé de chiffrement (la classe EncryptionKeyGenerator) et une interface utilisateur de base qui décrit l’utilisation de cette classe. Pour obtenir le code source complet, voir la section Exemple de code complet pour la génération et l’utilisation d’une clé de chiffrement .