W 9-tej wersji Acrobata firma Adobe wprowadziła rozszerzoną wersję algorytmu szyfrującego, wykorzystującą AES z kluczem o długości 256 bitów. Równocześnie jednak Elcomsoft - znany producent oprogramowania do łamania haseł w PDFach - pochwalił się, że szyfrowanie w wersji 9-tej jest stukrotnie łatwiejszy do złamania.

Szyfrowanie dokumentu hasłem jest obecne w specyfikacji PDF (”PDF Reference”) od pierwszych wersji wypuszczanych na początku lat 90-tych. Za aktualny należy uznać algorytm dostępny z Acrobatem 7, który używa szyfrowania AES z kluczem 128 bitów (”algorytm 3.2″, PDF Reference 1.7, str. 125) . Rozszerzona wersja została wprowadzona w Acrobacie 9 i jej specyfikacja znajduje sięw suplemencie (”algorytm 3.2a”, Adobe Supplement to ISO 32000, str. 19).

Algorytm 3.2

Hasło użytkownika jest ograniczone do 32 znaków interpretowanych według bieżącej strony kodowej. Hasłą krótsze niż 32 bajty są uzupełniane stałym ciągiem, co ma dodatkowo tę konsekwencję że hasło puste przekłada się na stały klucz szyfrujący zbudowany na bazie tego stałego uzupełnienia . Uzupełnione hasło jest przepuszczane 50 razy przez funkcję MD5, której wynik daje klucz szyfrujący dla AES-128.

Algorytm 3.2a

Hasło jest konwertowane na UTF-8. Z tej reprezentacji do dalszego przetwarzania brane jest 127 znaków, taka jest więc maksymalna długość hasła w Acrobacie 9 (w przybliżeniu, bo znaki spoza ASCII w UTF-8 będą zajmować 2 bajty). Po dodaniu 64-bitowego losowego modyfikatora (Key Salt) hasło jest przepuszczane przez SHA-256. Wynik o długości 32 bajtów jest używany do rozszyfrowania dodatkowej wartości pośredniej używanej do implementacji uprawnień dokumentu i generowanej losowo (”algorytm 3.8″).

Jak widać, algorytm używany w Acrobacie 9 pomija znany z PKCS#5 mechanizm wielokrotnego haszowania klucza wprowadzającego celowe opóźnienie przy konwersji hasła na klucz. Biorąc pod uwagę, że MD5 jest ok. 3,2x szybsze od SHA-256 ale powtarza się go 50x różnica w czasie wykonywania obu operacji może być mniej więcej piętnastokrotna. To znaczy w Acrobacie 9 liczenie klucza z hasła zajmie piętnastokrotnie mniej czasu niż w Acrobacie 7 i 8.

Jedyne uzasadnienie dla skrócenia tego czasu podane przez Adobe to przyspieszenie otwierania dokumentów zaszyfrowanych hasłem w Acrobacie 9 i cel ten niewątpliwie został osiągnięty. Równocześnie jednak przyspieszenie konwersji hasła na klucz jest przyczyną radości programistów Elcomsoftu, bo są w stanie w krótszym czasie przetestować wszystkie kombinacje hasła.

Wydaje mi się jednak, że przyspieszenie będzie widoczne tylko przy klasycznym łamaniu “brute force” polegającym na  podawaniu wszystkich możliwych kombinacji hasła (lub słów ze słownika) na wejście algorytmu. Niewątpliwie przyspieszy to złamanie hasła trywialnego. Sprawdźmy - w wersji demo programu APDFPR 5.0 osiągnąłem następujące wyniki w łamaniu czteroznakowego hasła zawierającego małe i duże litery:

• Acrobat 7 - 128 bit security v.4 - 14′674 haseł na sekundę, czas łamania 3 minuty 20 sekund
• Acrobat 9 - 256 bit security v.5, 298′981 haseł na sekundę, czas łamania 10 sekund

Z drugiej strony nowy algorytm dzięki zastosowaniu salta powinien uniemożliwić stosowanie łamania hasła przez atakowanie skrótu hasła techniką “Rainbow Tables” (zwanych przez Elcomsoft “Thunder Tables”). Równocześnie znacząco zwiększone zostały zarówno długość hasła (do 127 znaków) oraz dopuszczalny zestaw znaków (praktycznie cały Unikod). O atakowaniu klucza kryptograficznego można właściwie zapomnieć już od Adobe Acrobat 6, który stosuje klucze o długości 128 bitów.

Można sobie zadać pytanie, dlaczego projektanci “algorytmu 3.2a” nie wprowadzili co najmniej pięciokrotnej pętli SHA-256? Dałoby to taki sam efekt opóźniający jak w “algorytmie 3.2″. Równocześnie opóźnienie dla użytkownika jest raczej niezauważalne - na serwerze z procesorem 3 GHz w ciągu sekundy wykonuje się prawie 300 tys. operacji SHA-256 (i ok. 1 mln MD5), więc pięć w tę i we wtę nie robi dużej różnicy.

Warto dodać, że opisane algorytmy standardowe (czyli do Acrobata są opisane w specyfikacji PDF dostępnej jako ISO 32000, ale nie polecam jej do porównywania z suplementem, bo pomimo niemal identycznej zawartości merytorycznej nie zgadzają się numery stron. W oryginalnej specyfikacji Adobe jest więcej praktycznych uwag i komentarzy, które w ISO wyczyszczone zapewne ze względu na przejrzystość dokumentu. Z drugiej strony w specyfikacji ISO jest znacznie więcej przykładów.

W 9-tej wersji Acrobata firma Adobe wprowadzi??a rozszerzon?? wersj?? algorytmu szyfruj??cego, wykorzystuj??c?? AES z kluczem o d??ugo??ci 256 bit??w. R??wnocze??nie jednak Elcomsoft - znany producent oprogramowania do ??amania hase?? w PDFach - pochwali?? si??, ??e szyfrowanie w wersji 9-tej jest stukrotnie ??atwiejszy do z??amania.

Szyfrowanie dokumentu has??em jest obecne w specyfikacji PDF (”PDF Reference”) od pierwszych wersji wypuszczanych na pocz??tku lat 90-tych. Za aktualny nale??y uzna?? algorytm dost??pny z Acrobatem 7, kt??ry u??ywa szyfrowania AES z kluczem 128 bit??w (”algorytm 3.2″, PDF Reference 1.7, str. 125) . Rozszerzona wersja zosta??a wprowadzona w Acrobacie 9 i jej specyfikacja znajduje si??w suplemencie (”algorytm 3.2a”, Adobe Supplement to ISO 32000, str. 19).

Algorytm 3.2

Has??o u??ytkownika jest ograniczone do 32 znak??w interpretowanych wed??ug bie????cej strony kodowej. Has???? kr??tsze ni?? 32 bajty s?? uzupe??niane sta??ym ci??giem, co ma dodatkowo t?? konsekwencj?? ??e has??o puste przek??ada si?? na sta??y klucz szyfruj??cy zbudowany na bazie tego sta??ego uzupe??nienia . Uzupe??nione has??o jest przepuszczane 50 razy przez funkcj?? MD5, kt??rej wynik daje klucz szyfruj??cy dla AES-128.

Algorytm 3.2a

Has??o jest konwertowane na UTF-8. Z tej reprezentacji do dalszego przetwarzania brane jest 127 znak??w, taka jest wi??c maksymalna d??ugo???? has??a w Acrobacie 9 (w przybli??eniu, bo znaki spoza ASCII w UTF-8 b??d?? zajmowa?? 2 bajty). Po dodaniu 64-bitowego losowego modyfikatora (Key Salt) has??o jest przepuszczane przez SHA-256. Wynik o d??ugo??ci 32 bajt??w jest u??ywany do rozszyfrowania dodatkowej warto??ci po??redniej u??ywanej do implementacji uprawnie?? dokumentu i generowanej losowo (”algorytm 3.8″).

Jak wida??, algorytm u??ywany w Acrobacie 9 pomija znany z PKCS#5 mechanizm wielokrotnego haszowania klucza wprowadzaj??cego celowe op????nienie przy konwersji has??a na klucz. Bior??c pod uwag??, ??e MD5 jest ok. 3,2x szybsze od SHA-256 ale powtarza si?? go 50x r????nica w czasie wykonywania obu operacji mo??e by?? mniej wi??cej pi??tnastokrotna. To znaczy w Acrobacie 9 liczenie klucza z has??a zajmie pi??tnastokrotnie mniej czasu ni?? w Acrobacie 7 i 8.

Jedyne uzasadnienie dla skr??cenia tego czasu podane przez Adobe to przyspieszenie otwierania dokument??w zaszyfrowanych has??em w Acrobacie 9 i cel ten niew??tpliwie zosta?? osi??gni??ty. R??wnocze??nie jednak przyspieszenie konwersji has??a na klucz jest przyczyn?? rado??ci programist??w Elcomsoftu, bo s?? w stanie w kr??tszym czasie przetestowa?? wszystkie kombinacje has??a.

Wydaje mi si?? jednak, ??e przyspieszenie b??dzie widoczne tylko przy klasycznym ??amaniu “brute force” polegaj??cym na?? podawaniu wszystkich mo??liwych kombinacji has??a (lub s????w ze s??ownika) na wej??cie algorytmu. Niew??tpliwie przyspieszy to z??amanie has??a trywialnego. Sprawd??my - w wersji demo programu APDFPR 5.0 osi??gn????em nast??puj??ce wyniki w ??amaniu czteroznakowego has??a zawieraj??cego ma??e i du??e litery:

• Acrobat 7 - 128 bit security v.4 - 14′674 hase?? na sekund??, czas ??amania 3 minuty 20 sekund
• Acrobat 9 - 256 bit security v.5, 298′981 hase?? na sekund??, czas ??amania 10 sekund

Z drugiej strony nowy algorytm dzi??ki zastosowaniu salta powinien uniemo??liwi?? stosowanie ??amania has??a przez atakowanie skr??tu has??a technik?? “Rainbow Tables” (zwanych przez Elcomsoft “Thunder Tables”). R??wnocze??nie znacz??co zwi??kszone zosta??y zar??wno d??ugo???? has??a (do 127 znak??w) oraz dopuszczalny zestaw znak??w (praktycznie ca??y Unikod). O atakowaniu klucza kryptograficznego mo??na w??a??ciwie zapomnie?? ju?? od Adobe Acrobat 6, kt??ry stosuje klucze o d??ugo??ci 128 bit??w.

Mo??na sobie zada?? pytanie, dlaczego projektanci “algorytmu 3.2a” nie wprowadzili co najmniej pi??ciokrotnej p??tli SHA-256? Da??oby to taki sam efekt op????niaj??cy jak w “algorytmie 3.2″. R??wnocze??nie op????nienie dla u??ytkownika jest raczej niezauwa??alne - na serwerze z procesorem 3 GHz w ci??gu sekundy wykonuje si?? prawie 300 tys. operacji SHA-256 (i ok. 1 mln MD5), wi??c pi???? w t?? i we wt?? nie robi du??ej r????nicy.

Warto doda??, ??e opisane algorytmy standardowe (czyli do Acrobata s?? opisane w specyfikacji PDF dost??pnej jako ISO 32000, ale nie polecam jej do por??wnywania z suplementem, bo pomimo niemal identycznej zawarto??ci merytorycznej nie zgadzaj?? si?? numery stron. W oryginalnej specyfikacji Adobe jest wi??cej praktycznych uwag i komentarzy, kt??re w ISO wyczyszczone zapewne ze wzgl??du na przejrzysto???? dokumentu. Z drugiej strony w specyfikacji ISO jest znacznie wi??cej przyk??ad??w.

??

Firma itBCG poinformowała o wprowadzeniu zgodnego z ustawą o podpisie elektronicznym rozwiązania do wystawiania faktur elektronicznych wykorzystującego wyłącznie właściwości formatu PDF, to znaczy wbudowany w niego podpis elektroniczny w formacie PKCS#7.

czytaj dalej

W chwili obecnej Urzędowe poświadczenie odbioru (UPO) jest generowane przez skrzynki podawcze (ESP) różnych dostawców z tym samym zamiłowaniem do chaosu, jakie cechuje formaty podpisu elektronicznego od początków polskiej informatyzacji. W jaki sposób można to uporządkować pozostając w ramach obowiązującego prawa?

czytaj dalej

13 marca 2008 w Warszawie pod patronatem honorowym pani prezes UKE Anny Strężyńskiej odbędzie się konferencja "e-Dokument".Wstępny program konferencji:

czytaj dalej