KeeChallenge dla YubiKey — i dlaczego warto go unikać
KeeChallenge to wtyczka dodająca obsługę YubiKey do KeePass 2. Ma ona jednak szereg problemów. Ten artykuł omawia te problemy oraz alternatywne rozwiązania.
Jak działa KeeChallenge
KeeChallenge szyfruje bazę tajnym kluczem HMAC (S). Klucz ten jest przechowywany w YubiKey i służy do generowania odpowiedzi. Dodatkowo KeeChallenge szyfruje S za pomocą wstępnie obliczonej pary wyzwanie–odpowiedź i zapisuje zaszyfrowany sekret oraz wyzwanie w pomocniczym pliku XML.
Podczas odblokowywania bazy:
- KeeChallenge wczytuje wyzwanie C z pliku XML i wysyła je do YubiKey
- YubiKey przekształca wyzwanie (korzystając z sekretu S przechowywanego w kluczu) i zwraca odpowiedź R
- Odpowiedź R służy do odszyfrowania sekretu Senc zapisanego w pliku XML.
- Odszyfrowany sekret S służy do odszyfrowania bazy. Co istotne, jest to ten sam sekret, który jest przechowywany w YubiKey.
- KeeChallenge ponownie generuje plik XML (tworzy nowe losowe wyzwanie C, oblicza nową odpowiedź R, szyfruje S za pomocą R' i zapisuje zaktualizowane C oraz Senc do pliku XML)
Więcej szczegółów znajdziesz na pełnym diagramie działania.
Problemy z KeeChallenge
Podejście KeeChallenge ma kilka problemów związanych z bezpieczeństwem:
- Tajny klucz nigdy się nie zmienia — jest jedynie ponownie szyfrowany. Z punktu widzenia KeePass, KeeChallenge nie różni się niczym od statycznego pliku klucza, który za każdym razem dostarcza te same bajty.
- W konsekwencji powyższego KeeChallenge jest całkowicie podatny na atak przez powtórzenie (replay attack). Dowolny z poprzednich plików XML może posłużyć do odszyfrowania bazy. Innymi słowy, losowanie wyzwania i ponowne szyfrowanie sekretu nie ma sensu — to teatr bezpieczeństwa.
- Sekret nigdy nie powinien opuszczać YubiKey — to jest cała idea klucza sprzętowego działającego tylko w trybie zapisu. KeeChallenge łamie tę zasadę, przenosząc sekret na komputer. Teoretycznie atakujący może skopiować S z pamięci procesu, sklonować YubiKey właściciela bez jego wiedzy i odszyfrować dowolną przyszłą wersję bazy (ponieważ sekret jest statyczny).
Ponadto istnieje kilka powiązanych problemów:
- Deweloper z Yubico zgłosił zastrzeżenie dotyczące bezpieczeństwa w 2016 roku. Na rok 2024 zgłoszenie wciąż pozostaje otwarte.
- KeeChallenge wygląda na porzucony — nie było żadnych istotnych aktualizacji od 2016 roku.
- Opiekun projektu nie odpowiada na zgłoszenia.
Lepsza alternatywa
Alternatywne podejście zostało wprowadzone w KeePassXC i jest obsługiwane przez wszystkie zgodne aplikacje:
W KeePassXC nie wymagamy żadnej wiedzy o sekrecie HMAC. Jako wyzwania używamy głównego ziarna bazy (losowego ciągu bajtów będącego częścią Twojej bazy), a następnie używamy odpowiedzi do jej zaszyfrowania. Dzięki temu nie potrzebujemy dodatkowego pliku, a ponadto zyskujemy tę zaletę, że wymagana odpowiedź zmienia się przy każdym zapisaniu bazy, co bardziej przypomina prawdziwe uwierzytelnianie dwuskładnikowe.
To podejście ma kilka istotnych zalet w porównaniu z KeeChallenge:
- Klucz wyprowadzany z YubiKey jest dynamiczny — zmienia się przy każdym zapisie bazy. (W KeeChallenge klucz szyfrujący pozostaje ten sam, co w praktyce symuluje statyczny plik klucza.)
- Sekret HMAC nigdy nie opuszcza klucza sprzętowego, więc YubiKey nie może zostać potajemnie sklonowany.
- Nie ma pomocniczego pliku XML — jest tylko sama baza.
- Podejście to wspiera kilka aktywnych zespołów deweloperskich.
Z powodów opisanych powyżej KeePassium implementuje podejście KeePassXC. Nie planujemy obsługi baz zaszyfrowanych za pomocą KeeChallenge.
Jeśli masz bazę chronioną przez KeeChallenge — rozważ przejście na KeePassXC i KeePassium. To połączenie zapewni Ci bezpieczniejsze, zgodne i aktywnie utrzymywane rozwiązanie.