Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
Niemieckie BSI (organizacja odpowiedzialna za cyberbezpieczeństwo) wysłała petentowi swój klucz prywatny zamiast publicznego!
Wpadkę opisuje serwis Golem:
Someone had asked the BSI’s contact e-mail address for product approval to send them a PGP key in order to be able to communicate with the authorities in encrypted form. In response, however, the person received a private PGP key rather than a public PGP key, as expected.
Jak wiemy, PGP (bądź GPG) w kontekście szyfrowania poczty wykorzystuje m.in. dwa powiązane ze sobą klucze – klucz prywatny (służy do deszyfrowania wiadomości, podpisu wiadomości) oraz klucz publiczny (szyfrowanie wiadomości do adresata, weryfikacja podpisu).
Ktoś więc poprosił BSI o podesłanie „klucza” (tak żeby mógł zaszyfrować wiadomość do wspomnianej rządowej agencji), po czym zamiast klucza publicznego otrzymał prywatny (!).
Szczęśliwie klucz prywatny był dodatkowo zabezpieczony hasłem (czytaj: zaszyfrowany algorytmem symetrycznym) – ale to można by próbować łamać siłowo czy słownikowo…
BSI stwierdziło, że w sumie więc wszystko spoko, jednak po naciskach zmienili zdanie…:
It was only after a request from Golem.de to the BSI’s press office that the key was replaced. „A new PGP key was immediately generated for the mailbox mentioned,” replied the BSI. „The associated public key and a revocation certificate for the old PGP key will now be successively distributed to the respective contact person.”
~Michał Sajdak
No to czas na część konstruktywną. Jeżeli w organizacji konsultanci mają centralną aplikację z ticketami (i nie korzystają bezpośrednio z kluczy), to wystarczy upewnić się, że nie mają oni do kluczy dostępu. Ale jakie mamy opcje zabezpieczenia się w przypadku klientów e-mail, zakładając konieczność wysłania przez konsultanta klucza w formie pliku?