IDZ DO

PRZYKADOWY ROZDZIA
SPIS TRECI

KATALOG KSIEK
KATALOG ONLINE
ZAMW DRUKOWANY KATALOG

TWJ KOSZYK
DODAJ DO KOSZYKA

CENNIK I INFORMACJE
ZAMW INFORMACJE
O NOWOCIACH
ZAMW CENNIK

CZYTELNIA
FRAGMENTY KSIEK ONLINE

Wydawnictwo Helion
ul. Chopina 6
44-100 Gliwice
tel. (32)230-98-63
e-mail: helion@helion.pl

Kryptografia
w praktyce
Autorzy: Niels Ferguson, Bruce Schneier
Tumaczenie: Romasz mijewski
ISBN: 83-7361-211-4
Tytu oryginau: Practical Cryptography
Format: B5, stron: 290
Obecnie najwaniejszym zagadnieniem w wiecie biznesu jest bezpieczestwo.
Nie majc bezpiecznego systemu komputerowego nie mona zarabia pienidzy,
nie mona rozwija dziaalnoci, wic tak naprawd nie sposb przetrwa na rynku.
Kryptografia jawi si jako metoda zapewnienia bezpieczestwa w cyberprzestrzeni.
Co ciekawe, nie pojawiy si jeszcze ksiki powicone implementowaniu kryptografii
i wczaniu jej w uywane na co dzie systemy.
W wikszoci przypadkw kryptografia daa internetowej spoecznoci niewiele
ponad zudne poczucie bezpieczestwa, gdy tak naprawd bezpieczestwa
tego dotd nie ma. Sytuacja taka nie sprzyja nikomu poza wamywaczami.
Niniejsza ksika, autorstwa spki niekwestionowanych autorytetw wiatowych,
wypenia t luk pokazujc, jak implementowa metody kryptografii w praktyce;
ksika ta stanowi zatem poczenie teorii z praktyk informatyczn.
W ksice opisano midzy innymi:
Praktyczne zasady doboru i uycia kryptograficznych funkcji elementarnych,
od szyfrw blokowych po podpisy cyfrowe.
Implementacj algorytmw kryptograficznych i budow bezpiecznych systemw.
Spjn filozofi projektowania dajca gwarancj, e ostatecznie cay system
uzyska dany poziom bezpieczestwa.
Dlaczego bezpieczestwo wpywa na wszystkie skadniki systemu i dlaczego
ma ono by podstawowym celem projektu?
Jak proste interfejsy funkcji kryptograficznych pozwalaj ograniczy zoono
systemu i zwikszy jego bezpieczestwo?
O autorach:
Niels Ferguson jest inynierem i konsultantem kryptografii. Ma on ogromne
dowiadczenie w projektowaniu i implementacji algorytmw i protokow
kryptograficznych oraz duych systemw zabezpiecze. Wczeniej pracowa na rzecz
DigiCash i CWI; w Counterpane Internet Security cile wsppracowa z Brucem
Schneierem. Opublikowa wiele prac naukowych z dziedziny kryptografii.
Bruce Schneier jest zaoycielem i dyrektorem technicznym Counterpane Internet
Security, firmy zajmujcej si monitorowaniem bezpieczestwa. Ten wiatowej sawy
naukowiec, ekspert w dziedzinie bezpieczestwa, jest autorem ksiek Secrets and
Lies: Digital Security in a Networked World oraz Applied Cryptography wydanych
przez Wiley Technology Publishing.

Spis treci

Wstp .....................................................................................................................13
Jak czyta t ksik .................................................................................................................................... 14

1.
Nasza filozofia projektowa ....................................................................................17
1.1. Zgubne skutki wydajnoci .................................................................................................................... 17
1.2. Przeklestwa rozbudowanych moliwoci........................................................................................... 19

2.
Otoczka kryptografii ..............................................................................................21
2.1.
2.2.
2.3.
2.4.
2.5.
2.6.
2.7.
2.8.
2.9.

Rola kryptografii................................................................................................................................... 21
Regua najsabszego ogniwa................................................................................................................. 22
Wizerunek przeciwnika ........................................................................................................................ 24
Mylenie paranoiczne ........................................................................................................................... 24
2.4.1. Atak ............................................................................................................................................ 25
Model zagroe .................................................................................................................................... 26
Kryptografia nie rozwizuje problemu................................................................................................. 27
Kryptografia jest bardzo trudna ............................................................................................................ 28
Kryptografia jest atwym elementem systemu ..................................................................................... 28
Podstawowa literatura........................................................................................................................... 29

3.
Wprowadzenie do kryptografii ..............................................................................31
3.1. Szyfrowanie .......................................................................................................................................... 31
3.1.1. Zasada Kerckhoffsa .................................................................................................................... 32
3.2. Potwierdzanie tosamoci..................................................................................................................... 33
3.3. Szyfrowanie z kluczem publicznym..................................................................................................... 34
3.4. Podpis cyfrowy ..................................................................................................................................... 35
3.5. PKI........................................................................................................................................................ 36

SPIS TRECI

3.6. Ataki ..................................................................................................................................................... 37

3.6.1. Atak tylko z tekstem zaszyfrowanym......................................................................................... 37
3.6.2. Atak ze znanym tekstem otwartym ............................................................................................ 37
3.6.3. Atak z wybranym tekstem otwartym.......................................................................................... 38
3.6.4. Atak z wybranym tekstem zaszyfrowanym................................................................................ 38
3.6.5. Rozrnianie atakw .................................................................................................................. 39
3.6.6. Atak urodzinowy ........................................................................................................................ 39
3.6.7. Spotkanie porodku .................................................................................................................... 40
3.6.8. Inne rodzaje atakw.................................................................................................................... 41
3.7. Poziom bezpieczestwa ........................................................................................................................ 41
3.8. Wydajno ............................................................................................................................................ 42
3.9. Zoono.............................................................................................................................................. 43

Cz I Bezpieczestwo komunikacji

45

4.
Szyfry blokowe ......................................................................................................47
4.1.
4.2.
4.3.
4.4.

Co to jest szyfr blokowy? ..................................................................................................................... 47

Rodzaje ataku ....................................................................................................................................... 48
Idealny szyfr blokowy .......................................................................................................................... 49
Definicja bezpieczestwa szyfru blokowego ....................................................................................... 49
4.4.1. Parzysto permutacji ................................................................................................................. 51
4.5. Praktyczne szyfry blokowe................................................................................................................... 52
4.5.1. DES............................................................................................................................................. 52
4.5.2. AES............................................................................................................................................. 55
4.5.3. Serpent ........................................................................................................................................ 57
4.5.4. Twofish....................................................................................................................................... 58
4.5.5. Pozostali finalici AES ............................................................................................................... 59
4.5.6. Ataki przez rozwizywanie rwna ........................................................................................... 60
4.5.7. Ktrego szyfru blokowego naley uy?.................................................................................... 61
4.5.8. Jak dugi powinien by mj klucz? ............................................................................................ 62

5.
Tryby szyfrw blokowych .....................................................................................63
5.1. Dopenianie........................................................................................................................................... 63
5.2. ECB ...................................................................................................................................................... 64
5.3. CBC ...................................................................................................................................................... 65
5.3.1. Stay IV....................................................................................................................................... 65
5.3.2. IV jako licznik ............................................................................................................................ 65
5.3.3. Losowy IV .................................................................................................................................. 66
5.3.4. Jednorazowy IV.......................................................................................................................... 66
5.4. OFB ...................................................................................................................................................... 67
5.5. CTR ...................................................................................................................................................... 68
5.6. Nowe tryby ........................................................................................................................................... 69
5.7. Ktrego trybu naley uy? .................................................................................................................. 70
5.8. Wycieki informacji ............................................................................................................................... 71
5.8.1. Prawdopodobiestwo kolizji ...................................................................................................... 72
5.8.2. Jak radzi sobie z wyciekami ..................................................................................................... 73
5.8.3. O naszym podejciu do matematyki........................................................................................... 74

SPIS TRECI

6.
Funkcje mieszajce ................................................................................................75
6.1. Bezpieczestwo funkcji mieszajcych ................................................................................................. 76
6.2. Prawdziwe funkcje mieszajce ............................................................................................................. 77
6.2.1. MD5............................................................................................................................................ 78
6.2.2. SHA-1......................................................................................................................................... 78
6.2.3. SHA-256, SHA-384 i SHA-512 ................................................................................................. 79
6.3. Sabe punkty funkcji mieszajcych ...................................................................................................... 79
6.3.1. Wyduanie ................................................................................................................................. 80
6.3.2. Kolizja czci wiadomoci ......................................................................................................... 80
6.4. Usuwanie sabych punktw .................................................................................................................. 81
6.4.1. Rozwizanie kompletne.............................................................................................................. 81
6.4.2. Rozwizanie wydajne ................................................................................................................. 82
6.5. Wybr funkcji mieszajcej ................................................................................................................... 83
6.6. Ku przyszoci ...................................................................................................................................... 84

7.
Kody uwierzytelniania wiadomoci.......................................................................85
7.1.
7.2.
7.3.
7.4.
7.5.

Do czego suy MAC ........................................................................................................................... 85

Idealna funkcja MAC ........................................................................................................................... 85
Bezpieczestwo MAC .......................................................................................................................... 86
CBC-MAC............................................................................................................................................ 87
HMAC .................................................................................................................................................. 88
7.5.1. HMAC a SHAd ........................................................................................................................... 89
7.6. UMAC .................................................................................................................................................. 90
7.6.1. Rozmiar wyniku MAC ............................................................................................................... 90
7.6.2. Ktra UMAC? ............................................................................................................................ 90
7.6.3. Elastyczno rodowiska ............................................................................................................ 91
7.6.4. Zakres analizy............................................................................................................................. 92
7.6.5. Po co zatem w ogle wspomina o UMAC?.............................................................................. 92
7.7. Ktr funkcj MAC wybra? ............................................................................................................... 92
7.8. Uycie funkcji MAC ............................................................................................................................ 93

8.
Bezpieczny kana ...................................................................................................95
8.1. Opis zagadnienia................................................................................................................................... 95
8.1.1. Role............................................................................................................................................. 95
8.1.2. Klucz........................................................................................................................................... 96
8.1.3. Wiadomoci czy strumie danych.............................................................................................. 96
8.1.4. Waciwoci bezpieczestwa...................................................................................................... 97
8.2. Kolejno potwierdzania wiarygodnoci i szyfrowania ....................................................................... 98
8.3. Szkic rozwizania ................................................................................................................................. 99
8.3.1. Numerowanie wiadomoci ......................................................................................................... 99
8.3.2. Potwierdzanie autentycznoci................................................................................................... 100
8.3.3. Szyfrowanie .............................................................................................................................. 101
8.3.4. Format ramki ............................................................................................................................ 101
8.4. Szczegy implementacji.................................................................................................................... 101
8.4.1. Inicjalizacja............................................................................................................................... 102
8.4.2. Wysyanie wiadomoci............................................................................................................. 103

SPIS TRECI

8.4.3. Odbieranie wiadomoci ............................................................................................................ 103

8.4.4. Kolejno wiadomoci.............................................................................................................. 105
8.5. Alternatywy ........................................................................................................................................ 105
8.6. Podsumowanie.................................................................................................................................... 106

9.
O implementacji (I)..............................................................................................107
9.1. Tworzenie poprawnych programw ................................................................................................... 108
9.1.1. Specyfikacje.............................................................................................................................. 108
9.1.2. Testowanie i poprawki.............................................................................................................. 109
9.1.3. Lekcewace podejcie............................................................................................................. 110
9.1.4. Co zatem robi? ........................................................................................................................ 110
9.2. Tworzenie bezpiecznego oprogramowania ........................................................................................ 111
9.3. Zachowywanie tajemnic ..................................................................................................................... 111
9.3.1. Kasowanie pamici stanu ......................................................................................................... 112
9.3.2. Plik wymiany............................................................................................................................ 113
9.3.3. Pami podrczna ..................................................................................................................... 114
9.3.4. Zatrzymanie danych w pamici ................................................................................................ 115
9.3.5. Dostp osb postronnych.......................................................................................................... 117
9.3.6. Integralno danych .................................................................................................................. 117
9.3.7. Co robi .................................................................................................................................... 118
9.4. Jako kodu rdowego..................................................................................................................... 118
9.4.1. Prostota ..................................................................................................................................... 118
9.4.2. Modularyzacja .......................................................................................................................... 119
9.4.3. Asercje ...................................................................................................................................... 120
9.4.4. Przepenienie bufora ................................................................................................................. 121
9.4.5. Testowanie................................................................................................................................ 121
9.5. Ataki bocznym kanaem ..................................................................................................................... 122
9.6. Wnioski............................................................................................................................................... 123

Cz II Negocjowanie kluczy

125

10.
Generowanie wartoci losowych .........................................................................127
10.1. Wartoci prawdziwie losowe.............................................................................................................. 128
10.1.1. Problemy zwizane z uyciem prawdziwych danych losowych ............................................ 128
10.1.2. Dane pseudolosowe ................................................................................................................ 129
10.1.3. Prawdziwe dane losowe i PRNG............................................................................................ 129
10.2. Modele ataku na PRNG...................................................................................................................... 130
10.3. Fortuna................................................................................................................................................ 131
10.4. Generator ............................................................................................................................................ 131
10.4.1. Inicjalizacja............................................................................................................................. 133
10.4.2. Ponowne przekazanie ziarna .................................................................................................. 133
10.4.3. Generowanie blokw.............................................................................................................. 133
10.4.4. Generowanie danych losowych .............................................................................................. 134
10.4.5. Szybko dziaania generatora................................................................................................ 135
10.5. Akumulator......................................................................................................................................... 135
10.5.1. rda entropii ........................................................................................................................ 135
10.5.2. Pule ......................................................................................................................................... 136
10.5.3. O implementacji ..................................................................................................................... 137

SPIS TRECI

10.5.4. Inicjalizacja............................................................................................................................. 139

10.5.5. Pobieranie losowych danych .................................................................................................. 140
10.5.6. Dodawanie zdarzenia.............................................................................................................. 141
10.6. Obsuga pliku ziarna ........................................................................................................................... 142
10.6.1. Zapis pliku ziarna ................................................................................................................... 142
10.6.2. Aktualizacja pliku ziarna ........................................................................................................ 142
10.6.3. Kiedy czyta i zapisywa plik ziarna ..................................................................................... 143
10.6.4. Kopie bezpieczestwa ............................................................................................................ 143
10.6.5. Atomowo aktualizacji w systemie plikw .......................................................................... 144
10.6.6. Pierwsze uruchomienie........................................................................................................... 144
10.7. Co zatem robi? .................................................................................................................................. 145
10.8. Dobieranie elementw losowych........................................................................................................ 145

11.
Liczby pierwsze ...................................................................................................147
11.1. Podzielno i liczby pierwsze............................................................................................................. 147
11.2. Generowanie maych liczb pierwszych .............................................................................................. 149
11.3. Operacje arytmetyczne modulo liczba pierwsza ................................................................................ 150
11.3.1. Dodawanie i odejmowanie ..................................................................................................... 151
11.3.2. Mnoenie ................................................................................................................................ 151
11.3.3. Ciaa skoczone i grupy ......................................................................................................... 151
11.3.4. Algorytm NWD ...................................................................................................................... 152
11.3.5. Rozszerzony algorytm Euklidesa ........................................................................................... 153
11.3.6. Dziaania modulo 2................................................................................................................. 154
11.4. Due liczby pierwsze.......................................................................................................................... 155
11.4.1. Testowanie pierwszoci.......................................................................................................... 157
11.4.2. Potgowanie............................................................................................................................ 159

12.
Diffie-Hellman.....................................................................................................161
12.1.
12.2.
12.3.
12.4.
12.5.
12.6.
12.7.
12.8.
12.9.

Grupy .................................................................................................................................................. 161

Wersja podstawowa DH ..................................................................................................................... 162
Man-in-the-middle.............................................................................................................................. 163
Puapki ................................................................................................................................................ 164
Bezpieczne liczby pierwsze................................................................................................................ 165
Uywanie mniejszej podgrupy ........................................................................................................... 166
Rozmiar p ........................................................................................................................................... 167
Zasady praktyczne .............................................................................................................................. 168
Co moe si nie uda? ........................................................................................................................ 169

13.
RSA......................................................................................................................171
13.1. Wprowadzenie .................................................................................................................................... 171
13.2. Chiskie twierdzenie o resztach ......................................................................................................... 171
13.2.1. Wzr Garnera ......................................................................................................................... 172
13.2.2. Uoglnienia ............................................................................................................................ 173
13.2.3. Zastosowania .......................................................................................................................... 173
13.2.4. Wnioski................................................................................................................................... 174

SPIS TRECI

13.3. Mnoenie modulo n ............................................................................................................................ 174

13.4. Definicja RSA..................................................................................................................................... 175
13.4.1. RSA i podpisy cyfrowe........................................................................................................... 175
13.4.2. Wykadniki publiczne............................................................................................................. 176
13.4.3. Klucz prywatny....................................................................................................................... 176
13.4.4. Wielko n .............................................................................................................................. 177
13.4.5. Generowanie kluczy RSA ...................................................................................................... 178
13.5. Puapki zwizane z uyciem RSA ...................................................................................................... 179
13.6. Szyfrowanie ........................................................................................................................................ 180
13.7. Podpisy ............................................................................................................................................... 182

14.
Wprowadzenie do protokow kryptograficznych...............................................185
14.1. Role..................................................................................................................................................... 185
14.2. Zaufanie .............................................................................................................................................. 185
14.2.1. Ryzyko.................................................................................................................................... 187
14.3. Motywacje .......................................................................................................................................... 187
14.4. Zaufanie w protokoach kryptograficznych........................................................................................ 189
14.5. Wiadomoci i etapy ............................................................................................................................ 189
14.5.1. Warstwa nona (transportowa) ............................................................................................... 189
14.5.2. Tosamo protokou i wiadomoci ....................................................................................... 190
14.5.3. Kodowanie i analiza wiadomoci ........................................................................................... 191
14.5.4. Stany wykonania protokou .................................................................................................... 191
14.5.5. Bdy....................................................................................................................................... 192
14.5.6. Powtrki i ponowne prby ..................................................................................................... 193

15.
Protok negocjacji klucza...................................................................................195
15.1.
15.2.
15.3.
15.4.
15.5.
15.6.
15.7.
15.8.

15.9.
15.10.
15.11.
15.12.

Otoczenie ............................................................................................................................................ 195

Pierwsze podejcie.............................................................................................................................. 196
Protokoy s wieczne .......................................................................................................................... 197
Konwencja potwierdzania autentycznoci.......................................................................................... 197
Drugie podejcie ................................................................................................................................. 198
Trzecie podejcie ................................................................................................................................ 199
Ostateczna posta protokou ............................................................................................................... 199
Rne spojrzenia na protok ............................................................................................................. 202
15.8.1. Punkt widzenia Alicji ............................................................................................................. 202
15.8.2. Punkt widzenia Boba .............................................................................................................. 202
15.8.3. Punkt widzenia atakujcego ................................................................................................... 202
15.8.4. Ujawnienie klucza .................................................................................................................. 203
Zoono obliczeniowa protokou..................................................................................................... 204
15.9.1. Sztuczki optymalizacyjne ....................................................................................................... 205
Zoono protokou ........................................................................................................................... 205
Mae ostrzeenie ................................................................................................................................. 206
Negocjacja klucza na podstawie hasa................................................................................................ 206

SPIS TRECI

16.
O implementacji (II) ............................................................................................209
16.1. Arytmetyka duych liczb cakowitych ............................................................................................... 209
16.1.1. Wooping ................................................................................................................................. 210
16.1.2. Sprawdzanie oblicze DH ...................................................................................................... 212
16.1.3. Sprawdzanie szyfrowania RSA .............................................................................................. 213
16.1.4. Sprawdzanie podpisw RSA .................................................................................................. 213
16.1.5. Wnioski................................................................................................................................... 213
16.2. Przyspieszenie mnoenia .................................................................................................................... 214
16.3. Ataki bocznym kanaem ..................................................................................................................... 215
16.3.1. rodki zaradcze....................................................................................................................... 215
16.4. Protokoy ............................................................................................................................................ 216
16.4.1. Protokoy w bezpiecznym kanale ........................................................................................... 217
16.4.2. Odbieranie komunikatw ....................................................................................................... 217
16.4.3. Brak odpowiedzi w zadanym czasie....................................................................................... 218

Cz III Zarzdzanie kluczami

219

17.
Zegar ....................................................................................................................221
17.1. Zastosowania zegara........................................................................................................................... 221
17.1.1. Utrata wanoci ...................................................................................................................... 221
17.1.2. Niepowtarzalne wartoci ........................................................................................................ 221
17.1.3. Monotoniczno...................................................................................................................... 222
17.1.4. Transakcje w czasie rzeczywistym......................................................................................... 222
17.2. Uycie sprztowego zegara ................................................................................................................ 223
17.3. Zagroenia dla bezpieczestwa .......................................................................................................... 223
17.3.1. Cofnicie zegara ..................................................................................................................... 223
17.3.2. Zatrzymanie zegara................................................................................................................. 224
17.3.3. Przestawianie zegara w przd................................................................................................. 224
17.4. Budowa niezawodnego zegara ........................................................................................................... 225
17.5. Problem takiego samego stanu ........................................................................................................... 226
17.6. Czas .................................................................................................................................................... 227
17.7. Wnioski............................................................................................................................................... 228

18.
Serwery kluczy ....................................................................................................229
18.1. Podstawy............................................................................................................................................. 229
18.2. Kerberos.............................................................................................................................................. 230
18.3. Prostsze rozwizania........................................................................................................................... 230
18.3.1. Bezpieczne poczenie............................................................................................................ 231
18.3.2. Przygotowanie klucza............................................................................................................. 231
18.3.3. Zmiana klucza......................................................................................................................... 232
18.3.4. Inne waciwoci..................................................................................................................... 232
18.4. Jak dokona wyboru ........................................................................................................................... 232

10

SPIS TRECI

19.
Marzenia o PKI ....................................................................................................233
19.1. Krtkie wprowadzenie do PKI ........................................................................................................... 233
19.2. Przykadowy PKI................................................................................................................................ 234
19.2.1. Uniwersalne PKI..................................................................................................................... 234
19.2.2. Dostp VPN............................................................................................................................ 234
19.2.3. Bankowo elektroniczna ....................................................................................................... 234
19.2.4. Czujniki w rafinerii................................................................................................................. 234
19.2.5. Centrum kart kredytowych ..................................................................................................... 235
19.3. Dodatkowe szczegy ......................................................................................................................... 235
19.3.1. Certyfikaty wielopoziomowe ................................................................................................. 235
19.3.2. Wygasanie certyfikatw ......................................................................................................... 236
19.3.3. Osobny podmiot rejestrujcy.................................................................................................. 236
19.4. Wnioski............................................................................................................................................... 237

20.
Rzeczywisto PKI ..............................................................................................239
20.1.
20.2.
20.3.
20.4.
20.5.
20.6.
20.7.
20.8.

Nazwy................................................................................................................................................. 239
Podmiot decydujcy ........................................................................................................................... 241
Zaufanie .............................................................................................................................................. 241
Autoryzacja porednia ........................................................................................................................ 242
Autoryzacja bezporednia................................................................................................................... 242
Systemy delegacji uprawnie ............................................................................................................. 243
Marzenie po modyfikacjach ............................................................................................................... 244
Odbieranie uprawnie......................................................................................................................... 245
20.8.1. Lista odwoa ......................................................................................................................... 245
20.8.2. Krtki okres wanoci ............................................................................................................ 246
20.8.3. Odwoywanie jest potrzebne .................................................................................................. 246
20.9. Do czego naprawd suy PKI?.......................................................................................................... 247
20.10. Co wybra........................................................................................................................................... 248

21.
PKI w praktyce ....................................................................................................249
21.1. Format certyfikatu .............................................................................................................................. 249
21.1.1. Jzyk uprawnie ..................................................................................................................... 249
21.1.2. Klucz gwny.......................................................................................................................... 250
21.2. Cykl ycia klucza................................................................................................................................ 250
21.3. Czemu klucze si zuywaj ................................................................................................................ 252
21.4. Co zatem zrobi? ................................................................................................................................ 253

22.
Przechowywanie tajemnic ...................................................................................255
22.1. Dysk.................................................................................................................................................... 255
22.2. Pami ludzka..................................................................................................................................... 256
22.2.1. Solenie i rozciganie............................................................................................................... 257
22.3. Pami przenona ............................................................................................................................... 258
22.4. Token bezpieczestwa ........................................................................................................................ 259

SPIS TRECI

22.5.
22.6.
22.7.
22.8.
22.9.
22.10.

11

Bezpieczny interfejs uytkownika...................................................................................................... 260

Dane biometryczne ............................................................................................................................. 260
Jednorazowa rejestracja ...................................................................................................................... 261
Ryzyko utraty ..................................................................................................................................... 262
Wsplne tajemnice ............................................................................................................................. 262
Usuwanie tajemnic ............................................................................................................................. 263
22.10.1. Papier .................................................................................................................................... 263
22.10.2. Pami magnetyczna ............................................................................................................ 263
22.10.3. Pamici trwae ...................................................................................................................... 264

Cz IV Rnoci

265

23.
Standardy .............................................................................................................267
23.1. Proces tworzenia standardw ............................................................................................................. 267
23.1.1. Standard .................................................................................................................................. 268
23.1.2. Funkcjonalno....................................................................................................................... 268
23.1.3. Bezpieczestwo ...................................................................................................................... 269
23.2. SSL ..................................................................................................................................................... 269
23.3. AES: standaryzacja w wyniku konkursu ............................................................................................ 270

24.
Patenty .................................................................................................................271
24.1.
24.2.
24.3.
24.4.
24.5.
24.6.
24.7.
24.8.

Stan zastany ........................................................................................................................................ 271

Kontynuacje........................................................................................................................................ 272
Niepewno ........................................................................................................................................ 272
Czytanie patentw .............................................................................................................................. 272
Licencjonowanie................................................................................................................................. 273
Patenty ochronne ................................................................................................................................ 274
Naprawa systemu patentowego .......................................................................................................... 274
Nota prawna........................................................................................................................................ 275

25.
Pomoc ekspertw .................................................................................................277

Dodatki

281

Bibliografia ..........................................................................................................283
Skorowidz ............................................................................................................289

9
O implementacji (I)

Czas ju powiedzie co nieco o implementacji. Realizacja systemw kryptograficznych rni si

od implementacji zwykych programw na tyle, e zagadnienie to zasuguje na osobne omwienie.
Najwicej problemw, jak zwykle, sprawia zasada najsabszego ogniwa (punkt 2.2). Bardzo
atwo jest zmarnowa podczas implementacji cay wysiek zwizany z osigniciem wymaganego
poziomu bezpieczestwa. To wanie bdy implementacji (najczciej w formie przepenienia bufora) s w praktyce najwikszymi wrogami bezpieczestwa. Kady, kto interesowa si w cigu
ostatnich kilku lat kwestiami zabezpieczania systemw zrozumie, o co chodzi. W praktyce rzadko
zdarza si zamanie systemu kryptograficznego jako takiego. Nie wynika to wcale z doskonaej
jako systemw; widzielimy ich na tyle duo, by pozby si wszelkich zudze. Po prostu znacznie atwiej jest znale bd w implementacji ni znale sabo kryptograficzn systemu, a atakujcy zwykle maj do rozsdku, by nie mczy si nad kryptografi, skoro dostpne s metody
znacznie prostsze.
Jak dotd w niniejszej ksice zajmowalimy si tylko kryptografi, ale tym razem wicej
czasu powicimy rodowisku, w jakim ona funkcjonuje. Kada cz systemu wpywa na jego
bezpieczestwo i budujc dobry system musimy od pocztku nie tylko mie bezpieczestwo na
uwadze, postawi sobie bezpieczestwo jako podstawowy cel pracy. System w sensie, jaki mamy
tu na myli, jest bardzo rozlegy. Obejmuje wszystkie elementy, ktrych wadliwe dziaanie grozi
redukcj poziomu bezpieczestwa.
Jednym z najwaniejszych elementw, jak zawsze, jest system operacyjny. aden powszechnie dostpny system operacyjny nie powstawa gwnie z myl o bezpieczestwie. Logiczny bdzie zatem wniosek, e nie da si zaimplementowa naprawd bezpiecznego systemu. Nie wiemy,
jak mona by to zrobi, i nie znamy nikogo, kto by to wiedzia. Stosowane w praktyce systemy
zawieraj wiele elementw, przy ktrych tworzeniu w ogle nie brano pod uwag bezpieczestwa,
wobec czego niemoliwe jest uzyskanie takiego poziomu bezpieczestwa, na jakim naprawd nam
zaley. Czy wobec tego naley si od razu podda? Oczywicie nie. Tworzc system kryptograficzny, staramy si przynajmniej, by jego cz zalena od nas bya tak bezpieczna, jak to tylko
jest moliwe. By moe tchnie to nieco mentalnoci urzdnika: zajmujemy si tylko tym, co dotyczy nas bezporednio. Tym niemniej my naprawd troszczymy si take o inne czci systemu, ale
na tym polu nie mamy zbyt wielkiej swobody. Midzy innymi wanie dlatego piszemy t ksik:
chcemy uwiadomi innym podstpn natur bezpieczestwa i pokaza, jak istotne jest dooenie
wszelkich moliwych stara przy realizacji bezpiecznych systemw.
Jest jeszcze inny wany powd, dla ktrego warto zatroszczy si przynajmniej o poprawno
czci kryptograficznej: ataki bezporednio na elementy kryptograficzne s szczeglnie niebezpieczne dlatego, e mog pozosta niewidoczne, o czym wspominalimy ju wczeniej. Atakujcy,

108

9. O IMPLEMENTACJI (I)

ktremu uda si zama zabezpieczenia kryptograficzne, prawdopodobnie pozostanie nie zauwaony. Mona go porwna do wamywacza posiadajcego zestaw kluczy do mieszkania: o ile zachowa naleyt ostrono, nikt w ogle nie zauway wamania.
Naszym dugofalowym celem jest budowa bezpiecznych systemw komputerowych. Aby ten
cel osign, kady musi zajmowa si czci, za ktr jest odpowiedzialny. Nasza praca, o czym
traktuje niniejsza ksika, polega na opracowaniu skutecznych zabezpiecze kryptograficznych.
Jest oczywiste, e zabezpieczy bdzie trzeba take inne czci systemu. Nie wiemy, jak to zrobi,
ale by moe inni to wiedz, a by moe kto tego dopiero si nauczy. Do tego czasu cakowite bezpieczestwo systemu bdzie ograniczone przez jego najsabsze ogniwo, za my dooymy wszelkich stara, by tym ogniwem nie okazaa si kryptografia.
O poprawno elementw kryptograficznych warto zadba take dlatego, e po zaimplementowaniu systemu wszelkie zmiany s bardzo kopotliwe. System operacyjny dziaa na pojedynczym
komputerze. Systemy kryptograficzne czsto s uywane w ramach protokow komunikacyjnych
czcych szereg komputerw. Aktualizacje systemu operacyjnego pojedynczego komputera s do
proste i w praktyce czsto maj miejsce. Modyfikacja sieciowego protokou komunikacyjnego jest
koszmarem. Dlatego wanie wiele sieci dziaa do dzi zgodnie z projektami z lat 70. i 80. Musimy
pamita, e kady nowo tworzony dzi system kryptograficzny, o ile zostanie przyjty do powszechnego uytku, prawdopodobnie bdzie dziaa jeszcze przez 30 czy 50 lat. Mamy nadziej, e przez ten
czas pozostae czci systemu stan si znacznie bardziej bezpieczne.

9.1. Tworzenie poprawnych programw

Podstawowy problem zwizany z implementacj systemw polega na tym, e w informatyce nie
wiadomo, jak napisa poprawny program czy modu (przez poprawny rozumiemy taki program,
ktry zawsze zachowuje si zgodnie ze specyfikacj). Trudnoci pisania poprawnych programw
wynikaj z kilku przyczyn.

9.1.1. Specyfikacje
Pierwszy problem bierze si std, e mao ktry program ma jasno okrelone wymagania. Bez specyfikacji nie sposb nawet sprawdzi, czy program jest poprawny. W przypadku takich programw
kwestia poprawnoci jest w ogle nierozstrzygalna.
Wiele projektw informatycznych ma dokument nazywany specyfikacj funkcjonaln. Teoretycznie powinna by to specyfikacja programu, ale w praktyce dokument ten czsto nie istnieje,
jest niekompletny lub opisuje elementy nie odnoszce si do oczekiwanego zachowania programu.
Jak dugo brak porzdnej specyfikacji, nie moe by owy o poprawnym programie.
Istota specyfikacji obejmuje trzy etapy:
Wymagania. Wymagania obejmuj nieformalny opis efektw dziaania programu. Jest to dokument typu co mona za pomoc tego programu zrobi a nie jak mona co zrobi.
Wymagania czsto bywaj niedookrelone i koncentruj si na caociowym obrazie, z pominiciem szczegw.
Specyfikacja funkcjonalna. Opis wymaga funkcjonalnych mwi, jak program ma dziaa.
Specyfikacja funkcjonalna obejmuje tylko te elementy, ktre da si sprawdzi nie zagldajc
do wntrza programu. W przypadku kadej pozycji specyfikacji funkcjonalnej naley zada sobie pytanie, czy moliwe jest przeprowadzenie testu gotowego programu, ktry byby w stanie

9.1. TWORZENIE POPRAWNYCH PROGRAMW

109

rozstrzygn o spenieniu danego wymogu. Taki test moe bada jedynie zewntrzne zachowanie
si programu, nie moe natomiast analizowa adnych stanw wewntrznych. aden wymg,
dla ktrego nie da si stworzy odpowiedniego testu, nie moe nalee do specyfikacji funkcjonalnej.
Opis wymaga funkcjonalnych powinien by zupeny. Oznacza to, e powinien on obejmowa wszystkie elementy funkcjonalne. aden element nie ujty w specyfikacji nie musi
by implementowany.
Inny sposb patrzenia na specyfikacj funkcjonaln polega na testowaniu gotowego programu. Kady wymg moe by i powinien by przetestowany.
Projekt implementacji. Dokument ten miewa rozmaite nazwy, ale opisuje on sposb dziaania programu od wewntrz. Projekt zawiera wszystko, czego nie mona przetestowa z zewntrz. Dobry projekt zwykle opisuje podzia programu na moduy oraz funkcjonalno tych
moduw. Z kolei na opisy moduw mona patrze jak na wymagania wobec moduu. W tej
sytuacji mona z kolei powtrzy cay cykl na poziomie moduw.
Spord wskazanych trzech dokumentw najwaniejsza jest niewtpliwie specyfikacja funkcjonalna. To wedug tego dokumentu bdzie przebiega testowanie gotowego programu. Czasami
mona obej si bez nieformalnego opisu wymaga, a za projekt starczy kilka szkicw na tablicy.
Jednak bez specyfikacji funkcjonalnej nie sposb nawet opisa zakresu prac ani zdecydowa, czy
ich cel zosta zrealizowany.

9.1.2. Testowanie i poprawki

Drugi problem zwizany z pisaniem poprawnych programw dotyczy powszechnie praktykowanego cyklu testowania i robienia poprawek. Programista pisze program i sprawdza, czy zachowuje
si on zgodnie z oczekiwaniami. Jeli nie, to poprawia bdy i ponawia testowanie. Sposb ten, jak
wiadomo, nie prowadzi do uzyskania poprawnego programu. Wynikiem jest program, ktry dziaa
w typowych sytuacjach.
W roku 1972 Edsger Dijkstra w swoim artykule (za ktry otrzyma Nagrod Turinga) wyrazi
myl, e testowanie moe ujawni jedynie bdy, nie moe za zagwarantowa braku bdw [23].
Co do prawdziwoci tego stwierdzenia nie ma adnych wtpliwoci, a my chcielibymy pisa programy, ktrych poprawnoci mona byoby dowie. Niestety, istniejce obecnie techniki dowodzenia poprawnoci programw nie nadaj si do zastosowania nawet w rutynowej pracy programistycznej, nie mwic ju o caych projektach.
W obecnej chwili teoretycy informatyki nie znaj odpowiedniego rozwizania problemu poprawnoci. By moe w przyszoci udowodnienie poprawnoci programu bdzie moliwe. By
moe naley wypracowa te narzdzia i metodyk do znacznie bardziej dokadnego i wszechstronnego
testowanie. Jednak nawet nie dysponujc penym rozwizaniem moemy dokada wszelkich stara
i uywa wszystkich dostpnych obecnie narzdzi.
Jest kilka dziecinnie prostych zasad dotyczcych bdw. Mona je znale w kadym podrczniku inynierii oprogramowania:
Przy poszukiwaniu bdw najpierw naley zrealizowa test, ktry jest w stanie wykry dany
typ bdu. Nastpnie trzeba sprawdzi, czy bd faktycznie zostanie wykryty. Wtedy naley
bd poprawi i ponownie przeprowadzi test sprawdzajc, czy bd ju nie wystpi. Ten sam
test musi by wykonywany we wszystkich kolejnych wersjach, aby zagwarantowa, e bd
nie pojawi si ponownie.

110

9. O IMPLEMENTACJI (I)

Po znalezieniu bdu zawsze naley zastanowi si nad przyczyn jego wystpienia. Czy w innych czciach programu moe si zdarzy podobny bd? Naley sprawdzi wszystkie podejrzane miejsca.
Naley rejestrowa wszystkie znalezione bdy. Prosta analiza statystyczna znalezionych bdw moe wskaza, ktre czci programu maj szczeglnie duo niedorbek, jakiego typu
bdy pojawiaj si najczciej i tak dalej. Tego typu informacje zwrotne s niezbdne dla
kontroli jakoci.
Zasady te nie stanowi nawet niezbdnego minimum, ale z drugiej strony niewiele jest gotowych opracowa, z ktrych mona byoby korzysta. Jakoci oprogramowania powiconych jest
niewiele ksiek. Na dodatek pogldy ich autorw nie s ze sob zgodne. Wielu autorw opisuje
konkretn metodologi tworzenia oprogramowania jako jedyne suszne rozwizanie, a wszelkie
panacea s dla nas podejrzane. Prawda zawsze ley porodku.

9.1.3. Lekcewace podejcie

Trzecim problemem jest niesychanie lekcewacy stosunek wikszoci informatykw do bdw.
Bdy w programach s po prostu traktowane jako fakt naturalny. Sytuacja, w ktrej procesor tekstu
nagle przestaje dziaa powodujc utrat pracy z caego dnia, bywa traktowana jak normalny stan
rzeczy. Czsto win przenosi si na uytkownika: powiniene czciej zapisywa swoj prac.
Do powszechnej praktyki firm software-owych naley sprzeda produktw zawierajcych nieznane
bdy. Nie byby to wielki problem, gdyby chodzio o gry komputerowe, ale w obecnych czasach
nasza praca, ekonomia i w coraz wikszym stopniu cae ycie zale od oprogramowania. Producent samochodw, ktry znajdzie usterk (bd) w sprzedanym samochodzie, ujawnia j i zobowizuje si do jej usunicia. Firmy informatyczne zrzucaj z siebie wszelk odpowiedzialno odpowiednio formuujc umowy licencyjne podobne warunki byyby nie do przyjcia w przypadku
innych produktw. Przy takiej postawie nikt nie bdzie dokada stara, by jego oprogramowanie
byo poprawne.

9.1.4. Co zatem robi?

W adnym wypadku nie naley si spodziewa, e do produkcji poprawnego oprogramowania wystarczy dobry programista, uwane sprawdzanie kodu rdowego, certyfikat ISO 9001 czy dokadne
testowanie, a nawet kombinacja wszystkich tych elementw. W praktyce rzecz jest znacznie trudniejsza. Oprogramowanie jest produktem zbyt skomplikowanym, by dao si nad nim zapanowa
za pomoc kilku zasad i procedur. Lepiej wzi wzr z najlepszego na wiecie inynierskiego
systemu kontroli jakoci: chodzi o przemys lotniczy. Wszyscy uczestnicy rynku lotniczego zaangaowani s w system bezpieczestwa. Rygorystyczne zasady i procedury dotycz niemal wszystkich dziaa. Istnieje mnstwo wariantw awaryjnych. Kada nakrtka i kada rubka w samolocie
musz by zatwierdzone do uycia w lotnictwie, zanim mona je bdzie gdziekolwiek zamontowa. Kade podejcie mechanika ze rubokrtem w rku do samolotu jest nadzorowane i potwierdzane przez innego pracownika. Kad modyfikacj starannie si dokumentuje. Wszystkie wypadki
s drobiazgowo badane, aby znale i usun ich faktyczne przyczyny. To fanatyczne wprost denie do wysokiej jakoci jest niezwykle kosztowne. Samolot jest prawdopodobnie o rzd wielkoci droszy ni mgby by, gdyby jego plany konstrukcyjne zostay przesane do zwykej firmy

9.2. TWORZENIE BEZPIECZNEGO OPROGRAMOWANIA

111

produkcyjnej. Jednak z drugiej strony to denie do jakoci daje niesamowite efekty. Latanie jest
dzisiaj czynnoci rutynow, mimo e kada usterka w samolocie moe okaza si krytyczna. Pilot
w razie kopotw nie moe po prostu wcisn hamulcw i zatrzyma maszyny. Jedynym sposobem bezpiecznego powrotu jest bardzo delikatna operacja ldowania; niewiele jest na wiecie
miejsc, w ktrych mona j bezpiecznie przeprowadzi. Przemys lotniczy zadziwiajco skutecznie zatroszczy si o bezpieczestwo lotw. Byoby wskazane przej moliwie wiele z wypracowanych przeze procedur. By moe napisanie poprawnego oprogramowania musi by o rzd wielkoci drosze, ni jest obecnie, kiedy programy pisze si tak, jak do tego przywyklimy. Jeli jednak
wzi pod uwag koszty spoeczne bdw oprogramowania, moemy by pewni, e w duszym
okresie czasu wysiek si opaci.

9.2. Tworzenie bezpiecznego oprogramowania

Jak dotd mwilimy jedynie o poprawnoci oprogramowania. Samo tylko pisanie poprawnych
programw nie wystarcza do stworzenia bezpiecznego systemu. Oprogramowanie musi by nie tylko
poprawne, ale take bezpieczne.
Na czym polega rnica? Oprogramowanie poprawne realizuje pewn opisan specyfikacj:
wcinicie przycisku A wywoa skutek B. Wobec bezpiecznego oprogramowania stawia si jeszcze
jeden wymg: specyfikacj negatywn, polegajc na niemonoci zrealizowania pewnych funkcji.
Niezalenie od tego, co zrobi atakujcy, nie moe zdarzy si sytuacja X. Jest to zasadnicza rnica:
testowa mona jedynie funkcjonalno, ale nie jej brak. Aspektw zwizanych z bezpieczestwem
nie mona skutecznie przetestowa, przez co tworzenie oprogramowania bezpiecznego jest znacznie
trudniejsze od tworzenia oprogramowania poprawnego. Nieuchronny jest nastpujcy wniosek:
Standardowe techniki programowania s cakowicie nieprzydatne
przy tworzeniu bezpiecznych programw.
Tak naprawd nie wiemy, jak tworzy kod rdowy bezpiecznego programu. Jako oprogramowania jest tak szerokim zagadnieniem, e naleaoby jej powici kilka ksiek. Nasza wiedza
nie wystarcza co prawda do ich napisania, ale znamy zagadnienia specyficzne dla kryptografii oraz
wiemy, jakie problemy pojawiaj si najczciej. Tymi wanie problemami zajmiemy si do koca
biecego rozdziau.
Zanim zaczniemy, sformuujemy jasno nasz punkt widzenia: nikomu, kto nie zamierza woy
solidnej pracy w stworzenie bezpiecznego programu, nie warto w ogle kopota si kryptografi.
Tworzenie systemw kryptograficznych moe by dobr zabaw, ale w przypadku bdnej implementacji jest zwyk strat czasu.

9.3. Zachowywanie tajemnic

Kade zastosowanie metod kryptografii wie si z istnieniem tajemnic, ktre musz pozosta poufne. Oznacza to, e oprogramowanie obsugujce tajemnice musi dopilnowa, by nie wydostay
si one na zewntrz.
W przypadku bezpiecznego kanau mamy do czynienia z dwoma rodzajami tajemnic: z kluczami
i z danymi. Obie te tajemnice s zreszt tajemnicami chwilowymi: nie zamierzamy przechowywa
ich zbyt dugo. Dane s potrzebne tylko w chwili przetwarzania wiadomoci. Klucze s uywane

112

9. O IMPLEMENTACJI (I)

tylko przez czas istnienia bezpiecznego kanau. Dugoterminowe przechowywanie tajemnic zostanie
omwione w rozdziale 22.
Tajemnice tymczasowe przechowuje si w pamici. Niestety, pami wikszoci komputerw
nie jest miejscem zbyt bezpiecznym. Po kolei omwimy wszystkie typowe problemy z ni zwizane.

9.3.1. Kasowanie pamici stanu

Podstawowa zasada zwizana z tworzeniem oprogramowania dla celw bezpieczestwa kae usuwa
z pamici wszelkie informacje natychmiast, kiedy tylko przestaj by potrzebne. Im duej takie
informacje s przechowywane, tym wiksze prawdopodobiestwo, e komu uda si do nich sign.
Co wicej, ostateczne usunicie danych powinno nastpi jeszcze przed utrat kontroli nad nonikiem, na ktrym dane te zostay zapisane. W przypadku tajemnic tymczasowych chodzi o czyszczenie
odpowiednich fragmentw pamici.
Mimo e sama zasada wydaje si prosta, rodzi ona zadziwiajco wiele problemw. W przypadku programu pisanego w jzyku C mona zadba samemu o wyczyszczenie pamici. Piszc
bibliotek przeznaczon dla innych programw trzeba przyj, e program gwny wywoa odpowiednie procedury, kiedy przestanie potrzebowa danych. Na przykad przed zamkniciem poczenia komunikacyjnego biblioteka kryptograficzna powinna si dowiedzie o tym zamiarze, aby
moga usun z pamici stan sesji bezpiecznego kanau. Biblioteka powinna zawiera odpowiedni funkcj, ale musimy uwiadomi sobie, e programista moe by zbyt leniwy, by jej uy.
W kocu nawet bez jej wywoania program i tak dziaa znakomicie.
W niektrych jzykach obiektowych sytuacja nieco si upraszcza. W C++ kady obiekt posiada swj destruktor, i fakt ten mona wykorzysta do skasowania stanu. Taka praktyka jest standardem w programowaniu procedur obsugi bezpieczestwa w C++. O ile tylko program gwny
zachowuje si prawidowo i niszczy wszystkie obiekty, kiedy przestaj by potrzebne, pami opisujca stan jest prawidowo wymazywana. Jzyk C++ zapewnia, e obiekty alokowane na stosie
bd niszczone w miar oprniania stosu w trakcie obsugi wyjtkw, ale o zniszczenie obiektw
alokowanych na stercie musi zadba sam program. Wywoanie funkcji systemu operacyjnego dla
zakoczenia dziaania programu moe nawet nie oprni stosu, a my musimy zapewni, e nawet
w takiej sytuacji dane zostan wymazane. W kocu system operacyjny wcale nie gwarantuje, e
skasuje stan pamici przed przekazaniem sterowania nastpnej aplikacji.
Nawet jeli zrobimy wszystko co trzeba, komputer nadal moe odmawia posuszestwa.
Niektre kompilatory staraj si zbyt wiele optymalizowa. Typowe funkcje zwizane z bezpieczestwem cz oblicze wykonuj na zmiennych lokalnych, a potem staraj si te zmienne usun. W jzyku C mona to zrobi wywoujc funkcj

. Dobry kompilator zoptymalizuje
funkcj

 zastpujc j szybszym kodem wstawianym (in-line). Jednak niektre kompilatory
domylaj si zbyt wiele. Wykrywaj, e zamazywana zmienna lub tablica nie bdzie ju uywana
i optymalizuj program wyrzucajc wywoanie

. Cao dziaa szybciej, ale program przestaje si zachowywa zgodnie z naszymi wymaganiami. Nie jest trudno znale program, ktry
odczyta dane znajdujce si akurat w pamici. Przekazanie niewymazanej pamici innej bibliotece
grozi wic ujawnieniem danych atakujcemu. Wobec tego zachodzi konieczno sprawdzania kodu generowanego przez kompilator dla pewnoci, e faktycznie usuwa on sekrety z pamici.
W jzykach takich jak Java sytuacja komplikuje si jeszcze bardziej. Wszystkie obiekty alokowane s na stercie, ze sterty te usuwane s zbdne ju dane. Oznacza to, e funkcja finalizujca
(podobna do destruktora C++) nie jest wywoywana, dopki procedura porzdkujca pami nie
stwierdzi, e dany obiekt nie jest ju uywany. Nie jest nigdzie powiedziane, jak czsto procedura
ta ma by wywoywana i nietrudno sobie wyobrazi sytuacj, w ktrej tajne dane bd przebywa

9.3. ZACHOWYWANIE TAJEMNIC

113

w pamici przez dugi czas. Uycie procedur obsugi wyjtkw utrudnia rczne wymazywanie pamici. Po wygenerowaniu wyjtku ze stosu zdejmowane s kolejne wywoania, a programista nie
ma adnego wpywu na przebieg akcji, nie moe wywoa adnego swojego kodu; moe co najwyej kad funkcj umieci w duej klauzuli . Jest to rozwizanie cakiem niepraktyczne, na
dodatek naleaoby je stosowa w caym programie, wobec czego niemoliwe byoby stworzenie
prawidowo zachowujcej si biblioteki Javy do obsugi bezpieczestwa. Podczas obsugi wyjtkw Java zdejmuje dane ze stosu usuwajc wszelkie odwoania do obiektw, ale nie usuwa przy
tym samych obiektw. Pod tym wzgldem Java zachowuje si naprawd le. Najlepsze rozwizanie, do jakiego doszlimy, polegao na zapewnieniu wykonania procedur finalizacyjnych przy zamykaniu programu. Polega ono na tym, e metoda
 programu wykorzystuje instrukcj 

 . Blok   zawiera kod wymuszajcy wywoanie procedury czyszczenia pamici, za

procedura ta stara si wywoa wszystkie metody finalizujce (szczegy znajduj si w kodzie
rdowym funkcji 
 i 
   ). Nadal nie mamy gwarancji, e
metody finalizujce zostan wykonane, ale nic wicej nie udao nam si uzyska. Najlepszym
rozwizaniem byoby wsparcie od samego jzyka programowania. W C++ co prawda teoretycznie
moliwe jest napisanie programu czyszczcego stan wszystkich zmiennych z chwil, kiedy tylko
przestaj by potrzebne, ale wiele innych cech tego jzyka powoduje, e nie specjalnie si nadaje
do tworzenia oprogramowania zwizanego z bezpieczestwem. W Javie usuwanie stanu pamici
jest bardzo trudne. Jedno z moliwych udoskonale mogoby polega na deklarowaniu zmiennych
jako wraliwych i na takiej implementacji, ktra gwarantowaaby ich wymazanie. Jeszcze lepiej
byoby mie jzyk programowania wymazujcy i usuwajcy wszystkie zbdne ju dane. Pozwolioby to unikn wielu bdw bez znaczcej utraty wydajnoci.
Tajne dane mog gromadzi si take w innych miejscach. Wszystkie dane w razie potrzeby
s adowane do rejestrw CPU. Wikszo jzykw nie pozwala na czyszczenie rejestrw, ale
w komputerach o niewielkiej liczbie rejestrw bardzo mae jest prawdopodobiestwo, e dane pozostan w nich na duej.
W trakcie przeczania kontekstu (kiedy system operacyjny przecza si z jednego programu
na inny) wartoci rejestrw CPU s zapisywane w pewnym obszarze pamici i na og pozostaj w
nim na duej. O ile nam wiadomo, nie ma na to adnej rady, poza moliwoci zwikszajcej
bezpieczestwo poprawki w systemie operacyjnym.

9.3.2. Plik wymiany

Wikszo systemw operacyjnych (w tym biece wersje Windows oraz wszystkie systemy Unix)
korzysta z pamici wirtualnej w celu zwikszenia liczby rwnolegle dziaajcych programw.
Podczas dziaania programu nie wszystkie jego dane znajduj si w pamici; cz z nich jest przechowywana w pliku wymiany. Kiedy program potrzebuje danych, ktrych akurat nie ma w pamici,
jego wykonywanie jest przerywane. System obsugi pamici wirtualnej pobiera potrzebne dane z pliku
wymiany, a wtedy program moe kontynuowa swoje dziaanie. Co wicej, w razie, kiedy system
pamici wirtualnej stwierdzi, e potrzebuje wicej wolnej pamici, dowolny fragment pamici nalecej do programu moe zosta zapisany w pliku wymiany.
Oczywicie wikszo systemw pamici wirtualnej nawet nie prbuje ukrywa danych ani
szyfrowa ich przed zapisaniem na dysk. Wikszo oprogramowania powstaje z myl o wsppracy
z innymi programami we wsplnym rodowisku, a nie o pracy we wrogim rodowisku, z jakim
mamy do czynienia w kryptografii. Tak wic mamy do czynienia z zagroeniem, ktre opiszemy
nastpujco: system pamici wirtualnej moe pobra fragment pamici naszego programu i zapisa go na dysku. Program uytkowy nigdy nie jest informowany o takiej sytuacji, wic w ogle nie

114

9. O IMPLEMENTACJI (I)

jest w stanie na ni zareagowa. Zamy, e na dysk przeniesiony zostanie fragment pamici zawierajcy klucze. W razie awarii komputera lub choby wyczenia zasilania dane pozostan na
dysku. Wikszo systemw operacyjnych pozostawia dane na dyskach nawet w przypadku poprawnego zamknicia systemu. Zwykle nie ma sposobu na wymazanie pliku wymiany, wic dane
mog lee na dysku w nieskoczono. Nikt nie wie, kto w przyszoci uzyska dostp do takiego
pliku wymiany. Dlatego nie moemy sobie pozwoli na ryzyko zapisania naszych tajemnic w pliku
wymiany1.
Jak zatem uniemoliwi systemowi pamici wirtualnej zapisywanie naszych danych na dysku? W niektrych systemach operacyjnych dostpne s funkcje systemowe informujce system
pamici wirtualnej, e pewnych obszarw pamici nie wolno przenosi na dysk. Rzadko zdarza si
system operacyjny zawierajcy obsug bezpiecznego systemu wymiany, w ktrym zapisywane na
dysku dane byyby chronione kryptograficznie. Jeeli w naszym systemie nie jest dostpny aden
z opisanych przed chwil mechanizmw, to mamy pecha. Moemy wtedy tylko gono ponarzeka
na system operacyjny i zrobi wszystko, co da si zrobi w danej sytuacji.
Zamy teraz, e mamy rodki, by uniemoliwi zapisywanie czci pamici w pliku wymiany.
Ktrego fragmentu pamici winna dotyczy taka blokada? Oczywicie naleaoby ni obj wszystkie
te fragmenty pamici, ktre mog zawiera poufne dane. Mamy wic nastpny problem: w wielu
rodowiskach programowania bardzo trudno jest ustali, gdzie dokadnie dane zostay umieszczone.
Obiekty s czsto alokowane na stercie, dane globalne mona alokowa statycznie, za zmienne
lokalne zazwyczaj umieszcza si na stosie. Ustalanie takich szczegw jest bardzo skomplikowane
i moe by rdem bdw. Prawdopodobnie najlepsze rozwizanie polega na blokowaniu caej pamici naszej aplikacji. Jednak nawet ono nie jest tak proste, jak mogoby si wydawa, gdy moemy
przy okazji przegapi szereg usug systemu operacyjnego, takich jak automatycznie alokowany
stos. Poza tym blokowanie pamici powoduje, e system pamici wirtualnej staje si nieskuteczny.
Caa rzecz jest o wiele bardziej skomplikowana, ni powinna. Prawidowe rozwizanie polega
oczywicie na zbudowaniu systemu pamici wirtualnej, ktry chroniby poufno danych. Wie si
to ze zmian systemu operacyjnego i wobec tego jest poza nasz kontrol. Nawet jeli stosowne
funkcje pojawi si w nastpnej wersji uywanego systemu operacyjnego, to i tak trzeba bdzie starannie sprawdzi, czy system pamici wirtualnej dobrze strzee powierzanych mu tajnych danych.

9.3.3. Pami podrczna

We wspczesnych komputerach nie mamy do czynienia z jednym tylko rodzajem pamici. Istnieje
caa hierarchia pamici. Na samym dole jest pami gwna o pojemnoci idcej czsto w setki
megabajtw. Poniewa pami gwna jest wzgldnie powolna, stosuje si pami podrczn (cache).
Jest to pami mniej obszerna, ale za to szybsza. Zawiera ona kopi ostatnio uywanych danych
z pamici gwnej. Jednostka centralna, potrzebujc danych, najpierw szuka ich w pamici podrcznej. Jeli dane tam s, CPU otrzymuje je do szybko. Jeli danych w pamici podrcznej nie ma,
to odczytuje je ze stosunkowo powolnej pamici gwnej i kopiuje do pamici podrcznej na przyszo. Miejsce w pamici podrcznej uzyskuje si, wyrzucajc z niej jaki inny fragment danych.
Opisany mechanizm jest istotny, gdy pami podrczna zawiera skopiowane dane, w tym
kopie naszych danych poufnych. Problem polega na tym, e kiedy staramy si nasze tajne dane
usun, usuwanie takie moe si nie powie. W niektrych systemach modyfikacje s zapisywane
jedynie w pamici podrcznej, a nie w pamici gwnej. Dane zostan pniej zapisane do pamici
1
Nigdy nie powinnimy zapisywa tajemnic na adnym trwaym noniku bez ich uprzedniego zaszyfrowania. Zagadnieniem tym zajmiemy si pniej.

9.3. ZACHOWYWANIE TAJEMNIC

115

gwnej, ale dopiero wtedy, kiedy w pamici podrcznej braknie miejsca na jakie inne dane. Nie
znamy wszystkich szczegw tego mechanizmu, poza tym jest on zaleny od typu procesora. Nie
da si stwierdzi, czy istnieje jakie oddziaywanie midzy moduem alokacji pamici a systemem
pamici podrcznej, ktre pozwolioby pomin etap buforowania danych w pamici podrcznej
podczas zwalniania pamici. Producenci nie wskazuj sposobu usuwania danych z pamici, a aden
mechanizm, ktry nie jest oficjalnie udokumentowany, nie jest te godny zaufania.
Kolejne niebezpieczestwo zwizane z pamici podrczn polega na tym, e w pewnych warunkach pami taka moe otrzyma sygna o modyfikacji pewnego obszaru pamici gwnej, na przykad przez inny procesor w systemie wieloprocesorowym. Dane w pamici podrcznej otrzymuj
status niepoprawnych, ale zwykle nie oznacza to wcale ich usunicia. Znowu moe si okaza,
e gdzie istnieje kopia naszych danych poufnych.
Na opisane wyej problemy nie ma oglnej rady. Nie stanowi te na og wielkiego zagroenia, poniewa w wikszoci systemw jedynie sam system operacyjny ma bezporedni dostp do
mechanizmu pamici podrcznej. Systemowi operacyjnemu tak czy inaczej trzeba ufa, wic i my
mu zaufamy. Tym niemniej o opisanych niebezpieczestwach trzeba pamita podczas projektowania, gdy sprawiaj one, e tworzone systemy nie s tak bezpieczne, jak by powinny.

9.3.4. Zatrzymanie danych w pamici

Wiele osb zaskakuje fakt, e zwyke nadpisywanie danych w pamici wcale nie usuwa starych
danych. Szczegy samego procesu zale od rodzaju uywanej pamici, ale w zasadzie proces
zapisywania sprawia, e w odpowiednim miejscu pamici dane te dopiero zaczynaj si pojawia.
Na przykad w razie wyczenia maszyny stara warto czciowo moe pozosta w pamici.
Wszystko zaley od konkretnych warunkw, ale czasem chwilowe wyczenie i ponowne wczenie zasilania pamici mog przyczyni si do ujawnienia starych danych. Inne typy pamici mog
przypomnie sobie stare dane w przypadku uycia (czsto nieudokumentowanych) trybw testowania [39].
Zjawiskiem ty kieruj rne mechanizmy. Jeeli bdziemy przechowywa pewne dane przez
duszy czas w tym samym miejscu pamici typu SRAM, stan si one preferowanym stanem pocztkowym pamici po wczeniu zasilania. Wiele lat temu jeden z naszych przyjaci zetkn si
z tym problemem w swoim komputerze domowej produkcji [9]. Napisa on BIOS, w ktrym uy
pewnej magicznej wartoci w konkretnym miejscu pamici; penia ona rol znacznika wskazujcego, czy restart by zwizany ze startem zimnym, czy gorcym2. Po pewnym czasie komputer nie
chcia si uruchamia po wczeniu zasilania, gdy w pamici zakodowaa si na trwae magiczna
warto, wobec czego kade uruchamianie komputera byo traktowane jako restart gorcy. Wartoci startowe nie byy inicjalizowane prawidowo, wic proces uruchamiania komputera nie udawa
si. W tym przypadku rozwizaniem okazaa si wymiana niektrych ukadw pamici, przez co
w z odpowiedniego miejsca znika zapamitana magiczna warto. Bya to dla nas wana lekcja:
okazao si, e pami przechowuje wicej danych, ni si na pozr wydaje. Podobny proces ma
miejsce w pamiciach DRAM, tyle e w tym wypadku jest on nieco bardziej skomplikowany.
DRAM przechowuje may adunek na miniaturowych kondensatorach. Materia izolacyjny wok kondensatora jest poddawany wpywowi tak tworzonego pola. Wpyw ten powoduje zmian struktury
2

W owych czasach budowane w domu komputery programowano wprowadzajc bezporednio binarny

kod jzyka maszynowego. Powodowao to wiele bdw i jedyn pewn metod odzyskania panowania nad
komputerem po awarii programu byo wyzerowanie maszyny. Zimny start nastpowa po wyczeniu zasilania.
Gorcy start by wykonywany po wciniciu klawisza zerujcego. Start gorcy nie obejmowa inicjacji czci
stanu maszyny, wobec czego nie kasowa ustawie dokonanych wczeniej przez przez uytkownika.

116

9. O IMPLEMENTACJI (I)

materiau, a cilej migracj domieszek [39]. Atakujcy, majc fizyczny dostp do pamici, mgby teoretycznie odczyta tak zapisane dane.
Istotno opisanego typu zagroenia jest dyskusyjna; naszym zdaniem jest to zagroenie realne.
Nie chcielibymy przecie, by ewentualnej kradziey komputera towarzyszya kradzie skasowanych na nim wczeniej danych. Groby takiej unikniemy tylko troszczc si samemu, by komputer
rzeczywicie zapomina wszystkie kasowane dane.
Potrafimy wskaza jedynie czciowe rozwizanie, ktre dziaa przy pewnych zaoeniach
dotyczcych pamici. Rozwizanie to, nazwane Boojum3, nadaje si do wymazywania niewielkich
porcji danych, na przykad kluczy. Oznaczmy symbolem m dane, ktre chcemy przechowa. Zamiast
zapisywa m, wygenerujemy losowy acuch R i zapiszemy R oraz R m. Wartoci te umiecimy
w dwch rnych miejscach w pamici, najlepiej oddalonych od siebie. Caa sztuka polega na czstych zmianach R. W regularnych odstpach czasu, na przykad co 100 ms, generujemy now warto
R' i aktualizujemy pami tak, by zawieraa R R' oraz R R' m. Sposb ten daje gwarancj, e
kady bit pamici bdzie zalee od cigu bitw losowych. W celu skasowania pamici zapiszemy
jako nowe m cig zer, w wyniku czego oba obszary pamici otrzymaj te same, losowe dane.
Chcc odczyta warto m, musimy pobra dane z obu lokalizacji i podda je operacji XOR.
Podczas zapisywania obliczamy XOR nowych danych z R i umieszczamy wynik pod drugim z uywanych adresw.
Naley zwrci uwag na to, by cigi bitw R i R m nie zostay umieszczone w ukadzie
RAM obok siebie. Bez informacji na temat dziaania RAM nie jest to oczywiste, ale w wikszoci
pamici bity przechowuje si w prostoktnej macierzy, ktrej przestrze adresowa skada si
z czci odpowiedzialnych za wiersz i kolumn. Dwa fragmenty przechowywane w miejscach, ktrych adresy rni si o , maj ma szans, by ssiadoway w ukadzie fizycznie (zakadamy
przy tym, e w pamici bity z adresami parzystymi nie s numerami wierszy, a z bity adresami
nieparzystymi nie s numerami kolumn; zreszt takiej konstrukcji pamici nigdy jeszcze nie widzielimy). Jeszcze lepsze rozwizanie polegaoby na ustaleniu dwch losowych adresw w bardzo
duej przestrzeni adresowej. W ten sposb prawdopodobiestwo przylegania dwch wybranych
obszarw byoby bardzo mae, niezalenie od konstrukcji uytej pamici.
Opisane rozwizanie jest jedynie czciowe, przy tym jest ono jest dosy trudne do zastosowania. Sprawdza si ono tylko dla niewielkich porcji danych, gdy w przypadku wikszych iloci
danych funkcja aktualizujca warto dziaaaby zbyt wolno. Jednak jego uycie gwarantuje, e
aden obszar pamici nie bdzie naraony na regularne przechowywanie w nim tajnych danych
w sposb wpywajcy na jego preferowany stan.
Nadal jednak nie mamy gwarancji, e pami zostanie skasowana. Z dokumentacji ukadw
scalonych RAM nie wynika, e dane raz umieszczone w pamici w ogle musz by kasowane.
Oczywicie aden ukad nie zachowuj si w ten sposb, ale z uwanej lektury wynika, e moliwe
jest uzyskanie jedynie pewnego poziomu bezpieczestwa.
Skoncentrowalimy si tutaj na pamici gwnej. To samo rozwizanie zadziaa w pamici
podrcznej, tyle e niemoliwe bdzie kontrolowanie adresu, pod ktrym dane zostan umieszczone. Analogiczne rozwizanie nie dziaa w przypadku rejestrw procesora, ale rejestry uywane s
na tyle intensywnie, e proces przetrzymywania danych prawdopodobnie nigdy nie bdzie ich dotyczy. Z drugiej strony rejestry rozszerzajce, na przykad rejestry zmiennoprzecinkowe czy rejestry typu MMX, uywane s rzadziej, wic mog sprawia pewne problemy.
W sytuacji, kiedy konieczne jest przechowanie duej iloci danych, rozwizanie polegajce
na utrzymywaniu dwch kopii i mnoeniu ich przez nowe acuchy losowe staje si zbyt kosztowne. Lepsze okazuje si wtedy zaszyfrowanie duego bloku danych i zapisanie w pamici tekstu
3
Nazwa pochodzi z poematu Lewisa Carrolla The Hunting of the Snark [15]. W polskiej terminologii:
Bdzio; przekad Stanisawa Baraczaka pt. owy na Snarka przyp. tum.

9.3. ZACHOWYWANIE TAJEMNIC

117

zaszyfrowanego, ktry ewentualnie mgby zosta przez kogo odczytany. Naley jedynie unika
przetrzymywania w pamici kluczy, posugujc si np. technik Boojum. Wicej szczegw czytelnik znajdzie w [24].

9.3.5. Dostp osb postronnych

Przechowywanie poufnych danych ma jeszcze jeden aspekt: dotyczy on innych programw, ktre
dziaajc na tym samym komputerze mog siga do naszych danych. Niektre systemy operacyjne
pozwalaj kilku programom wspuytkowa pami. Istnienie innego programu, bdcego w stanie
odczyta tajne klucze, oznacza powane zagroenie. Czsto stosowane rozwizanie, polegajce na
koniecznoci zainicjowania wspdzielonej pamici przez oba programy, znacznie ogranicza ryzyko.
Inne przypadki obejmuj moliwo automatycznego wspuytkowania pamici w wyniku wspuytkowania biblioteki.
Szczeglnie niebezpieczn klas programw s rodowiska kontrolowanego wykonywania
programw (debugery). Uywane obecnie systemy operacyjne czsto zawieraj opcje przeznaczone
wanie dla debugerw. Rne wersje Windows pozwalaj debugerom przejmowa kontrol nad
ju dziaajcym procesem. Debugery maj bardzo szerokie moliwoci, mog midzy innymi odczytywa pami. System Unix umoliwia wykonanie zrzutu pamici programu (ang. core dump).
Zrzut pamici jest to plik zawierajcy obraz pamici z danymi programu, oczywicie wcznie
z wszystkimi danymi poufnymi.
Inne niebezpieczestwo zagraa ze strony uytkownikw o szczeglnie szerokich uprawnieniach. Nazywa si ich superuytkownikami albo administratorami. Wolno im robi rzeczy niedostpne dla zwykych uytkownikw. W systemie Unix na przykad administrator ma prawo odczyta
dowolny fragment pamici.
Oglnie rzecz biorc, program nie moe skutecznie broni si przed opisanymi typami atakw.
Staranny projekt przyczyni si do wyeliminowania niektrych ze wspomnianych problemw, ale
czsto okazuje si, e mamy raczej ograniczone moliwoci. Tym niemniej wszystkie wymienione
zagroenia naley rozpatrzy w kontekcie konkretnego rodowiska operacyjnego, w ktrym bdzie
pracowa nasz projekt.

9.3.6. Integralno danych

Oprcz koniecznoci utrzymania tajemnic musimy jeszcze pamita o ochronie spjnoci przechowywanych danych. Funkcja MAC zabezpiecza spjno danych podczas transmisji, ale nie rozwizuje problemu modyfikacji danych bezporednio w pamici.
W naszym wywodzie zakadamy, e korzystamy z niezawodnego sprztu. Gdyby byo inaczej,
niewiele daoby si zrobi w kwestii bezpieczestwa. Wobec tego warto powici czas i rodki na
analiz niezawodnoci, cho w zasadzie naley ona do zada systemu operacyjnego. Na pewno warto
sprawdzi, czy nasza maszyna jest wyposaona w pami gwn typu ECC (tzn. z obsug korekcji
bdw)4. W razie wystpienia przekamania w jednym bicie, mechanizm ECC wykryje i skoryguje
bd. Bez ECC kady bd powoduje, e procesor otrzyma bdne dane.
4

Trzeba si upewni, e wszystkie czci skadowe komputera obsuguj pami ECC. Ostrzegamy zwaszcza przed nieznacznie taszymi moduami pamici, ktre nie przechowuj dodatkowych informacji, tylko obliczaj
je na bieco. Ich uycie cakowicie przekrela celowo korzystania z pamici ECC.

118

9. O IMPLEMENTACJI (I)

Czemu jest to a tak wane? Wspczesne komputery przetwarzaj ogromne liczby bitw.
Zamy, e z pami jest bardzo dobra jakociowo i szansa bdnego odczytu z pojedynczego
bitu pamici w cigu sekundy wynosi jedynie 1015. W maszynie wyposaonej w 128 MB, to znaczy w okoo 1012 bitw pamici, bdu mona spodziewa si co 1000 sekund, to znaczy w przyblieniu co 17 minut. Taka ilo bdw jest z naszego punktu widzenia niedopuszczalna. Liczba
bdw zwiksza si wraz ze wzrostem iloci pamici w komputerze, tak wic w maszynie dysponujcej 1 GB pamici sytuacja tylko si pogorszy. W serwerach zwykle montuje si pami ECC,
gdy serwery maj duo pamici i pracuj duej ni stacje robocze. Dobrze byoby jednak utrzyma podobny poziom stabilnoci we wszystkich uywanych komputerach.
Nasze uwagi dotycz oczywicie kwestii sprztowych. Zazwyczaj nie mamy moliwoci
okrelania rodzaju pamici w komputerze, na ktrym nasza aplikacja bdzie uruchamiana.
Czasami zagroenie poufnoci naszych danych zagraa jednoczenie ich integralnoci. Na
przykad za pomoc debugera mona zmodyfikowa stan pamici nalecej do programu. Superuytkownik ma te moliwo bezporedniej modyfikacji pamici. Nie da si zapobiec takiemu
niebezpieczestwu ani mu zaradzi, ale trzeba zdawa sobie z niego spraw.

9.3.7. Co robi
Zachowanie tajemnicy we wspczesnym komputerze nie jest takie proste, jak mogoby si wydawa.
Jest wiele drg, ktrymi tajemnice mog wycieka z systemy. Dla penego bezpieczestwa naleaoby zablokowa je wszystkie. Niestety, stosowane obecnie systemy operacyjne i jzyki programowania nie dostarczaj stosownych narzdzi. Mona i trzeba robi to, co si da, lecz oznacza
to mnstwo pracy cile zwizanej z konkretnym rodowiskiem realizacji.
Opisane problemy powoduj, e bardzo trudno jest stworzy bibliotek funkcji kryptograficznych. Zachowanie tajemnic wymaga czsto modyfikacji gwnego programu aplikacji. Oczywicie
program gwny te zawiera dane, ktre powinny pozosta ukryte; w przeciwnym wypadku biblioteka
kryptograficzna byaby w ogle zbdna. Wracamy do znanego ju stwierdzenia, e zachowanie
bezpieczestwa w systemie jako caoci wymaga zachowania go w kadej czci tego systemu.

9.4. Jako kodu rdowego

Podczas realizacji systemu kryptograficznego warto wiele czasu powici jakoci kodu programu.
Mimo, e nasza ksika ta nie dotyczy bezporednio programowania, powiemy kilka sw na ten
temat, gdy zagadnienia jakoci kodu s zazwyczaj pomijane w ksikach powiconych programowaniu.

9.4.1. Prostota
Zoono jest najwikszym to wrogiem bezpieczestwa. Wobec tego w projektach zwizanych
z bezpieczestwem naley za wszelk cen dy do prostoty. Naley eliminowa wszystkie elementy, ktre nie s absolutnie niezbdne. Trzeba pozby si wszystkich barokowych ozdobnikw,
na og zreszt wykorzystywanych przez bardzo niewielu uytkownikw. Naley z dala omija

9.4. JAKO KODU RDOWEGO

119

projekty zbiorowe, gdy praca w komisji zawsze wymusza dodatkowe opcje w ramach kompromisu.
Tam, gdzie w gr wchodzi bezpieczestwo, prostota jest warunkiem pierwszorzdnym.
Typowym przykadem jest nasz bezpieczny kana. Jego projekt nie zawiera adnych opcji.
Nie pozwala zaszyfrowa nieuwierzytelnionych danych ani uwierzytelni danych niezaszyfrowanych. Wielu uytkownikw byoby zadowolonych z dodatkowych moliwoci, ale zwykle s to osoby
niewiadome konsekwencji takich rozwiza. Wikszo uytkownikw wie zbyt mao o bezpieczestwie, by pozwoli im wybiera odpowiednie opcje zabezpiecze. Najlepszym rozwizaniem
jest rezygnacja z opcji i wymuszanie bezpieczestwa domylnie. Jeli jest to naprawd konieczne,
naley umoliwi tylko jeden wybr: albo bezpieczny, albo niebezpieczny.
Wiele systemw udostpnia cay szereg szyfrw, za uytkownik moe wybra do uytku
szyfr i funkcj uwierzytelniajc. Nawet w sytuacji, ktra teoretycznie dopuszcza taki wybr, zalecamy bezwzgldne eliminowanie podobnych komplikacji. W zamian naley wybra jeden tryb
dziaania dostatecznie bezpieczny do wszystkich moliwych zastosowa. Rnice zoonoci obliczeniowej poszczeglnych trybw szyfrowania s niewielkie, a obecnie kryptografia ju tylko
wyjtkowo bywa wskim gardem przetwarzania. Pozbywajc si opcji nie tylko pozbywamy si
zoonoci, ale jednoczenie uniemoliwiamy uytkownikowi takie skonfigurowanie aplikacji, by
stosowa w niej sabe szyfry. Ostatecznie skoro wybr trybu szyfrowania i autoryzacji jest tak
trudny, e projektant nie podejmuje ostatecznej decyzji, to na jakiej podstawie miaby j podj
uytkownik?

9.4.2. Modularyzacja
Nawet po wyeliminowaniu mnstwa opcji i dodatkowych moliwoci moe si okaza, e uzyskany
system nadal pozostaje do zoony. Zapanowanie nad zoonoci umoliwia technika modularyzacji. Dzieli si w niej system na odrbne moduy, ktre nastpnie bd osobno projektowane,
analizowane i implementowane.
Sama koncepcja modularyzacji z pewnoci nie jest obca Czytelnikowi; w kryptografii po
prostu nabiera wagi waciwe jej zastosowanie. Mwic wczeniej o elementach skadowych systemu kryptograficznego, odnosilimy si do nich jak do moduw. Interfejs moduu powinien by
prosty, powinien te zachowywa si zgodnie z intuicj. Warto przyjrze si interfejsom zaprojektowanych przez siebie moduw. Czsto mona w nich dostrzec waciwoci czy opcje, ktre
su do rozwizania problemw zwizanych z innym moduem. Jeli tylko to moliwe, naley je
odrzuci. Kady modu powinien zajmowa si wycznie sam sob. Z naszego dowiadczenia
wynika, e kiedy modu zaczyna obrasta w dziwne waciwoci, nadchodzi czas na przejrzenie
projektu, gdy prawie zawsze okazuje si, e owe dziwne cechy byy zwizane z jakimi wadami
projektowymi.
Modularyzacja jest tak istotna, poniewa jest jedyn skuteczn metod panowania nad zoonoci. Dana opcja ograniczona do pojedynczego moduu moe by przeanalizowana w kontekcie
tego moduu. Jednak opcja, ktra zmienia zewntrzne zachowanie danego moduu, moe wpywa na
zachowanie innych moduw. W ukadzie 20 moduw, z ktrych kady jest wyposaony w jedn
dwustanow opcj zmieniajc jego dziaanie, moliwych jest ponad milion konfiguracji. Dla penego bezpieczestwa konieczne byoby przeanalizowanie wszystkich tych moliwoci, co jednak
jest niemoliwe.
Jak zauwaylimy, e wiele opcji powstaje z myl o poprawie wydajnoci. Temat ten jest
dobrze znany w inynierii oprogramowania. Wiele systemw jest wyposaonych w tak zwane optymalizacje, ktre jednak okazuj si cakiem bezuyteczne, zmniejszajc wydajno, lub s nieistotne,
gdy optymalizuj te czci systemu, ktre nie s wcale wskimi gardami caoci. W sprawach

120

9. O IMPLEMENTACJI (I)

optymalizacji jestemy bardzo zachowawczy. Zwykle w ogle si ni nie przejmujemy. Tworzymy dokadny projekt, a nastpnie staramy si zapewni, by dao si go zrealizowa w duych
kawakach. Za typowy przykad niech posuy stary BIOS IBM PC. Procedura wywietlajca
znak na ekranie ma tylko jeden parametr wywietlany znak. Procedura spdza wikszo
swojego czasu bezproduktywnie, a samo wstawiane znaku do bufora pamici zajmuje tylko
drobn jego cz. Gdyby interfejs procedury pozwala uy w charakterze parametru acucha
znakw, to moliwe byoby wywietlenie caego acucha w czasie nieznacznie duszym ni
wywietlenie pojedynczego znaku. Wynikiem tak kiepskiego projektu byo bardzo powolne wywietlanie znakw w systemie DOS. Ta sama zasada obowizuje w projektach kryptograficznych. Naley dy do tego, by przetwarzanie odbywao si w moliwie duych porcjach. Pozostanie wtedy jedynie optymalizacja tych czci programu, ktrych wpyw na wydajno caoci
zostanie wykazany jako istotny.

9.4.3. Asercje
Asercje s doskonaym narzdziem do poprawy jakoci programw5.
Podczas implementacji programu kryptograficznego trzeba przyj postaw zawodowego paranoika. aden modu nie ma prawa ufa innym moduom, wszystkich obowizuje sprawdzanie
poprawnoci parametrw, wymuszanie ogranicze wywoywania oraz odmowa wykonywania niebezpiecznych operacji. W wikszoci sytuacji chodzi o bardzo proste asercje. Jeeli specyfikacja
moduu wymaga, by uycie pewnego obiektu byo poprzedzone jego inicjalizacj, to odwoanie do
niezainicjowanego obiektu tego typu powinno spowodowa wygenerowanie bdu asercji. Bdy
zwizane z niespenieniem asercji powinny zawsze prowadzi do przerwania programu i udostpnienia diagnozy bdu.
Jako ogln zasad przyjmujemy, e kada kontrola spjnoci wewntrz programu winna posugiwa si asercjami. Naley wychwytywa tym sposobem tyle bdw, ile tylko si da; dotyczy
to zarwno bdw wasnych, jak i innych programistw. Bd wychwycony przez asercj oznacza
uniknicie dziury w systemie bezpieczestwa.
Niektrzy programici realizuj asercje na etapie budowy oprogramowania, a wyczaj je
przed oddaniem ostatecznej wersji. Kto to wymyli? Co by byo, gdyby pocigi do nuklearnej
elektrowni podjeday zgodnie z pen procedur ochronn, ale przy podjedaniu do samego reaktora wyczay systemy bezpieczestwa. Albo co myle o spadochroniarzu, ktry na kady trening naziemny zabieraby spadochron zapasowy, ale z samolotu skakaby ju bez niego?. Po co
w ogle usuwa sprawdzanie asercji z programw przekazywanych klientowi? Przecie tylko tam
jest ono naprawd potrzebne! Kiedy asercja zawodzi w gotowym kodzie wykonywalnym, mamy
do czynienia z bdem programistycznym. Zignorowanie tego bdu prawdopodobnie doprowadzi
do dalszych bdw, gdy przynajmniej jedno zaoenie dotyczce programu zostao naruszone.
Podawanie nieprawidowych odpowiedzi jest chyba najgorszym moliwym sposobem dziaania
programu. Znacznie lepiej jest poinformowa uytkownika, e wystpi bd programistyczny, wobec czego nie naley bezgranicznie ufa dalszym odpowiedziom systemu. Szczegowe sprawdzanie
bdw zostawimy ju Czytelnikom.

5
Wiemy, e nasze uwagi upodabniaj ksik do niedzielnej szkki programowania, ale przypominamy
je wszystkim programistom, z ktrymi pracujemy.

9.4. JAKO KODU RDOWEGO

121

9.4.4. Przepenienie bufora

Sam fakt, e jestemy zmuszeni umieci w ksice biecy podrozdzia, przynosi wstyd caemu
przemysowi informatycznemu. Problemy zwizane z przepenieniem bufora znane s ju od 40 lat.
Od rwnie dugiego czasu znane s skuteczne sposoby ich unikania. Niektre wczesne jzyki programowania wysokiego poziomu, na przykad Algol 60, cakowicie eliminoway ten problem wprowadzajc obowizkow kontrol zakresu indeksw tablic. Mimo to przepenienie bufora jest przyczyn okoo poowy przypadkw naruszenia bezpieczestwa w Internecie. Bdy tego rodzaju
wci si zdarzaj, gdy nikt nie ma ochoty uywa lepszych narzdzi. Uwaamy, e jest to przejaw
karygodnego lekcewaenia obowizkw, porwnywalnego do postawy producenta samochodw,
ktry robiby zbiorniki na paliwo z woskowanego papieru. Pki wszystko dziaa poprawnie, nikt
oczywicie nie bdzie si czepia, ale naszym zdaniem dyrektor odpowiedzialny za tak praktyk
powinien trafi do wizienia. Z niejasnych powodw dua cz firm informatycznych zachowuje
si tak, jakby nie ponosia odpowiedzialnoci za konsekwencje swoich dziaa (by moe wynika
to std, e prawodawcy umoliwili unikanie odpowiedzialnoci za pomoc takiej konstrukcji
umw licencyjnych, ktra byaby nie do pomylenia w jakiejkolwiek innej dziedzinie przemysu).
Biorc pod uwag, e takie lekcewaenie jest udziaem znakomitej wikszoci uczestnikw rynku
informatycznego, zastanawiamy si czasem, czy dziedzina tak zaawansowana, jak kryptografia,
jest w ogle warta podejmowania wysiku.
Jednak nie jestemy w stanie zmieni wszystkiego. Moemy jedynie doradzi, jak pisa dobre programy kryptograficzne. Naley unika jzykw programowania pozwalajcych na przepenianie buforw. Dokadniej mwic, nie naley uywa C ani C++. Nigdy nie naley wycza kontroli indeksw tablic w kompilatorze jzyka programowania. Zasada jest naprawd
prosta, lecz jej nieprzestrzeganie jest prawdopodobnie przyczyn okoo poowy bdw zwizanych z bezpieczestwem.

9.4.5. Testowanie
Dokadne testowanie jest obowizkowym elementem procesu tworzenia oprogramowania. Testowanie pomaga w znalezieniu bdw w programach, ale nie pozwoli ono znale dziur w systemie
zabezpiecze. Nigdy nie naley myli testowania z analiz bezpieczestwa. Te dwa elementy wzajemnie si uzupeniaj, ale s odrbne.
Istniej dwa rodzaje testw, ktre naleaoby realizowa. Pierwszy obejmuje oglne testy zwizane ze specyfikacj funkcjonaln moduu. W idealnej sytuacji jeden programista implementuje
modu, a drugi realizuje testy. Obaj pracuj na podstawie specyfikacji funkcjonalnej. Kade nieporozumienie midzy nimi wskazuje na konieczno poprawienia specyfikacji. Testy oglne powinny
obejmowa wszystkie moliwoci moduu. Czasami testy s proste; a czasami program testujcy
musi zastpi cae rodowisko. Kod programu testujcego czsto bywa rwnie obszerny, jak sam
kod testowanego moduu, i nie ma na to rady.
Druga grupa testw obejmuje testy wykonywane przez samego programist realizujcego dany
modu. Testy te su do zbadania wszelkich ogranicze danej implementacji. Na przykad dodatkowe testy moduu, ktry uywa wewntrznego bufora o rozmiarze 4 kB, powinny obejmowa traktowanie skrajnych czci bufora, tak by na ich podstawie dao si wychwyci wszelkie bdy zarzdzania tym buforem. Czasem stworzenie odpowiednich testw wymaga znajomoci wewntrznej
budowy moduu.

122

9. O IMPLEMENTACJI (I)

Czsto tworzymy cigi testw sterowane generatorem wartoci losowych. Generator liczb losowych omwimy w rozdziale 10. Uycie takiego generatora znakomicie uatwia przeprowadzenie wielu
testw. Przechowanie wartoci ziarna generatora pozwala powtrzy cay cykl testw, co jest przydatne
przy wykrywaniu i usuwaniu bdw. Szczegy realizacji zale od konkretnego moduu.
W kocu dobrze jest mie program do szybkiego testowania, ktry mona by uruchamia
przy kadym uruchamianiu programu. W swoich ostatnich projektach jeden z autorw, Niels, mia
zaimplementowa AES. Kod inicjalizujcy wykonywa algorytm AES dla kilku przypadkw testowych i sprawdza, czy wyniki s zgodne ze znanymi prawidowymi odpowiedziami. Kade naruszenie poprawnoci kodu implementujcego AES, ktre moe si zdarzy w toku dalszego rozwoju aplikacji, zostanie prawdopodobnie wychwycone przez opisany przed chwil szybki test.

9.5. Ataki bocznym kanaem

Znana jest caa klasa atakw, noszcych nazw atakw bocznym kanaem [49]. Ataki te s moliwe,
kiedy atakujcy dysponuje dodatkowym kanaem informacji o systemie. Np. atakujcy moe dokadnie mierzy czas, jaki zajmuje zaszyfrowanie wiadomoci. Sprztowa implementacja skadnika
kryptograficznego w postaci karty procesorowej pozwala zmierzy, ile energii ta karta zuywa.
Pola magnetyczne, emisja promieniowania podczerwonego, zuycie prdu, czas odpowiedzi, interferencja z innymi kanaami danych wszystkie te dane mog posuy do przeprowadzenia ataku
bocznym kanaem.
Nie powinno zaskakiwa, e tego typu ataki okazuj si najskuteczniejsze w odniesieniu do
systemw, przy ktrych tworzeniu nie uwzgldniono tej klasy atakw. Szczeglnie skuteczna jest
analiza zuycia prdu przez karty procesorowe [57].
Ochrona przed wszystkimi formami atakw bocznym kanaem jest bardzo trudna, o ile w ogle
moliwa, tym niemniej zawsze da si przedsiwzi pewne proste rodki ostronoci. Przed laty
Niels implementowa system zabezpiecze kart procesorowych, w ktrym jedna z zasad projektowych gosia, e cig instrukcji wykonywanych przez procesor zalee moe jedynie od informacji
znanych ju atakujcemu. Ten warunek wyklucza ataki oparte na analizie czasu odpowiedzi, utrudnia
te analiz zuycia prdu, gdy wykonywany cig instrukcji nie ujawnia ju adnych nowych informacji. Warunek w nie opisuje penego rozwizania problemu, poza tym wspczesne techniki analizy
zuycia mocy potrafi bez problemu zama zabezpieczenia kart tworzonych w czasach, o ktrych
jest tu mowa. Tym niemniej rozwizanie, jakie wtedy zaproponowalimy, byo najlepszym z realnie
moliwych. Odpieranie atakw bocznym kanaem zawsze polega na pewnej kombinacji przeciwdziaa z ktrych cz jest zaimplementowana w oprogramowaniu systemu kryptograficznego,
a cz ma realizacj sprztow.
Ochrona przed atakami bocznym kanaem ma wszelkie cechy wycigu szczurw. Staramy si
chroni przed znanymi kanaami bocznymi, lecz kto dostatecznie sprytny znajduje nowy kana.
Wtedy jestemy zmuszeni si cofn i uwzgldni take nowy kana. W praktyce nie jest a tak le,
gdy wikszo atakw bocznym kanaem jest bardzo trudna do przeprowadzenia. Kanay boczne
s realnym zagroeniem dla kart procesorowych, gdy przeciwnik po przechwyceniu takiej karty
moe podda j penej analizie. Jednak w przypadku innych rodzajw komputerw praktyczne
znaczenie maj tylko niektre rodzaje kanaw. Z praktycznego punktu widzenia najwaniejszymi
kanaami bocznymi s: czas reakcji oraz nasuch radiowy (karty procesorowe s szczeglnie podatne na pomiar zuycia prdu).

9.6. WNIOSKI

123

9.6. Wnioski
Mamy nadziej, e lektura biecego rozdziau wyjania, e bezpieczestwo nie zaczyna si ani
nie koczy na projekcie kryptograficznym. Na bezpieczestwo wpywaj istotnie wszystkie aspekty
funkcjonowania caego systemu. Dlatego specjalici bezpieczestwo spotykaj si tak czsto z negatywnymi reakcjami: wszdzie wciubiaj swoje nosy, wszystkich pouczaj, a w kocu odcinaj
mnstwo bardzo przydatnych opcji, twierdzc, jakoby byy one niebezpieczne.
Implementacja systemu kryptograficznego sama w sobie jest sztuk. Najwaniejsza jest jako
kodu programu. Kod niskiej jakoci jest w praktyce najczstszym powodem atakw; z drugiej
strony wyeliminowanie kiepskiego kodu jest stosunkowo atwe. Z naszego dowiadczenia wynika,
e tworzenie porzdnego kodu rdowego wcale nie trwa duej ni tworzenie kodu byle jakiego,
o ile tylko liczy si czas od pocztku projektu do oddania gotowego produktu, a nie do czasu oddania pierwszej, najeonej bdami, wersji. Warto fanatycznie dba o jako tworzonego kodu. Porzdne kodowanie ley jak najbardziej w zasigu moliwoci i trzeba si go nauczy, moliwie jak
najprdzej.
Idealnie byoby przeanalizowa i przebudowa cae rodowisko, w tym stosowany jzyk programowania i system operacyjny, jako najwyszy priorytet przyjmujc bezpieczestwo. Mamy
wielk ochot wzi kiedy udzia w takim projekcie, wic prosimy o kontakt kadego, kto ma do
wydania kilka milionw dolarw na komputer naprawd godny zaufania.