Core Data Encryption

Question

Mam pytanie dotyczące szyfrowania danych podstawowych. Przechowuję poufne dane użytkownika w bazie danych SQLite Core Data. Wartości krytyczne są wszystkie transformables i używam AES256 do szyfrowania i odszyfrowywania ich "w locie", w tym indywidualnych IV dla każdej wartości. Klucz szyfrowania to skrót SHA512 hasła wybranego przez użytkownika. Działa to bardzo dobrze do tej pory.

Teraz hasło użytkownika. Gdy użytkownik uruchamia aplikację, jest proszony o podanie swojego hasła. Hasło jest mieszane za pomocą SHA512 i przechowywane w pęku kluczy systemu iOS. Dla każdej operacji zapisu lub odczytu NSValueTransformer otrzyma hasło z pęku kluczy. Jeśli aplikacja jest zamykana, usuwam hash hasła z pęku kluczy.

W mojej bazie danych podstawowych mam specjalną jednostkę, która ma losową liczbę! = 0, ponieważ jest to tylko wartość. Aby sprawdzić, czy użytkownik wprowadził poprawne hasło, pobieram ten element i odczytuję numer. Jeśli jest =! 0, Wiem, że hasło było poprawne, ponieważ gdy odszyfrowanie się nie powiedzie, NSValueTransformer zawsze zwraca 0.

Teraz moje aktualne pytania: Czy uważasz, że to dobre podejście do szyfrowania? Jak inaczej można sprawdzić, czy wprowadzone hasło jest poprawne?

Jestem trochę zaniepokojony, że przechowywanie skrótu hasła w pęku kluczy podczas działania aplikacji sprawia, że ​​wszystko wolniej, ponieważ NSValueTransformer musi przez cały czas mieć dostęp do pęku kluczy. Czy byłoby wystarczająco bezpieczne, aby zachować hasło w pamięci, więc zostanie ono usunięte po zamknięciu aplikacji?

Answer 1

Nie powinieneś używać skrótu hasła, skróty są zaprojektowane tak, aby były szybkie, więc jest (stosunkowo) łatwe do przeprowadzenia ataku brute-force. Użyj key derivation function, np. PBKDF2.

Nie używaj klucza bezpośrednio uzyskanego z hasła jako klucza szyfrowania. Jeśli użytkownik zmieni hasło, konieczne będzie ponowne szyfrowanie wszystkich danych, a kopie zapasowe staną się bezwartościowe. Użyj losowo wygenerowanego klucza szyfrującego, który jest szyfrowany kluczem szyfrowania opartym na haśle.

Nie jestem pewien, czy zapisać hasz w pęku kluczy, zamiast tylko trzymać go w pamięci. Kiedy ostatnio się nad tym zastanawiałem, łatwo było odszyfrować brelok. Każdy atakujący, który może odczytać pamięć uruchomionej aplikacji najprawdopodobniej będzie mógł śledzić dostęp do pęku kluczy lub odszyfrowane dane. Po prostu zapamiętaj pamięć i wyczyść pamięć, jeśli aplikacja zawiesza się w tle itd. Dotyczy to oczywiście również wszystkich odszyfrowanych danych.

[EDIT: @JeffLockhart wyjaśnienie procedury klucza szyfrującego mistrz] wygenerować losowy klucz do szyfrowania danych, nazwijmy to klucz A. Można użyć SecRandomCopyBytes do generowania klucza A, patrz Apple's CryptoExcercise do użytkowania przykład. Klawisz A służy do szyfrowania danych użytkownika. Aby zapisać klucz A, należy zaszyfrować klucz A za pomocą drugiego klawisza B. Nie należy używać hasła bezpośrednio jako klucza B, ze względu na szybkie ataki brute-force lub słownikowe. W ten sposób można uzyskać klucz z hasła z PBKDF, podobnie jak w this stackoverflow odpowiedź. Następnie zaszyfrujesz klucz A za pomocą klucza B, np. przy użyciu CCCrypt. Zapisujesz zaszyfrowany klucz A i sól użytą do wyprowadzenia klucza B. Aby odszyfrować, użytkownik wprowadza hasło, uzyskujesz klucz B, używając hasła i soli. Odszyfrowujesz klucz A, używając klucza pochodnego B. Nadzieja, która wyjaśnia.

Answer 2

Można spojrzeć na to:

Secure Incremental Store

wdrożyły podklasę NSIncrementalStore który jest zaszyfrowany przy użyciu SQLite-Database. Jest to zastępczy zamiennik dla sklepu SQLite firmy Apple. W zestawie z ceną.