Korzystanie z szyfrowania w bazach danych SQL

Szyfrowanie jest przydatne w sytuacjach, gdy chcemy ograniczyć dostęp do informacji przechowywanych w bazie danych. Funkcja szyfrowania baz danych oferowana przez środowisko Adobe AIR może być używana w kilku różnych celach. Poniżej przedstawiono przykłady sytuacji, w których celowe mogłoby okazać się użycie zaszyfrowanej bazy danych.

• Przeznaczona tylko do odczytu pamięć podręczna na prywatne dane aplikacji pobrane z serwera.

• Lokalny magazyn aplikacji przeznaczony na dane prywatne i synchronizowane z serwerem (dane są wysyłane do serwera i z niego ładowane).

• Pliki zaszyfrowane jako format dokumentów tworzonych i edytowanych przez aplikację. Pliki mogą być prywatnymi plikami jednego użytkownika lub współużytkowane przez wszystkich użytkowników aplikacji.

• Wszelkie inne zastosowania lokalnego magazynu danych, takie jak opisane w sekcji Zastosowania lokalnych baz danych SQL , gdy dane muszą być niedostępne dla osób mających dostęp do komputera lub plików bazy danych.

Prawidłowe zdefiniowanie powodu, dla którego chcemy korzystać z zaszyfrowanej bazy danych, pomaga w podjęciu decyzji co do architektury aplikacji. W szczególności może mieć wpływ na sposób tworzenia, uzyskiwania i przechowywania klucza szyfrowania dla bazy danych. Więcej informacji na temat tych zagadnień zawiera sekcja Uwarunkowania szyfrowania bazy danych .

Alternatywnym dla zaszyfrowanej bazy danych mechanizmem zapewnienia poufności danych jest użycie zaszyfrowanego magazynu lokalnego . Zaszyfrowany magazyn lokalny umożliwia przechowywanie pojedynczej wartości ByteArray przy użyciu klucza typu String. Dostęp do takiej wartości ma tylko ta aplikacja AIR, która ją zapisała, i tylko na komputerze, na którym wartość jest przechowywana. W przypadku zaszyfrowanego magazynu lokalnego nie ma potrzeby tworzenia własnego klucza szyfrowania. Z tego względu zaszyfrowany magazyn lokalny jest najprostszym mechanizmem przechowywania pojedynczej wartości lub zestawu wartości, które można w prosty sposób zakodować w obiekcie ByteArray. Zaszyfrowana baza danych najlepiej nadaje się do przechowywania większych zestawów danych, gdy pożądane jest przechowywanie danych w postaci strukturyzowanej i możliwość kierowania zapytań do bazy danych. Więcej informacji na temat korzystania z zaszyfrowanego magazynu lokalnego zawiera sekcja Zaszyfrowany magazyn lokalny .

Aby skorzystać z szyfrowania bazy danych, plik bazy danych należy zaszyfrować już na etapie jego tworzenia. Bazy danych utworzonej jako niezaszyfrowanej nie można później zaszyfrować. Podobnie, zaszyfrowanej bazy danych nie można później przekształcić w niezaszyfrowaną. W razie potrzeby można zmienić klucz szyfrowania zaszyfrowanej bazy danych. Szczegółowe informacje zawiera sekcja Zmiana klucza szyfrowania bazy danych . Jeśli istnieje już niezaszyfrowana baza danych, a chcemy skorzystać z szyfrowania bazy danych, można utworzyć nową zaszyfrowaną bazę danych i kopiować istniejącą strukturę tabel oraz dane do nowej bazy danych.

Tworzenie zaszyfrowanej bazy danych odbywa się niemal identycznie jak tworzenie niezaszyfrowanej bazy danych, co opisano w sekcji Tworzenie bazy danych . Najpierw tworzymy instancję klasy SQLConnection reprezentującą połączenie z bazą danych. Bazę danych można utworzyć, wywołując metodę open() lub metodę openAsync() obiektu SQLConnection, jako lokalizację bazy danych wskazując plik, który jeszcze nie istnieje. Jedyna różnica występująca przy tworzeniu zaszyfrowanej bazy danych polega na konieczności podania wartości parametru encryptionKey (piątego parametru metody open() i szóstego parametru metody openAsync() ).

Poprawną wartością parametru encryptionKey jest obiekt ByteArray zawierający dokładnie 16 bajtów.

Poniższe przykłady ilustrują tworzenie zaszyfrowanej bazy danych. Dla uproszczenia przykładów klucz szyfrowania został zapisany na stałe w kodzie aplikacji. Jednak w rzeczywistych zastosowaniach nie zaleca się stosowania tego rozwiązania, ponieważ nie jest ono bezpieczne.

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);

Przykład demonstrujący zalecany sposób generowania klucza szyfrowania zawiera sekcja Przykład: Generowanie i używanie klucza szyfrowania .

Podobnie jak w przypadku tworzenia zaszyfrowanej bazy danych, procedura otwierania połączenia z zaszyfrowaną bazą danych jest podobna do otwierania połączenia z bazą niezaszyfrowaną. Procedurę tę opisano bardziej szczegółowo w sekcji Połączenie z bazą danych . Należy użyć metody open() http://help.adobe.com/pl_PL/Flash/CS5/AS3LR/flash/data/SQLConnection.html#open() w celu otwarcia połączenia w trybie wykonywania synchronicznego lub metody openAsync() w celu otwarcia połączenia w trybie wykonywania asynchronicznego . Jedyna różnica polega na tym, że aby utworzyć zaszyfrowaną bazę danych, należy podać prawidłową wartość parametru encryptionKey (piątego parametru metody open() i szóstego parametru metody openAsync() ).

Jeśli podany klucz szyfrowania nie jest prawidłowy, zgłaszany jest błąd. W przypadku metody open() generowany jest wyjątek SQLError . W przypadku metody openAsync() obiekt SQLConnection wywołuje zdarzenie SQLErrorEvent , którego właściwość error zawiera obiekt SQLError . W obu przypadkach obiekt SQLError wygenerowany przez wyjątek ma właściwość errorID równą 3138. Ten identyfikator błędu odpowiada komunikatowi „Otwarty plik nie jest plikiem bazy danych”.

Poniższy przykład ilustruje otwieranie zaszyfrowanej bazy danych w trybie wykonywania asynchronicznego. W celu uproszczenia przykładu klucz szyfrowania został zapisany na stałe w kodzie aplikacji. Jednak w rzeczywistych zastosowaniach nie zaleca się stosowania tego rozwiązania, ponieważ nie jest ono bezpieczne.

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); 
    } 
} 

Poniższy przykład ilustruje otwieranie zaszyfrowanej bazy danych w trybie wykonywania synchronicznego. W celu uproszczenia przykładu klucz szyfrowania został zapisany na stałe w kodzie aplikacji. Jednak w rzeczywistych zastosowaniach nie zaleca się stosowania tego rozwiązania, ponieważ nie jest ono bezpieczne.

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); 
    } 
} 

Przykład demonstrujący zalecany sposób generowania klucza szyfrowania zawiera sekcja Przykład: Generowanie i używanie klucza szyfrowania .

Klucz zaszyfrowanej bazy danych można zmieniać po jej utworzeniu. Aby zmienić klucz szyfrowania bazy danych, należy najpierw otworzyć połączenie z bazą danych, tworząc instancję klasy SQLConnection i wywołując jej metodę open() lub openAsync() . Po nawiązaniu połączenia z bazą danych należy wywołać metodę reencrypt() , przekazując jako jej argument nowy klucz szyfrowania.

Podobnie jak w przypadku większości operacji na bazie danych, działanie metody reencrypt() jest różne w zależności od tego, czy połączenie z bazą danych jest nawiązane w trybie wykonywania synchronicznego, czy asynchronicznego. Jeśli do połączenia z bazą danych użyto metody open() , operacja reencrypt() działa asynchronicznie. Gdy operacja zostanie zakończona, następuje wznowienie wykonywania kodu od kolejnego wiersza:

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

Natomiast jeśli połączenie z bazą danych zostało otwarte przy użyciu metody openAsync() , operacja reencrypt() jest asynchroniczna. Wywołanie metody reencrypt() rozpoczyna proces ponownego szyfrowania. Po zakończeniu operacji obiekt SQLConnection wywołuje zdarzenie reencrypt . W celu wykrycia zakończenia operacji ponownego szyfrowania należy skorzystać z detektora zdarzeń:

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 
}

Operacja reencrypt() działa w ramach swojej własnej transakcji. Jeśli zostanie przerwana lub zakończy się niepowodzeniem (na przykład aplikacja zostanie zamknięta przed ukończeniem operacji), transakcja jest wycofywana. W takim wypadku w bazie danych nadal obowiązuje dotychczasowy klucz szyfrowania.

Metoda reencrypt() nie umożliwia przekształcenie bazy danych w niezaszyfrowaną. Przekazanie do metody reencrypt() klucza szyfrowania o wartości null lub niebędącego 16-bajtowym obiektem ByteArray spowoduje błąd.

W sekcji Zastosowania zaszyfrowanej bazy danych przedstawiono kilka przypadków, w których celowe byłoby użycie zaszyfrowanej bazy danych. Oczywiste jest, że w różnych zastosowaniach (przedstawionych oraz innych) obowiązują różne wymagania w zakresie poufności danych. Sposób włączenia mechanizmu szyfrowania do struktury aplikacji istotnie wpływa na skuteczność ochrony poufności danych w bazie. Na przykład, jeśli zaszyfrowana baza danych ma zapewniać poufność danych osobistych, nawet między różnymi użytkownikami tego samego komputera, to baza danych każdego użytkownika powinna mieć inny klucz szyfrowania. Aby uzyskać najwyższy poziom bezpieczeństwa, aplikacja może generować klucze na podstawie haseł wprowadzanych przez użytkowników. Powiązanie klucza szyfrowania z hasłem gwarantuje, że nawet jeśli inna osoba zdoła podszyć się pod konto użytkownika na komputerze, nadal nie będzie mieć dostępu do danych. Przeciwstawny skrajny przypadek to sytuacja, w której plik bazy danych powinien być czytelny dla wszystkich użytkowników naszej aplikacji, ale nie dla innych aplikacji. W takim przypadku każda zainstalowana kopia aplikacji musi mieć dostęp do współużytkowanego klucza szyfrowania.

Budowę aplikacji, a w szczególności technikę generowania kluczy szyfrowania, można dopasować do wymaganego poziomu poufności danych aplikacji. Na poniższej liście przedstawiono propozycje rozwiązań odpowiadających różnym poziomom poufności danych:

• Aby baza danych była dostępna dla każdego użytkownika mającego dostęp do aplikacji na dowolnym komputerze, należy użyć jednego klucza dostępnego dla wszystkich instancji aplikacji. Na przykład przy pierwszym uruchomieniu aplikacja może pobrać współużytkowany klucz szyfrowania z serwera, korzystając z bezpiecznego protokołu, np. SSL. Następnie aplikacja może zapisać klucz w szyfrowanym magazynie lokalnym i korzystać z niego w przyszłości. Alternatywnym rozwiązaniem jest szyfrowanie danych poszczególnych użytkowników na komputerze i synchronizowanie danych ze zdalnym magazynem danych, na przykład serwerem, w celu zapewnienia przenośności danych między komputerami.

• Aby baza danych była dostępna dla jednego konkretnego użytkownika na dowolnym komputerze, należy wygenerować klucz szyfrowania na podstawie informacji znanej tylko użytkownikowi (np. hasła). W szczególności do generowania klucza nie należy używać wartości powiązanej z konkretnym komputerem (np. przechowywanej w szyfrowanym magazynie lokalnym). Alternatywnym rozwiązaniem jest szyfrowanie danych poszczególnych użytkowników na komputerze i synchronizowanie danych ze zdalnym magazynem danych, np. serwerem, w celu zapewnienia przenośności danych między komputerami.

• Aby baza danych była dostępna tylko dla jednej konkretnej osoby na jednym konkretnym komputerze, należy wygenerować klucz na podstawie hasła i wygenerowanego modyfikatora. Zastosowanie tej techniki ilustruje Przykład: Generowanie i używanie klucza szyfrowania .

Poniżej przedstawiono dodatkowe uwarunkowania dotyczące bezpieczeństwa, o których należy pamiętać, projektując aplikację korzystającą z zaszyfrowanej bazy danych.

• System jest tylko tak bezpieczny, jak jego najsłabsze ogniwo. Jeśli klucz szyfrowania jest generowany na podstawie hasła wprowadzanego przez użytkownika, wskazane jest narzucenie minimalnej długości i złożoności hasła. Krótkie hasła składające się tylko z podstawowych znaków można szybko odgadnąć.

• Kod źródłowy aplikacji AIR jest przechowywany na komputerze użytkownika w postaci zwykłego tekstu (w przypadku treści HTML) lub w formacie binarnym, który można jednak łatwo zdekompilować (w przypadku treści SWF). Ponieważ kod źródłowy jest dostępny, należy pamiętać o dwóch kwestiach:

  • Nigdy nie należy wpisywać klucza szyfrowania na stałe w kodzie aplikacji.

  • Należy zawsze zakładać, że osoba nieuprawniona będzie w stanie odtworzyć technikę użytą do wygenerowania klucza szyfrowania (np. generator liczb pseudolosowych lub konkretny algorytm mieszający).

• W środowisku AIR do szyfrowania baz danych używany jest algorytm Advanced Encryption Standard (AES) z licznikiem w trybie CBC-MAC (CCM). Aby ten szyfr był bezpieczny, klucz wprowadzony przez użytkownika musi być połączony z wartością modyfikatora. Zastosowanie tej techniki ilustruje Przykład: Generowanie i używanie klucza szyfrowania .

• Zaszyfrowanie bazy danych powoduje zaszyfrowanie wszystkich plików dyskowych używanych przez mechanizm serwera bazy danych w związku z daną bazą. Jednak mechanizm serwera bazy danych tymczasowo przechowuje pewne dane w pamięci podręcznej, aby przyspieszyć odczytywanie i zapisywanie danych w transakcjach. Wszystkie dane przechowywane w pamięci są niezaszyfrowane. Jeśli osoba nieuprawniona zdoła uzyskać dostęp do pamięci wykorzystywanej przez aplikację AIR, np. za pomocą debugera, to uzyska również dostęp do niezaszyfrowanych danych pochodzących z otwartej bazy.

Ta przykładowa aplikacja ilustruje jedną z technik generowania klucza szyfrowania. Aplikacja została zaprojektowana w taki sposób, aby zapewniała najwyższy poziom poufności i bezpieczeństwa danych użytkowników. Jednym z ważnych aspektów ochrony danych poufnych jest wymuszenie na użytkowniku wprowadzenia hasła za każdym razem, gdy aplikacja łączy się z bazą danych. Dlatego, co ilustruje omawiany przykład, aplikacja wymagająca tak wysokiego poziomu bezpieczeństwa nie powinna nigdy bezpośrednio przechowywać klucza szyfrowania bazy danych.

Aplikacja składa się z dwóch części: klasy ActionScript generującej klucz szyfrowania (klasa EncryptionKeyGenerator) oraz prostego interfejsu użytkownika, który ilustruje zastosowanie tej klasy. Pełny kod źródłowy zawiera sekcja Kompletny przykładowy kod ilustrujący generowanie i używanie klucza szyfrowania .