Atak na podpis elektroniczny przez zmianę formatu

Rozszerzenie pliku determinuje sposób jego interpretacji przez odbiorcę, powinno być więc chronione wewnątrz podpisanej elektronicznie struktury - taka lekcja płynie z nowego ataku opublikowanego przez badaczy z włoskiego uniwersytetu Reggio Calabria. Informacja krąży w zainteresowanych kręgach od kilku tygodni, ale jako pierwsi napisali o niej Czesi w magazynie CryptoWorld.

Demonstracją ataku jest plik graficzny w formacie BMP, który zawiera jakiś tekst. Jednak wystarczy tylko zmienić rozszerzenie na HTML by plik wyświetlił tekst o zupełnie odmiennej treści. Jak to jest zrobione?

Tak się akurat składa, że w formacie BMP początek pliku stanowią dwa znaki ASCII ("BM"). Zaraz po nich w pliku występuje ciąg "<!--" mające różne znaczenie w zależności od tego, czy interpretujemy go jako HTML czy jako BMP. W tym pierwszym przypadku chroni on przed interptetacją bitmapę, która wyświetliłaby się jako śmieci w przeglądarce. Dla programu graficznego jest on ciągiem bajtów szesnastkowych, określających m.in. rozmiar nagłówka i tak dalej.

W sensie technicznym Włosi nie odkryli nic nowego, bo już w latach
90-tych programiści urządzali konkursy polegające np. na napisaniu
programu wykonywalnego zawierającego tylko drukowalne znaki ASCII - i
wtedy taki plik z rozszerzeniem TXT można było np. wydrukować, a po
zmianie na COM - uruchomić. Nowe jest odniesienie tego do podpisu
elektronicznego jako metody manipulacji.

Ryzyko dla podpisującego zależy od formatu podpisu, a w szczególności
czy nazwa podpisanej treści jest atrybutem chronionym czy nie. I to jest
tutaj kluczowe, bo warunkiem powodzenia ataku jest możliwość późniejszej
zmiany nazwy pliku zachowanej w podpisanym kontenerze. Standard PKCS#7
na który tutaj się powołują autorzy dokumentu o ile wiem nie przechowuje nazwy
pliku w środku (chyba że za pomocą prywatnych rozszerzeń jakiejś
implementacji). Przyjęta praktyka jest taka, że jak plik nazywa się
TEST.BMP.P7M to po weryfikacji zapisujemy go do TEST.BMP. Ponieważ nazwa
pliku nie jest chroniona, więc taki atak jest możliwy.

W każdym przypadku jest to natomiast dobry argument przeciwko
podpisywaniu danych w formie ciągu bitowego niezrozumiałego dla SCA, w
odróżnieniu od podpisu struktury danych zrozumiałej dla SCA.
Jeśli już, to należy albo zastosować jeszcze jeden wewnętrzny kontener, który będzie zawsze tak samo interpretowany przez obie strony, niezależnie od nazwy, albo skorzystać z formatu, który przechowuje typ pliku.

Pierwsze rozwiązanie zastosowało Certum w swoim Delivery Authority - zrobili to w ten sposób, że plik oryginalny -
dowolnego typu i rozszerzenia - jest zawsze pakowany w archiwum ZIP.
Przy weryfikacji plik jest zawsze zapisywany z rozszerzeniem ZIP,
niezależnie od rozszerzenia kontenera. A z ZIPa każdy sobie wypakowuje
to co tam było oryginalnie. I nazwa oryginalnego pliku jest chroniona, i
wynikowe rozszerzenie jest przewidywalne. Podobne rozwiązanie zostało zastosowane w Słowacji i to na poziomie rozporządzenia.

Formatem, który może chronić typ pliku jest natomiast XAdES - służy do tego atrybut DataObjectFormat. Podobne atrybuty definiuje również CMS. Warto zauważyć, że problem nie dotyczy tylko formatów podpisu - nieprzypadkowo atrybut SignatureAlgorithm w certyfikacie X.509 jest zdublowany na zewnątrz struktury tbsCertificate, jak i wewnątrz niej.

Niezależnie od profilaktyki przypuszczam, że taki podpis można łatwo
obalić przed sądem. Każdy kompetentny biegły powinien z łatwością
wykazać, że plik był skonstruowany w celu oszukania podpisującego. Cały materiał dowodowy jest na miejscu, wystarczy go podejrzeć hexedytorem.

Bibliografia

• "Príklad útoku na podpisovaný dokument, ktorého typ nie je chránený samotným podpisom", Peter Rybar, Crypto-World - Informační sešit GCUCMP, numer 5/2008, 15 kwietnia 2008, ISSN 1801-2140
• "Signing the Document Content is not Enough: A new Attack to Digital Signature", Francesco Buccafurri, Gianluca Caminiti, Gianluca Lax; DIMET, Universita degli Studi Mediterranea di Reggio Calabria
  via Graziella; kwiecień 2008; manuskrypt nieopublikowany