Bezpieczne przechowywanie kluczy prywatnych

[scabala]

Cześć,
słowem wstępu chciałem podziękować za udostępnienie tego narzędzia - bardzo fajna rzecz!

Bardzo chciałbym wykorzystywać je 'produkcyjnie' ale natknąłem się na pewien problem: przechowywanie kluczy prywatnych certifikatów do uwierztylniania i innych. Z tego co udało mi się wyczyta z kodu oraz przetestowąć, wygenerowany klucz prywatny jest przechowywany bez hasła na dysku w drzewie folderów. Mój wewnętrzny 'bezpiecznik' mocno się na krzywi ;)

Technicznie rzecz biorąć, jest to potencjalny problem w przypadku kiedy ktoś ma dostęp do dysku. Natomiast możę to być zneutrlizowane na poziomie systemu operacyjnego poprzez pełne szyfrowanie dysku. Ale szczerze powiedziawszey, myślę że można to zrobić lepiej na poziomie aplikacji.

Moje propozycje:

• szyfrowanie klucza prywatnego wygenerowanym dynamicznie hasłem przechowywanym w systemowym keyringu - najprostsze do implementacji
• przechowywanie klucza prywatnego w systemowym keyringu - mogą być problemy z wielkością klucza i miejsca w keyringu
• utworzenie klucza prywatnego na sprzętowym kluczu bezpieczeństwa poprze interfejs PKCS#11 - dużo pracy, odporne na ataki na pamięć procesu
• szyfrowanie klucza prywatnego poprzez rozszerzenie WebAuthn PRF - klucze sprzętowe implementujące FIDO2 i posiadające wsparcei dla PRF są coraz bardziej popularne
• utowrzenie klucza prywatnego na wbudowanym module TPM - obecnie TPM jest dostępny wszędzie, klucz jest przywiązany do sprzętu więc mamy to interesujący aspekt bezpieczeństwa fizycznego (dostęp do konkretnego komputera)

Osobiście uważam że najlepsze opcje to szyfrowanie hasłęm w keyringu oraz PKCS#11 ale to tylko propozycje. Użycie PKCS3!! wymaga użycia CGO i linkowania bibliotek natywnych co może być problemem dla wieloplatformowośći. Z drugiej storny, możę być to opcja ukryta za flagą podczas budowania albo można użyć kompilatora zig który pozwala na kompilację wskrośną na wiele platform bez dodatkowych narzędzi.

Chętnie poznam zdanie autora na ten temat. Jeśli będzie zielone światło to całkiem prawdopodobne że pokuszę się o zaimplementowania tych zmian.

[toudi]

zgadza się, byłem świadomy tego zagrożenia. nie ukrywajmy, program od zawsze w założeniu miał być jedynie do celów amatorskich i dla mikro / małych przedsiębiorców. oczywiście nie zwalnia to z obowiązku zabezpieczenia go.. po prostu jako że rozwijam program tylko w czasie wolnym od pracy to niestety ale musiałem priorytetyzować zmiany i zawsze starałem się na pierwszym miejscu stawiać to, żeby w ogóle dało radę z niego skorzystać. nawiasem mówiąc ostatnio czytałem jakiś artykuł w którym była mowa że jest multum innych rozwiązań - mam wrażenie że to moje jest niszowe i mało kto z niego korzysta.

co do meritum - klucze są przechowywane plaintextem tylko dlatego, że nie udało mi się znaleźć rozwiązania / biblioteki która wprost dałaby radę obsługiwać zaszyfrowane klucze (czyli te które generuje ministerstwo finansów). może taka biblioteka jest a ja nie potrafiłem jej znaleźć - nie wiem.

po drugie to trochę jest tak że jeśli ktoś uzyska dostęp do Twojego dysku to i tak jest pozamiatane a fakt, że ktoś wystawi na Ciebie fakturę w KSeF będzie chyba najmniejszym z Twoich problemów (bo w sumie te certyfikaty są honorowane tylko przez sam KSeF)

tym niemniej.. :)

myślę, że z przedstawionych rozwiązań najbardziej podoba mi się wersja nr. 1 (czyli symetryczny klucz przetrzymywany w keyringu) + pewnie jakaś dodatkowa flaga do struktury certyfikatu która informowałaby program że certyfikat jest zaszyfrowany - żeby nie trzeba było tego każdorazowo sprawdzać. chyba że prościej byłoby zrobić po prostu jakiś magiczny nagłówek rzędu 5 bajtów + zaszyfrowana treść? wtedy do pamięci wczytujemy treść pliku - jeśli zaczyna się od magicznej sekwencji to wiemy że jest zaszyfrowany - tak luźno sobie myślę. tu należy tylko nadmienić, że jednym z dostępnych keyringów jest plik zaszyfrowany aesem (chodzi o systemy na których systemowy keyring nie działa lub zawiesza program). więc wtedy nawet w przypadku zaszyfrowania keyringu wydaje mi się, że zagrożenie byłoby wciąż realne. był tu też założony wątek gdzie ktoś wspominał o keyringu trzymanym w keepassx ale tego osobiście nie sprawdzałem z braku czasu

[toudi]

0.2.20-rc1 - ale potraktuj to proszę jako wersję wybitnie eksperymentalną, oczywiście zrób kopię zapasową bazy certyfikatów, etc, etc, etc

[toudi]

acha, zapomniałem dodać - nowe komendy:

./ksef certs pkeys [encrypt | decrypt]

[scabala]

O! Nie spodziewałem się że to zaimplementujesz :D miałem w planach sam spróbować swoich sił.

Dzięki wielkie i przetestuję to w najbliższych dniach.

[toudi]

nie ma sprawy. pamiętaj tylko, że ta zmiana jest jedynie w wersji 0.2.20-rc1 - jest budowana z innego brancha. w międzyczasie wydałem kolejną wersję (0.2.21) ale ta nie ma zmian z tego ticketu. chyba, że budujesz binarkę sam to wtedy znajdziesz to w branchu feature/encrypt-certificate-pkeys

[toudi]

@scabala czy jesteś w stanie potwierdzić, że działa ? (u mnie działa ale wiadomo jak to jest z programistyczym "works for me" :D chyba, że konkretnie chciałbyś przerobić to na jakiś szerszy interfejs z możliwością szyfrowania przy użyciu wielu wspomnianych przez Ciebie opcji ?

[scabala]

Cześć, przepraszam za brak kontaktu - życie. Miałem pewne problemy z kompilacją: moje poprawki są tutaj: scabala@63ac40d to raczej proste poprawki, nic szczególnego.

Jak się z tym uporałem, niestety okazało się że jest coś nie tak z moim certyfikatem a kiedy próbuję zainicjalizować (ksef auth init) to dostaję panic. Logi:

time=2026-03-29T14:12:13.860+02:00 level=INFO msg="start programu"
time=2026-03-29T14:12:13.860+02:00 level=INFO msg="wybrane środowisko" env=demo
time=2026-03-29T14:12:13.867+02:00 level=INFO msg="klient KSeF v2 - start programu"
time=2026-03-29T14:12:13.867+02:00 level=DEBUG msg="auth handler initialized - receive challenge" auth="token manager"
time=2026-03-29T14:12:13.867+02:00 level=DEBUG msg="get auth challenge"
time=2026-03-29T14:12:13.867+02:00 level=DEBUG msg=request method=POST url=https://api-demo.ksef.mf.gov.pl/v2/auth/challenge attempt=1 max=3 operationId=""
time=2026-03-29T14:12:14.017+02:00 level=DEBUG msg=response body="{\"challenge\":\"<REDACTED>\",\"timestamp\":\"2026-03-29T12:12:13.9885019+00:00\",\"timestampMs\":1774786333988,\"clientIp\":\"<REDACTED>"}"
time=2026-03-29T14:12:14.017+02:00 level=DEBUG msg="received response" response="{Challenge:<REDACTED> Timestamp:2026-03-29 12:12:13.9885019 +0000 +0000}"
time=2026-03-29T14:12:14.017+02:00 level=DEBUG msg="żądanie zrzucenia wyzwania do pliku" output=AuthTokenRequest.xml
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0xa11a0c]

goroutine 7 [running]:
ksef/internal/client/v2/auth.(*TokenManager).Run(0x326d463c0230)
        /mnt/internal/client/v2/auth/token_manager_event_loop.go:96 +0x7ec
created by ksef/internal/client/v2.(*APIClient).StartTokenManager in goroutine 1
        /mnt/internal/client/v2/client_auth.go:58 +0x68

Nie do końca wiem co robię nie tak, mam wrażenie że to raczej coś po mojej stronie niż problem z proramem ale przyjmę chętnie wszelkie wsakzówki

[toudi]

nie, masz rację. błąd był po mojej stronie. albo jakiś zły merge albo miałem gorszy dzień :) wypchnąłem zmiany do tego samego brancha

[scabala]

Dzięki za poprawki :D Teraz chyba znalazłem błąd przy ksef auth login ./AuthTokenRequest.signed.xml:

time=2026-03-31T20:43:48.850+02:00 level=INFO msg="start programu"
time=2026-03-31T20:43:48.850+02:00 level=INFO msg="wybrane środowisko" env=demo
time=2026-03-31T20:43:48.851+02:00 level=INFO msg="klient KSeF v2 - start programu"
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x30 pc=0xa126c0]

goroutine 29 [running]:
ksef/internal/client/v2/auth.(*TokenManager).persistTokens(0xe21d7f57030)
        /mnt/internal/client/v2/auth/token_manager_persistence_layer.go:41 +0x500
ksef/internal/client/v2/auth.(*TokenManager).updateSessionTokens(0xe21d7f57030, 0xe21d7ff60e0, 0x1)
        /mnt/internal/client/v2/auth/token_manager.go:156 +0x192
ksef/internal/client/v2/auth.(*TokenManager).redeemTokens(0xe21d7f57030, {0xcb6bb8, 0x1431580})
        /mnt/internal/client/v2/auth/token_manager_redeem.go:30 +0x2eb
ksef/internal/client/v2/auth.(*TokenManager).checkAuthStatus(0xe21d7f57030, {0xcb6bb8, 0x1431580})
        /mnt/internal/client/v2/auth/token_manager_check_auth_status.go:40 +0x43b
ksef/internal/client/v2/auth.(*TokenManager).Run(0xe21d7f57030)
        /mnt/internal/client/v2/auth/token_manager_event_loop.go:58 +0x4e5
created by ksef/internal/client/v2.(*APIClient).StartTokenManager in goroutine 1
        /mnt/internal/client/v2/client_auth.go:58 +0x68

chyba coś z keyringiem ale nie jestem pewien. Natomiast przetestowałem go i mój keyring systemowy działa

[toudi]

dzięki! poprawione :) te komendy są raczej przestarzałe, na codzień z nich nie korzystam. ale wiadomo - lepiej, żeby też je poprawić :)