11:10
30/11/2014

Osoby stojące za projektem Evil32 informują, że korzystając z GPU znaleźli kolizje dla wszystkich opublikowanych w internecie (tj. na keyserverach) kluczy GPG z tzw. “strong setu”. Nie należy jednak wpadać w panikę, bo działania te nie “łamią” modelu GPG, choć w pewnych sytuacjach rzeczywiście mogą stwarzać niemałe zagrożenie.

Oh hai, agent Smith!

Oh hai, agent Smith!

Jak wygenerowano kolizje?

Na początek wyjaśnijmy, że kolizja jest tu rozumiana w następujący sposób: udało się wygenerować inny klucz, który ma takie samo 32 bitowe ID, jak prawdziwy klucz. Generowanie kolizji shortID dla jednego klucza zajmuje 4 sekundy przy użyciu tego narzędzia.

To oznacza, że atakujący może podrzucać na keyserwery dodatkowy klucz, który będzie wyglądał tak samo jak oryginalny i będzie się razem z nim ściągał na komputer ofiary przy użyciu komendy pobrania klucza z keyservera:

free@turing ~$ gpg --keyserver pgp.mit.edu --recv-keys 10000001

gpg: requesting key 10000001 from hkp server pgp.mit.edu
gpg: key 10000001: public key "John Doe" imported
gpg: key 10000001: public key "Jane Doe" imported
gpg: Total number processed: 2
gpg: imported: 2 (RSA: 2)

Jeśli chcecie sprawdzić, czy wasz klucz został sklonowany, to rzućcie okiem na http://pgp.evil32.com/ — fałszywy keyserver wystawiony przez badaczy, zawierający skolidowane, wygenerowane przez nich klucze będące “odwzorowaniem” prawdziwych kluczy.

Podczas komunikacji z keyserverami GPG (z reguły) nie wykorzystuje szyfrowania w transporcie (np. TLS) i dodatkowo nie weryfikuje kluczy uzyskanych poprzez parametr –recv-keys. To stwarza ryzyko ataku Man in the Middle.

Co robić? Jak żyć?

Z wymenionych powyżej powodów, zawsze powinniśmy wykonywać ręczne sprawdzenie, czy klucz który pobraliśmy, na pewno jest tym, który powinniśmy pobrać. Wystarczy wykonać polecenie gpg –fingerprint i porównać wartości z drugą stroną poprzez inny kanał komunikacji.

W związku z powyższym, problem przedstawiony przez badaczy wydaje się być lekko rozdmuchany. W końcu podstawą oceny zaufania do kluczy w modelu OpenGPG jest weryfikacja ich podpisów, które winny być złożone na kluczu przez znane nam osoby (z którymi nawiązaliśmy wcześniej pewne “zaufanie”, np. poprzez wspólne uczestnictwo w Key Signing Party, na którym wzajemnie podpisaliśmy sobie klucze) albo przez osoby, którym znane nam osoby podpisały klucze, gwarantując tym samym ich tożsamość. Niestety, na swojej stronie badacze nie wspominają w szczegółach o tych środkach zaradczych…

Key Signing Party i weryfikacja z dokumentu tożsamości

Key Signing Party i weryfikacja z dokumentu tożsamości

Kiedy taki klucz faktycznie stwarza zagrożenie?

O ile z ludźmi można (z ogromnym wysiłkiem, ale jednak) zrealizować sprawnie działający, powyższy model zaufania polegający na poprawnej wymianie kluczy, to trochę gorzej będzie z narzędziami, które np. weryfikują poprawność paczek w oparciu o ich podpisy złożone kluczami GPG. To właśnie tu upatrujemy faktyczne ryzyko ataku wstrzyknięcia “skolidowanego” klucza.

Świetnym przykładem jest Puppet, dla którego badacze rozpisali scenariusz ataku. Pięknie zadziała on nawet wtedy, jeśli ofiara (użytkownik Puppeta) będzie stosowała się do kroków opisanych w dokumentacji Puppeta, jako zalecane podczas weryfikacji autentyczności paczki.

Tu uwaga do wszystkich developerów. Jeśli w instrukcjach sugerujecie użytkownikom, aby ściągali klucze z keyserverów, zmodyfikujcie swoje komendy tak, aby wskazywały one na wasz klucz po longID, a nie shortID.

GPG wymaga zmian?

Badacze słusznie zauważają, że o ile z GPG korzystamy od lat, to przez ten czas niewiele zmieniła się użyteczność tego narzędzia. Np. w przypadku “wielu dopasowań” dla tego samego keyID albo UserID, GPG mogłoby wyraźnie ostrzegać użytkownika, wymuszając na nim podjęcie decyzji i ręczną weryfikację klucza.

Nie do końca też działa tzw. Web of Trust — niewiele osób zgodnie ze sztuką podpisuje sobie klucze, pozwalając na budowanie łańcuchów zaufania. Może dobrym pomysłem byłoby połączenie Key Signing Party z wyborami? Taka dodatkowa budka GPG, do której każdy w celu weryfikacji mógłby zajrzeć, skoro i tak dowód osobisty ma przy sobie…? A może lepszą odpowiedzią na tego typu bolączki stanie się zyskujący popularność serwis https://keybase.io?

Przeczytaj także:


Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

9 komentarzy

Dodaj komentarz
  1. —–BEGIN PGP MESSAGE—–
    Version: Keybase OpenPGP v1.1.6
    Comment: https://keybase.io/crypto

    wcNOA7cCjmtevwW0EA//SXCbMa0TNI18yOb88Q0aoygBgqO/PvxSkDSyWgHtc63q
    Yq1bRljroX3cUuMlje22g0ov3tdeFzpNQSYJuleieVoe0d8Y5xqzWfD3M6iAd1WJ
    XHGTyL3QB0o8RnZqj6zxpKUgzJaIFCIr89WdPLilh8nLlscco2LA9XXvBK2+/fjr
    s++xcYoX2Co+ONp0zvXC/kaV00rR9zS66O8pwNNfdnBwHb5ggFikOYaBJ10G3J2S
    C07Wl2xO5FxA6Wimc6Uv7CfTbuWJx8cZNOyfkC0ya1dgsZqmw5ZaZuPip3I2lPSE
    ckgBDhuEUyBH4l/poa+8eojDSMyMj6mBU9iIVKlXFraYDQVUkwMWhmZNfyOrLQCn
    ThaLdpl520hwylBk4J526DjKInMx31ORy1hsJ/4gz409J8ZAdG55ZUhd/VemaqPS
    96UOUCOxCkeUfxCdJTbecCnjiyXDZDTM3AXfh0LEXpe1N5T3XV58yAYIt0nNwxeC
    sf4O+K9IofAwkeTJJal7rqsyrmFY2WESan1UrOu/y4BpAcX/BbzYIsQiM7Wk4+N3
    AwSBQmg8vxM0jE6YpI+C/DMpCJkympmMgURHVaWqFvGwmkGcszcDDSNkPKhvj1Te
    ozNfc7mCRV/THpDsjPRzTLtuFjR+Ul/vv0tiEnbt+SZJwF3jd2eNUA7lXYT2c+gP
    /3TSERn3lw3ivNWXi8RtN2Ma0ia1f+y+p2LAdIbOSAbvdxDJSb+z/+HNMTvSyhTR
    VBfDa2/9MkL0cM19bhVrqf6gMNol3Gcipj7bZ1+zII4xDqYMqsFtZU2IlG++81Wz
    AOA9c0fEoHyjKkpxkSuklCycZ7cmQ3Ad4p7UKXYf9yP4NlJV8MKy8xyOAAe5aSfm
    tzos4bTNR2ZPcBaERk1gID/IPgXVbGUinN6v6zIckXbbhdWHhAs0acjZGbRp3MQ9
    oIjnCQezGR1rd5PMbhBuQRWf10sNkmISL+MlM3soywsNkc4RL62AxEVzignSHYqQ
    S9TjQdxzuAvnBq06fUUSglCXNrpNByGIig0bCP9IJrZNx+jOu6ByUmuHGhzFFhvV
    K0PaShSFFCuuFJDpWAtxJLznd6Nwe9sI9OX5D15yysQY+2wqpZPEyQRDWnyEYijZ
    B9x4eNziQMcS5g5SgkEkgyZnvmsj47LHuKBR2NlSyQ1TRyRf1QVuyPde9neGyKP+
    DP0LG2PRUEjAsCgu7bGcH98t6suxG4UdQNPD5W5QUTPAfA5p+JCTCGHwOHjtn9wz
    gqok3Gj1R36gdXAt3UyCwKz6Y3uEhp9TztvC4dVPDE5JpwgqP8Yy++mKq1vp/mk/
    jZMHJ5d8TlH23iZ2vaOfpKa6euDSn6eZRoOkxmOAB8C60nkBYjBPo5mpPTHjlu4X
    o2bZapKfcWp+mv74cpR33oAhvqu5yWGAX6FTsXbp9SKEer5ib94CXQocmPEw07Sl
    xb+uH6SPMiMMFR1vxccvbqTessEC3jaNumhByW3SCd6vjWD85yuu49Em+R7m1J32
    8Z0YegkaRxGNZx6R
    =uqIW
    —–END PGP MESSAGE—–

  2. Ale z tego co widzę, keybase jest na chwilę obecną tylko na zaproszenia. A szkoda, chętnie bym skorzystał.

  3. No tak,
    jednak od dawna zaleca się:
    keyid-format 0xlong
    jest to 64b ID.

  4. “Keybase.io is also a Keybase client, however certain crypto actions (signing and decrypting) are limited to users who store client-encrypted copies of their private keys on the server, an optional feature we didn’t mention above.”

    Thank you, but no. ;-)

  5. Wiedziałem, że tak będzie.

  6. Managery paczek też weryfikują/pokazują kompletny klucz i ściągają brakujący po pełnym fingerprint. Short ID jest tylko pokazywany dla ludzi, żeby szybciej sprawdzić który klucz jest który.

    Kolejny fałszywy alarm jakich zaskakująco wiele ostatnimi czasy, wygląda mi to na jakąś kampanię siania FUD’u przeciwko free software przez ‘wiecie kogo’.

  7. Oświećcie mnie jeżeli się mylę, ale chyba nie jest jakimś wielkim wyzwaniem wygenerować kolizję dla 32 bitowych wartości w jakimkolwiek kryptograficznym kontekście. Nie zgłębiałem nigdy GPG, ale wydaje mi się, że nikt rozsądny nie opierałby bezpieczeństwa systemu kryptograficznego na 32 bitowym kluczu.

    • Nie no, klucz jest dłuższy. ID słyszy tylko do szybkiej weryfikacji czy klucz się zgadza.
      Ale jeśli ściągasz skądś klucz z bazy po tym krótkim ID, to ściągną ci się oba/ściągnie się zły.
      Jeśli do tego nazwę będą miały taką samą/podobną, to możesz się dać nabrać i wysłać zaszyfrowaną (tym podstawionym kluczem) wiadomość z jakimiś wrażliwymi danymi do złej osoby lub dane zaszyfrowane złym kluczem mogą zostać podsłuchane i po prostu odszyfrowane.

      Na githubie tego narzędzia jest powiedziane, że narzędzie to pozwala też generować kolidujące adresy ukrytych usług w sieci Tor (które też są generowane z kluczem, chyba też z któregoś ID potraktowanego base32).
      Czyli o ile dobrze rozumiem, można podstawić stronę-pułapkę z tym samym adresem i czekać aż jakieś pakiety znajdą nasz serwer szybciej niż prawdziwy…?

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: