├── .gitattributes ├── .github └── workflows │ └── website.yml ├── .gitignore ├── Cryptanalysis_methods_and_types_of_attacks.tex ├── Information Security.tcp ├── Information Security.tex ├── LICENSE ├── README.md ├── The_minimum_key_lengths.tex ├── _settings.tex ├── appendix ├── aes_math.tex ├── birthdays_paradox.tex ├── chinese_remainder_theorem.tex ├── coincide-index_method.tex ├── euclidean_algorithm.tex ├── groups.tex ├── groups_of_ec_points_over_finite_fields.tex ├── index.tex ├── index_only.tex ├── modular_ariphmetics.tex ├── pic │ ├── Edward Curves.svg │ ├── Edward-curves.png │ ├── Twisted-Edwards-Curve-Example.graphml │ ├── Twisted-Edwards-Curve-Example.ods │ ├── Twisted-Edwards-Curve-Example.pdf │ ├── elliptic-curve-1.eps │ ├── elliptic-curve-1.old.png │ ├── elliptic-curve-1.pdf │ ├── elliptic-curve-1.vsd │ ├── elliptic-curve-2.eps │ ├── elliptic-curve-2.old.png │ ├── elliptic-curve-2.pdf │ ├── elliptic-curve-2.vsd │ ├── elliptic-curve-3.eps │ ├── elliptic-curve-3.old.png │ ├── elliptic-curve-3.pdf │ └── elliptic-curve-3.vsd ├── prime-check-aks.tex ├── prime-check-ferma.tex ├── prime-check-miller-rabin.tex ├── prime-check-miller.tex ├── prime-check-naive.tex ├── prime_numbers_count.tex ├── pseudo-primes.tex ├── pseudo-primes_generation.tex ├── questions-4.tex ├── questions-5.tex ├── questions.tex └── tasks.tex ├── bbs_generator.tex ├── bibliography.bib ├── block-ciphers ├── AES.tex ├── Avalanche_effect.tex ├── DES.tex ├── Feistel_cipher.tex ├── Feistel_cipher_without_s_blocks.tex ├── GOST_28147-89.tex ├── GOST_R_34.12-2015.tex ├── block_ciphers.tex ├── double_and_triple_ciphering.tex ├── feistel_network_reversibility.tex ├── index.tex ├── index_only.tex ├── lucifer.tex ├── modes │ ├── CBC.tex │ ├── CFB.tex │ ├── CTR.tex │ ├── ECB.tex │ ├── GCM.tex │ ├── GOST_MAC.tex │ ├── OFB.tex │ ├── index.tex │ ├── index_only.tex │ └── pic │ │ ├── Block Cipher Modes.graphml │ │ ├── CBC.pdf │ │ ├── CFB.pdf │ │ ├── CTR.pdf │ │ ├── ECB.pdf │ │ ├── GCM.pdf │ │ ├── GOST_MAC.pdf │ │ ├── OFB.pdf │ │ ├── aes-128-ecb-demo.rar │ │ ├── starfish-aes-128-ecb.eps │ │ ├── starfish-aes-128-ecb.pdf │ │ ├── starfish.eps │ │ └── starfish.pdf └── pic │ ├── block-cipher.graphml │ ├── block-cipher.pdf │ ├── des.graphml │ ├── des.pdf │ ├── feistel.graphml │ ├── feistel.pdf │ ├── gost-28147-89.eps │ ├── gost-28147-89.pdf │ ├── gost-28147-89.vsd │ ├── kuznechik-key.graphml │ ├── kuznechik-key.pdf │ ├── kuznechik-keys.graphml │ ├── kuznechik-keys.pdf │ ├── kuznechik-p.graphml │ ├── kuznechik-p.pdf │ ├── kuznechik-s.graphml │ ├── kuznechik-s.pdf │ ├── kuznechik-step.graphml │ ├── kuznechik-step.pdf │ ├── lucifer.graphml │ ├── lucifer.pdf │ ├── p-box-inside.graphml │ ├── p-box-inside.pdf │ ├── s-box-inside.graphml │ ├── s-box-inside.pdf │ ├── sp-network.graphml │ └── sp-network.pdf ├── classification_by_symmetry.tex ├── composite_ciphers.tex ├── crypto-random.tex ├── definitions.tex ├── foreword.tex ├── generators.tex ├── generators_with_multiple_shift_registers.tex ├── generators_with_nonlinear_transformations.tex ├── hash-functions ├── GOST_R_34.11-2012.tex ├── GOST_R_34.11-94.tex ├── MD5.tex ├── blockchain.tex ├── collisions_probability.tex ├── hash-functions_combinations.tex ├── index.tex ├── index_only.tex ├── mac │ ├── hmac.tex │ ├── index.tex │ ├── index_only.tex │ ├── one-time-mac.tex │ ├── pic │ │ ├── UMAC.graphml │ │ └── UMAC.pdf │ ├── umac.tex │ ├── universal-hashing.tex │ └── wcmac.tex ├── merkle-damgard.tex ├── pic │ ├── gost-94-elxlxl.png │ ├── gost-94-encrypt.png │ ├── gost-94-permutation.png │ ├── gost-94-round.graphml │ ├── gost-94.graphml │ ├── gost-94.png │ ├── md5-padding.graphml │ ├── md5-padding.pdf │ ├── md5-round.graphml │ ├── md5-round.png │ ├── merkle-damgard.graphml │ ├── merkle-damgard.png │ ├── stribog-md.graphml │ ├── stribog-md.pdf │ ├── stribog-mp.graphml │ ├── stribog-mp.pdf │ ├── stribog-xspl.graphml │ └── stribog-xspl.pdf └── when_not_to_hash.tex ├── historical-ciphers ├── bigrammnye_substitution_ciphers.tex ├── hills_cipher.tex ├── index.tex ├── index_only.tex ├── monoalphabetic_ciphers.tex ├── polyalphabetic_cipher_cryptanalysis.tex └── vigeneres_cipher.tex ├── history ├── index.tex ├── index_only.tex └── pic │ ├── Aristotle_Altemps_Inv8575.jpg │ ├── EnigmaMachine.jpg │ ├── Leon_Battista_Alberti_1.jpg │ ├── Lorenz-SZ42-2.jpg │ ├── Skytale.png │ └── Trithemiusmoredetail.jpg ├── lfsr.tex ├── linear-congruential-generator.tex ├── majority_generators.tex ├── micalis_generator.tex ├── model_of_the_transmission_system_with_crypto.tex ├── mystyle.xdy ├── perfect_secure_systems.tex ├── permutation_ciphers.tex ├── pic ├── a5-1.eps ├── a5-1.pdf ├── a5-1.vsd ├── generator.png ├── generators.eps ├── generators.pdf ├── gsm-a51-cipher.eps ├── gsm-a51-cipher.pdf ├── gsm-a51-cipher.vsd ├── hamming-exploit.src.rar ├── lfsr-zhegalkin.eps ├── lfsr-zhegalkin.pdf ├── lfsr-zhegalkin.vsd ├── lfsr.graphml ├── lfsr.pdf ├── model-auten.pdf ├── model-cipher.pdf ├── model-simple-with-channel.pdf ├── model-simple.pdf ├── models.graphml ├── shift-register-small.eps ├── shift-register-small.png ├── stream-cipher.graphml ├── stream-cipher.pdf ├── taktovi-impuls.png ├── wep_incaps.eps ├── wep_incaps.old.vsd ├── wep_incaps.pdf ├── wep_incaps.vsd ├── wikilogo-aes-128-ecb.pdf └── wikilogo.pdf ├── protocols ├── _settings.tex ├── asymmetric.tex ├── attacks.tex ├── bb84.tex ├── bb92.tex ├── bloms_scheme.tex ├── classification.tex ├── cryptosystems-protocols.tex ├── dass.tex ├── definitions.tex ├── denning-sacco.tex ├── diffie-hellman.tex ├── el-gamal.tex ├── girault_scheme.tex ├── index.tex ├── index_only.tex ├── key-distribution-schemas.tex ├── lo05.tex ├── mti.tex ├── pic │ ├── key_distribution-networks.graphml │ └── key_distribution-networks.pdf ├── properties.tex ├── quantum.tex ├── sts.tex ├── symmetric │ ├── index.tex │ ├── index_only.tex │ ├── kerberos.tex │ ├── needham-schroeder.tex │ ├── wide-mouth_frog.tex │ └── yahalom.tex ├── three-pass.tex ├── woo-lam.tex └── writing-rules.tex ├── public-key ├── CAs.tex ├── ECIES.tex ├── EdDSA.tex ├── GOST_R_34.10-2001.tex ├── el-gamal.tex ├── elliptic_curve_cryptography.tex ├── index.tex ├── index_only.tex ├── pic │ ├── X509-hierarchy.eps │ ├── X509-hierarchy.pdf │ └── X509-hierarchy.vsd ├── pki_key_length.tex ├── rsa.tex └── x509.tex ├── rc4.tex ├── secret-sharing ├── blackleys.tex ├── brickells.tex ├── index.tex ├── index_only.tex ├── pic │ ├── blakley-2.png │ ├── blakley-3.png │ ├── shamir.odg │ ├── shamir.pdf │ └── shamir.svg ├── shamirs.tex └── xor.tex ├── secure-systems-examples ├── gsm2.tex ├── gsm3.tex ├── index.tex ├── index_only.tex ├── ipsec.tex ├── kerberos.tex ├── pgp.tex ├── pic │ ├── gsm2.eps │ ├── gsm2.pdf │ ├── gsm2.vsd │ ├── gsm3.eps │ ├── gsm3.pdf │ ├── gsm3.vsd │ ├── ipsec-ah-modes.eps │ ├── ipsec-ah-modes.pdf │ ├── ipsec-ah-modes.vsd │ ├── ipsec-ah.eps │ ├── ipsec-ah.pdf │ ├── ipsec-ah.vsd │ ├── ipsec-esp-modes.eps │ ├── ipsec-esp-modes.pdf │ ├── ipsec-esp-modes.vsd │ ├── ipsec-esp.eps │ ├── ipsec-esp.pdf │ ├── ipsec-esp.vsd │ ├── kerberos.eps │ ├── kerberos.pdf │ ├── kerberos.vsd │ ├── pgp.eps │ ├── pgp.pdf │ └── pgp.vsd └── tls.tex ├── software-security ├── index.tex ├── index_only.tex ├── os_access_controls.tex ├── pic │ ├── stack-overflow.eps │ ├── stack-overflow.pdf │ └── stack-overflow.vsd ├── security_models.tex ├── sql-injections.tex ├── stack_overflow.tex └── xss.tex ├── stream-ciphers.tex ├── substitution_ciphers.tex ├── unicity_distance.tex └── user-authentication ├── cookies_auth.tex ├── http_auth.tex ├── index.tex ├── index_only.tex ├── openid.tex ├── os_passwords.tex └── pic ├── openid.eps ├── openid.pdf └── openid.vsd /.gitattributes: -------------------------------------------------------------------------------- 1 | *.eps -crlf 2 | *.jpg -crlf 3 | *.pdf binary -text 4 | *.png -crlf 5 | -------------------------------------------------------------------------------- /.github/workflows/website.yml: -------------------------------------------------------------------------------- 1 | name: WebSite 2 | on: 3 | workflow_dispatch: {} 4 | push: 5 | branches: 6 | - master 7 | 8 | jobs: 9 | build: 10 | runs-on: ubuntu-latest 11 | 12 | steps: 13 | - uses: actions/checkout@v2 14 | - name: Set up JDK 11 15 | uses: actions/setup-java@v2 16 | with: 17 | java-version: '11' 18 | distribution: adopt 19 | - name: Download tex2html with maven 20 | run: mvn org.apache.maven.plugins:maven-dependency-plugin:2.4:get -DremoteRepositories=central::default::https://repo.maven.apache.org/maven2,jitpack::::https://jitpack.io -DgroupId=com.github.vlsergey -DartifactId=tex2html -Dversion=master-SNAPSHOT -Dclassifier=application -Dtransitive=false -Ddest=./tex2html.jar 21 | - name: Make tex2html executable 22 | run: chmod +x ./tex2html.jar 23 | - name: Checkout current branch as docs branch 24 | run: git checkout -b docs 25 | - name: Create docs folder 26 | run: mkdir docs 27 | - name: Run docs 28 | run: ./tex2html.jar --in "./Information Security.tex" --out ./docs --format=WEBSITE 29 | - name: Set git environment (user.name) 30 | run: git config user.name "${{github.actor}}" 31 | - name: Set git environment (user.email) 32 | run: git config user.email "${{github.actor}}@users.noreply.github.com" 33 | - name: Add docs to GIT index 34 | run: git add ./docs/* 35 | - name: Commit docs 36 | run: git commit -m "Generate website" 37 | - name: Update remote docs branch 38 | run: git push origin docs:docs -f 39 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | *.acn 2 | *.acr 3 | *.alg 4 | *.aux 5 | *.bbl 6 | *.blg 7 | *.dvi 8 | *.fdb_latexmk 9 | *.glg 10 | *.glo 11 | *.gls 12 | *.idx 13 | *.ilg 14 | *.ind 15 | *.ist 16 | *.lof 17 | *.log 18 | *.lot 19 | *.maf 20 | *.mtc 21 | *.mtc0 22 | *.nav 23 | *.nlo 24 | *.out 25 | *.pdfsync 26 | *.ps 27 | *.snm 28 | *.synctex.gz 29 | *.toc 30 | *.vrb 31 | *.xdy 32 | *.tdo 33 | *.tps 34 | *.bcf 35 | *.run.xml 36 | Information Security.pdf 37 | index_only.pdf 38 | .project 39 | /.settings/ 40 | -------------------------------------------------------------------------------- /Information Security.tcp: -------------------------------------------------------------------------------- 1 | [FormatInfo] 2 | Type=TeXnicCenterProjectInformation 3 | Version=4 4 | 5 | [ProjectInfo] 6 | MainFile=Information Security.tex 7 | UseBibTeX=1 8 | UseMakeIndex=1 9 | ActiveProfile=LaTeX ⇨ PDF (biber & xindy) 10 | ProjectLanguage=ru 11 | ProjectDialect=RU 12 | 13 | -------------------------------------------------------------------------------- /Information Security.tex: -------------------------------------------------------------------------------- 1 | \input{_settings} 2 | \addbibresource{bibliography.bib} 3 | 4 | \title{Криптографические методы \\ защиты информации \\ \bigskip \normalsize{Учебное пособие}} 5 | \author{Владимиров Сергей Михайлович \\ Габидулин Эрнст Мухамедович \\ Колыбельников Александр Иванович \\ Кшевецкий Александр Сергеевич} 6 | \date{\bigskip \bigskip \bigskip \bigskip \bigskip \today \bigskip \\ \small{черновой вариант третьего издания}} 7 | 8 | \begin{document} 9 | \selectlanguage{russian} 10 | 11 | \maketitle 12 | \setcounter{page}{3} 13 | 14 | \newpage 15 | %\thispagestyle{empty} 16 | \setcounter{tocdepth}{2} 17 | \tableofcontents 18 | %\thispagestyle{empty} 19 | \newpage 20 | 21 | %\lhead[\leftmark]{} 22 | %\rhead[]{\rightmark} 23 | 24 | \input{foreword} 25 | 26 | \subimport*{history/}{index} 27 | 28 | \input{definitions} 29 | 30 | \subimport*{historical-ciphers/}{index} 31 | 32 | \input{perfect_secure_systems} 33 | 34 | \subimport*{block-ciphers/}{index} 35 | 36 | \input{generators} 37 | 38 | \input{stream-ciphers} 39 | 40 | \subimport*{hash-functions/}{index} 41 | 42 | \subimport*{public-key/}{index} 43 | 44 | \subimport*{protocols/}{index} 45 | 46 | \subimport*{secret-sharing/}{index} 47 | 48 | \subimport*{secure-systems-examples/}{index} 49 | 50 | \subimport*{user-authentication/}{index} 51 | 52 | \subimport*{software-security/}{index} 53 | 54 | %\chapter{Послесловие} 55 | %Это должно быть что-то в виде заключения, объяснения, почему именно эти темы выбраны, насколько актуален материал с теоретической и практической точки зрения. 56 | 57 | \subimport*{appendix/}{index} 58 | 59 | \printindex 60 | 61 | \printusedliterature 62 | 63 | \end{document} 64 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/LICENSE -------------------------------------------------------------------------------- /The_minimum_key_lengths.tex: -------------------------------------------------------------------------------- 1 | \section{Минимальные длины ключей} 2 | \selectlanguage{russian} 3 | 4 | Оценим минимальную битовую длину ключа, необходимую для обеспечения криптостойкости, то есть защиты криптосистемы от атаки полным перебором всех возможных секретных ключей. Сделаем такие предположения: 5 | 6 | \begin{itemize} 7 | \item одно ядро процессора выполняет $R = 10^7 \approx 2^{23}$ шифрований и расшифрований в секунду; 8 | \item вычислительная сеть состоит из $n = 10^3 \approx 2^{10}$ узлов; 9 | \item в каждом узле имеется $C = 16 = 2^4$ ядер процессора; 10 | \item нужно обеспечить защиту данных на $Y = 100$ лет, то есть на $S \approx 2^{32}$ с; 11 | \item выполняется закон Мура об удвоении вычислительной производительности на единицу стоимости каждые 2 года, то есть производительность вырастет в $M = 2^{Y/2} \approx 2^{50}$ раз. 12 | \end{itemize} 13 | 14 | Число попыток $N$ при переборе примерно равно 15 | \[ N \approx R \cdot n \cdot C \cdot S \cdot M, \] 16 | \[ N \approx 2^{23} \cdot 2^{10} \cdot 2^{4} \cdot 2^{32} \cdot 2^{50} = 2^{23+10+4+32+50} = 2^{119}. \] 17 | 18 | Следовательно, минимально допустимая длина ключа для защиты от атаки перебором на 100 лет составляет порядка 19 | \[ \log_2 N \approx 119\text{ бит}. \] 20 | 21 | Примером успешной атаки перебором может служить взлом перебором секретных ключей интернет-сетью из 78~000 частных компьютеров, производивших фоновые вычисления по проекту \textsc{DesChal}, предыдущего американского стандарта шифрования DES с 56-битовым секретным ключом в 1997 году. 22 | -------------------------------------------------------------------------------- /appendix/birthdays_paradox.tex: -------------------------------------------------------------------------------- 1 | \section{Парадокс дней рождения}\label{section:birthday-paradox} 2 | \selectlanguage{russian} 3 | 4 | Парадокс дней рождения\index{парадокс дней рождения} связан с контринтуитивным ответом на следующую задачу: какой должен быть минимальный размер группы, чтобы вероятность совпадения дней рождения хотя бы у пары человек из этой группы была больше $1 / 2$? Первый возникающий в голове вариант ответа <<183 человека>> (то есть $\left\lceil 365 / 2 \right\rceil$) является неверным. 5 | 6 | Найдём вероятность $P(n)$ того, что в группе из $n$ человек хотя бы двое имеют дни рождения в один день года. Вероятность того, что $n$ человек ($n < N = 365$) не имеют общего дня рождения, есть 7 | \[ 8 | \bar{P}(n) = 1 \cdot \left( 1 - \frac{1}{N} \right) \cdot \left(1 - \frac{2}{N} \right)\cdot \dots \cdot \left( 1 - \frac{n-1}{N} \right) = \prod\limits_{i=0}^{n-1} \left( 1 - \frac{i}{N} \right). 9 | \] 10 | 11 | Аппроксимируя $1-x \leq \exp({-x})$, находим 12 | \[ \bar{P}(n) \approx \prod\limits_{i=0}^{n-1} \exp\left(-\frac{i}{N}\right) = \exp\left(-\frac{n(n-1)}{2} \cdot \frac{1}{N}\right) \approx \exp\left(-\frac{n^2}{2} \cdot \frac{1}{N}\right). \] 13 | 14 | Вероятность того, что хотя бы 2 человека из $n$ имеют общий день рождения, есть 15 | \[ P(n) = 1 - \bar{P}(n) \approx 1 - \exp\left(-\frac{n^2}{2} \cdot \frac{1}{N}\right). \] 16 | 17 | Кроме того, найдём минимальный размер группы, в которой дни рождения совпадают хотя бы у двоих с вероятностью не менее $1 / 2$. То есть найдём такое число $n_{1/2}$, чтобы выполнялось условие $P(n_{1/2}) \geq \frac{1}{2}$. Подставляя это значение в формулу для вероятности, получим $\frac{1}{2} \geq \exp\left(-\frac{n_{1/2}^2}{2} \cdot \frac{1}{N}\right)$. Следовательно, 18 | \[n_{1/2} \geq \sqrt{2 \ln 2 \cdot N} \approx 1,18 \sqrt{ N } \approx 22,5.\] 19 | В криптографии при оценках стойкости алгоритмов часто опускают коэффициент $\sqrt{2 \ln 2}$, считая ответом на задачу <<округлённое>> значение $\sqrt{ N }$. Например, оценку числа операций хеширования для поиска коллизии идеальной криптографической хеш-функции с размером выхода $k$ бит часто записывают как $2^{k/2}$. 20 | -------------------------------------------------------------------------------- /appendix/index_only.tex: -------------------------------------------------------------------------------- 1 | \input{../_settings} 2 | \addbibresource{../bibliography.bib} 3 | \begin{document} 4 | \selectlanguage{russian} 5 | 6 | \tableofcontents 7 | 8 | \input{index} 9 | 10 | \printusedliterature 11 | 12 | \end{document} 13 | 14 | -------------------------------------------------------------------------------- /appendix/pic/Edward-curves.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/appendix/pic/Edward-curves.png -------------------------------------------------------------------------------- /appendix/pic/Twisted-Edwards-Curve-Example.ods: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/appendix/pic/Twisted-Edwards-Curve-Example.ods -------------------------------------------------------------------------------- /appendix/pic/Twisted-Edwards-Curve-Example.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/appendix/pic/Twisted-Edwards-Curve-Example.pdf -------------------------------------------------------------------------------- /appendix/pic/elliptic-curve-1.old.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/appendix/pic/elliptic-curve-1.old.png -------------------------------------------------------------------------------- /appendix/pic/elliptic-curve-1.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/appendix/pic/elliptic-curve-1.pdf -------------------------------------------------------------------------------- /appendix/pic/elliptic-curve-1.vsd: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/appendix/pic/elliptic-curve-1.vsd -------------------------------------------------------------------------------- /appendix/pic/elliptic-curve-2.old.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/appendix/pic/elliptic-curve-2.old.png -------------------------------------------------------------------------------- /appendix/pic/elliptic-curve-2.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/appendix/pic/elliptic-curve-2.pdf -------------------------------------------------------------------------------- /appendix/pic/elliptic-curve-2.vsd: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/appendix/pic/elliptic-curve-2.vsd -------------------------------------------------------------------------------- /appendix/pic/elliptic-curve-3.old.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/appendix/pic/elliptic-curve-3.old.png -------------------------------------------------------------------------------- /appendix/pic/elliptic-curve-3.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/appendix/pic/elliptic-curve-3.pdf -------------------------------------------------------------------------------- /appendix/pic/elliptic-curve-3.vsd: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/appendix/pic/elliptic-curve-3.vsd -------------------------------------------------------------------------------- /appendix/prime-check-aks.tex: -------------------------------------------------------------------------------- 1 | \subsection{Тест AKS}\label{section-prime-check-aks}\index{тест!AKS} 2 | \selectlanguage{russian} 3 | 4 | \emph{Первый} корректный, детерминированный и полиномиальный алгоритм проверки числа на простоту предложили Агравал, Каял и Саксена (\langen{Manindra Agrawal, Neeraj Kayal, Nitin Saxena}) в 2002 году~\cite{aks:2002}. Тест получил название AKS по фамилиям авторов. Сложность алгоритма для проверки $k$-битового числа равна 5 | \[ O(k^{6}). \] 6 | К сожалению, несмотря на полиномиальность сложности теста, алгоритм очень медленный и не может быть применён для чисел с большой битовой длиной (в сотни, тысячи бит). 7 | 8 | Основой теста является аналог малой теоремы Ферма\index{теорема!Ферма малая} для многочленов. Пусть числа $a$ и $p>1$ взаимно простые. В этом случае $p$ -- простое число тогда и только тогда, когда 9 | \begin{equation} 10 | \label{eq:AKS1} 11 | (x - a)^p = x^p - a \mod p. 12 | \end{equation} 13 | 14 | Действительно, если $p$ -- простое\index{число!простое}, то биномиальные коэффициенты $\binom{p}{i},\ i = 1, \dots, p-1$ в разложении левой части делятся на $p$, то есть~$\binom{p}{i} = 0 \mod p$, а для последнего члена разложения $a^p$ выполняется $a^p = a \mod p$ по малой теореме Ферма\index{теорема!Ферма малая}. Следовательно, равенство верно. 15 | 16 | Пусть число $p$ составное. Представим его в виде $p = A q^r$ с взаимно простыми $A$ и $q$ для некоторого простого $q$. Тогда коэффициент $\binom{p}{q}$ равен 17 | \begin{multline*} 18 | \binom{p}{q} = \frac{(A q^r) (A q^r - 1)(A q^r - 2) \dots (A q^r - q + 1)}{q (q-1)(q-2) \cdots 1} = \\ 19 | = \frac{A q^r}{q} \cdot \frac{A q^r - 1}{q-1} \cdot \frac{A q^r - 2}{q-2} \cdot ~\cdots~ \cdot \frac{A q^r - q + 1}{1}. 20 | \end{multline*} 21 | Первый множитель $A q^r$ в числителе делится на $q$, далее идут \mbox{$q-1$} последовательно убывающих чисел, которые не делятся на $q$. Значит, $\binom{p}{q}$ не делится на $A q^r$,~$\binom{p}{q} \neq 0 \mod p$. Следовательно, 22 | \[ 23 | (x - a)^p \neq x^p - a \mod p. 24 | \] 25 | 26 | Непосредственная проверка равенства \eqref{eq:AKS1} является трудоёмкой из-за необходимости проверить все коэффициенты. Рассмотрим следующую модификацию теста, которая тоже имеет полиномиальную сложность. Пусть для некоторого числа $r \nmid n$ ($r$ не делит $n$) выполняется равенство 27 | \begin{equation} 28 | \label{eq:AKS2} 29 | (x - a)^p = x^p - a \mod (x^r-1, p). 30 | \end{equation} 31 | Другими словами, пусть 32 | \[ (x - a)^p - (x^p - a) = (x^r-1) \cdot f(x) + p \cdot g(x) \] 33 | для некоторых многочленов $f(x)$ и $g(x)$. Тогда, либо $p$ -- простое, либо $p^2 = 1 \mod r$. 34 | 35 | Описание теста AKS приведено в алгоритме~\ref{alg:aks}. 36 | 37 | \begin{algorithm}[!ht] 38 | \caption{Детерминированный полиномиальный тест AKS\label{alg:aks}} 39 | \begin{algorithmic} 40 | \STATE Вход: число $n>1$ для проверки на простоту. 41 | \STATE Выход: \textsc{Составное} или \textsc{Простое}. 42 | \IF{~$n = a^b, ~a, b \in \group{N}, ~ b > 1$, для некоторых $a, b$~} 43 | \STATE \textbf{return} \textsc{Составное}. 44 | \ENDIF 45 | \STATE \textbf{Найти} наименьшее $r \in \group{N}$ с порядком $\ord_n(r) > \log_2^2 n$. Порядок числа $r$ по модулю $n$ определяется как минимальное число $ord_n(r) \in \group{N}$: \\ 46 | \indent ~~~~~~~~~~~~~~~~~~~~~~~~~~~ $r^{\ord_n(r)} = 1 \mod n$. 47 | \IF{~$\gcd(a,n) \neq 1$ для некоторого $a \in \group{N}, ~a < r$~} 48 | \STATE \textbf{return} \textsc{Составное}. 49 | \ENDIF 50 | \FOR{~$a = 1$ ~\textbf{to}~ $2 \sqrt{r} \log_2 n$~} 51 | \IF{~$(x - a)^n ~\neq~ x^n - a \mod (x^r - 1, n)$~} 52 | \STATE \textbf{return} \textsc{Составное}. 53 | \ENDIF 54 | \ENDFOR 55 | \STATE \textbf{return} \textsc{Простое} 56 | \end{algorithmic} 57 | \end{algorithm} 58 | -------------------------------------------------------------------------------- /appendix/prime-check-ferma.tex: -------------------------------------------------------------------------------- 1 | \subsection{Тест Ферма}\label{section-prime-check-ferma}\index{тест!Ферма} 2 | \selectlanguage{russian} 3 | 4 | Многие тесты на простоту основаны на малой теореме Ферма\index{теорема!Ферма малая}~\cite{Vinberg:2008}: если $n$ -- простое число и $a$ -- целое число, не делящееся на $n$, то 5 | \begin{equation}\label{eq:prime-check-ferma} 6 | a^{n-1} \equiv 1 \mod n. 7 | \end{equation} 8 | 9 | Можно сформулировать следующую <<обратную>> теорему. Если для некоторого $a: 1 < a < n$ не выполняется утверждение~\ref{eq:prime-check-ferma}, то число $n$ не является простым. На этой теореме основан следующий алгоритм, который и называется тестом Ферма. 10 | 11 | Будем называть число $a$ \emph{свидетелем простоты числа $n$ по Ферма}, если для него выполняется~\ref{eq:prime-check-ferma}. 12 | 13 | Тест Ферма для числа $n$ состоит в том, чтобы проверить, что все числа от $2$ до $n$ являются свидетелями простоты числа $n$ по Ферма. С точки зрения производительности, тест Ферма хуже <<наивного>> теста. 14 | 15 | Вероятность встретить <<свидетеля непростоты>> аналогична <<наивному>> тесту в худшем случае (для чисел $n$, являющихся числами Кармайкла\index{число!Кармайкла}), а скорость проверки одного свидетеля много меньше, чем у <<наивного>> теста. 16 | -------------------------------------------------------------------------------- /appendix/prime-check-naive.tex: -------------------------------------------------------------------------------- 1 | \subsection{<<Наивный>> тест}\label{section-prime-check-naive} 2 | \selectlanguage{russian} 3 | 4 | <<Наивный>> тест состоит в проверке того, что число $n$ не делится на числа от $2$ до $\sqrt{n}$. Из определения простоты\index{число!простое} числа следует, что алгоритм будет являться корректным. Также очевидно, что алгоритм будет являться неполиномиальным относительно битовой длины числа $n$. Однако на нём можно удачно проиллюстрировать определение <<свидетеля простоты>>, которое будет использоваться в алгоритмах в дальнейшем. 5 | 6 | Будем называть число $a$ \emph{свидетелем простоты числа $n$ по наивному алгоритму}, если выполняется условие 7 | \[ 8 | n / a \notin \group{Z}. 9 | \] 10 | 11 | Теперь детерминированный <<наивный>> алгоритм можно сформулировать следующим образом: если все числа $a$ от 2 до $\sqrt{n}$ являются свидетелями простоты числа $n$ по наивному алгоритму, то число $n$ является простым\index{число!простое}. Иначе -- составным\index{число!составное}. 12 | 13 | Детерминированный <<наивный>> тест можно превратить в вероятностный. 14 | 15 | \begin{enumerate} 16 | \item Выберем случайным образом $k$ различных $a_1, a_2, \dots, a_k$ от 2 до $\sqrt{n}$. 17 | \item Проверим, являются ли они все свидетелями простоты числа $n$ по наивному алгоритму. 18 | \item Если являются, то будем утверждать, что число $n$ является псевдопростым\index{число!псевдопростое} с вероятностью ошибки $\epsilon < \left( 1 - 1 / \sqrt{n} \right)^k$, иначе -- составным\index{число!составное}\footnote{Вероятность ошибки получена из вероятности <<наткнуться>> на \emph{несвидетеля простоты числа $n$ по наивному алгоритму}, которая для чисел от 2 до $\sqrt{n}$ не менее $1 / \sqrt{n}$ (минимальная вероятность для случая, когда $n = p \times q$, $p < \sqrt{n} < q$).}. 19 | \end{enumerate} 20 | 21 | Так как проверку каждого <<свидетеля>> можно сделать за одну операцию деления (полиномиальное число операций относительно длины числа $n$), то для заданного числа проверок $k$ данный вариант алгоритма будет являться доказанным, полиномиальным, но вероятностным. Кроме того, вероятность ошибки $\epsilon$ слишком велика. Для того чтобы вероятность ошибки составляла менее 99\%, число проверок $k$ должно быть сравнимо по величине с $\sqrt{n}$. 22 | -------------------------------------------------------------------------------- /appendix/prime_numbers_count.tex: -------------------------------------------------------------------------------- 1 | 2 | \subsection{Оценка числа простых чисел} 3 | \selectlanguage{russian} 4 | 5 | Функция $\pi(n)$ определяется как количество простых\index{число!простое} чисел из диапазона $[2, n]$. 6 | Существует предел~\cite{Hadamard:1896, ValleePoussin:1896} 7 | \[ \lim\limits_{n \rightarrow \infty}\frac{ \pi(n)}{ \frac{n}{\ln n}}=1. \] 8 | 9 | Для $n \geq 17$ верно неравенство $\pi(n) > \frac{n}{\ln n}$. 10 | 11 | Идея поиска(генерации) простых чисел состоит в случайном выборе числа и тестировании его на простоту. 12 | 13 | Вероятность $P_k$ того, что случайное $k$-битовое число $n$ будет простым, равна 14 | \[ \lim\limits_{k \rightarrow \infty} P_k = \frac{1}{\ln n} = \frac{1}{k \ln 2}. \] 15 | 16 | \example 17 | Вероятность того, что случайное 500-битное число, включая чётные числа, будет простым, примерно равна $\frac{1}{347}$, вероятность простоты случайного 2000-битного числа примерно равна $\frac{1}{1386}$. 18 | \exampleend 19 | 20 | Для дальнейшего рассмотрения интересен также вопрос об оценке вероятности того, что число $n$ будет простым, если оно априори взаимно простое с первыми $L$ простыми числами. 21 | 22 | Пусть 23 | \[ \Delta_L = 2 \cdot 3 \cdot 5 \cdot ~\cdots~ \cdot p_L = \prod \limits_{p \leq p_L} p \] 24 | -- произведение первых $L$ простых чисел. Из теоремы о распределении простых чисел\index{теорема!о распределении простых чисел} следует: 25 | \[ L \approx \frac{p_L}{\ln p_L}, ~~ p_L \approx L \ln L. \] 26 | %TODO Что то из Чебышева 27 | 28 | Вероятность того, что случайное \emph{нечётное} число не будет иметь общих делителей с первыми $L$ простыми числами, равна 29 | \[ P(L) = \prod \limits_{3 \leq p \leq p_L} \left( 1 - \frac{1}{p} \right). \] 30 | Используя приближение $1-x \leq e^{-x}$, получаем: 31 | \[ P(L) ~\lesssim~ \operatorname{exp}\left(-\sum\limits_{3 \leq p \leq p_L} \frac{1}{p}\right) = \operatorname{exp}\left(\frac{1}{2} - \sum\limits_{p \leq p_L} \frac{1}{p}\right). \] 32 | Существует предел 33 | \[ \lim \limits_{n \rightarrow \infty} \left( \sum \limits_{p \leq n} \frac{1}{p} - \ln \ln n \right) = M, \] 34 | называемый константой Мейсселя~---~Мертенса:\index{константа!Мейсселя~---~Мертенса} 35 | \[ M \approx 0.261497. \] 36 | Упрощая уравнение, получаем: 37 | \[ P(L) \approx e^{\frac{1}{2} - \ln \ln p_L - M} = \frac{e^{\frac{1}{2} - M}}{\ln(L \ln L)}. \] 38 | 39 | -------------------------------------------------------------------------------- /appendix/pseudo-primes.tex: -------------------------------------------------------------------------------- 1 | \section{Псевдопростые числа}\index{число!псевдопростое} 2 | \selectlanguage{russian} 3 | 4 | \input{prime_numbers_count} 5 | 6 | \input{pseudo-primes_generation} 7 | 8 | \input{prime-check-naive} 9 | 10 | \input{prime-check-ferma} 11 | 12 | \input{prime-check-miller} 13 | 14 | \input{prime-check-miller-rabin} 15 | 16 | \input{prime-check-aks} 17 | -------------------------------------------------------------------------------- /appendix/questions-5.tex: -------------------------------------------------------------------------------- 1 | \section{Курс <<Криптографические протоколы>>} 2 | \selectlanguage{russian} 3 | 4 | Список вопросов по курсу <<Криптографические протоколы>> кафедры защиты информации МФТИ для 5-го курса. 5 | 6 | \begin{enumerate} 7 | \item Криптографические протоколы. Определения, способы записи, классификация. 8 | \item Свойства безопасности криптографических протоколов в терминах проекта AVISPA. С примерами реализации свойств, относящихся к распределению ключей. 9 | \item Атаки на криптографические протоколы. С примерами. 10 | 11 | \item Протокол Wide-Mouth Frog. Описание, плюсы и минусы, возможные атаки, известные модификации. 12 | \item Протокол Yahalom. Описание, плюсы и минусы, возможные атаки, известные модификации. 13 | \item Симметричный вариант протокола Нидхема~---~Шрёдера. Описание, плюсы и минусы, возможные атаки, известные модификации. 14 | \item Симметричный вариант протокола Kerberos (математический). Описание, плюсы и минусы, возможные атаки, известные модификации. 15 | \item Трёхпроходные протоколы. Бесключевой протокол Шамира. Описание, плюсы и минусы, возможные атаки. 16 | \item Протокол Диффи~---~Хеллмана. Описание, плюсы и минусы, возможные атаки, известные модификации. 17 | \item Протокол Эль-Гамаля. Описание, плюсы и минусы, возможные атаки, известные модификации. 18 | \item Протокол MTI/A(0). Описание, плюсы и минусы, возможные атаки, известные модификации. 19 | \item Протокол Station-to-Station. Описание, плюсы и минусы, возможные атаки, известные модификации. 20 | \item Схема Жиро. Описание, плюсы и минусы, возможные атаки, известные модификации. 21 | \item Схема Блома. Описание, плюсы и минусы, возможные атаки, известные модификации. 22 | \item Протокол Деннинг~---~Сакко. Описание, плюсы и минусы, возможные атаки, известные модификации. 23 | \item Протокол DASS. Описание, плюсы и минусы, возможные атаки, известные модификации. 24 | \item Протокол Ву~---~Лама. Описание, плюсы и минусы, возможные атаки, известные модификации. 25 | \item Протокол BB84. Описание, плюсы и минусы, возможные атаки, известные модификации. 26 | \item Протокол B92 / BB92. Описание, плюсы и минусы, возможные атаки, известные модификации. 27 | 28 | \item База данных на основе Echo-сети. Blockchain. Доказательство работы (proof-of-work, proof-of-share). BitCoin. 29 | \item Аутентификация в WEB. Basic, Digest, form- и cookie-ау\-тен\-ти\-фи\-ка\-ция, местоположение аутентификационных данных в HTTP-сообщении (path, headers, body). Использование HTTPS для аутентификации клиента. 30 | \item Аутентификация в WEB. Протокол OAuth 2.0. Использование JWT. 31 | 32 | \end{enumerate} 33 | -------------------------------------------------------------------------------- /appendix/questions.tex: -------------------------------------------------------------------------------- 1 | \chapter{Экзаменационные вопросы} 2 | \selectlanguage{russian} 3 | 4 | \input{questions-4} 5 | 6 | \input{questions-5} 7 | 8 | -------------------------------------------------------------------------------- /bbs_generator.tex: -------------------------------------------------------------------------------- 1 | \subsection{Генератор BBS} 2 | \selectlanguage{russian} 3 | 4 | Имеются примеры <<хороших>> генераторов, вырабатывающих криптографически стойкие последовательности, например генератор Blum-Blum-Shub (BBS). Алгоритм работы состоит в следующем: выбирают большие (длиной не менее 512 бит) простые числа\index{число!простое} $p, q$, которые при делении на $4$ дают в остатке $3$. Вычисляют $n = p q$, с помощью генератора случайных чисел вырабатывают число $x_{0}$, где $1 \leq x_0 \leq n-1$ и $\gcd(x_0, n) = 1$. Далее проводят следующие вычисления: 5 | \[ \begin{array}{l} 6 | x_{1} = x_{0}^{2} \mod n,\\ 7 | x_{2} = x_{1}^{2} \mod n,\\ 8 | \dots,\\ 9 | x_{N} = x_{N-1}^{2} \mod n. 10 | \end{array} \] 11 | 12 | Для каждого вычисленного значения оставляют один младший разряд. Вычисляют двоичную псевдослучайную последовательность $k_1, k_2, k_3, \dots$ : 13 | \[ \begin{array}{l} 14 | k_{1} = x_{1} \mod 2,\\ 15 | k_{2} = x_{2} \mod 2,\\ 16 | \dots,\\ 17 | k_{N} = x_{N} \mod 2. 18 | \end{array} \] 19 | 20 | Число $a$ называется \emph{квадратичным вычетом} по модулю $n$, если для него существует квадратный корень $b$ (или два корня): $a = b^2 \mod n$. Для $p,q ~=~ 3 \mod 4$ верно утверждение, что квадратичный вычет имеет единственный корень, и операция $x \rightarrow x^2 \mod n$, применённая к элементам множества всех квадратичных вычетов $\set{QR}_n$ по модулю $n$, является перестановкой множества $\set{QR}_n$. 21 | 22 | Полученная последовательность $x_1, x_2, x_3, \dots$ квадратичных вычетов -- периодическая ($T < |\set{QR}_n|$). Чтобы её период для случайного $x_0$ с большой вероятностью оказался большим, числа $p,q$ выбирают с условием малого $\gcd(\varphi(p-1), \varphi(q-1))$, где $\varphi(n)$ -- функция Эйлера. 23 | 24 | Полученная последовательность ключей является криптографически стойкой. Доказано, что для <<взлома>> (то есть определения следующего символа с вероятностью, большей $\frac{1}{2}$) требуется разложить число $n=pq$ на множители. Разложение числа на множители считается трудной задачей, все известные алгоритмы не являются полиномиальными по $\log_2 n$. 25 | 26 | Оказывается, что если вместо одного последнего бита $k_i = x_i \mod 2$ брать $O(\log_2 \log_2 n)$ последних битов рассмотренного выше генератора $x_i$, то полученная последовательность останется криптостойкой. 27 | 28 | Большим недостатком генератора BBS является малая скорость генерирования битов. 29 | -------------------------------------------------------------------------------- /block-ciphers/DES.tex: -------------------------------------------------------------------------------- 1 | \section{Шифр DES}\index{шифр!DES|(} 2 | \selectlanguage{russian} 3 | 4 | Развитием проекта <<Люцифер>>\index{шифр!Люцифер} стал государственный стандарт США, известный как DES (\langen{data encryption standard}). Это первый из рассматриваемых нами блочных шифров, который имеет ярко выраженные раунды шифрования, отдельно выделенную функцию ключевого расписания и основан на классической ячейке Фейстеля\index{ячейка Фейстеля}. Поэтому для знакомства с шифром достаточно рассмотреть устройство функции Фейстеля\index{функция!Фейстеля} как основного элемента, отличающего данный шифр от аналогичных. 5 | 6 | В шифре DES открытый текст делится на блоки по 32 бита, и они обрабатываются в 16 раундах. Раундовые ключи генерируются из исходных 64 бит ключа (при этом значащими являются только 56 бит, а последние 8 бит используются для проверки корректности ввода ключа). На вход функции Фейстеля для шифра DES, схема которой приведена на рис.~\ref{fig:des}, подаётся половина от размера входного блока -- 32 бита. 7 | 8 | \begin{figure}[!htb] 9 | \centering 10 | \includegraphics[width=0.75\textwidth]{pic/des} 11 | \caption{Функция Фейстеля\index{функция!Фейстеля} шифра DES\label{fig:des}} 12 | \end{figure} 13 | 14 | Эти 32 бита проходят через функцию расширения, которая с помощью дублирования отдельных битов превращает их в 48 бит. Они суммируются побитово по модулю 2 с раундовым ключом. Результат подаётся на вход 8 s-блоков, которые работают как таблицы замен последовательности из 6 бит в 4 бита (каждый блок). На выходе s-блоков получаются $8 \times 4 = 32$ бита, которые попадают в p-блок перестановки. Результат работы p-блока является результатом функции Фейстеля\index{функция!Фейстеля} для одного раунда шифра DES. 15 | 16 | Интересно отметить, что изначально автором предполагалось использовать ключ в 128 бит, но под напором АНБ (Агентство национальной безопасности, \langen{National Security Agency, NSA}) он был сокращён до 56 бит, что на тот момент составляло вполне достаточную для криптостойкости величину. Кроме того, АНБ указало обязательные к использованию s-блоки (таблицы замен). Много позже, в 90-х годах, когда были разработаны методы линейного и дифференциального криптоанализа, выяснилось, что предложенные АНБ в 70-х годах s-блоки устойчивы к данным методам криптоанализа, как будто специально делались с учётом возможности их использования. 17 | 18 | \index{шифр!DES|)} 19 | -------------------------------------------------------------------------------- /block-ciphers/Feistel_cipher.tex: -------------------------------------------------------------------------------- 1 | \section{Ячейка Фейстеля}\index{ячейка Фейстеля|(} 2 | \selectlanguage{russian} 3 | 4 | Следующей идеей, продвинувшей развитие блочных шифров и приведшей к появлению государственного стандарта DES\index{шифр!DES}, стала конструкция, получившая название \emph{ячейка Фейстеля}. Данная конструкция приведена на рис.~\ref{fig:Feistel}. 5 | 6 | \begin{figure}[!htb] 7 | \centering 8 | \includegraphics[width=0.6\textwidth]{pic/feistel} 9 | \caption{Ячейка Фейстеля\label{fig:Feistel}} 10 | \end{figure} 11 | 12 | На рис.~\ref{fig:Feistel} изображён один раунд шифрования блочного шифра, использующего оригинальную ячейку Фейстеля. Каждый раунд шифрования принимает на вход блок с чётным количеством бит и делит его на две равные части $L_k$ и $R_k$. Входным блоком для первого раунда является блок открытого текста. Правая часть $R_k$ без изменений становится левой частью входного блока $L_{k+1}$ следующего раунда шифрования. Кроме того, правая часть подаётся на вход \emph{функции Фейстеля} $F\left(R_k, K_k \right)$\index{функция!Фейстеля}, аргументами которой являются половина блока данных и раундовый ключ\index{ключ!раундовый} (раундовые ключи получаются в результате работы алгоритма ключевого расписания, как описано в разделе~\ref{section-block-ciphers-intro}). Результат работы функции Фейстеля складывается с помощью побитового сложения по модулю 2 с левой частью входного блока $L_k$. Полученная последовательность бит становится правой частью выходного блока раунда шифрования. Таким образом, работа $k$-го раунда ячейки Фейстеля описывается следующими соотношениями: 13 | \[\begin{array}{l} 14 | L_{k+1} = R_{k}, \\ 15 | R_{k+1} = L_{k} \oplus F\left( R_k, K_k \right). 16 | \end{array}\] 17 | 18 | Результатом шифрования является конкатенация последних выходных блоков $L_n$ и $R_n$, где $n$ -- число раундов шифрования. 19 | 20 | Несложно показать, что зная раундовые ключи $K_1, \dots, K_n$ и результат шифрования $L_n$ и $R_n$, можно восстановить открытый текст. В частности, для каждого раунда: 21 | \[\begin{array}{l} 22 | R_k = L_{k+1}, \\ 23 | L_k = R_{k+1} \oplus F\left( R_k, K_k \right). 24 | \end{array}\] 25 | 26 | Таким образом, ячейка Фейстеля гарантирует корректность работы блочного шифра вне зависимости от сложности функции Фейстеля\index{функция!Фейстеля} $F\left(R_k, K_k \right)$. В результате криптограф (автор шифра) при использовании ячейки Фейстеля не должен беспокоиться об обратимости функции шифрования в целом (конструкция ячейки Фестеля уже гарантирует это), а должен беспокоиться только о достаточной криптографической стойкости функции Фейстеля, необратимость которой не требуется (и даже вредит криптостойкости). Функция Фейстеля обычно состоит из блоков перестановок и замен (то есть из p- и s-блоков, уже рассмотренных ранее). 27 | 28 | \index{ячейка Фейстеля|)} 29 | -------------------------------------------------------------------------------- /block-ciphers/Feistel_cipher_without_s_blocks.tex: -------------------------------------------------------------------------------- 1 | \subsection{Схема Фейстеля без s-блоков} 2 | \selectlanguage{russian} 3 | 4 | Пусть функция $F$ является простой линейной комбинацией некоторых битов правой части и ключа раунда относительно операции XOR. Тогда можно записать систему линейных уравнений битов выхода $y_i$ относительно битов входа $x_i$ и ключа $k_i$ после всех 16 раундов в виде 5 | \[ y_i = \left(\sum_{i=0}^{n_1} a_i x_i\right) \oplus \left(\sum_{i=0}^{n_2} b_i k_i\right), \] 6 | где суммирование производится по модулю 2, коэффициенты $a_i$ и $b_i$ известны и равны 0 или 1, количество битов в блоке открытого текста равно $n_1$, количество битов ключа равно $n_2$. 7 | 8 | Имея открытый текст и шифртекст, легко найти ключ. Без знания открытых текстов, выполняя XOR шифртекстов, можно найти XOR открытых текстов, что может привести к возникновению благоприятных для взлома шифра условий. Во-первых, это может позволить провести атаку на различение сообщений. Во-вторых, в широко распространенных случаях, когда известны форматы сообщений, отдельные поля или распределение символов открытого текста, появляется возможность осуществить атаку перебором с учётом множества уравнений, полученных XOR шифртекстов. 9 | 10 | Для предотвращения подобных атак используются s-блоки замены для создания нелинейности в уравнениях выхода $y_i$ относительно сообщения и ключа. 11 | 12 | 13 | \subsubsection[Схема Фейстеля в ГОСТ 28147-89 без s-блоков]{Схема Фейстеля в~ГОСТ~28147-89 без~s-блоков} 14 | 15 | В отличие от устаревшего алгоритма DES блочный шифр ГОСТ без s-блоков намного сложнее для взлома, так как для него нельзя записать систему линейных уравнений: 16 | \[ 17 | \begin{array}{l} 18 | L_1 = R_0, \\ 19 | R_1 = L_0 \oplus ((R_0 \boxplus K_1) \lll 11), \\ 20 | \end{array} 21 | \] \[ 22 | \begin{array}{l} 23 | L_2 = R_1 = L_0 \oplus ((R_0 \boxplus K_1) \lll 11), \\ 24 | R_2 = L_1 \oplus (R_1 \boxplus K_2) = \\ 25 | ~~~~~= R_0 \oplus (((L_0 \oplus ((R_0 \boxplus K_1) \lll 11)) \boxplus K_2) \lll 11). \\ 26 | \end{array} 27 | \] 28 | 29 | Операция $\boxplus$ нелинейна по XOR. Например, только на трёх операциях $\oplus$, $\boxplus$ и $\lll f(R_i)$ без использования s-блоков построен блочный шифр RC5, который по состоянию на 2010 г. не был взломан. 30 | -------------------------------------------------------------------------------- /block-ciphers/GOST_28147-89.tex: -------------------------------------------------------------------------------- 1 | \section{ГОСТ 28147-89}\index{шифр!ГОСТ 28147-89|(} 2 | \selectlanguage{russian} 3 | 4 | Российский стандарт шифрования, получивший известность как ГОСТ 28147-89 (\cite{GOST-89}), относится к действующим симметричным одноключевым криптографическим алгоритмам. Он зарегистрирован 2 июня 1989 года и введён в действие Постановлением Государственного комитета СССР по стандартам от 02.06.89 \No1409. В настоящий момент шифр известен под названиями <<ГОСТ>> (<>) и <<Магма>>. Последнее название появилось в стандарте ГОСТ Р 34.12-2015~\cite{GOST-R:34.12-2015}, описывающем как данный блочный шифр, так и более новый шифр <<Кузнечик>>, о котором будет рассказано в разделе \ref{section-grig}. 5 | 6 | ГОСТ 28147-89 устанавливает единый алгоритм криптографических преобразований для систем обмена информацией в вычислительных сетях и определяет правила шифрования и расшифрования данных, а также выработки имитовставки\index{имитовставка}. Основные параметры шифра таковы: размер блока составляет 64 бита, число раундов $m=32$, имеется 8 ключей по 32 бита каждый, так что общая длина ключа -- 256 бит. Основа алгоритма -- цепочка ячеек Фейстеля\index{ячейка Фейстеля}. 7 | 8 | \begin{figure}[!ht] 9 | \centering 10 | \includegraphics[width=0.6\textwidth]{pic/gost-28147-89} 11 | \caption{Схема ГОСТ 28147-89\label{fig:gost-28147-89}} 12 | \end{figure} 13 | 14 | Структурная схема алгоритма шифрования представлена на рис.~\ref{fig:gost-28147-89} и включает: 15 | \begin{itemize} 16 | \item ключевое запоминающее устройство (КЗУ) на 256 бит, которое состоит из восьми 32-разрядных накопителей $(X_0, X_1, \dots, X_7)$ и содержит сеансовые ключи шифрования одного раунда; 17 | \item 32-разрядный сумматор $\boxplus$ по модулю $2^{32}$; 18 | \item сумматор $\oplus$ по модулю 2; 19 | \item блок подстановки $(S)$; 20 | \item регистр циклического сдвига на одиннадцать шагов в сторону старшего разряда $(R)$. 21 | \end{itemize} 22 | 23 | Блок подстановки $(S)$ состоит из 8 узлов замены -- s-блоков с памятью на 64 бита каждый. Поступающий на вход блока подстановки 32-разрядный вектор разбивается на 8 последовательных 4-разрядных векторов, каждый из которых преобразуется в 4-разрядный вектор соответствующим узлом замены. Узел замены представляет собой таблицу из 16 строк, содержащих по 4 бита в строке. Входной вектор определяет адрес строки в таблице, заполнение данной строки является выходным вектором. Затем 4-разрядные выходные векторы последовательно объединяются в 32-разрядный вектор. 24 | 25 | При перезаписи информации содержимое $i$-го разряда одного накопителя переписывается в $i$-й разряд другого накопителя. 26 | 27 | Ключ, определяющий заполнение КЗУ, и таблицы блока подстановки $K$ являются секретными элементами. 28 | 29 | Стандарт не накладывает ограничений на степень секретности защищаемой информации. 30 | 31 | ГОСТ 28147-89 удобен как для аппаратной, так и для программной реализаций. 32 | 33 | Алгоритм имеет четыре режима работы: 34 | \begin{itemize} 35 | \item простой замены, 36 | \item гаммирования, 37 | \item гаммирования с обратной связью, 38 | \item выработки имитовставки\index{имитовставка}. 39 | \end{itemize} 40 | 41 | Из них первые три -- режимы шифрования, а последний -- генерирования имитовставки\index{имитовставка} (другие названия: инициализирующий вектор, синхропосылка). Подробно данные режимы описаны в следующем разделе. 42 | 43 | \index{шифр!ГОСТ 28147-89|)} 44 | -------------------------------------------------------------------------------- /block-ciphers/feistel_network_reversibility.tex: -------------------------------------------------------------------------------- 1 | \subsection{Обратимость схемы Фейстеля} 2 | \selectlanguage{russian} 3 | 4 | Покажем, что обратимость схемы Фейстеля не зависит от выбора функции $F$. 5 | 6 | Напомним, что схема Фейстеля -- это итеративное шифрование, в котором выход подаётся на вход следующей итерации по правилу: 7 | \[ \begin{array}{l} 8 | L_i = R_{i-1}, \\ 9 | R_i = L_{i-1} \oplus F(R_{i-1}, K_i), \\ 10 | \end{array} \] 11 | \[ 12 | (L_0,R_0) \rightarrow (L_1,R_1) \rightarrow \ldots \rightarrow (L_n,R_n). 13 | \] 14 | 15 | При расшифровании используется та же схема, только левая и правая части меняются местами перед началом итераций, а ключи раунда подаются в обратном порядке: 16 | \[ R_i = L_{i-1} \oplus F(R_{i-1}, K_{n+1-i}), \] 17 | \[ \begin{array}{l} 18 | L_0^* = R_n = L_{n-1} \oplus F(R_{n-1}, K_n), \\ 19 | R_0^* = L_n = R_{n-1}, \\ 20 | \\ 21 | %\end{array} \] 22 | %\[ \begin{array}{l} 23 | L_1^* = R_{n-1}, \\ 24 | R_1^* = L_{n-1} \oplus F(R_{n-1}, K_n) \oplus F(R_{n-1}, K_n) = L_{n-1}, \\ 25 | \dots. 26 | \end{array} \] 27 | -------------------------------------------------------------------------------- /block-ciphers/index.tex: -------------------------------------------------------------------------------- 1 | \chapter{Блочные шифры}\label{chapter-block-ciphers}\index{шифр!блочный|(} 2 | \selectlanguage{russian} 3 | 4 | \input{block_ciphers} 5 | 6 | \input{lucifer} 7 | 8 | \input{Feistel_cipher} 9 | 10 | \input{DES} 11 | 12 | \input{GOST_28147-89} 13 | 14 | \input{AES} 15 | 16 | \input{GOST_R_34.12-2015} 17 | 18 | \subimport*{modes/}{index} 19 | 20 | \section{Некоторые свойства блочных шифров} 21 | 22 | \input{feistel_network_reversibility} 23 | 24 | \input{Feistel_cipher_without_s_blocks} 25 | 26 | \input{Avalanche_effect} 27 | 28 | \input{double_and_triple_ciphering} 29 | 30 | \index{шифр!блочный|)} 31 | -------------------------------------------------------------------------------- /block-ciphers/index_only.tex: -------------------------------------------------------------------------------- 1 | \input{../_settings} 2 | \addbibresource{../bibliography.bib} 3 | \begin{document} 4 | \selectlanguage{russian} 5 | 6 | \input{index} 7 | 8 | \printusedliterature 9 | 10 | \end{document} 11 | 12 | -------------------------------------------------------------------------------- /block-ciphers/modes/CFB.tex: -------------------------------------------------------------------------------- 1 | \subsection{Обратная связь по шифртексту} 2 | \selectlanguage{russian} 3 | 4 | В режиме обратной связи по шифртексту (\langen{Cipher FeedBack, CFB}, рис.~\ref{fig:CFB}) ключ $K_j$ получается с помощью процедуры шифрования предыдущего шифрованного блока $C_{j-1}$. Может быть использован не весь блок $C_{j-1}$, а только его часть. Как и в предыдущем случае, начальное значение ключа $K_0$ известно криптографу и легальному пользователю: 5 | \[ \begin{array}{l} 6 | K_0 = \textrm{IV}, \\ 7 | K_j = E_K(C_{j-1}), ~ j = 1, 2, \dots, n,\\ 8 | C_j = K_j \oplus M_j. 9 | \end{array} \] 10 | 11 | \begin{figure}[bt] 12 | \centering 13 | \includegraphics[width=1\textwidth]{pic/CFB} 14 | \caption{Режим обратной связи по шифртексту} 15 | \label{fig:CFB} 16 | \end{figure} 17 | 18 | У этого режима нет особых преимуществ по сравнению с другими режимами. 19 | -------------------------------------------------------------------------------- /block-ciphers/modes/CTR.tex: -------------------------------------------------------------------------------- 1 | \subsection{Режим счётчика} 2 | \selectlanguage{russian} 3 | 4 | Режим счётчика (\langen{Counter, CTR}, рис.~\ref{fig:CTR}) был описан Диффи и Хеллманом в 1979 году.~\cite{Diffie:Hellman:1979} Правило шифрования имеет вид, похожий на режим обратной связи по выходу (OFB), но позволяющий вести независимое (параллельное) шифрование и расшифрование блоков: 5 | \[ \begin{array}{l} 6 | K_j = E_K(\textrm{Nonce} ~\|~ j - 1), ~ j = 1, 2, \dots, n, \\ 7 | C_j = M_j \oplus K_j, 8 | \end{array} \] 9 | где $\textrm{Nonce} ~\|~ j - 1$ -- конкатенация битовой строки одноразовой метки $\textrm{Nonce}$ и номера блока, уменьшенного на единицу. 10 | %Для стандарта AES значение $\textrm{Nonce}$ занимает 16 бит, номер блока -- 48 бит. С одним ключом выполняется шифрование $2^{48}$ блоков. 11 | 12 | \begin{figure}[bt] 13 | \centering 14 | \includegraphics[width=1\textwidth]{pic/CTR} 15 | \caption{Режим счётчика. Пунктирной рамкой выделена область формирования \emph{гаммы}, независящей от открытого текста.} 16 | \label{fig:CTR} 17 | \end{figure} 18 | 19 | Правило расшифрования идентичное: 20 | \[ \begin{array}{l} 21 | M_j = C_j \oplus K_j. \\ 22 | \end{array} \] 23 | 24 | Преимущества: 25 | \begin{itemize} 26 | \item относительно простая реализация -- операции шифрования и расшифрования совпадают; 27 | \item нет необходимости дополнять открытый текст до размера, кратного размеру блоку шифрования; 28 | \item возможность полной параллелизации шифрования (можно приступать к шифрованию любого блока в любой момент); 29 | \item ошибка передачи одного бита приводит к ошибке в единственном бите открытого текста. 30 | \end{itemize} 31 | 32 | Недостатки: 33 | \begin{itemize} 34 | \item не обеспечивает целостность. 35 | \end{itemize} 36 | 37 | В отличии от режима OFB период генерируемой <<гаммы>> всегда одинаков и зависит только от количества бит в \emph{nonce}. Так как после достижения максимального значения счётчика значение \emph{nonce} \emph{не} увеличивается на единицу, период <<гаммы>> равен: 38 | \[ 39 | \textrm{period} = \textrm{size}_\textrm{block} \times 2^{ \textrm{size}_\textrm{block} - \textrm{size}_\textrm{nonce} }. 40 | \] 41 | 42 | Данный режим (как и большая часть остальных рассмотренных режимов) обеспечивает только конфиденциальность\index{конфиденциальность} передачи данных, но не целостность\index{целостность}. В модели активного злоумышленника, если последний может предположить о содержимом любой части открытого текста, злоумышленник может поменять отдельные биты шифртекста, что приведёт к предсказуемым (с точки зрения криптоаналитика) изменениям в расшифрованном тексте. -------------------------------------------------------------------------------- /block-ciphers/modes/GCM.tex: -------------------------------------------------------------------------------- 1 | \subsection{Счётчик с аутентификацией Галуа} 2 | \selectlanguage{russian} 3 | 4 | Режим счётчика с аутентификацией Галуа был предложен Девидом МакГрю и Джоном Виега в 2004 году (\langen{Galois/Counter Mode, GCM}, рис.~\ref{fig:GCM}, \cite{McGrew:Viega:2004}). Данный режим обеспечивает одновременно конфиденциальность и целостность, при условии правильного использования. 5 | 6 | \begin{figure}[bt] 7 | \centering 8 | \includegraphics[width=1\textwidth]{pic/GCM} 9 | \caption{Режим счётчика с аутентификацией Галуа. Пунктирной рамкой выделена область формирования \emph{гаммы}, независящей от открытого текста.} 10 | \label{fig:GCM} 11 | \end{figure} 12 | 13 | Результатом работы режима, кроме набора шифроблоков, является тег аутентификации, который должен быть использован принимающей стороной для проверки целостности сообщения. Как и в режиме выработки имитовставки, генерация данного тега возможна только легальным пользователем -- знающим секретный ключ, который был использован для шифрования данных. 14 | 15 | <<Верхняя>> часть режима является режимом работы счётчика. В качестве первого значения берётся дополнение нулями вектора инициализации до размера обрабатываемого блока. Потом, как и в режиме CTR, правая часть увеличивается на 1 для каждого следующего блока. Значения счётчика шифруются на секретном ключе $K$ для получения блоков гаммы. Самый первый блок полученной гаммы используется не для шифрования открытого текста, а для формирования тега аутентификации. 16 | 17 | Сам тег аутентификации вырабатывается следующим образом. На вход <<подрежима>> генерации тега сначала (опционально) подаются дополнительные данные (\langen{additional authenticated data, AAD}), которые не нужно шифровать в режиме GCM, но которым нужно обеспечить целостность. Например, это может быть заголовок передаваемого пакета данных. После того, как эти данные закончатся, на вход начнут подаваться блоки шифротекста $C_1, C_2, \dots, C_n$. Использование блоков шифротекста, а не открытого текста, позволяет получателю проверить целостность передаваемых данных до того, как приступит к расшифровке. В качестве последнего блока выступает конкатенация длин дополнительных данных и открытого текста. 18 | 19 | Формирование тега происходит через побитовое сложение результата предыдущего блока с новым блоком AAD или $C_j$ и умножение результата на константу $H$, которая в двоичном виде равна результату шифрования нулевого вектора (блока, заполненного нулями) на ключе $K$: 20 | 21 | \[ \begin{array}{l} 22 | H = E_K ( 0^{\{n\}} ) \\ 23 | \end{array} \] 24 | 25 | Умножение на константу $H$ происходит в поле Галуа $\GF{2^{n}}$. Рекомендуемый порождающий многочлен поля для шифра AES (с размером блока 128 бит): 26 | 27 | \[ \begin{array}{l} 28 | f(x) = x^{128} + x^7 + x^2 + x + 1. 29 | \end{array} \] 30 | 31 | Результат умножения самого последнего блока побитово складывается с первым блоком сформированной гаммы. 32 | 33 | Данный режим обеспечивает и конфиденциальность, и целостность. Шифровать отдельные блоки можно параллельно, а вычисление тега аутентификации делается намного быстрее, чем шифрование. Однако любая ошибка передачи приведёт к вычислению некорректного тега аутентификации, а отличить изменение текста в результате ошибки передачи от вмешательства злоумышленника принципиально невозможно. -------------------------------------------------------------------------------- /block-ciphers/modes/GOST_MAC.tex: -------------------------------------------------------------------------------- 1 | \subsection{Режим имитовставки}\index{имитовствка!(} 2 | \selectlanguage{russian} 3 | 4 | Режим выработки имитовставки (рис.~\ref{fig:GOST_MAC}, \cite{GOST-89}) принципиально отличается от рассмотренных ранее режимов тем, что призван обеспечивать не конфиденциальность, а целостность. Результатом является блок данных фиксированного размера (в ГОСТ 28147-89 -- до 32 бит), длина которого не зависит от длины исходного сообщения. 5 | 6 | \begin{figure}[bt] 7 | \centering 8 | \includegraphics[width=1\textwidth]{pic/GOST_MAC} 9 | \caption{Режим выработки имитовставки} 10 | \label{fig:GOST_MAC} 11 | \end{figure} 12 | 13 | Входное сообщение как и ранее разбивается на блоки равной длины $M_1, M_2, \dots, M_n$. Последний блок, при необходимости, дополняется (ГОСТ 28147-89 -- нулями). Формула выработки имитовставки выглядит следующим образом: 14 | 15 | \[ \begin{array}{l} 16 | X_1 = M_1; \\ 17 | Y_j = E_K ( X_j ), ~ j = 1, 2, \dots, n; \\ 18 | X_j = Y_{j-1} \oplus M_j, ~ j = 2, \dots, n; \\ 19 | \textbf{MAC} = Y_n. 20 | \end{array} \] 21 | 22 | В ГОСТ 28147-89 для режима выработки имитовставки функция шифрования использует 16 раундов вместо 32. 23 | 24 | Как уже было сказано, данный режим обеспечивает только целостность информации. Причём саму информацию необходимо передавать, и, возможно, шифровать отдельно. Режим не обеспечивает возможности параллельных вычислений для разных блоков открытого текста. 25 | 26 | Принципиальным недостатком является необходимость использовать секретный ключ\index{ключ!секретный} как для выработки имитовставки, так и для её валидации (путём повторной выработки на принимающей стороне и сравнения с результатом). Позже мы рассмотрим функциональных электронных цифровых подписей, которые по своему назначению схожи с имитовставкой, но обеспечивают вариант более гибкого использования -- без необходимости раскрытия ключа, используемого для генерации ЭЦП. 27 | 28 | \index{имитовствка!)} -------------------------------------------------------------------------------- /block-ciphers/modes/index.tex: -------------------------------------------------------------------------------- 1 | \section{Режимы работы блочных шифров}\label{section-block-chaining} 2 | \selectlanguage{russian} 3 | 4 | Перед шифрованием открытый текст $M$ разбивают на части $M_1, M_2, \dots, M_n$, называемые \emph{блоками шифрования}\index{блок!шифрования}. Размер блока зависит от используемого блочного шифра, и, как упоминалось ранее, для шифра <<Магма>>\index{шифр!Магма} он составляет 64 бита, для AES\index{шифр!AES} и шифра <<Кузнечик>>\index{шифр!Кузнечик} -- 128 бит. 5 | \[ M = M_1 || M_2 || \dots || M_i. \] 6 | 7 | Размер открытого текста может быть не кратен размеру блока шифрования. В этом случае для последнего блока применяют процедуру дополнения (удлинения) до стандартного размера. Процедура должна быть обратимой: после расшифрования последнего блока пакета лишние байты необходимо обнаружить и удалить. Некоторые способы дополнения: 8 | \begin{itemize} 9 | \item добавить один байт со значением $128$, а остальные байты принять за нулевые; 10 | \item определить, сколько байтов надо добавить к последнему блоку, например $b$, и добавить $b$ байтов со значением $b$ в каждом. 11 | \end{itemize} 12 | 13 | После шифрования всех блоков открытого текста (блоков шифрования) получается набор блоков шифртекста $C_1, C_2, C_3, \dots, C_n$. Обычно размер этих блоков равен размеру блока шифрования (точно не может быть меньше блока шифрования). Процедура, по которой этот из этого набора блоков получается итоговый шифртекст, называется режимом работы блочного шифра. Некоторые режимы работы могут оперировать не только блоками шифртекста, но и исходными блоками шифрования, номерами блоков и специальными векторами инициализации. 14 | 15 | Существует несколько режимов работы блочных шифров: режим электронной кодовой книги, режим шифрования зацепленных блоков, режим обратной связи, режим шифрованной обратной связи, режим счётчика. Рассмотрим особенности каждого из этих режимов. 16 | 17 | \input{ECB} 18 | 19 | \input{CBC} 20 | 21 | \input{OFB} 22 | 23 | \input{CFB} 24 | 25 | \input{CTR} 26 | 27 | \input{GOST_MAC} 28 | 29 | \input{GCM} 30 | -------------------------------------------------------------------------------- /block-ciphers/modes/index_only.tex: -------------------------------------------------------------------------------- 1 | \input{../../_settings} 2 | \addbibresource{../../bibliography.bib} 3 | \begin{document} 4 | \selectlanguage{russian} 5 | 6 | \input{index} 7 | 8 | \printusedliterature 9 | 10 | \end{document} 11 | 12 | -------------------------------------------------------------------------------- /block-ciphers/modes/pic/CBC.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/block-ciphers/modes/pic/CBC.pdf -------------------------------------------------------------------------------- /block-ciphers/modes/pic/CFB.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/block-ciphers/modes/pic/CFB.pdf -------------------------------------------------------------------------------- /block-ciphers/modes/pic/CTR.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/block-ciphers/modes/pic/CTR.pdf -------------------------------------------------------------------------------- /block-ciphers/modes/pic/ECB.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/block-ciphers/modes/pic/ECB.pdf -------------------------------------------------------------------------------- /block-ciphers/modes/pic/GCM.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/block-ciphers/modes/pic/GCM.pdf -------------------------------------------------------------------------------- /block-ciphers/modes/pic/GOST_MAC.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/block-ciphers/modes/pic/GOST_MAC.pdf -------------------------------------------------------------------------------- /block-ciphers/modes/pic/OFB.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/block-ciphers/modes/pic/OFB.pdf -------------------------------------------------------------------------------- /block-ciphers/modes/pic/aes-128-ecb-demo.rar: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/block-ciphers/modes/pic/aes-128-ecb-demo.rar -------------------------------------------------------------------------------- /block-ciphers/modes/pic/starfish-aes-128-ecb.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/block-ciphers/modes/pic/starfish-aes-128-ecb.pdf -------------------------------------------------------------------------------- /block-ciphers/modes/pic/starfish.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/block-ciphers/modes/pic/starfish.pdf -------------------------------------------------------------------------------- /block-ciphers/pic/block-cipher.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/block-ciphers/pic/block-cipher.pdf -------------------------------------------------------------------------------- /block-ciphers/pic/des.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/block-ciphers/pic/des.pdf -------------------------------------------------------------------------------- /block-ciphers/pic/feistel.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/block-ciphers/pic/feistel.pdf -------------------------------------------------------------------------------- /block-ciphers/pic/gost-28147-89.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/block-ciphers/pic/gost-28147-89.pdf -------------------------------------------------------------------------------- /block-ciphers/pic/gost-28147-89.vsd: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/block-ciphers/pic/gost-28147-89.vsd -------------------------------------------------------------------------------- /block-ciphers/pic/kuznechik-key.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/block-ciphers/pic/kuznechik-key.pdf -------------------------------------------------------------------------------- /block-ciphers/pic/kuznechik-keys.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/block-ciphers/pic/kuznechik-keys.pdf -------------------------------------------------------------------------------- /block-ciphers/pic/kuznechik-p.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/block-ciphers/pic/kuznechik-p.pdf -------------------------------------------------------------------------------- /block-ciphers/pic/kuznechik-s.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/block-ciphers/pic/kuznechik-s.pdf -------------------------------------------------------------------------------- /block-ciphers/pic/kuznechik-step.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/block-ciphers/pic/kuznechik-step.pdf -------------------------------------------------------------------------------- /block-ciphers/pic/lucifer.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/block-ciphers/pic/lucifer.pdf -------------------------------------------------------------------------------- /block-ciphers/pic/p-box-inside.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/block-ciphers/pic/p-box-inside.pdf -------------------------------------------------------------------------------- /block-ciphers/pic/s-box-inside.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/block-ciphers/pic/s-box-inside.pdf -------------------------------------------------------------------------------- /block-ciphers/pic/sp-network.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/block-ciphers/pic/sp-network.pdf -------------------------------------------------------------------------------- /classification_by_symmetry.tex: -------------------------------------------------------------------------------- 1 | \subsection{Симметричные и асимметричные криптосистемы} 2 | \selectlanguage{russian} 3 | 4 | Криптографические системы и шифры можно разделить на две большие группы в зависимости от принципа использования ключей для шифрования и расшифрования. 5 | 6 | Если для шифрования и расшифрования используется один и тот же ключ $K$, либо если получение ключа расшифрования $K_2$ из ключа шифрования $K_1$ является тривиальной операцией, то такая криптосистема называется \emph{симметричной}\index{криптосистема!симметричная}. В зависимости от объёма данных, обрабатываемых за одну операцию шифрования, симметричные шифры делятся на \emph{блочные}\index{шифр!блочный}, в которых за одну операцию шифрования происходит преобразование одного блока данных (32 бита, 64, 128 или больше), и \emph{потоковые}\index{шифр!потоковый}, в которых работают с каждым символом открытого текста по отдельности (например, с 1 битом или 1 байтом). Примеры блочных шифров рассмотрены в главе~\ref{chapter-block-ciphers}, а потоковых -- в главе~\ref{chapter-stream-ciphers}. 7 | 8 | Использование блочного шифра подразумевает разделение открытого текста на блоки одинаковой длины, к каждому из которых применяется функция шифрования. Кроме того, результат шифрования следующего блока может зависеть от предыдущего\footnote{Строго говоря, функция шифрования может применяться не только к самому блоку данных, но и к другим параметрам текущего отрывка открытого текста. Например, к его позиции в тексте (\langen{offset}) или даже к результату шифрования предыдущего блока.}. Данная возможность регулируется \emph{режимом работы блочного шифра}. Примеры нескольких таких режимов рассмотрены в разделе~\ref{section-block-chaining}. 9 | 10 | Если ключ расшифрования получить из ключа шифрования вычислительно сложно, то такие криптосистемы называют криптосистемами \emph{с открытым ключом}\index{криптосистема!с открытым ключом} или \emph{асимметричными} криптосистемами\index{криптосистема!асимметричная}. Некоторые из них рассмотрены в главе~\ref{chapter-public-key}. Все используемые на сегодняшний день асимметричные криптосистемы работают с открытым текстом, составляющим несколько сотен или тысяч бит, поэтому классификация таких систем по объёму обрабатываемых за одну операцию данных не производится. 11 | 12 | Алгоритм, который выполняет отображение аргумента произвольной длины в значение фиксированной длины, называется \emph{хеш-функцией}. Если для такой хеш-функции выполняются определённые свойства, например, устойчивость к поиску коллизий, то это уже \emph{криптографическая хеш-функция}. Такие функции рассмотрены в главе~\ref{chapter-hash-functions}. 13 | 14 | Для проверки аутентичности сообщения с использованием общего секретного ключа отправителем и получателем используется \emph{код аутентификации [сообщения]} (другое название в русскоязычной литературе - \emph{имитовставка}, \langen{message authentication code, MAC}), рассмотренный в разделе~\ref{section-MAC}. Его аналогом в криптосистемах с открытым ключом является \emph{электронная подпись}, алгоритмы генерации и проверки которой рассмотрены в главе~\ref{chapter-public-key} вместе с алгоритмами асимметричного шифрования. 15 | -------------------------------------------------------------------------------- /composite_ciphers.tex: -------------------------------------------------------------------------------- 1 | \subsubsection{Композиционные шифры} 2 | \selectlanguage{russian} 3 | 4 | Почти все современные шифры являются \emph{композиционными}~\cite{AlZKCh:2001}. В них применяются несколько различных методов шифрования к одному и тому же открытому тексту. Другое их название -- \emph{составные шифры}. Впервые понятие <<составные шифры>> было введено в работе Клода Шеннона (\langen{Claude Elwood Shannon},~\cite{Shannon:1949:CTS}). 5 | 6 | В современных криптосистемах шифры замены и перестановок используются многократно, образуя составные (композиционные) шифры. 7 | -------------------------------------------------------------------------------- /crypto-random.tex: -------------------------------------------------------------------------------- 1 | \section[КСГПСЧ]{Криптографически стойкие генераторы псевдослучайных чисел}\label{section-crypto-random}\index{генератор!криптографически-стойкий} 2 | \selectlanguage{russian} 3 | 4 | Итак, просто генератором псевдослучайных чисел мы называем функцию $g$ вида 5 | \[g: \left\{0, 1\right\}^{n} \to \left\{0, 1\right\}^{q\left(n\right)},\] 6 | вычислимую за полиномиальное время, результатом работы которой является последовательность чисел, обладающая свойствами случайной. 7 | 8 | Были рассмотрены два генератора (линейный конгруэнтный генератор в разделе~\ref{section-linear-congruential-generator} и генератор на основе РСЛОС в разделе~\ref{section-lfsr}). Однако они обладают фундаментальными недостатками, которые не дают использовать их в криптографии. Зная определённое число предыдущих значений выхода генератора (и его внутреннее устройство), криптоаналитик имеет возможность предсказать следующие элементы последовательности. Избежать этого можно только увеличением размера внутреннего состояния. 9 | 10 | Пусть $b \left( g \right)$ -- число предыдущих бит, которые необходимо знать криптоаналитику для восстановления внутреннего состояния и параметров генератора (и, следовательно, для предсказания дальнейшей последовательности). И для линейного конгруэнтного генератора\footnote{Для получения параметров \texttt{a} и \texttt{c}.}, и для генератора на основе РСЛОС функция $b (g)$ является линейной функцией от размера внутреннего состояния $size\left( g \right)$ в битах: 11 | \[\begin{array}{l} 12 | b \left( LCG \right) = 3 \cdot size\left( g \right), \\ 13 | b \left( LFSR \right) = 2 \cdot size\left( g \right). \\ 14 | \end{array}\] 15 | 16 | То есть, если мы решим увеличить размер внутреннего состояния для защиты от криптоаналитика, это приведёт не более чем к линейному росту затрат последнего на необходимые вычисления (сравните это с экспоненциальным ростом затрат криптоаналитика при увеличении размера ключа для блочных шифров). Поэтому для использования в криптографии к генераторам псевдослучайных чисел предъявляются дополнительные требования. 17 | 18 | \emph{Криптографически стойким генератором псевдослучайных чисел} будем называть функцию $g$ вида 19 | \[g: \left\{0, 1\right\}^{n} \to \left\{0, 1\right\}^{q\left(n\right)},\] 20 | вычислимую за полиномиальное время, результатом работы которой является последовательность чисел, удовлетворяющая тесту на следующий бит: не должно существовать полиномиального алгоритма, который по $k$ битам последовательности будет предсказывать следующий с вероятностью более $1/2$. 21 | 22 | В 1982 году Эндрю Яо (\langen{Andrew Chi-Chih Yao},~\cite{Yao:1982}) доказал, что любой генератор, проходящий тест на следующий бит, сможет пройти и любые другие статистические полиномиальные тесты на случайность. 23 | 24 | Как и в случае с блочными шифрами, да и с криптографией вообще, под криптографической стойкостью конкретных алгоритмов в 99\% случаев стоит понимать не принципиальное отсутствие, а неизвестность конкретных алгоритмов, которые могут предсказать выход генератора за полиномиальное время. Для тех генераторов, которые считались криптографически стойкими 20 лет назад, сегодня могут уже существовать алгоритмы для предсказания следующего элемента последовательности. 25 | -------------------------------------------------------------------------------- /generators_with_multiple_shift_registers.tex: -------------------------------------------------------------------------------- 1 | \subsection[Генераторы с несколькими регистрами сдвига]{Генераторы с несколькими регистрами \protect\\ сдвига} 2 | \selectlanguage{russian} 3 | 4 | Первый способ улучшения криптографических свойств последовательности состоит в создании композиционных генераторов из нескольких регистров сдвига при определённом способе выбора параметров. Схема такого генератора показана на рис.~\ref{fig:generators}. Здесь $L_i, ~ i = 1, 2, \dots, M$ -- регистры сдвига с линейной обратной связью. Вырабатываемые ими двоичные символы $x_{1,i}, x_{2,i}, \dots, x_{M,i}$ поступают синхронно на устройство преобразования, задаваемое булевой функцией $f(x_{1,i}, x_{2,i}, \dots, x_{M,i})$. В булевой функции и аргументы, и значения функции принимают значения $0$ или $1$. 5 | 6 | Число ячеек в $i$-м регистре равно $L_{i}$, причём $\gcd(L_i, L_j)=1$ для $i \neq j$, где $\gcd$ -- наибольший общий делитель. Общее число ячеек $L = \sum\limits_{i=1}^M L_i$. Булева функция $f$ должна включать слагаемое по одному из входов, то есть $f = \dots + x_i + \dots$, для того чтобы двоичные символы на выходе этой функции были равновероятными. Период этого генератора может достигать величины (немного меньше) 7 | \[ T \simeq 2^L. \] 8 | 9 | \begin{figure}[!ht] 10 | \centering 11 | \includegraphics[width=0.7\textwidth]{pic/generators} 12 | \caption{Генератор с несколькими регистрами сдвига\label{fig:generators}} 13 | \end{figure} 14 | 15 | Таким образом, увеличение числа регистров сдвига с обратной связью увеличивает период последовательности. 16 | 17 | Одним из способов оценки криптостойкости генератора является оценка длины регистра с линейной обратной связью, эквивалентного по порождаемой последовательности. Такой эквивалентный РСЛОС находится с помощью алгоритма Берлекэмпа~---~Мэсси\index{алгоритм!Берлекэмпа~---~Мэсси} декодирования циклических кодов. В лучшем случае длина эквивалентного регистра соизмерима с периодом последовательности, порождённой нелинейным генератором. В общем случае определение эквивалентной длины является сложной задачей. 18 | -------------------------------------------------------------------------------- /generators_with_nonlinear_transformations.tex: -------------------------------------------------------------------------------- 1 | \subsection[Генераторы с нелинейными преобразованиями]{Генераторы с нелинейными \protect\\ преобразованиями} 2 | \selectlanguage{russian} 3 | 4 | Известно, что любая булева функция $f(x_1, x_2, \dots, x_M)$ может быть единственным образом записана многочленом Жегалкина\index{многочлен!Жегалкина}: 5 | \[ \begin{array}{ll} 6 | f(x_1, x_2, \dots, x_M) & = ~c~ \oplus \\ 7 | & \oplus \sum\limits_{1 \leq i \leq M} c_i x_i \oplus \\ 8 | & \oplus \sum\limits_{1 \leq i < j \leq M} c_{i,j} x_i x_j \oplus \\ 9 | & \oplus \sum\limits_{1 \leq i < j < k \leq M} c_{i,j,k} x_i x_j x_k \oplus \\ 10 | & \oplus \dots \oplus \\ 11 | & \oplus ~ c_{1,2,\dots,M} ~ x_1 x_2 \dots x_M. 12 | \end{array} \] 13 | 14 | %Криптографу рекомендуется выбирать булеву функцию с возможно большим числом ненулевых коэффициентов при квадратичных членах полинома Жегалкина. 15 | 16 | Второй способ улучшения криптостойкости последовательности поясняется с помощью рис.~\ref{fig:lfsr-zhegalkin}, на котором представлены регистр сдвига с $M$ ячейками и устройство, осуществляющее преобразование с помощью булевой функции $f(x_1, x_2, \dots, x_M)$, причём функция $f$ содержит нелинейные члены, то есть произведения $x_i x_j \dots$. Тактовый вход здесь такой же, как у регистров, показанных на других рисунках. 17 | 18 | Если функция $f$ нелинейная, то в общем случае неизвестен полиномиальный алгоритм восстановления состояния регистров по нескольким последним выходам генератора. Таким образом, использование нескольких регистров сдвига увеличивает максимально возможный период, по сравнению с одним регистром, до $T < 2^{L_1 + L_2 + \dots + L_M}$, а нелинейность функции $f$ позволяет избежать простого нахождения состояния по выходу. Чтобы улучшить криптостойкость последовательности, порождаемой регистром, рекомендуется брать много нелинейных членов многочлена Жегалкина. 19 | 20 | Такой подход применён в системе GPS. Удачных попыток её взлома до сих пор нет. 21 | 22 | \begin{figure}[!ht] 23 | \centering 24 | \includegraphics[width=0.4\textwidth]{pic/lfsr-zhegalkin} 25 | \caption{Криптографический генератор с нелинейной булевой функцией\label{fig:lfsr-zhegalkin}} 26 | \end{figure} 27 | -------------------------------------------------------------------------------- /hash-functions/collisions_probability.tex: -------------------------------------------------------------------------------- 1 | \subsection{Вероятность коллизии} 2 | \selectlanguage{russian} 3 | 4 | Если $k$-битовая криптографическая хеш-функция имеет равномерное распределение выходных хеш-значений по всем сообщениям, то, согласно парадоксу дней рождения\index{парадокс дней рождения} (см.~\autoref{section:birthday-paradox} в~приложении), среди 5 | \[ n_{1/2} \approx \sqrt{2 \ln 2} \cdot 2^{k/2} \] 6 | случайных сообщений с вероятностью больше $1/2$ найдутся два сообщения с одинаковыми значениями хеш-функций, то есть произойдёт коллизия. 7 | 8 | Криптографические хеш-функции должны быть равномерными по выходу, насколько это можно проверить, чтобы быть устойчивыми к коллизиям. Следовательно, для нахождения коллизии нужно взять группу из примерно $2^{k/2}$ сообщений. 9 | 10 | Например, для нахождения коллизии в 96-битовой хеш-функ\-ции, которая, в частности, используется в имитовставке\index{имитовставка} $\MAC$ в протоколе IPsec\index{протокол!IPsec}, потребуется группа из $2^{48}$ сообщений, 3072 Тбайт памяти для хранения группы и время на $2^{48}$ операций хеширования, что достижимо. 11 | 12 | Если значения хеш-функции имеют неравномерное распределение, то размер группы с коллизией меньше, чем $n_{1/2}$. Если для поиска коллизии достаточно взять группу с размером, много меньшим $n_{1/2}$, то хеш-функция не является устойчивой к коллизиям. 13 | 14 | Например, для 128-битовой функции MD5\index{коллизия}\index{хеш-функция!MD5} в 2005 году Ван Сяоюн и Ю Хунбо (пиньинь \textit{Wáng Xiǎo\-yún} и \textit{Yú Hóng\-bō}) представили атаку для нахождения коллизии за $2^{39} \ll 2^{64}$ операций~\cite{WangYu:2005}. Это означает, что MD5 взломана и более не может считаться надёжной криптографической хеш-функцией. 15 | -------------------------------------------------------------------------------- /hash-functions/hash-functions_combinations.tex: -------------------------------------------------------------------------------- 1 | \subsection{Комбинации хеш-функций} 2 | \selectlanguage{russian} 3 | 4 | Для иллюстрации свойств устойчивости к коллизиям исследуем следующий пример комбинирования двух хеш-функций. Рассмотрим две хеш-функции $f$ и $g$. Известно, что одна из этих функций не противостоит коллизиям, но какая именно -- неизвестно. Тогда имеют место следующие утверждения: 5 | \begin{itemize} 6 | \item Функция $h(x) = f(g(x))$ не устойчива к коллизиям, если $g(x)$ имеет коллизии. 7 | \item Функция $h(x) = f(g(x)) ~\|~ g(f(x))$ не устойчива, например, если $g(x) = \textrm{const}$. 8 | \item Функция $h(x) = f(x) ~\|~ g(x)$ устойчива к коллизиям. 9 | \end{itemize} 10 | -------------------------------------------------------------------------------- /hash-functions/index_only.tex: -------------------------------------------------------------------------------- 1 | \input{../_settings} 2 | \addbibresource{../bibliography.bib} 3 | \begin{document} 4 | \selectlanguage{russian} 5 | 6 | \tableofcontents 7 | 8 | \input{index} 9 | 10 | \printusedliterature 11 | 12 | \end{document} 13 | 14 | -------------------------------------------------------------------------------- /hash-functions/mac/index.tex: -------------------------------------------------------------------------------- 1 | \section{Имитовставка (MAC)}\label{section-MAC} 2 | \selectlanguage{russian} 3 | \index{имитовставка} 4 | 5 | Для обеспечения целостности и подтверждения авторства информации, передаваемой по каналу связи, используют \emph{имитовставку} $\MAC$ (\langen{Message Authentication Code}). 6 | 7 | \begin{displayquote}\begin{sloppypar} 8 | Имитовставка, код аутентичности сообщения (\langen{message authentication code, seal, integrity check value}) — в протоколах аутентификации сообщений с доверяющими друг другу участниками — специальный набор символов, добавляемый к сообщению и предназначенный для обеспечения его целостности и аутентификации источника данных. 9 | \begin{flushright}Словарь криптографических терминов~\cite{Pogorelov:Sachkov:2006} 10 | \end{flushright} 11 | \end{sloppypar}\end{displayquote} 12 | 13 | Далее под имитовставкой мы будем понимать некоторую ключевую функцию (класс функций) $\MAC(K,m)$\[ 14 | \textrm{MAC}: \{0,1\}^{|K|} \times \{0,1\}^* \to \{0,1\}^{|MAC|}, 15 | \] зависящую от передаваемого сообщения $m$ и некоторого ключа $K$ отправителя $A$, обеспечивающую свойства аутентификации сообщения: 16 | \begin{itemize} 17 | \item {[}свойство корректности{]} получатель $B$, используя такой же или другой связанный ключ, имеет возможность проверить целостность\index{целостность} и доказать принадлежность информации участнику, знающему ключ $K$\footnote{В случае использования симметричной криптографии участник $B$ знает секретный ключ $K$ и доказать авторство отправителя $A$ он может только самому себе. При попытке доказать другому участнику оригинальный отправитель $A$ может отрицать авторство сообщения и настаивать, что имитовставку сгенерировал получатель $B$, так как он тоже знает секретный ключ $K$.}; 18 | \item {[}свойство надёжности{]} злоумышленник (криптоаналитик) не может (за обозримое время или же в принципе) сфальсифицировать значение имитовставки, то есть сгенерировать новое сообщение или модифицировать старое таким образом, чтобы получатель $B$ некорректно принял сообщение как от отправителя $A$ с вероятностью, больше заданной. 19 | \end{itemize} 20 | 21 | Имитовставка может быть построена либо на симметричной криптосистеме (в таком случае обе стороны имеют один общий секретный ключ), либо на криптосистеме с открытым ключом, в которой $A$ использует свой секретный ключ, а $B$ -- открытый ключ отправителя $A$. 22 | 23 | \input{hmac} 24 | 25 | \input{universal-hashing} 26 | 27 | \input{one-time-mac} 28 | 29 | \input{wcmac} 30 | 31 | \input{umac} 32 | 33 | -------------------------------------------------------------------------------- /hash-functions/mac/index_only.tex: -------------------------------------------------------------------------------- 1 | \input{../../_settings} 2 | \addbibresource{../../bibliography.bib} 3 | \begin{document} 4 | \selectlanguage{russian} 5 | 6 | \tableofcontents 7 | 8 | \input{index} 9 | 10 | \printusedliterature 11 | 12 | \end{document} 13 | 14 | -------------------------------------------------------------------------------- /hash-functions/mac/one-time-mac.tex: -------------------------------------------------------------------------------- 1 | \subsection{Одноразовая имитовставка}\label{sec:one-time-mac} 2 | \selectlanguage{russian} 3 | Одноразовый MAC (\langen{One-Time MAC}) можно рассматривать как аналог одноразового шифрблокнота для целей аутентификации сообщения. Если использовать один ключ для ровно одного сообщения, можно построить код аутентификации, который гарантированно не может быть подделан злоумышленником. 4 | 5 | Если сообщение короткое, то можно считать ключом два числа $a$ и $b$, а в качестве значения MAC для сообщения $m \in M$ будет выступать 6 | \[ 7 | h(m) = a \times m + b \bmod p. 8 | \] 9 | 10 | Если $p$ -- простое, то вероятность угадать значение MAC для некоторого сообщения $m_2$ (то есть подменить сообщение $m_1$ с одновременной генерацией нового MAC) без знания ключа $k=\overrightarrow{(a,b)}$, равна строго $1/p$. 11 | 12 | Можно воспользоваться описанной ранее функцией хеширования для сообщений переменной длины и использовать чуть более сложную формулу для вычисления MAC: 13 | 14 | \[ \begin{array}{l} 15 | \vec{m} = \left \langle m_1, m_2, \dots, m_l \right \rangle, \\ 16 | h(\vec{m}) = b + \sum_{i=1}^{l} a^i m_i \mod p. \\ 17 | \end{array} \] 18 | 19 | Для этой формулы по прежнему сохраняется свойство, что если ключ $k=\overrightarrow{(a,b)}$ используется ровно один раз, злоумышленник не сможет подделать (угадать) MAC с вероятностью более $1/p$. 20 | -------------------------------------------------------------------------------- /hash-functions/mac/pic/UMAC.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/hash-functions/mac/pic/UMAC.pdf -------------------------------------------------------------------------------- /hash-functions/mac/umac.tex: -------------------------------------------------------------------------------- 1 | \subsection{UMAC}\label{sec:umac} 2 | \selectlanguage{russian} 3 | 4 | Конструкция UMAC, предложенная в 1999 году (\cite{Black:Halevi:Krawczyk:etc:1999}), также использует подход с быстрым универсальным хешированием большого исходного сообщения и хешированием небольшого блока информации надёжной (на 1999 год), но медленной ключевой функцией HMAC-SHA1. В 2003 году вошёл в список алгоритмов, отобранных инициативой NESSIE (\langen{New European Schemes for Signatures, Integrity, and Encryptions}) как безопасный алгоритм вычисления имитовставки. В 2006 году был стандартизован как RFC~4418 (\cite{rfc4418}). На сегодняшний день не считается криптографически стойким из-за уязвимостей, найденных в SHA-1. 5 | 6 | Используемый в UMAC универсальный$_2$ класс хеш-функций $\textrm{NH}_K (m)$ описывается следующим образом. Битовая строка $m$ длиной до 1024 32-битовых <<слов>> и размером, кратная 2 <<словам>>, разбивается на отдельные блоки по 32 бита $m_1, m_2, \dots, m_l$. 32-битные ключи $K_1, K_2, \dots, K_l$ получаются из исходного ключа $K$ с помощью генератора псевдослучайных чисел. Далее вычисление 64-битового хеша выглядит так: \[\begin{array}{ll} 7 | \textrm{NH}_K (m) = & ( m_1 +_{32}K_1) \times_{64} (m_2 +_{32} K_2) +_{64} \dots \\ 8 | & \dots ~ +_{64} ~ \dots \\ 9 | & \dots ~ +_{64} ~ (m_{l-1} +_{32} K_{l-1}) \times_{64} (m_l+_{32}K_l), 10 | \end{array} \] где $+_{32}$ -- сложение 32-битных строк, в результате которого получается 32-битная сумма, $\times_{64}$ -- произведение двух 32-битных строк, и получаемый 64-битный результат умножения (рис.~\ref{fig:UMAC}). 11 | 12 | \begin{figure} 13 | \centering 14 | \includegraphics[width=1\textwidth]{pic/UMAC} 15 | \caption{Универсальное хеширование $\textrm{NH}_K (m)$ в UMAC} 16 | \label{fig:UMAC} 17 | \end{figure} 18 | 19 | Генерация имитовставки делается следующим образом. Предполагается, что вместе с сообщением $m$ передаётся случайная строка \emph{nonce} (должна быть уникальна для каждого сообщения), а у отправителя и получателя есть общий секретный ключ $K$. 20 | 21 | \begin{enumerate} 22 | \item Пусть Len это остаток от деления длины сообщения в битах $|m|$ на 4096:\[ 23 | \textrm{Len} = |m| \bmod 4096. 24 | \] 25 | \item Сообщение $m$ в битовом представлении дополняется нулями таким образом, чтобы длина сообщения $|m|$ была кратна 64 бит (8 байт). 26 | \item Сообщение $m$ разбивается на блоки по 32768 бита (1024 <<слова>> по 32 бита) $m_1, m_2, \dots, m_t$. Последний блок будет содержать от 2 до 1024 <<слов>>. 27 | \item Каждый блок хешируется ключевой хеш-функцией $\textrm{NH}_K$, результаты конкатенируются между собой и $Len$:\[ 28 | H_K(m) = \textrm{NH}_K (m_1) ~ \| ~ \textrm{NH}_K (m_2) ~ \| ~ \dots ~ \| ~ \textrm{NH}_K (m_t) ~ \| ~ \textrm{Len}. 29 | \] 30 | \item Итоговое значение имитовставки получается через хеширование ключевой функцией HMAC-SHA1:\[ 31 | \textrm{UMAC}_K( m, \textrm{nonce} ) = \textrm{HMAC-SHA1}_K( \textrm{nonce} ~ \| ~ H_K(m) ). 32 | \] 33 | \end{enumerate} 34 | -------------------------------------------------------------------------------- /hash-functions/mac/universal-hashing.tex: -------------------------------------------------------------------------------- 1 | \subsection{Универсальное хеширование}\label{sec:universal-hashing} 2 | \selectlanguage{russian} 3 | Наличие одного единственного правила хеширования может привести к тому, что злоумышленник, зная точную формулу вычисления хеша, сможет подобрать такой набор входных данных, который с большой степенью вероятности даёт коллизии обычной (не криптографической) хеш-функции. Кроме того, сами хеш-функции также разрабатываются исходя из определённого предположения о входных данных. Алгоритмы хеширования могут содержать некоторые константы, которые разработчику информационной системы предлагается выбрать самостоятельно, основываясь на его предположениях об особенностях входных данных. Но квалификации разработчика, либо его априорных знаний, может не хватать для эффективного выбора конкретной реализации (алгоритм и параметры) хеширования. Исходя из этого Картер и Вегман в 1979 году (\langen{John Lawrence Carter, Mark N. Wegman}, \cite{Carter:Wegman:1979}) предложили определить класс алгоритмов хеширования с возможностью выбора одного из них непосредственно в момент вызова. 4 | 5 | Обозначим через $\delta$ возможный факт совпадения значения некоторой унарной функции для некоторых значений аргументов: 6 | 7 | \[ 8 | \delta_{f}( x, y ) = \left\{\begin{matrix} 9 | 1, & f(x) = f(y);\\ 10 | 0, & f(x) \neq f(y). 11 | \end{matrix}\right. 12 | \] 13 | 14 | Пусть $H$ -- класс функций, преобразующих $M \to R$. Будем называть класс $H$ универсальным$_{2}$, если 15 | 16 | \[ 17 | \forall x, y \in M: \sum_{h \in H} \delta_{h}( x, y ) \leq |H| / |R|. 18 | \] 19 | 20 | То есть класс функций $H$ универсален$_{2}$, если для любых пар аргументов $x$ и $y$ значения функций совпадают не более чем для $1/|R|$-ой части функций из множества $H$. Нижний индекс <<$_{2}$>> подчёркивает тот факт, что речь идёт о совпадении значений только для пар элементов. В дальнейшем мы его будем опускать. 21 | 22 | Примеры универсальных классов для хеширования:\footnote{Универсальность первых двух примеров была показана ещё в работе Картера и Вегмана~\cite{Carter:Wegman:1979}. Последний описан, например, в~\cite{Dietzfelbinger:Gil:Matias:Pippenger:1992}.} 23 | 24 | \begin{itemize} 25 | \item функции хеширования для чисел $x$ 26 | \[ \begin{array}{l} 27 | h(x) = ax + b \bmod p,\\ 28 | a \in \Z^*_p, b \in \Z_p;\\ 29 | \end{array} \] 30 | \item функции хеширования для векторов $\vec{x}$ 31 | \[ \begin{array}{l} 32 | \vec{x} = \left \langle x_0, x_1, \dots, x_r \right \rangle,\\ 33 | \vec{a} = \left \langle a_0, a_1, \dots, a_r \right \rangle,\\ 34 | \forall i \in \Z_{r+1}: a_i \in \Z_{p},\\ 35 | h( \vec{x} ) = \sum_{i=0}^{r} a_i x_i \bmod p;\\ 36 | \end{array} \] 37 | \item функции хеширования для строк (последовательностей переменной длины) $\vec{x}$ 38 | \[ \begin{array}{l} 39 | \vec{x} = \left \langle x_0, x_1, \dots, x_l \right \rangle,\\ 40 | \forall x_i: x_i \in \Z_{u}, \\ 41 | p \geq u, \\ 42 | a \in \Z_{p}, a \neq 0,\\ 43 | h( \vec{x} ) = \sum_{i=0}^{l} a^{i} x_i \bmod p.\\ 44 | \end{array} \] 45 | \end{itemize} 46 | 47 | На основе универсального хеширования построены такие криптографические примитивы, как UMAC и Poly1305 (RFC 8439). 48 | -------------------------------------------------------------------------------- /hash-functions/mac/wcmac.tex: -------------------------------------------------------------------------------- 1 | \subsection{Конструкция Вегмана-Картера} 2 | \selectlanguage{russian} 3 | 4 | В 1981 году Вегман и Картер предложили (\cite{Wegman:Carter:1981}) использовать универсальное хеширование (раздел~\ref{sec:universal-hashing}) для построение алгоритмов имитовставок. В оригинале авторы предполагали, что каждое сообщение содержит неповторяющийся номер $i$, а секретный ключ между отправителем и получателем состоит из двух частей: 5 | 6 | \begin{itemize} 7 | \item параметра $k_1$, задающего способ выбора функции из универсального класса хеширования $H: K \times A \to B$; 8 | \item параметра $k_2$, который является \emph{последовательностью} строк $b_1, b_2, \dots, b_n$, длина каждой из которых совпадает с размером элементов множества $B$. 9 | \end{itemize} 10 | 11 | Результатом вычисления имитовставки является: 12 | 13 | \[ \begin{array}{l} 14 | m' = \langle i, m \rangle,\\ 15 | \textrm{MAC} (m') = H_{k_1}(m) \oplus b_i. 16 | \end{array} \] 17 | 18 | Авторы показали надёжность данной схемы при условии случайного выбора ключей и универсальности класса хеширования. Однако с практической точки зрения использовать ключи, состоящие из \emph{последовательностей} очень непрактично. Более того, можно было передать столько сообщений, сколько элементов последовательности задано в $k_2$. Для передачи сообщения сверх этого лимита нужно было либо расширить существующий ключ, либо сгенерировать новый. 19 | 20 | По этой причине сейчас вместо использования последовательности строк $b_1, b_2, \dots, b_n$ в качестве ключа предполагается наличие некоторого класса псевдослучайных функций (\langen{pseudorandom function family, PRF}), который эмулирует \emph{случайного оракула}\index{оракул!случайный}. В своей идеализированной модели он для каждого некоторого входа может выдать ответ, случайно распределённой по области значений. Однако если на вход случайного оракула будет подано уже ранее подававшееся значение, он должен выдать прежний ответ. Входом этого оракула являются, во-первых, некоторое случайное число $r$, которое заменило собой номер сообщения, во-вторых часть общего секретного ключа $k_2$, которая будет служить для выбора конкретной функции из класса псевдослучайных. 21 | 22 | В качестве практической реализации такого класса функций могут, с некоторым приближением, выступать другие реализации имитовставок, даже если они медленно работают. Например, основанные на криптографических хеш-функциях или блочных шифрах. Потому что им на вход (в отличие от быстрой функции универсального хеширования) подаётся только небольшой блок информации -- случайное число $r$. 23 | 24 | Таким образом, современную конструкцию Вегмана-Картера можно описать так. Пусть выбран некоторый класс универсальных хеш-функций (например, в качестве него можно использовать одноразовую имитовставку из раздела~\ref{sec:one-time-mac}) \[ 25 | H: \{0,1\}^{|k_1|} \times \{0,1\}^* \to \{0,1\}^n, 26 | \] и некоторая надёжная реализация медленной имитовставки \[ 27 | PRF: \{0,1\}^{|k_2|} \times \{0,1\}^{|r|} \to \{0,1\}^n. 28 | \] 29 | 30 | Тогда получение быстрой имитовставки можно сделать следующим образом 31 | \[ \begin{array}{l} 32 | \textrm{secret key: } k: \langle k_1, k_2 \rangle,\\ 33 | \textrm{random nonce: } r \leftarrow \{0,1\}^n,\\ 34 | \textrm{MAC} (m) = \langle r, H_{k_1}(m) \oplus PRF_{k_2}(r) \rangle. 35 | \end{array} \] 36 | 37 | Как утверждается в~\cite{Krovetz:2000}, использование данной конструкции позволяет достичь скорости хеширования в $0{,}5$ циклов процессора на один байт сообщения (\langen{cycles per byte, cpb}). 38 | -------------------------------------------------------------------------------- /hash-functions/merkle-damgard.tex: -------------------------------------------------------------------------------- 1 | \section{Структура Меркла~---~Дамгора}\label{sec:merkle-damgard}\index{структура!Меркла~---~Дамгора|(} 2 | \selectlanguage{russian} 3 | 4 | Приведём пример метода построения хеш-функции, называемого структурой (конструкцией, методом) Меркла~---~Дамгора (рис.~\ref{fig:merkle-damgard}), впервые описанной в кандидатской диссертации Ральфа Меркла в 1979 году. Меркл и Дамгор независимо друг от друга показали, что если раундовая функция сжатия (обозначенная $f$ на рис.~\ref{fig:merkle-damgard}) устойчива к коллизиям, то итоговая хеш-функция будет также устойчива (\langen{Ralph Charles Merkle}, \langda{Ivan Bjerre Damgård}, \cite{Merkle:1979, Merkle:1990, Damgard:1990}). 5 | 6 | \begin{figure}[htb] 7 | \centering 8 | \includegraphics[width=0.95\textwidth]{pic/merkle-damgard} 9 | \caption{Структура Меркла~---~Дамгора} 10 | \label{fig:merkle-damgard} 11 | \end{figure} 12 | 13 | Пусть есть задан открытый текст $M$ в виде двоичной последовательности некоторой длины. Текст дополняется, во-первых, дополнением (паддингом), во-вторых, длиной исходного сообщения таким образом, чтобы после дополнения обрабатываемая последовательность можно было разбить на целое число блоков фиксированной длины $M_1, M_2, \dots, M_n$. 14 | 15 | Выбирается некоторый начальный вектор IV. Далее последовательно применяется раундовая функция сжатия к двум аргументам, первым из которых является рещультат предыдущего вызова (IV для самого первого), а вторым аргументом -- соответствующий блок $M_i$ обрабатываемой последовательности. 16 | 17 | \[\begin{array}{l} 18 | H_0 = \text{IV},\\ 19 | H_i = f ( H_{i-1}, M_i ).\\ 20 | \end{array}\] 21 | 22 | В зависимости от хеш-функции структура может быть дополнена финальным преобразованием, в котором вторым аргументом будет ещё одна некоторая функция от исходного сообщения. Например, в хеш-функции <<Стрибог>>\index{хеш-функция!Стрибог} таким аргументом является арифметическая функция всех блоков исходного открытого текста. 23 | 24 | К плюсам данной конструкции относят доказанный авторами факт, что если раундовая функция сжатия устойчива к коллизиям, то итоговая хеш-функция будет также устойчива. Однако у конструкции присутствуют и недостатки. 25 | 26 | \begin{itemize} 27 | \item Атака на нахождение второго прообраза (для некоторого известного открытого текста) может быть выполнена за $2^n / | M |$ операций, где $| M |$ -- длина открытого текста. Это меньше, чем требуется операций для полного перебора ($2^n$), особенно для длинных сообщений. 28 | \item Если известен способ нахождения пары коллизий, то множественные коллизии найти незначительно сложнее. 29 | \item В отсуствие финального преобразования при заданном значении хеш-функции $h = H(M)$ (и неизвестном исходном сообщении $M$) можно легко найти значение $H( pad(M) \| M' )$, где $pad(M)$ -- функция дополнения, а $M'$ -- выбранный злоумышленником дополнительный текст к исходному сообщению. 30 | \end{itemize} 31 | 32 | С использованием данной конструкции построены такие криптографические хеш-функции, как MD4\index{хеш-функция!MD4}, SHA-1\index{хеш-функция!SHA-1}, SHA-2\index{хеш-функция!SHA-2}, российский стандарт ГОСТ~Р~34.11-2012 (<<Стрибог>>)\index{хеш-функция!Стрибог} и многие другие. 33 | 34 | \index{структура!Меркла~---~Дамгора|)} -------------------------------------------------------------------------------- /hash-functions/pic/gost-94-elxlxl.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/hash-functions/pic/gost-94-elxlxl.png -------------------------------------------------------------------------------- /hash-functions/pic/gost-94-encrypt.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/hash-functions/pic/gost-94-encrypt.png -------------------------------------------------------------------------------- /hash-functions/pic/gost-94-permutation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/hash-functions/pic/gost-94-permutation.png -------------------------------------------------------------------------------- /hash-functions/pic/gost-94.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/hash-functions/pic/gost-94.png -------------------------------------------------------------------------------- /hash-functions/pic/md5-padding.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/hash-functions/pic/md5-padding.pdf -------------------------------------------------------------------------------- /hash-functions/pic/md5-round.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/hash-functions/pic/md5-round.png -------------------------------------------------------------------------------- /hash-functions/pic/merkle-damgard.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/hash-functions/pic/merkle-damgard.png -------------------------------------------------------------------------------- /hash-functions/pic/stribog-md.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/hash-functions/pic/stribog-md.pdf -------------------------------------------------------------------------------- /hash-functions/pic/stribog-mp.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/hash-functions/pic/stribog-mp.pdf -------------------------------------------------------------------------------- /hash-functions/pic/stribog-xspl.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/hash-functions/pic/stribog-xspl.pdf -------------------------------------------------------------------------------- /historical-ciphers/bigrammnye_substitution_ciphers.tex: -------------------------------------------------------------------------------- 1 | \section{Биграммные шифры замены}\index{шифр!биграммный} 2 | \selectlanguage{russian} 3 | 4 | Если при шифровании преобразуется по две буквы открытого текста, то такой шифр называется \emph{биграммным}\index{шифр!биграммный} шифром замены. Первый биграммный шифр был изобретён аббатом Иоганном Тритемием и опубликован в 1508-м году. Другой биграммный шифр изобретён в 1854 году Чарльзом Витстоном. Лорд Лайон Плейфер (\langen{Lyon Playfair}) внедрил этот шифр в государственных службах Великобритании, и шифр был назван шифром Плейфера\index{шифр!Плейфера}. 5 | 6 | Опишем шифр Плейфера\index{шифр!Плейфера}. Составляется таблица для английского алфавита (буквы \texttt{I}, \texttt{J} отождествляются), в которую заносятся буквы перемешанного алфавита, например, в виде таблицы, представленной ниже. Часто перемешивание алфавита реализуется с помощью начального слова, в котором отбрасываются повторяющиеся символы. В нашем примере начальное слово \texttt{playfair}. Таблица имеет вид: 7 | 8 | \begin{center} 9 | \begin{tabular}{ccccc} 10 | p & l & a & y & f \\ 11 | i & r & b & c & d \\ 12 | e & g & h & k & m \\ 13 | n & o & q & s & t \\ 14 | u & v & w & x & z \\ 15 | \end{tabular} 16 | \end{center} 17 | 18 | Буквы открытого текста разбиваются на пары. Правила шифрования каждой пары состоят в следующем. 19 | 20 | \begin{itemize} 21 | \item Если буквы пары не лежат в одной строке или в одном столбце таблицы, то они заменяются буквами, образующими с исходными буквами вершины прямоугольника. Первой букве пары соответствует буква таблицы, находящаяся в том же столбце. Пара букв открытого текста \texttt{we} заменяется двумя буквами таблицы \texttt{hu}. Пара букв открытого текста \texttt{ew} заменяется двумя буквами таблицы \texttt{uh}. 22 | \item Если буквы пары открытого текста расположены в одной строке таблицы, то каждая буква заменяется соседней справа буквой таблицы. Например, пара \texttt{gk} заменяется двумя буквами \texttt{hm}. Если одна из этих букв -- крайняя правая в таблице, то её <<правым соседом>> считается крайняя левая в этой строке. Так, пара \texttt{to} заменяется буквами \texttt{nq}. 23 | \item Если буквы пары лежат в одном столбце, то каждая буква заменяется соседней буквой снизу. Например, пара \texttt{lo} заменяется парой \texttt{rv}. Если одна из этих букв крайняя нижняя, то её <<нижним соседом>> считается крайняя верхняя буква в этом столбце таблицы. Например, пара \texttt{kx} заменяется буквами \texttt{sy}. 24 | \item Если буквы в паре одинаковые, то между ними вставляется определённая буква, называемая <<буквой-пустышкой>>. После этого разбиение на пары производится заново. 25 | \end{itemize} 26 | 27 | \example 28 | Используем шифр Плейфера\index{шифр!Плейфера} и зашифруем сообщение "\texttt{Wheatstone was the inventor}". Исходное сообщение, разбитое на биграммы, показано в первой строке таблицы. Результат шифрования, также разбитый на биграммы, приведён во второй строке. 29 | \begin{center} \begin{tabular}{|*{12}c|} 30 | \hline 31 | wh & ea & ts & to & ne & wa & st & he & in & ve & nt & or \\ 32 | \hline 33 | aq & ph & nt & nq & un & ab & tn & kg & eu & gu & on & vg \\ 34 | \hline 35 | \end{tabular} \end{center} 36 | \exampleend 37 | 38 | Шифр Плейфера\index{шифр!Плейфера} не является криптографически стойким. Несложно найти ключ, если известны пара открытого текста и соответствующего ему шифртекста. Если известен только шифртекст, криптоаналитик может проанализировать соответствие между частотой появления биграмм в шифртексте и известной частотой появления биграмм в языке, на котором написано сообщение. Такой частотный анализ помогает дешифрованию. 39 | -------------------------------------------------------------------------------- /historical-ciphers/index.tex: -------------------------------------------------------------------------------- 1 | \chapter{Исторические шифры}\label{sec:historical-ciphers} 2 | 3 | В главе приведены наиболее известные исторические шифры, которыми можно было пользоваться до появления роторных машин. К ним относятся такие шифры, как шифр Цезаря\index{шифр!Цезаря}, шифр Плейфера\index{шифр!Плейфера}, шифр Хилла\index{шифр!Хилла} и шифр Виженера\index{шифр!Виженера}. Они наглядно демонстрируют различные классы шифров. 4 | 5 | \input{monoalphabetic_ciphers} 6 | 7 | \input{bigrammnye_substitution_ciphers} 8 | 9 | \input{hills_cipher} 10 | 11 | \input{vigeneres_cipher} 12 | 13 | \input{polyalphabetic_cipher_cryptanalysis} 14 | -------------------------------------------------------------------------------- /historical-ciphers/index_only.tex: -------------------------------------------------------------------------------- 1 | \input{../_settings} 2 | \addbibresource{../bibliography.bib} 3 | \begin{document} 4 | \selectlanguage{russian} 5 | 6 | \tableofcontents 7 | 8 | \input{index} 9 | 10 | \printbibliography[heading=bibintoc,title={Литература}] 11 | 12 | \end{document} 13 | 14 | -------------------------------------------------------------------------------- /history/index_only.tex: -------------------------------------------------------------------------------- 1 | \input{../_settings} 2 | \addbibresource{../bibliography.bib} 3 | \begin{document} 4 | \selectlanguage{russian} 5 | 6 | \tableofcontents 7 | 8 | \input{index} 9 | 10 | \printusedliterature 11 | 12 | \end{document} 13 | 14 | -------------------------------------------------------------------------------- /history/pic/Aristotle_Altemps_Inv8575.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/history/pic/Aristotle_Altemps_Inv8575.jpg -------------------------------------------------------------------------------- /history/pic/EnigmaMachine.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/history/pic/EnigmaMachine.jpg -------------------------------------------------------------------------------- /history/pic/Leon_Battista_Alberti_1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/history/pic/Leon_Battista_Alberti_1.jpg -------------------------------------------------------------------------------- /history/pic/Lorenz-SZ42-2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/history/pic/Lorenz-SZ42-2.jpg -------------------------------------------------------------------------------- /history/pic/Skytale.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/history/pic/Skytale.png -------------------------------------------------------------------------------- /history/pic/Trithemiusmoredetail.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/history/pic/Trithemiusmoredetail.jpg -------------------------------------------------------------------------------- /linear-congruential-generator.tex: -------------------------------------------------------------------------------- 1 | \section{Линейный конгруэнтный генератор}\label{section-linear-congruential-generator}\index{генератор!линейный конгруэнтный} 2 | \selectlanguage{russian} 3 | 4 | Алгоритм был предложен Лемером (\langen{Derrick Henry Lehmer}, \cite{Lehmer:1951:1, Lehmer:1951:2}) в 1949 году. Линейный конгруэнтный генератор основывается на вычислении последовательности $x_n, x_{n+1}, \dots$, такой что: 5 | \[x_{n+1} = a \cdot x_n + c \mod m.\] 6 | 7 | Числа $a, c, m$, $ 0 < a < m, 0 < c < m$, являются параметрами алгоритма. 8 | 9 | \example 10 | Для параметров $a = 2, c = 3, m = 5$ и начального состояния $x_0 = 1$ получаем последовательность: $0, 3, 4, 1, 0, \dots$ 11 | \exampleend 12 | 13 | Максимальный период ограничен значением $m$. Но максимум периода достигается тогда и только тогда, когда~\cite[Линейный конгруэнтный метод]{Knuth:2001:2}: 14 | 15 | \begin{itemize} 16 | \item числа $c$ и $m$ взаимно просты\index{числа!взаимно простые}; 17 | \item число $a - 1$ кратно каждому простому делителю числа $m$; 18 | \item число $a - 1$ кратно 4, если $m$ кратно 4. 19 | \end{itemize} 20 | 21 | Конкретная реализация алгоритма может использовать в качестве выхода либо внутреннее состояние целиком (число $x_n$), либо его отдельные биты. Линейный конгруэнтный генератор является простым (то есть <<дешёвым>>) и быстрым генератором. Результат его работы -- статистически качественная псевдослучайная последовательность. Линейный конгруэнтный генератор нашёл широкое применение в качестве стандартной реализации функции для получения псевдослучайных чисел в различных компиляторах и библиотеках времени исполнения (см. таблицу~\ref{table:lcg}). Забегая вперёд, предупредим читателя, что его использование в криптографии недопустимо. Зная два последовательных значения выхода генератора ($x_n$ и $x_{n+1}$) и единственный параметр схемы $m$, можно решить систему уравнений и найти $a$ и $c$, чего будет достаточно для нахождения всей дальнейшей (или предыдущей) части последовательности. Параметр $m$, в свою очередь, можно найти перебором, начиная с некоторого $\min(X): X \geq x_i$, где $x_i$ -- наблюдаемые элементы последовательности. 22 | 23 | \begin{landscape} 24 | {\renewcommand{\arraystretch}{1.5} 25 | \begin{table}[h] 26 | \begin{tabular}{|p{0.34\linewidth}|r|r|r|l|} 27 | \hline 28 | & a & c & m & используемые биты \\ 29 | \hline 30 | \cite{Press:2007}~Numerical Recipes: The Art of Scientific Computing & 1664525 & 1013904223 & $2^{32}$ & \\ 31 | \cite{Knuth:2005}~MMIX in The Art of Computer Programming & \tiny{6364136223846793005} & \tiny{1442695040888963407} & $2^{64}$ & \\ 32 | \hline 33 | \cite{Entacher:1997}~ANSI C: 34 | \tiny{(Watcom, Digital Mars, CodeWarrior, IBM VisualAge C/C++)} & 1103515245 & 12345 & $2^{31}$ & биты с 30 по 16-й \\ 35 | \cite{Sirca:Horvat:2012}~glibc & 1103515245 & 12345 & $2^{31}$ & биты с 30 по 0-й \\ 36 | C99, C11 (ISO/IEC 9899) & 1103515245 & 12345 & $2^{32}$ & биты с 30 по 16-й \\ 37 | C++11 (ISO/IEC 14882:2011) & 16807 & 0 & $2^{31} - 1$ & \\ 38 | Apple CarbonLib & 16807 & 0 & $2^{31} - 1$ & \\ 39 | Microsoft Visual/Quick C/C++ & 214013 & 2531011 & $2^{32}$ & биты с 30 по 16-й \\ 40 | \hline 41 | \cite{Bucknall:2001}~Borland Delphi & 134775813 & 1 & $2^{32}$ & \\ 42 | \cite{MS-VBRAND:2004}~Microsoft Visual Basic \tiny{(версии 1--6)} & 1140671485 & 12820163 & $2^{24}$ & \\ 43 | \cite{Mak:2003}~ Sun (Oracle) Java Runtime Environment & 25214903917 & 11 & $2^{48} - 1$ & биты с 47 по 16-й \\ 44 | \hline 45 | \end{tabular} 46 | \caption{Примеры параметров линейного конгруэнтного генератора в различных книгах, компиляторах и библиотеках времени исполнения\label{table:lcg}} 47 | \end{table} 48 | } 49 | \end{landscape} 50 | -------------------------------------------------------------------------------- /majority_generators.tex: -------------------------------------------------------------------------------- 1 | \subsection[Мажоритарные генераторы, шифр A5/1]{Мажоритарные генераторы на примере алгоритма шифрования A5/1}\label{section:majority_generators}\index{шифр!A5} 2 | \selectlanguage{russian} 3 | 4 | Третий способ улучшения криптостойкости последовательностей поясняется с помощью рис.~\ref{fig:gsm-a51-cipher}, на котором показан мажоритарный генератор ключей алгоритма потокового шифрования A5/1 стандарта GSM. В отличие от случая нелинейного комбинирования выходов нескольких регистров в этом случае применён условный сдвиг регистров, то есть на каждом такте некоторые регистры могут не сдвигаться, а оставаться в прежнем состоянии. На рисунке показана схема из трёх регистров сдвига с различными многочленами обратной связи (здесь применена обратная нумерация ячеек, коэффициентов и переменных по сравнению с предыдущими разделами): 5 | \[ \left\{ \begin{array}{l} 6 | c_1(y) = y^{19} + y^{18} + y^{17} + y^{14} + 1, \\ 7 | c_2(y) = y^{22} + y^{21} + 1, \\ 8 | c_3(y) = y^{23} + y^{22} + y^{21} + y^8 + 1. 9 | \end{array} \right. \] 10 | 11 | \begin{figure}[!ht] 12 | \centering 13 | \includegraphics[width=\textwidth]{pic/gsm-a51-cipher} 14 | \caption{Регистр сдвига алгоритма шифрования A5/1\label{fig:gsm-a51-cipher}} 15 | \end{figure} 16 | 17 | В алгоритме A5/1 регистры сдвигаются не на каждом такте. Правило сдвига следующее. В каждом регистре есть один тактовый бит, определяющий сдвиг, -- восьмой бит $\textrm{C1}$ для первого регистра, десятые биты $\textrm{C2}$ и $\textrm{C3}$ для второго и третьего регистров. На каждом такте вычисляется мажоритарное значение тактового бита $m = \textrm{majority}(\textrm{C1}, \textrm{C2}, \textrm{C3})$, то есть по большинству значений: 0 или 1. Если для данного регистра значение тактового бита совпадает с мажоритарным решением, то регистр сдвигается. Если не совпадает, то остаётся в прежнем состоянии без сдвига на следующий такт. Так как всего состояний тактовых битов $2^3$, то в среднем каждый регистр сдвигается в $\frac{3}{4}$ всех тактов. 18 | 19 | Общее количество ячеек всех трёх регистров $19+22+23=64$, следовательно, период генератора A5/1: $T < 2^{64}$. Данный шифр не может считаться стойким из-за возможности полного перебора. Например, известны атаки на шифр A5/1, требующие 150-300 GiB оперативной памяти и нескольких минут вычислений одного ПК (2001 г.). 20 | -------------------------------------------------------------------------------- /micalis_generator.tex: -------------------------------------------------------------------------------- 1 | \subsection{Генератор Микали}\index{генератор!Микали} 2 | 3 | Другой пример -- генератор Микали. 4 | 5 | Так же выбирают большие простые числа $p,q$ с битовой длиной не менее 512, вычисляют число $n = pq$. Находят функцию Эйлера $\varphi(n) = (p-1) (q-1)$ и задают целое число $e$ такое, что наибольший общий делитель $\gcd(e, \varphi(n)) = 1$. С помощью генератора случайных чисел выбирают $0 \leq x_{0} \leq n-1$. Вычисляют 6 | \[ \begin{array}{l} 7 | x_1 = x_0^e \mod n, \\ 8 | x_2 = x_1^e \mod n, \\ 9 | \dots \\ 10 | x_N = x_{N-1}^e \mod n. 11 | \end{array} \] 12 | Чтобы уменьшить сложность вычислений, в значениях $x_i$ оставляют $l$ младших разрядов, причём $l \leq \log_2 \log_2 N$. Последовательность ключей получают в виде 13 | \[ \begin{array}{l} 14 | k_1 = x_1^2 \mod 2, \\ 15 | k_2 = x_2^2 \mod 2, \\ 16 | \dots \\ 17 | k_N = x_N^2 \mod 2. \\ 18 | \end{array} \] 19 | 20 | Как и генератор BBS, генератор Микали -- криптостойкий, для его взлома требуется разложить число $n$ на множители. Недостаток -- маленькая скорость. 21 | -------------------------------------------------------------------------------- /mystyle.xdy: -------------------------------------------------------------------------------- 1 | ;;; xindy style file 2 | (markup-locclass-list :open "\dotfill" :sep "") 3 | 4 | (define-letter-groups 5 | ("a" "b" "c" "d" "e" "f" "g" "h" "i" "j" "k" "l" "m" 6 | "n" "o" "p" "q" "r" "s" "t" "u" "v" "w" "x" "y" "z")) 7 | 8 | (require 9 | "rules/latin-tolower.xdy") 10 | 11 | (use-rule-set 12 | :run 0 13 | :rule-set ("latin-tolower")) 14 | 15 | (markup-letter-group 16 | :open-head "~n~n \textbf {\Large " 17 | :close-head "}~n \nopagebreak" 18 | :capitalize) 19 | -------------------------------------------------------------------------------- /permutation_ciphers.tex: -------------------------------------------------------------------------------- 1 | \subsubsection{Шифры перестановки} 2 | \selectlanguage{russian} 3 | 4 | Шифры \emph{перестановки} реализуются следующим образом. Берут открытый текст, например буквенный, и разделяют на блоки определённой длины m: $x_1, x_2, \dots, x_m$, где $x_i$ - i-й символ, $i = 1, \dots , m$. Затем осуществляется перестановка позиций блока (вместе с символами). Перестановки могут быть однократные и многократные. Частный случай перестановки -- сдвиг. Приведём пример: 5 | \begin{center} 6 | секрет $\xrightarrow{\text{сдвиг}}$ ретсек $\xrightarrow{\text{перестановка}}$ рскете. 7 | \end{center} 8 | Ключ такого шифра указывает изменение порядка номеров позиций блока при шифровании и расшифровании. 9 | 10 | Существуют так называемые \emph{маршрутные перестановки}. Используется какая-либо геометрическая фигура, например прямоугольник. Запись открытого текста ведётся по одному \emph{маршруту}, например по строкам, а считывание для шифрования осуществляется по другому маршруту, например по столбцам. Ключ шифра определяет эти маршруты. 11 | В случае, когда рассматривается перестановка блока текста фиксированной длины, перестановку можно рассматривать как замену. 12 | 13 | В полиалфавитных шифрах при шифровании открытый текст разбивается на блоки (последовательности) длины $n$, где $n$ -- \emph{период}. Этот параметр выбирает \emph{криптограф} и держит его в секрете. 14 | 15 | Поясним процедуру шифрования полиалфавитным шифром. Запишем шифруемое сообщение в матрицу по столбцам определённой длины. Пусть открытый текст таков: <<Игры различаются по содержанию, характерным особенностям, а также по тому, какое место они занимают в жизни детей>>. Зададим $n=4$ и запишем этот текст в матрицу размера $(4 \times 24)$: 16 | 17 | \begin{center} \resizebox{\textwidth}{!}{ \begin{tabular}{|*{24}{c|}} 18 | \hline 19 | и&р&и&т&о&е&н&а&т&ы&о&н&я&а&п&м&к&е&о&а&а&ж&и&е \\ 20 | г&а&ч&с&с&р&и&р&е&м&б&о&м&к&о&у&о&с&н&н&ю&и&д&й \\ 21 | р&з&а&я&о&ж&ю&а&р&о&е&с&а&ж&т&к&е&т&и&и&т&з&е& \\ 22 | ы&л&ю&п&д&а&х&к&н&с&н&т&т&е&о&а&м&о&з&м&в&н&т& \\ 23 | \hline 24 | \end{tabular} } \end{center} 25 | 26 | Выбираем $4$ различных моноалфавитных шифра. 27 | 28 | Первую строку 29 | 30 | \begin{center} \resizebox{\textwidth}{!}{ \begin{tabular}{|*{24}{c|}} 31 | \hline 32 | и&р&и&т&о&е&н&а&т&ы&о&н&я&а&п&м&к&е&о&а&а&ж&и&е \\ 33 | \hline 34 | \end{tabular} } \end{center} 35 | 36 | шифруем, используя первый шифр. Вторую строку 37 | 38 | \begin{center} \resizebox{\textwidth}{!}{ \begin{tabular}{|*{24}{c|}} 39 | \hline 40 | г&а&ч&с&с&р&и&р&е&м&б&о&м&к&о&у&о&с&н&н&ю&и&д&й \\ 41 | \hline 42 | \end{tabular} } \end{center} 43 | 44 | шифруем, используя второй шифр, и~т.\,д. 45 | 46 | Выполняя расшифрование, легальный пользователь знает период. Он записывает принятую шифрограмму по строкам в матрицу с длиной строки, равной периоду, к каждому столбцу применяет соответствующий ключ и расшифровывает сообщение, зная соответствующие шифры. 47 | 48 | Шифры перестановки можно рассматривать как частный случай шифров замены, если отождествить один блок перестановки с одним символом большого алфавита. 49 | -------------------------------------------------------------------------------- /pic/a5-1.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/pic/a5-1.pdf -------------------------------------------------------------------------------- /pic/a5-1.vsd: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/pic/a5-1.vsd -------------------------------------------------------------------------------- /pic/generator.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/pic/generator.png -------------------------------------------------------------------------------- /pic/generators.eps: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/pic/generators.eps -------------------------------------------------------------------------------- /pic/generators.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/pic/generators.pdf -------------------------------------------------------------------------------- /pic/gsm-a51-cipher.eps: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/pic/gsm-a51-cipher.eps -------------------------------------------------------------------------------- /pic/gsm-a51-cipher.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/pic/gsm-a51-cipher.pdf -------------------------------------------------------------------------------- /pic/gsm-a51-cipher.vsd: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/pic/gsm-a51-cipher.vsd -------------------------------------------------------------------------------- /pic/hamming-exploit.src.rar: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/pic/hamming-exploit.src.rar -------------------------------------------------------------------------------- /pic/lfsr-zhegalkin.eps: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/pic/lfsr-zhegalkin.eps -------------------------------------------------------------------------------- /pic/lfsr-zhegalkin.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/pic/lfsr-zhegalkin.pdf -------------------------------------------------------------------------------- /pic/lfsr-zhegalkin.vsd: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/pic/lfsr-zhegalkin.vsd -------------------------------------------------------------------------------- /pic/lfsr.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/pic/lfsr.pdf -------------------------------------------------------------------------------- /pic/model-auten.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/pic/model-auten.pdf -------------------------------------------------------------------------------- /pic/model-cipher.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/pic/model-cipher.pdf -------------------------------------------------------------------------------- /pic/model-simple-with-channel.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/pic/model-simple-with-channel.pdf -------------------------------------------------------------------------------- /pic/model-simple.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/pic/model-simple.pdf -------------------------------------------------------------------------------- /pic/shift-register-small.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/pic/shift-register-small.png -------------------------------------------------------------------------------- /pic/stream-cipher.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/pic/stream-cipher.pdf -------------------------------------------------------------------------------- /pic/taktovi-impuls.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/pic/taktovi-impuls.png -------------------------------------------------------------------------------- /pic/wep_incaps.old.vsd: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/pic/wep_incaps.old.vsd -------------------------------------------------------------------------------- /pic/wep_incaps.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/pic/wep_incaps.pdf -------------------------------------------------------------------------------- /pic/wep_incaps.vsd: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/pic/wep_incaps.vsd -------------------------------------------------------------------------------- /pic/wikilogo-aes-128-ecb.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/pic/wikilogo-aes-128-ecb.pdf -------------------------------------------------------------------------------- /pic/wikilogo.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/pic/wikilogo.pdf -------------------------------------------------------------------------------- /protocols/_settings.tex: -------------------------------------------------------------------------------- 1 | % Протокол без разрывов между страницами, но зато 2 | % разрешаем разрывать страницу до и после определения протокола 3 | % (по умолчанию itemize / enumerate так не разрешают) 4 | \newsavebox{\protocolbox} 5 | \makeatletter\newenvironment{protocol}{% 6 | \begin{samepage}% 7 | \@beginparpenalty=\@lowpenalty% 8 | \@endparpenalty=\@lowpenalty% 9 | \begin{itemize}} 10 | {\end{itemize}\end{samepage}}\makeatother 11 | % Разрешить разрывать страницу для длинных протоколов 12 | \makeatletter\newenvironment{protocol*}{% 13 | \begin{itemize}} 14 | {\end{itemize}}\makeatother 15 | 16 | % https://tex.stackexchange.com/questions/164707/how-to-use-greek-letters-in-pgf-umlsd-or-generally-terms-starting-with 17 | \renewcommand{\mess}[4][0]{ 18 | \stepcounter{seqlevel} 19 | \path 20 | (#2)+(0,-\theseqlevel*\unitfactor-0.7*\unitfactor) node (mess from) {}; 21 | \addtocounter{seqlevel}{#1} 22 | \path 23 | (#4)+(0,-\theseqlevel*\unitfactor-0.7*\unitfactor) node (mess to) {}; 24 | \draw[->,>=angle 60] (mess from) -- (mess to) node[midway, above] 25 | {#3}; 26 | 27 | \node (\detokenize{#3} from) at (mess from) {}; 28 | \node (\detokenize{#3} to) at (mess to) {}; 29 | } 30 | -------------------------------------------------------------------------------- /protocols/asymmetric.tex: -------------------------------------------------------------------------------- 1 | \section{Асимметричные протоколы}\label{section-protocols-asymmetric} 2 | \selectlanguage{russian} 3 | 4 | Асимметричные протоколы, или же протоколы, основанные на криптосистемах с открытыми ключами, позволяют ослабить требования к предварительному этапу протоколов. Вместо общего секретного ключа, который должны иметь две стороны (либо каждая из сторон и доверенный центр), в рассматриваемых ниже протоколах стороны должны предварительно обменяться открытыми ключами (между собой либо с доверенным центром). Такой предварительный обмен может проходить по открытому каналу связи, в предположении, что криптоаналитик не может повлиять на содержимое канала связи на данном этапе. 5 | 6 | В данном разделе рассмотрены только такие протоколы, которые не описывают и не ограничивают используемые математические операции, а позволяют использовать любые надёжные криптографические примитивы из симметричной и асимметричной криптографии. При анализе надёжности таких протоколов считается, что используемые примитивы криптографически надёжны и их можно заменить идеализированной моделью (например, \emph{случайным оракулом}\index{оракул!случайный} для криптографических хеш-функций). 7 | 8 | \input{denning-sacco} 9 | 10 | \input{dass} 11 | 12 | \input{woo-lam} 13 | -------------------------------------------------------------------------------- /protocols/bb92.tex: -------------------------------------------------------------------------------- 1 | \subsection{Протокол B92 (BB92)}\index{протокол!B92|(}\index{протокол!BB92|(} 2 | \selectlanguage{russian} 3 | 4 | В 1992 году один из авторов протокола BB84 Чарльз Беннетт выдвинул идею (\cite{Bennett:1992}), что участникам не обязательно использовать четыре разных варианта поляризации, а достаточно двух, но неортогональных. Например, $0^{\circ}$ (<<$\to$>>) и $45^{\circ}$ (<<$\nearrow$>>). Протокол получил названия B92 и BB92. 5 | 6 | Для каждого бита выполняется следующее. 7 | 8 | \begin{protocol} 9 | \item[(1)] Алиса поляризует фотон в зависимости от бита $b_i$ и передаёт его по квантовому каналу связи Бобу: 10 | \begin{itemize} 11 | \item для $b_i=0$ поляризует под $0^{\circ}$ (<<$\to$>>); 12 | \item для $b_i=1$ поляризует под $45^{\circ}$ (<<$\nearrow$>>). 13 | \end{itemize} 14 | \item[(2)] Боб случайным образом выбирает один из двух базисов: $90^{\circ}$ (<<$\uparrow$>>) или $135^{\circ}$ (<<$\nwarrow$>>), и пробует детектировать фотон. Если получилось, то он делает вывод о выбранной Алисой поляризации фотона и бите $b_i$: 15 | \begin{itemize} 16 | \item если детектировал на $135^{\circ}$ (<<$\nwarrow$>>), значит Алиса выбрала поляризацию $0^{\circ}$ (<<$\to$>>) и $b_i=0$; 17 | \item если детектировал на $90^{\circ}$ (<<$\uparrow$>>), значит Алиса выбрала поляризацию $45^{\circ}$ (<<$\nearrow$>>) и $b_i=1$. 18 | \end{itemize} 19 | \item[{}] Боб по классическому каналу связи сообщает Алисе, получилось детектировать фотон или нет. Если да, то бит принимается участниками за переданный. 20 | \end{protocol} 21 | 22 | \begin{table} 23 | \centering 24 | \begin{tabular}{|l|c|c|c|c|c|c|c|c|} 25 | \hline 26 | \parbox[c][1cm][c]{2,8cm}{биты Алисы} & 0 & 0 & 0 & 0 & 1 & 1 & 1 & 1 \\ 27 | \hline 28 | \parbox[c][1cm][c]{2,8cm}{поляризация \\ фотона} & $\to$ & $\to$ & $\to$ & $\to$ & $\nearrow$ & $\nearrow$ & $\nearrow$ & $\nearrow$ \\ 29 | \hline 30 | \parbox[c][1cm][c]{2,8cm}{поляризация \\ детектора Боба} & $\nwarrow$ & $\uparrow$ & $\nwarrow$ & $\uparrow$ & $\nwarrow$ & $\uparrow$ & $\nwarrow$ & $\uparrow$ \\ 31 | \hline 32 | \parbox[c][1cm][c]{2,8cm}{вероятность \\ детектирования} & $\frac{1}{2}$ & 0 & $\frac{1}{2}$ & 0 & 0 & $\frac{1}{2}$ & 0 & $\frac{1}{2}$ \\ 33 | \hline 34 | \parbox[c][1cm][c]{2,8cm}{удалось или нет детектировать} & да & нет & нет & нет & нет & да & нет & нет \\ 35 | \hline 36 | \parbox[c][1cm][c]{2,8cm}{принятые Бобом биты} & 0 & - & - & - & - & 1 & - & - \\ 37 | \hline 38 | \end{tabular} 39 | \caption{Пример сеансов протокола B92 / BB92. По итогам передачи 8 фотонов от Алисы Боб сумел детектировать 2 фотона, что позволило передать от Алисы к Бобу 2 бита информации} 40 | \label{tab:b92} 41 | \end{table} 42 | 43 | Если Боб выбрал поляризацию, ортогональную оригинальной, то он со 100\% вероятностью не зарегистрирует фотон. Если же поляризация неортогональна оригинальной, то с вероятностью 50\% Боб сумеет зарегистрировать фотон на детекторе. Таким образом, если Боб зарегистрировал фотон, то он будет точно знать, какой бит передавала Алиса. Если же не зарегистрировал, то это трактуется, как стирание. 44 | 45 | Пример сеансов протоколов передачи приведён в таблице~\ref{tab:b92}. 46 | 47 | В среднем для передачи одного бита информации Алисе и Бобу потребуется провести 4 итерации протокола. Это в два раза больше, чем в протоколе BB84\index{протокол!BB84}. 48 | 49 | \index{протокол!B92|)}\index{протокол!BB92|)} 50 | -------------------------------------------------------------------------------- /protocols/bloms_scheme.tex: -------------------------------------------------------------------------------- 1 | \subsection{Схема Блома}\label{section-bloms-scheme}\index{схема!Блома|(} 2 | \selectlanguage{russian} 3 | 4 | Схема Блома (\langen{Rolf Blom},~\cite{Blom:1984, Blom:1985}) используется в протоколе HDCP\index{протокол!HDCP} (\langen{High-bandwidth Digital Content Protection}) для предотвращения копирования высококачественного видеосигнала. Предполагается, что некоторый доверенный центр распределит ключи таким образом, что легальные производители видеокарт, мониторов высокого разрешения и других компонент будут передавать видеоконтент по защищённому каналу, а <<пиратские>> устройства не смогут эти данные перехватить, и, например, записать на другой носитель. 5 | 6 | На этапе инициализации доверенный центр выбирает симметричную матрицу $D_{m,m}$ над конечным полем $\GF p$. Для присоединения к сети распространения ключей, новый участник либо самостоятельно, либо с помощью доверенного центра выбирает новый открытый ключ (идентификатор) $I_i$, представляющий собой вектор длины $m$ над $\GF p$. Доверенный центр вычисляет для нового участника закрытый ключ $K_i$: 7 | \begin{equation} 8 | K_i = D_{m,m} I_i. 9 | \label{eq:blom_center_matrix} 10 | \end{equation} 11 | 12 | \begin{figure} 13 | \centering 14 | \begin{sequencediagram} 15 | \newinst{Alice}{Alice} 16 | \newinst[3]{Bob}{Bob} 17 | 18 | \mess{Alice}{$ I_A $}{Bob} 19 | \mess{Bob}{$I_B $}{Alice} 20 | 21 | \postlevel 22 | \begin{callself}{Alice}{$K_{AB} = K^T_A I_B$}{}\end{callself} 23 | \prelevel\prelevel 24 | \begin{callself}{Bob}{$K_{BA} = K^T_B I_A$}{}\end{callself} 25 | \end{sequencediagram} 26 | \caption{Схема Блома\label{fig:key_distribution-bloms-scheme}} 27 | \end{figure} 28 | 29 | Симметричность матрицы $D_{m,m}$ доверенного центра позволяет любым двум участникам сети создать общий сеансовый ключ. Пусть Алиса и Боб -- легальные пользователи сети, то есть они обладают открытыми ключами $I_A$ и $I_B$ соответственно, а их закрытые ключи $K_A$ и $K_B$ были вычислены одним и тем же доверенным центром по формуле~\ref{eq:blom_center_matrix}. Тогда протокол выработки общего секретного ключа выглядит следующим образом (рис.~\ref{fig:key_distribution-bloms-scheme}). 30 | 31 | \begin{protocol} 32 | \item[(1)] $Alice \to \left\{ I_A \right\} \to Bob$ 33 | \item[(2)] Боб вычисляет $K_{BA} = K^T_B I_A = I^T_B D_{m,m} I_A$. 34 | \item[{}] $Bob \to \left\{ I_B \right\} \to Alice$ 35 | \item[(3)] Алиса вычисляет $K_{AB} = K^T_A I_B = I^T_A D_{m,m} I_B$. 36 | \end{protocol} 37 | 38 | Из симметричности матрицы $D_{m,m}$ следует, что значения $K_{AB}$ и $K_{BA}$ совпадут, они же и будут являться общим секретным ключом для Алисы и Боба. Этот секретный ключ будет свой для каждой пары легальных пользователей сети. 39 | 40 | Присоединение новых участников к схеме строго контролируется доверенным центром, что позволяет защитить сеть от нелегальных пользователей. Надёжность данной схемы основывается на невозможности восстановить исходную матрицу. Однако для восстановления матрицы доверенного центра размера $m \times m$ необходимо и достаточно всего $m$ пар линейно независимых открытых и закрытых ключей. В 2010-м году компания Intel, которая является <<доверенным центром>> для пользователей системы защиты HDCP, подтвердила, что криптоаналитикам удалось найти секретную матрицу (точнее, аналогичную ей), используемую для генерации ключей в упомянутой системе предотвращения копирования высококачественного видеосигнала. 41 | 42 | \index{схема!Блома|)} -------------------------------------------------------------------------------- /protocols/cryptosystems-protocols.tex: -------------------------------------------------------------------------------- 1 | \section{<<Криптосистемы-протоколы>>}\label{section-cryptosystems-protocols} 2 | \selectlanguage{russian} 3 | 4 | Как и создатели трёхпроходных протоколов из раздела~\ref{section-three-pass-protocols}, авторы следующих алгоритмов считали их не просто математическими конструкциями, обеспечивающие некоторую элементарную операцию (например, шифрование с открытым ключом), но пытались вокруг одной-двух математических конструкций построить законченную систему распространения ключей. Некоторые из этих конструкций, преобразовавшись, используются до настоящего времени (например, протокол Диффи-Хеллмана), некоторые -- остались только в истории криптографии и защиты информации. 5 | 6 | Позже в 1990-х годах будут разделены математические асимметричные примитивы (шифрование и электронная подпись) и протоколы, эти примитивы использующие, что будет продемонстрировано в разделе~\ref{section-protocols-asymmetric}. 7 | 8 | \input{diffie-hellman} 9 | 10 | \input{el-gamal} 11 | 12 | \input{mti} 13 | 14 | \input{sts} 15 | -------------------------------------------------------------------------------- /protocols/definitions.tex: -------------------------------------------------------------------------------- 1 | \section{Основные понятия} 2 | \selectlanguage{russian} 3 | Для успешного выполнения любых целей по защите информации необходимо участие в процессе защиты нескольких субъектов, которые по определённым правилам будут выполнять технические или организационные действия, криптографические операции, взаимодействовать друг с другом, например, передавая сообщения или проверяя личности друг друга. 4 | 5 | Формализация таких действий делается через описание протокола. \emph{Протокол} -- описание распределённого алгоритма, в процессе выполнения которого два или более участников последовательно выполняют определённые действия и обмениваются сообщениями\footnote{Здесь и далее в этом разделе определения даны на основе~\cite{Cheremushkin:2009}.}. 6 | 7 | Под участником\index{участник!протокола} (субъектом\index{субъект!протокола}, стороной\index{сторона!протокола}) протокола понимают не только людей, но и приложения, группы людей или целые организации. Формально участниками считают только тех, кто выполняет активную роль в рамках протокола. Хотя при создании и описании протоколов забывать про пассивные стороны тоже не стоит. Например, пассивный криптоаналитик\index{криптоаналитик!пассивный} формально не является участником протоколов, но многие протоколы разрабатываются с учётом защиты от таких <<неучастников>>. 8 | 9 | Протокол состоит из \emph{циклов}\index{цикл!протокола} (\langen{round}) или \emph{проходов}\index{проход!протокола} (\langen{pass}). Цикл -- временной интервал активности только одного участника. За исключением самого первого цикла протокола, обычно начинается приёмом сообщения, а заканчивается -- отправкой. 10 | 11 | Цикл (или проход) состоит из \emph{шагов} (действий, \langen{step, action}) -- конкретных законченных действий, выполняемых участником протокола. Например: 12 | \begin{itemize} 13 | \item генерация нового (случайного) значения; 14 | \item вычисление значений функции; 15 | \item проверка сертификатов, ключей, подписей, и др.; 16 | \item приём и отправка сообщений. 17 | \end{itemize} 18 | 19 | Прошедшая в прошлом или даже просто теоретически описанная реализация протокола для конкретных участников называется \emph{сеансом}\index{сеанс!протокола}. Каждый участник в рамках сеанса выполняет одну или несколько \emph{ролей}. В другом сеансе протокола участники могут поменяться ролями и выполнять уже совсем другие функции. 20 | 21 | Можно сказать, что протокол прескрептивно описывает правила поведения каждой роли в протоколе. А сеанс это дескриптивное описание (возможно теоретически) состоявшейся в прошлом реализации протокола. 22 | 23 | Пример описания протокола. 24 | \begin{enumerate} 25 | \item Участник с ролью <<Отправитель>> должен отправить участнику с ролью <<Получатель>> сообщение. 26 | \item Участник с ролью <<Получатель>> должен принять от участника с ролью <<Отправитель>> сообщение. 27 | \end{enumerate} 28 | 29 | Пример описания сеанса протокола. 30 | \begin{enumerate} 31 | \item 1-го апреля в 13:00 Алиса отправила Бобу сообщение. 32 | \item 1-го апреля в 13:05 Боб принял от Алисы сообщение. 33 | \end{enumerate} 34 | 35 | \emph{Защищённым протоколом}\index{протокол!защищённый} или \emph{протоколом обеспечения безопасности}\index{протокол!обеспечения безопасности} будет называть протокол, обеспечивающий выполнение хотя бы одной защитной функции~\cite{ISO:7498-2:1989}: 36 | \begin{itemize} 37 | \item аутентификация сторон и источника данных, 38 | \item разграничение доступа, 39 | \item конфиденциальность, 40 | \item целостность, 41 | \item невозможность отказа от факта отправки или получения. 42 | \end{itemize} 43 | 44 | Если защищённый протокол предназначен для выполнения одной или нескольких функций безопасности криптографической системы, или если в процессе его исполнения используются криптографические алгоритмы, то такой протокол будем называть \emph{криптографическим}\index{протокол!криптографический}. 45 | -------------------------------------------------------------------------------- /protocols/denning-sacco.tex: -------------------------------------------------------------------------------- 1 | \subsection{Протокол Деннинг~---~Сакко}\index{протокол!Деннинг~---~Сакко|(} 2 | \selectlanguage{russian} 3 | 4 | \begin{figure} 5 | \centering 6 | \begin{sequencediagram} 7 | \newinst{Trent}{Trent} 8 | \newinst[2.5]{Alice}{Alice} 9 | \newinst[2.5]{Bob}{Bob} 10 | 11 | \begin{call}{Alice}{ $A, B$ }{Trent} 12 | {\shortstack{ $S_T( A, K_A, T_T )$, \\ $S_T( B, K_B, T_T )$ }}\postlevel\end{call} 13 | \mess{Alice}{\shortstack{ $E_B( S_A ( K, T_A ) )$, \\ $S_T( A, K_A, T_T )$, \\ $S_T( B, K_B, T_T )$ }}{Bob} 14 | \end{sequencediagram} 15 | \caption{Протокол Деннинг~---~Сакко\label{fig:denning-sacco}} 16 | \end{figure} 17 | 18 | Протокол был предложен в 1981 году сотрудниками Университета Пердью Дороти Деннинг и Джованни Марией Сакко (\langen{Dorothy E. Denning, Giovanni Maria Sacco},~\cite{Denning:Sacco:1981}). В данном протоколе к доверенному центру (Тренту) за сертификатами сразу обоих участников обращается инициатор (Алиса, рис.~\ref{fig:denning-sacco}). Этот же участник отвечает и за формирование нового сессионного ключа $K$. 19 | 20 | \begin{protocol} 21 | \item[(1)] $Alice \to \left\{ A, B \right\} \to Trent$ 22 | \item[(2)] $Trent \to \left\{ S_T( A, K_A, T_T ), S_T( B, K_B, T_T ) \right\} \to Alice$ 23 | \item[(3)] Алиса генерирует новый сессионный ключ $K$ 24 | \item[{}] $\begin{array}{lll} 25 | Alice \to \{ & E_B( S_A ( K, T_A ) ), & \\ 26 | & S_T( A, K_A, T_T ), & \\ 27 | & S_T( B, K_B, T_T ) & \} \to Bob 28 | \end{array}$ 29 | \item[(4)] Боб проверяет подпись доверенного центра на сертификате $S_T( A, K_A, T_T )$, расшифровывает сессионный ключ $K$ и проверяет подпись Алисы. 30 | \end{protocol} 31 | 32 | В протоколе отсутствует как аутентификация второй стороны (Боба), так и подтверждение владения новым сессионным ключом. 33 | 34 | Кроме того, отсутствие в сообщении $E_B( S_A ( K, T_A ) )$ каких-либо идентификаторов делает протокол уязвимым к атаке с известными сеансовым ключом\index{атака!с известным разовым ключом} и позволяет второй стороне (Бобу) выдать себя за инициатора (Алису) в сеансе с третьей стороной (Кларой, рис.~\ref{fig:denning-sacco-attack}). 35 | 36 | \begin{figure} 37 | \centering 38 | \begin{sequencediagram} 39 | \newinst{Trent}{Trent} 40 | \newinst[2.5]{Bob}{Bob} 41 | \newinst[2.5]{Clara}{Clara} 42 | 43 | \begin{call}{Bob}{ $ B, C $ }{Trent} 44 | {\shortstack{ $S_T( B, K_B, T_{T2} )$, \\ $S_T( C, K_C, T_{T2} )$ }}\postlevel\end{call} 45 | \mess{Bob}{\shortstack{ $ E_C( S_A ( K, T_A ) )$, \\ $S_T( A, K_A, T_{T1} )$, \\ $S_T( C, K_C, T_{T2} )$ }}{Clara} 46 | \end{sequencediagram} 47 | \caption{Атака на протокол Деннинг~---~Сакко с известным разовым ключом. Опущены шаги взаимодействия Алисы, Трента и Боба, в процессе которых Боб запомнил полученные им $E_C( S_A ( K, T_A ) )$ и $S_T( A, K_A, T_{T1} )$.\label{fig:denning-sacco-attack}} 48 | \end{figure} 49 | 50 | \begin{protocol} 51 | \item[(1)--(4)] Алиса и Боб провели сеанс протокола, выработав новый сессионный ключ $K$. 52 | \item[(5)] $Bob \to \left\{ B, C \right\} \to Trent$ 53 | \item[(6)] $Trent \to \left\{ S_T( B, K_B, T_T ), S_T( C, K_C, T_T ) \right\} \to Bob$ 54 | \item[(7)] Боб воспроизводит сообщения $S_A ( K, T_A )$ и $S_T( A, K_A, T_T )$ от Алисы в сеансе с Кларой: 55 | \item[{}] $\begin{array}{lll} 56 | Bob~(Alice) \to \{ & E_C( S_A ( K, T_A ) ), & \\ 57 | & S_T( A, K_A, T_T ), & \\ 58 | & S_T( C, K_C, T_T ) & \} \to Clara 59 | \end{array}$ 60 | \item[(8)] Клара проверяет подпись доверенного центра $T$ на сертификате $S_T( A, K_A, T_T )$, расшифровывает сессионный ключ $K$ и проверяет подпись Алисы. 61 | \end{protocol} 62 | 63 | В результате Клара уверена, что получила от Алисы новый сессионный ключ $K$. 64 | 65 | \index{протокол!Деннинг~---~Сакко|)} -------------------------------------------------------------------------------- /protocols/el-gamal.tex: -------------------------------------------------------------------------------- 1 | \subsection{Протокол Эль-Гамаля}\index{протокол!Эль-Гамаля|(} 2 | \selectlanguage{russian} 3 | 4 | \begin{figure} 5 | \centering 6 | \begin{sequencediagram} 7 | \newinst{Alice}{Alice} 8 | \newinst[2.5]{Bob}{Bob} 9 | 10 | \mess{Alice}{$ g^x \bmod p $}{Bob} 11 | \end{sequencediagram} 12 | \caption{Протокол Эль-Гамаля\label{fig:key_distribution-el-gamal}} 13 | \end{figure} 14 | 15 | Протокол Эль-Гамаля (рис.~\ref{fig:key_distribution-el-gamal}, \cite{ElGamal:1984, ElGamal:1985}) за счёт предварительного распространения открытого ключа одной из сторон обеспечивает аутентификацию ключа для этой стороны. Можно гарантировать, что только владелец соответствующего закрытого ключа сможет вычислить сеансовый ключ. Однако подтверждение факта получение ключа (выполнение целей G1 и G8) не является частью протокола. 16 | 17 | \begin{protocol} 18 | \item[(0)] Алиса и Боб выбирают общие параметры $p$ и $g$, где $p$ -- большое простое число, а $g$ -- примитивный элемент поля $\Z_p^*$. 19 | \item[{}] Боб создаёт пару из закрытого и открытого ключей $b$ и $K_B$: 20 | \[\begin{array}{l} 21 | b: 2 \leq b \leq p - 1, \\ 22 | K_B = g^b \bmod p. 23 | \end{array}\] 24 | \item[{}] Открытый ключ $K_B$ находится в общем открытом доступе для всех сторон. Криптоаналитик не может подменить его -- подмена будет заметна. 25 | \item[(1)] Алиса выбирает секрет $x$ и вычисляет сеансовый ключ $K$ 26 | \[ K = K_B^{x} = g^{bx} \bmod p. \] 27 | \[ Alice \to \left\{ g^x \bmod p \right\} \to Bob\] 28 | \item[(2)] Боб вычисляет сеансовый ключ 29 | \[ K = (g^x)^{b} = g^{bx} \bmod p. \] 30 | \end{protocol} 31 | 32 | Протокол не обеспечивает гарантию выбора нового сессионного ключа в каждом сеансе протокола (G10), а использование <<мастер>>-ключа $K_B$ для передачи сеансового ключа позволяет злоумышленнику вычислить все сессионные ключи из прошлых сеансов при компрометации закрытого ключа $b$ (цель G9). 33 | 34 | \index{протокол!Эль-Гамаля|)} -------------------------------------------------------------------------------- /protocols/girault_scheme.tex: -------------------------------------------------------------------------------- 1 | \subsection{Схема Жиро}\label{section-girault-scheme}\index{схема!Жиро|(} 2 | \selectlanguage{russian} 3 | 4 | В схеме Жиро (\langfr{Marc Girault},~\cite{Girault:1990, Girault:1991}) надёжность строится на стойкости криптосистемы RSA (сложности факторизации больших чисел и вычисления дискретного корня). 5 | 6 | Предварительно: 7 | \begin{itemize} 8 | \item Доверенный центр (Трент, $T$): 9 | \begin{itemize} 10 | \item выбирает общий модуль $n = p \times q$, где $p$ и $q$ -- большие простые числа; 11 | \item выбирает пару из закрытого и открытого ключей:\[\begin{array}{l} 12 | K_{T, \text{public}}: (e, n) \\ 13 | K_{T, \text{private}}: (d, n); 14 | \end{array}\] 15 | \item выбирает элемент $g$ поля $\mathbb{Z}_n^{\times}$ максимального порядка; 16 | \item публикует в общедоступном для всех участников месте параметры схемы $n$, $e$ и $g$. 17 | \end{itemize} 18 | \item Каждый из легальных участников: 19 | \begin{itemize} 20 | \item выбирает себе закрытый ключ $s_i$ и идентификатор $I_i$; 21 | \item вычисляет и отправляет доверенному центру\[v_i = g^{-s_i} \mod n;\] 22 | \item используя протокол аутентификации сторон (см. ниже) участник доказывает доверенному центру $T$, что владеет закрытым ключом, не раскрывая его значение; 23 | \item получает от доверенного центр свой открытый ключ: 24 | \[ P_i = (v_i - I_i)^d = (g^{-s_i} - I_i)^d \mod n; \] 25 | \end{itemize} 26 | В результате для каждого участника, например, Алисы, которая владеет $P_A, I_A, s_a$ будет выполняться утверждение: 27 | \[ P_A^e + I_A = g^{-s_A} \mod n. \] 28 | \end{itemize} 29 | 30 | \begin{figure} 31 | \centering 32 | \begin{sequencediagram} 33 | \newinst{Alice}{Alice} 34 | \newinst[3]{Bob}{Bob} 35 | 36 | \mess{Alice}{$ I_A, P_A, t = g^{R_A} \bmod n $}{Bob} 37 | \mess{Bob}{$ R_B $}{Alice} 38 | \mess{Alice}{$ y = R_A + s_A \times R_B \bmod n $}{Bob} 39 | \end{sequencediagram} 40 | \caption{Протокол аутентификации Жиро\label{fig:key_distribution-girault-auth}} 41 | \end{figure} 42 | 43 | Протокол аутентификации сторон в общем случае выглядит следующим образом (рис.~\ref{fig:key_distribution-girault-auth}). 44 | 45 | \begin{protocol} 46 | \item[(1)] Алиса выбирает случайное $R_A$. 47 | \item[{}] $Alice \to \left\{ I_A, P_A, t = g^{R_A} \bmod n \right\} \to Bob$ 48 | \item[(2)] Боб выбирает случайное $R_B$. 49 | \item[{}] $Bob \to \left\{ R_B \right\} \to Alice$ 50 | \item[(3)] $Alice \to \left\{ y = R_A + s_A \times R_B \bmod n \right\} \to Bob$ 51 | \item[(4)] Боб вычисляет $v_A = P_A^e + I_A \bmod n $; 52 | \item[{}] Боб проверяет, что $t = g^ y v_A^{R_B} \bmod n$. 53 | \end{protocol} 54 | 55 | \begin{figure} 56 | \centering 57 | \begin{sequencediagram} 58 | \newinst{Alice}{Alice} 59 | \newinst[3]{Bob}{Bob} 60 | 61 | \mess{Alice}{$ P_A, I_A $}{Bob} 62 | \mess{Bob}{$ P_B, I_B $}{Alice} 63 | \end{sequencediagram} 64 | \caption{Схема Жиро\label{fig:key_distribution-girault-scheme}} 65 | \end{figure} 66 | 67 | Протокол генерации сессионного ключа, называемый \emph{схемой Жиро}, как и другие схемы, состоит из проходов обмена открытой информацией и вычисления ключа (рис.~\ref{fig:key_distribution-girault-scheme}). 68 | 69 | \begin{protocol} 70 | \item[(1)] $Alice \to \left\{ P_A, I_A \right\} \to Bob$ 71 | \item[(2)] Боб вычисляет $K_{BA} = (P_A^e + I_A)^{s_B} \bmod n$. 72 | \item[{}] $Bob \to \left\{ P_B, I_B \right\} \to Alice$ 73 | \item[(3)] Алиса вычисляет $K_{AB} = (P_B^e + I_B)^{s_A} \bmod n$. 74 | \end{protocol} 75 | 76 | В результате работы схемы стороны сгенерировали одинаковый общий сеансовый ключ. 77 | \[ K_{AB} = (P_A^e + I_A)^{s_B} = (g^{-s_A})^{s_B} = g^{-s_As_B} \mod n; \] 78 | \[ K_{BA} = (P_B^e + I_B)^{s_A} = (g^{-s_B})^{s_A} = g^{-s_As_B} \mod n; \] 79 | \[ K = K_{AB} = K_{BA} = g^{-s_As_B} \mod n. \] 80 | 81 | Схема обеспечивает аутентификацию ключа (цель G7), так как только легальные пользователи смогут вычислить корректное значение общего сессионного ключа. 82 | 83 | \index{схема!Жиро|)} -------------------------------------------------------------------------------- /protocols/index.tex: -------------------------------------------------------------------------------- 1 | \chapter{Криптографические протоколы}\index{протокол!криптографический}\label{chapter-protocols} 2 | \selectlanguage{russian} 3 | 4 | \input{_settings} 5 | 6 | \input{definitions} 7 | 8 | \input{writing-rules} 9 | 10 | \input{properties} 11 | 12 | \input{classification} 13 | 14 | \input{attacks} 15 | 16 | \chapter{Распространение ключей}\label{chapter-key-distribution-protocols} 17 | 18 | Задача распространения ключей является одной из множества задач построения надёжной сети общения многих абонентов. Задача состоит в получении в нужный момент времени двумя легальными абонентами сети секретного сессионного ключа шифрования (и аутентификации сообщений). Хорошим решением данной задачи будем считать такой протокол распространения ключей, который удовлетворяет следующим условиям. 19 | 20 | \begin{itemize} 21 | \item В результате работы протокола между двумя абонентами должен быть сформирован секретный сессионный ключ. 22 | \item Успешное окончание протокола в том числе должно означать и успешную взаимную аутентификацию абонентов. Не должно быть такого, что протокол успешно завершился с точки зрения одной из сторон, а вторая сторона при этом представлена злоумышленником. 23 | \item К участию в работе протокола должны допускаться только легальные пользователи сети. Внешний пользователь не должен иметь возможность получить общий сессионный ключ с кем-либо из абонентов. 24 | \item Добавление нового абонента в сеть (или исключение из неё) не должно требовать уведомления всех участников сети. 25 | \end{itemize} 26 | 27 | Последнее требование сразу исключает такие варианты протоколов, в которых каждый из абонентов знал бы некоторый мастер-ключ общения с любым другим участником. Данные варианты плохи тем, что с ростом системы количество пар мастер-ключей <<абонент-абонент>> растёт как квадрат от количества участников. Поэтому большая часть рассматриваемых решений состоит в том, что в сети выделяется один или несколько доверенных центров T (\langen{Trent}, от \langen{trust}), которые как раз и владеют информацией обо всех легальных участниках сети и их ключах. Они же будут явно или неявно выступать одним из участников протоколов по формированию сеансовых ключей. 28 | 29 | \begin{figure}[!htb] 30 | \centering 31 | \includegraphics[width=0.8\textwidth]{pic/key_distribution-networks} 32 | \caption{Варианты сетей без выделенного доверенного центра и с выделенным доверенным центром T\label{fig:key_distribution-networks}} 33 | \end{figure} 34 | 35 | Если говорить о требованиях к данному классу протоколов с точки зрения свойств безопасности, то <<идеальный>> протокол распространения ключей должен реализовывать следующие цели: 36 | \begin{itemize} 37 | \item[G1] аутентификация сторон протокола; 38 | \item[G3] защита от повтора; 39 | \item[G7] аутентификация ключа; 40 | \item[G8] подтверждение владения [новым] ключом; 41 | \item[G9] совершенная прямая секретность; 42 | \item[G10] формирование новых ключей. 43 | \item[G11] ограниченная защита от атак отказа в обслуживании. 44 | \end{itemize} 45 | 46 | Разумеется, <<идеальный>> протокол должен быть устойчивым ко всем известным атакам, в том числе рассмотренным в разделе~\ref{section-protocols-attacks}. 47 | 48 | \subimport*{symmetric/}{index} 49 | 50 | \input{three-pass} 51 | 52 | \input{cryptosystems-protocols} 53 | 54 | \input{key-distribution-schemas} 55 | 56 | \input{asymmetric} 57 | 58 | \input{quantum} 59 | -------------------------------------------------------------------------------- /protocols/index_only.tex: -------------------------------------------------------------------------------- 1 | \input{../_settings} 2 | \addbibresource{../bibliography.bib} 3 | \begin{document} 4 | \selectlanguage{russian} 5 | 6 | \input{index} 7 | 8 | \printusedliterature 9 | 10 | \end{document} 11 | 12 | -------------------------------------------------------------------------------- /protocols/key-distribution-schemas.tex: -------------------------------------------------------------------------------- 1 | \section{Схемы с доверенным центром}\label{key-distribution-schemas}\index{схема!распределения ключей|(} 2 | \selectlanguage{russian} 3 | 4 | Схемы распределения ключей с доверенным центром состоят из трёх этапов. 5 | 6 | \begin{enumerate} 7 | \item На первом этапе доверенный центр создаёт некоторый секрет, известный только ему. Это может быть некоторая секретная матрица с особыми свойствами, как в схеме Блома\index{схема!Блома} из раздела~\ref{section-bloms-scheme}, или пара из закрытого и открытого ключей, как в схеме Жиро\index{схема!Жиро} из раздела~\ref{section-girault-scheme}. 8 | \item Для каждого нового легального участника сети доверенный центр, используя свою секретную информацию, вырабатывает некоторый отпечаток или сертификат, который позволяет новому участнику вырабатывать сеансовые ключи с другими легальными участниками. 9 | \item Наконец, на третьем этапе, когда начинается протокол общения двух легальных участников, они предъявляют друг-другу идентификаторы и/или дополнительную информацию от доверенного центра. Используя её, без дополнительного обращения к центру, они могут сгенерировать секретный сеансовый ключ для общения между собой. 10 | \end{enumerate} 11 | 12 | \input{girault_scheme} 13 | 14 | \input{bloms_scheme} 15 | 16 | \index{схема!распределения ключей|)} -------------------------------------------------------------------------------- /protocols/lo05.tex: -------------------------------------------------------------------------------- 1 | \subsection{Модификация Lo05} 2 | \selectlanguage{russian} 3 | 4 | В 2005 году Хои-Квоном Ло, Ксионфеном Ма и Кай Ченом (\langen{Hoi-Kwong Lo, Xiongfeng Ma, Kai Chen}, ~\cite{Lo:Ma:Chen:2004, Lo:Ma:Chen:2005}) была предложена модификация к квантовым протоколам, основанная на возможности обнаружения злоумышленника через измерение характеристик передаваемого сигнала (потока фотонов). 5 | 6 | Авторы обратили внимание, что защищённость квантовых протоколов BB84 и BB92 основывается на невозможности злоумышленником скопировать состояние единственного фотона. Если отправитель вместо передачи одного фотона будет передавать два и больше, это позволит злоумышленнику проводить атаки, связанные с разбиением мультифотонных сигналов. Одну копию фотона криптоаналитик будет сохранять себе, а Бобу отправлять вторую. Передачу же однофотонных состояний можно блокировать. 7 | 8 | Было предложено ослабить требование к генераторам сигнала (не требовать однофотонных состояний), а вместо этого использовать состояния-ловушки, измерение которых злоумышленником (в том числе с разбиением) можно будет отследить. 9 | 10 | Авторы не описывают конкретного протокола, но показывают, как их модификация позволяет добиться одновременно безусловной конфиденциальности передаваемой информации и наилучших экспериментальных результатов в скорости и дальности передачи информации по квантовым каналам связи. 11 | -------------------------------------------------------------------------------- /protocols/mti.tex: -------------------------------------------------------------------------------- 1 | \subsection{Протокол MTI/A(0)}\label{section-protocols-mti}\index{протокол!MTI/A(0)|(} 2 | \selectlanguage{russian} 3 | 4 | В 1986 году Ц.~Мацумото (\langen{Tsutomu Matsumoto}), И.~Такашима (\langen{Youichi Takashima}) и Х.~Имаи (\langen{Hideki Imai}) предложили несколько алгоритмов, позже названных семейством протоколов MTI (\cite{Matsumoto:Tsutomu:Imai:1986}). За счёт предварительного распространения открытых ключей обоих сторон они обеспечивали неявную аутентификацию ключа (цель G7). То есть сессионный ключ гарантированно мог получить только владельцы соответствующих открытых ключей. Мы рассмотрим одного из представителей данного семейства -- протокол MTI/A(0) (рис.~\ref{fig:key_distribution-mti}). 5 | 6 | Предварительно стороны договорились об общих параметрах системы $p$ и $g$, где $p$ -- большое простое число, а $g$ -- примитивный элемент поля $\Z_p^*$. 7 | 8 | Каждая из сторон (Алиса и Боб) сгенерировала пару из закрытого и открытого ключей: 9 | \[\begin{array}{ll} 10 | Alice: & ~ a, ~~ K_A = g^a \bmod p, \\ 11 | Bob: & ~ b, ~~ K_B = g^b \bmod p. \\ 12 | \end{array}\] 13 | 14 | \begin{figure} 15 | \centering 16 | \begin{sequencediagram} 17 | \newinst{Alice}{Alice} 18 | \newinst[2.5]{Bob}{Bob} 19 | 20 | \mess{Alice}{$ g^{R_A} \bmod p $}{Bob} 21 | \mess{Bob}{$ g^{R_B} \bmod p $}{Alice} 22 | \end{sequencediagram} 23 | \caption{Протокол MTI/A(0)\label{fig:key_distribution-mti}} 24 | \end{figure} 25 | 26 | \begin{protocol} 27 | \item[(1)] Алиса сгенерировала случайное число $R_A: ~ 2\leq R_A\leq p-1$ 28 | \item[{}] $ Alice \to \left\{ g^{R_A} \bmod p \right\} \to Bob$ 29 | \item[(2)] Боб сгенерировал случайное число $R_B: ~ 2\leq R_B\leq p-1$ 30 | \item[{}] Боб вычислил сеансовый ключ $K = (g^{R_A})^b \cdot K_A^{R_B} \bmod p$ 31 | \item[{}] $ Bob \to \left\{ g^{R_B} \bmod p \right\} \to Alice$ 32 | \item[(3)] Алиса вычислила сеансовый ключ $K = (g^{R_B})^a \cdot K_B^{R_A} \bmod p$ 33 | \end{protocol} 34 | 35 | Если открытые ключи $K_A$ и $K_B$ соответствуют своим закрытым ключам $a$ и $b$, то вычисленные участниками сессионные ключи совпадают: 36 | \[\begin{array}{lll} 37 | (g^{R_A})^b \cdot K_A^{R_B} \bmod p & = & g^{b R_A + a R_B} \bmod p, \\ 38 | (g^{R_B})^a \cdot K_B^{R_A} \bmod p & = & g^{a R_B + b R_A} \bmod p. 39 | \end{array}\] 40 | 41 | Из-за сложности задачи дискретного логарифмирования злоумышленник не сможет получить $a, R_A$ или $b, R_B$ из передаваемых сообщений, а предварительная публикация открытых ключей гарантирует, что сессионный ключ получат только легальные пользователи. Случайный выбор $R_A$ и $R_B$ гарантирует, что обе стороны могут быть уверены в создании нового сессионного ключа в каждом сеансе протокола. 42 | 43 | Как и другие представители криптосистем-протоколов, MTI не разрабатывался с учётом возможности компрометации закрытых <<мастер>>-ключей $a$ и $b$ (цель G9). 44 | 45 | \index{протокол!MTI/A(0)|)} -------------------------------------------------------------------------------- /protocols/pic/key_distribution-networks.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/protocols/pic/key_distribution-networks.pdf -------------------------------------------------------------------------------- /protocols/quantum.tex: -------------------------------------------------------------------------------- 1 | \section{Квантовые протоколы}\index{протокол!квантовые|(} 2 | \selectlanguage{russian} 3 | 4 | \input{bb84} 5 | 6 | \input{bb92} 7 | 8 | \input{lo05} 9 | 10 | \subsection{Общие недостатки квантовых протоколов} 11 | Подводя итоги, можно сказать, что квантовые протоколы распределения ключей (а именно ими пока что и ограничивается вся известная на сегодняшний день <<квантовая криптография>>) обладают как определёнными преимуществами, так и фатальными недостатками, затрудняющими их использование (и ставящими под вопрос саму эту необходимость). 12 | 13 | \begin{itemize} 14 | \item Любые квантовые протоколы (как и вообще любые квантовые вычисления) требуют оригинального дорогостоящего оборудования, которое пока что нельзя сделать частью com\-mo\-di\-ty-устройств или обычного сотового телефона. 15 | \item Квантовые каналы связи -- это всегда физические каналы связи. У них существует максимальная длина канала и определённый уровень ошибок. Для квантовых каналов (на сегодняшний день) не придумали <<повторителей>>, которые позволили бы увеличить длину безусловно квантовой передачи данных. 16 | \item Ни один квантовый протокол (на сегодняшний день) не может обходиться без дополнительного классического канала связи. Для такого связи требуются как минимум такой же уровень защиты, как и при использовании, например, криптографии с открытым ключом. 17 | \item Для всех протоколов особую проблему представляет не только доказательство корректности (что является весьма нетривиальным делом в случае наличия <<добросовестных>> помех), но и инженерная задача по реализации протокола в <<железе>>. 18 | \end{itemize} 19 | 20 | \index{протокол!квантовые|)} 21 | 22 | -------------------------------------------------------------------------------- /protocols/symmetric/index.tex: -------------------------------------------------------------------------------- 1 | \section{Симметричные протоколы} 2 | \selectlanguage{russian} 3 | 4 | Как отмечено ранее в разделе~\ref{section-protocols-classification} про классификацию протоколов, к симметричным будем относить те протоколы, которые используют примитивы только классической криптографии на секретных ключах. К ним относятся уже известные блочные шифры, криптографически стойкие генераторы псевдослучайных чисел (КСГПСЧ) и хеш-функции. 5 | 6 | \input{wide-mouth_frog} 7 | 8 | \input{yahalom} 9 | 10 | \input{needham-schroeder} 11 | 12 | \input{kerberos} 13 | -------------------------------------------------------------------------------- /protocols/symmetric/index_only.tex: -------------------------------------------------------------------------------- 1 | \input{../../_settings} 2 | \input{../_settings} 3 | \addbibresource{../../bibliography.bib} 4 | \begin{document} 5 | \selectlanguage{russian} 6 | 7 | \input{index} 8 | 9 | \printusedliterature 10 | 11 | \end{document} 12 | 13 | -------------------------------------------------------------------------------- /protocols/symmetric/kerberos.tex: -------------------------------------------------------------------------------- 1 | \subsection{Протокол <>}\index{протокол!Kerberos|(}\label{section-protocols-kerberos} 2 | \selectlanguage{russian} 3 | 4 | В данном разделе будет описан протокол аутентификации сторон с единственным доверенным центром. Сетевой протокол <> использует эти идеи при объединении нескольких доверенных центров в единую сеть для обеспечения надёжности и отказоустойчивости. Подробнее о сетевом протоколе <> смотрите в разделе~\ref{sec:kerberos}. 5 | 6 | \begin{figure} 7 | \centering 8 | \begin{sequencediagram} 9 | \newinst{Alice}{Alice} 10 | \newinst[2.5]{Trent}{Trent} 11 | \newinst[2.5]{Bob}{Bob} 12 | 13 | \mess{Alice}{$ A, B $}{Trent} 14 | \mess{Trent}{$ E_A \left( T_T, L, K, B \right), E_B \left( T_T, L, K, A \right) $}{Alice} 15 | \mess{Alice}{$ E_B \left( T_T, L, K, A \right), E_K \left( A, T_A \right) $}{Bob} 16 | \mess{Bob}{$ E_K \left( T_T + 1 \right) $}{Alice} 17 | \end{sequencediagram} 18 | \caption{Протокол <>\label{fig:key_distribution-kerberos}} 19 | \end{figure} 20 | 21 | Как и в протоколе Нидхема~---~Шрёдера, инициирующий абонент (Алиса) общается только с выделенным доверенным центром, получая от него два пакета с зашифрованным сессионным ключом -- один для себя, а второй -- для вызываемого абонента (Боба). Однако в отличие от Нидхема~---~Шрёдера\index{протокол!Нидхема~---~Шрёдера} в рассматриваемом протоколе зашифрованные пакеты содержат также метку времени $T_T$ и срок действия сессионного ключа $L$ (от \langen{lifetime} -- срок жизни). Что позволяет, во-первых, защититься от рассмотренной в предыдущем разделе атаки повтором. А, во-вторых, позволяет доверенному центру в некотором смысле управлять абонентами, заставляя их получать новые сессионные ключи по истечению заранее заданного времени $L$. 22 | 23 | \begin{protocol} 24 | \item[(1)] $ Alice \to \{ A, B \} \to Trent $ 25 | \item[(2)] $ Trent \to \{ E_A \left( T_T, L, K, B \right), E_B \left( T_T, L, K, A \right) \} \to Alice $ 26 | \item[(3)] $ Alice \to \{ E_B \left( T_T, L, K, A \right), E_K \left( A, T_A \right) \} \to Bob $ 27 | \item[(4)] $ Bob \to \{ E_K \left( T_T + 1 \right) \} \to Alice $ 28 | \end{protocol} 29 | 30 | Обратите внимание, что на третьем проходе за счёт использования метки времени от доверенного центра $T_T$ вместо случайной метки от Боба $R_B$ позволяет сократить количество проходов на один по сравнению с протоколом Нидхема~---~Шрёдера\index{протокол!Нидхема~---~Шрёдера}. Также наличие метки времени делает ненужным и предварительную генерацию случайной метки Алисой и её передачу на первом шаге. 31 | 32 | Метка времени $T_A$ в сообщении $E_K \left( A, T_A \right)$ позволяет Бобу убедиться, что Алиса владеет текущим сессионным ключом $K$. Если расшифрованная метка $T_A$ сильно отличается от текущего времени, значит либо этот пакет из другого сеанса протокола, либо не от Алисы вообще. 33 | 34 | Пакеты $E_A \left( T_T, L, K, B \right)$ и $E_B \left( T_T, L, K, A \right)$ одинаковы по своему формату. В некотором смысле их можно назвать сертификатами сессионного ключа для Алисы и Боба. Причём все подобные пары пакетов можно сгенерировать заранее (например, в начале дня), выложить на общедоступный ресурс, предоставить в свободное использование и выключить доверенный центр (он своё дело уже сделал -- сгенерировав эти пакеты). И до момента времени $T_T + L$ этими <<сертификатами>> можно пользоваться. Но только если вы являетесь одной из допустимых пар абонентов. Конечно, эта идея непрактична -- ведь количество таких пар растёт как квадрат от числа абонентов. Однако интересен тот факт, что подобные пакеты можно сгенерировать заранее. Эта идея нам пригодится при рассмотрении инфраструктуры открытых ключей (\langen{public key infrastructure, PKI}). 35 | 36 | \index{протокол!Kerberos|)} -------------------------------------------------------------------------------- /protocols/symmetric/yahalom.tex: -------------------------------------------------------------------------------- 1 | \subsection{Протокол Yahalom}\index{протокол!Yahalom|(}\label{section-protocols-yahalom} 2 | 3 | \begin{figure} 4 | \centering 5 | \begin{sequencediagram} 6 | \newinst{Alice}{Alice} 7 | \newinst[2.5]{Trent}{Trent} 8 | \newinst[2.5]{Bob}{Bob} 9 | 10 | \mess{Alice}{$A$, $R_A$}{Bob} 11 | \mess{Bob}{$ B, E_B( A, R_A, R_B ) $}{Trent} 12 | \mess{Trent}{$ E_A( B, K, R_A, R_B )$, $E_B(A, K) $}{Alice} 13 | \mess{Alice}{$E_B( A, K )$, $E_K( R_B )$}{Bob} 14 | \end{sequencediagram} 15 | \caption{Протокол Yahalom\label{fig:key_distribution-yahalom}} 16 | \end{figure} 17 | 18 | Протокол Yahalom можно рассматривать как улучшенную версию протокола Wide-Mouth Frog\index{протокол!Wide-Mouth Frog} из раздела~\ref{section-protocols-wide-moth-frog}. Данный протокол <<перекладывает>> генерацию нового сессионного ключа на сторону доверенного центра, а также использует случайные числа для защиты от атак повтором. 19 | 20 | \begin{protocol} 21 | \item[(1)] $Alice \to \{ A, R_A \} \to Bob$ 22 | \item[(2)] $Bob \to \{ B, E_B( A, R_A, R_B ) \} \to Trent$ 23 | \item[(3)] Трент генерирует новый сессионный ключ $K$ 24 | \item[{}] $Trent \to \{ E_A( B, K, R_A, R_B ), E_B(A, K) \} \to Alice$ 25 | \item[(4)] $Alice \to \{ E_B( A, K ), E_K( R_B ) \} \to Bob$ 26 | \end{protocol} 27 | 28 | После того, как Боб провалидирует число $R_B$, присланное Алисой, стороны смогут использовать новый сессионный ключ $K$. Протокол, кроме генерации ключа, обеспечивает взаимную аутентификацию сторон: 29 | 30 | \begin{itemize} 31 | \item Аутентификация Алисы перед Бобом происходит на 4-м проходе, когда Боб может провалидировать возможность Алисы зашифровать известное только ей (и Тренту) случайное число $R_B$ на ключе $K$. 32 | \item Аутентификация Боба перед Алисой происходит на 3-м проходе, когда Трент демонстрирует Алисе, что он получил случайное число $R_A$ именно от Боба. 33 | \end{itemize} 34 | 35 | Нужно отметить (\cite{Zhou:Yu:Pan:Wang:2016}), что в рамках протокола Боб никак не продемонстрировал, что он успешно получил новый сессионный ключ $K$ и может им оперировать (не выполнена цель G8). Сообщение от Алисы на 4-м проходе могло быть перехвачено или модифицировано злоумышленником. Но никакого ответа Алиса от Боба уже не ожидает и уверена, что протокол завершился успешно. 36 | 37 | \begin{figure}[thb] 38 | \centering 39 | \begin{sequencediagram} 40 | \newinst{Alice}{Alice} 41 | \newinst[2.5]{Trent}{Trent} 42 | \newinst[2.5]{Bob}{Bob} 43 | 44 | \mess{Alice}{$A$, $R_{A2}$}{Bob} 45 | \mess{Bob}{$ B, E_B( A, R_{A2}, R_{B2} ) $}{Trent} 46 | \mess{Trent}{$ E_A( B, K_2, R_{A2}, R_{B2} )$, $E_B(A, K_2) $}{Alice} 47 | \mess{Alice}{$E_B( A, K_1 )$, $E_{K_1}( R_{B2} )$}{Bob} 48 | \end{sequencediagram} 49 | \caption{Атака на протокол Yahalom\label{fig:key_distribution-yahalom-attack}} 50 | \end{figure} 51 | 52 | Также на 3-м проходе Трент не включает случайное число $R_B$ в сообщение $E_B(A, K)$, что позволяет Алисе, действуя не из лучших побуждений, заставить Боба принять старый сессионный ключ (рис.~\ref{fig:key_distribution-yahalom-attack}). 53 | 54 | \begin{protocol} 55 | \item[(1)] $Alice \to \{ A, R_A \} \to Bob$ 56 | \item[(2)] $Bob \to \{ B, E_B( A, R_A, R_B ) \} \to Trent$ 57 | \item[(3)] Трент генерирует новый сессионный ключ $K_2$ 58 | \item[{}] $Trent \to \{ E_A( B, K, R_A, R_B ), E_B(A, K_2) \} \to Alice$ 59 | \item[(4)] Алиса использует старый сессионный ключ $K_1$ и сообщение $E_B( A, K_1 )$ из старого сеанса протокола 60 | \item[{}] $Alice \to \{ E_B( A, K_1 ), E_{K_2}( R_B ) \} \to Bob$ 61 | \end{protocol} 62 | 63 | Протокол Yahalom послужил основной большому количеству научных работ, связанных с автоматизированным анализом стойкости криптографических протоколов и имел несколько <<улучшенных>> вариантов. Однако о широком использовании данного протокола в реальных информационных системах неизвестно. 64 | 65 | \index{протокол!Yahalom|)} 66 | -------------------------------------------------------------------------------- /protocols/woo-lam.tex: -------------------------------------------------------------------------------- 1 | \subsection{Протокол Ву~---~Лама}\index{протокол!Ву~---~Лама|(}\label{section-woo-lam} 2 | \selectlanguage{russian} 3 | 4 | \begin{figure} 5 | \centering 6 | \begin{sequencediagram} 7 | \newinst{Alice}{Alice} 8 | \newinst[1.5]{Trent}{Trent} 9 | \newinst[4]{Bob}{Bob} 10 | 11 | \begin{call}{Alice}{ $A, B$ }{Trent} 12 | {$S_T( K_B )$}\end{call} 13 | \mess{Alice}{$ E_B ( A, R_A ) $}{Bob} 14 | \begin{call}{Bob}{$A, B, E_T( R_A )$}{Trent} 15 | { $S_T( K_A ), E_B ( S_T ( R_A, K, A, B ) )$ }\end{call} 16 | \mess{Bob}{$ E_A (S_T (R_A, K, A, B), R_B) $}{Alice} 17 | \mess{Alice}{$ E_K( R_B ) $}{Bob} 18 | \end{sequencediagram} 19 | \caption{Протокол Ву~---~Лама\label{fig:woo-lam}} 20 | \end{figure} 21 | 22 | Протокол Ву~---~Лама, предложенный в 1992 году (\langen{Thomas Y. C. Woo, Simon S. Lam},~\cite{Woo:Lam:1992:1, Woo:Lam:1992:3}, рис.~\ref{fig:woo-lam}), добавляет к сообщениям случайные числа участников, что позволяет защитить протокол в том числе от атак повтором, а также обеспечивает подтверждение владения ключами. 23 | 24 | Также это единственный из рассмотренных в этом разделе протоколов, в котором новый ключ формируется доверенной стороной (Трентом). 25 | 26 | \begin{protocol} 27 | \item[(1)] $Alice \to \left\{ A, B \right\} \to Trent$ 28 | \item[(2)] $Trent \to \left\{ S_T( K_B ) \right\} \to Alice$ 29 | \item[(3)] $Alice \to \left\{ E_B ( A, R_A ) \right\} \to Bob$ 30 | \item[(4)] $Bob \to \left\{ A, B, E_T( R_A ) \right\} \to Trent$ 31 | \item[(5)] $Trent \to \left\{ S_T( K_A ), E_B ( S_T ( R_A, K, A, B ) ) \right\} \to Bob$ 32 | \item[(6)] $Bob \to \left\{ E_A (S_T (R_A, K, A, B), R_B) \right\} \to Alice$ 33 | \item[(7)] $Alice \to \left\{ E_K( R_B ) \right\} \to Bob$ 34 | \end{protocol} 35 | 36 | Так как в сертификате сессионного ключа $S_T (R_A, K, A, B)$ присутствует случайное число Алисы $R_A$, то злоумышленник не сможет использовать старый сертификат в новом сеансе от имени Боба. Следовательно 6-й проход протокола позволяет Алисе убедиться, что Боб знает новый сессионный ключ $K$, и, следовательно владеет своим <<мастер>>-ключом $K_B$ (так как это единственный способ получить сертификат из сообщения $E_B ( S_T ( R_A, K, A, B ) ))$). 37 | 38 | Сообщение $E_K( R_B )$ от Алисы к Бобу на седьмом проходе позволяет одновременно гарантировать, что Алиса знает и свой <<мас\-тер>>-ключ $K_A$ (так как смогла расшифровать $E_A(\dots, R_B)$), и новый сессионный ключ $K$, так как смогла корректно зашифровать $R_B$ этим ключом. 39 | 40 | \index{протокол!Ву~---~Лама|)} -------------------------------------------------------------------------------- /public-key/ECIES.tex: -------------------------------------------------------------------------------- 1 | \subsection{ECIES} 2 | \selectlanguage{russian} 3 | 4 | Схема ECIES (\langen{Elliptic Curve Integrated Encryption Scheme}) является частью сразу нескольких стандартов, в том числе ANSI X9.63, IEEE 1363a, ISO 18033-2 и SECG SEC 1. Эти стандарты по-разному описывают выбор параметров схемы~\cite{Martinez:Encinas:Avila:2010}: 5 | 6 | \begin{itemize} 7 | \item ENC (\langen{Encryption}) -- блочный режим шифрования (в том числе простое гаммирование, 3DES\index{шифр!3DES}, AES\index{шифр!AES}, MISTY1\index{шифр!MISTY1}, CAST-128\index{шифр!CAST-128}, Camelia\index{шифр!Camelia}, SEED\index{шифр!SEED}); 8 | \item KA (\langen{Key Agreement}) -- метод для генерации общего секрета двумя сторонами (оригинальный метод, описанный в протоколе Диффи~---~Хеллмана\index{протокол!Диффи~---~Хеллмана}~\cite{Diffie:Hellman:1976} либо его модификации~\cite{Miller:1986}); 9 | \item KDF (\langen{Key Derivation Function}) -- метод получения ключей из основной и дополнительной информации; 10 | \item HASH -- криптографическая хеш-функция (SHA-1\index{хеш-функция!SHA-1}, SHA-2\index{хеш-функция!SHA-2}, RIPEMD\index{хеш-функция!RIPEMD}, WHIRLPOOL\index{хеш-функция!WHIRLPOOL}); 11 | \item MAC (\langen{Message Authentication Code}) -- функция вычисления имитовставки\index{имитовставка} (DEA, ANSI X9.71, MAC1, HMAC-SHA-1, HMAC-SHA-2, HMAC-RIPEMD, CMAC-AES). 12 | \end{itemize} 13 | 14 | К параметрам относится выбор группы точек над эллиптической кривой $\group{E}$, а также некоторой большой циклической подгруппы $\group{G}$ в группе $\group{E}$, задаваемой точкой-генератором $G$. Мощность циклической группы обозначается $n$. 15 | \[n = \left\| \group{G} \right\|.\] 16 | 17 | Предположим, что в нашем сценарии Алиса хочет послать сообщение Бобу. У Алисы есть открытый ключ Боба $P_B$, а у Боба -- соответствующий ему закрытый ключ $p_B$. Для отправки сообщения Алиса также сгенерирует временную (\langen{ephemeral}) пару из открытого ($P_A$) и закрытого ($p_A$) ключей. Закрытыми ключами являются некоторые натуральные числа, меньшие $n$, а открытыми ключами являются произведения закрытых на точку-генератор $G$: 18 | \[ \begin{array}{ll} 19 | p_A \in \Z, & p_B \in \Z, \\ 20 | 1 < p_A < n, & 1 < p_B < n, \\ 21 | P_A = p_A \times G, & P_B = p_B \times G, \\ 22 | P_A \in \group{G} \in \group{E}, & P_B \in \group{G} \in \group{E}.\\ 23 | \end{array} \] 24 | 25 | \begin{enumerate} 26 | \item С помощью метода генерации общего секрета KA Алиса вычисляет общий секрет $s$. В случае использования оригинального протокола Диффи~---~Хеллмана\index{протокол!Диффи~---~Хеллмана} общим секретом будет являться результат умножения закрытого ключа Алисы на открытый ключ Боба $s = p_a \times P_B$. 27 | \item Используя полученный общий секрет $s$ и метод получения ключей из ключевой и дополнительной информации KDF, Алиса получает ключ шифрования $k_{ENC}$, а также ключ для вычисления имитовставки $k_{MAC}$. 28 | \item С помощью симметричного алгоритма шифрования ENC Алиса шифрует открытое сообщение $m$ ключом $k_{ENC}$ и получает шифртекст $c$. 29 | \item Взяв ключ $k_{MAC}$, зашифрованное сообщение $c$ и другие заранее обговорённые сторонами параметры, Алиса вычисляет тэг сообщения (\langen{tag}) с помощью функции MAC. 30 | \item Алиса отсылает Бобу $\{P_A, tag, c\}$. 31 | \end{enumerate} 32 | 33 | В процессе расшифрования Боб последовательно получает общий секрет $s = p_b \times P_A$, ключи шифрования $k_{ENC}$ и имитовставки $k_{MAC}$, вычисляет тэг сообщения и сверяет его с полученным тэгом. В случае совпадения вычисленного и полученного тэгов Боб расшифровывает исходное сообщение $m$ из шифртекста $c$ с помощью ключа шифрования $k_{ENC}$. 34 | -------------------------------------------------------------------------------- /public-key/EdDSA.tex: -------------------------------------------------------------------------------- 1 | \subsection{EdDSA и Ed25519}\label{sec:EdDSA}\label{sec:Ed25519} 2 | \selectlanguage{russian} 3 | 4 | Схема цифровой подписи EdDSA использует эллиптическую кривую, представленную в скрученной форме Эдвардса (см. раздел~\ref{sec:twisted-edward-curves}). В данной схеме используются следующие параметры: 5 | 6 | \begin{itemize} 7 | \item конечное поле $\F_{p}$, где $p$ -- большое простое число; 8 | \item группа точек эллиптической кривой в скрученной форме Эдвардса $E$ над полем $\F_{p}$ порядка $Ord(E) = 2^c l$, где $l$ -- большое простое число, $c$ -- целое; 9 | \item точка, генератор $G$ циклической подгруппы порядка $l$; 10 | \item криптографическая хеш-функция $H$, имеющая выход $2b$ бит, $b > 1 + log_2 p$, чтобы элементы поля $\F_{p}$ и координаты точек $E$ могли быть представлены в виде $b$-битовых строк. 11 | \end{itemize} 12 | 13 | Параметр $l$ должен быть достаточно большим, чтобы $\rho$-метод Полларда для дискретного логарифмирования требовал большого количества операций для вычисления <<логарифма>> -- не менее $\sqrt{l \pi / 4}$ сложений точек в группе. Рекомендуется, чтобы значение $l$ превышало $2^{200}$ -- для получения не менее $\approx 2^{99{,}8}$ сложений точек в $\rho$-методе Полларда. 14 | 15 | В качестве закрытого ключа каждый участник выбирает некоторую $b$-битовую строку $k$. Данная строка хешируется выбранной криптографической хеш-функцией $H$, после чего последние $b$-бит трактуются как целое число в кодировке \foreignlanguage{english}{\textit{little endian}} $s$ и формируется открытый ключ $A \in E$: 16 | 17 | \[ \begin{array}{l} 18 | s = H_{0, \dots, b-1}(k),\\ 19 | A = s \times G. 20 | \end{array} \] 21 | 22 | Электронная цифровая подпись $(R, S)$ вычисляется следующим образом: 23 | 24 | \begin{enumerate} 25 | \item $r = H( H_{b,\dots,2b-1}(k) \| M )$ -- аналог случайного параметра $k$ из схемы электронной цифровой подписи Эль-Гамаля; 26 | \item $R = r \times G$; 27 | \item $S = r + H( R \| A \| M ) \times s \bmod l$; 28 | \end{enumerate} 29 | 30 | Для валидации подписи получатель, знающий параметры схемы и открытый ключ отправителя $A$, проверяет выполнение равенства: 31 | 32 | \[ 33 | 2^c S \times G = 2^c \times R + 2^c H( R \| A \| M ) \times A. 34 | \] 35 | 36 | Корректность схемы можно проверить через раскрытие значения $S$: 37 | 38 | \[ \begin{array}{ll} 39 | 2^c S \times G & = 2^c ( r + H( R \| A \| M ) \times s ) \times G = \\ 40 | & = 2^c r \times G + 2^c H( R \| A \| M ) s \times G = \\ 41 | & = 2^c R + 2^c H( R \| A \| M ) \times A. 42 | \end{array} \] 43 | 44 | Ed25519 задаёт конкретные параметры схемы EdDSA следующим образом (\cite{Bernstein:Duif:Lange:Schwabe:Yang:2011}): 45 | 46 | \begin{itemize} 47 | \item порядок конечного поля является простым числом $p = 2^{255}-19$; 48 | \item коэффициенты эллиптической кривой в скрученной форме Эдвардса $e = -1$ и $d = \frac{121665}{121666}$: 49 | \[ 50 | -x^2 + y^2 = 1 - \frac{121665}{121666}x^2y^2 \mod p; 51 | \] 52 | \item базовая точка $G$ имеет координату $y = 4/5 \bmod q$, координата $x$ -- положительная; 53 | \item порядок базовой точки $G$ является большим простым числом и равен $l = 2^{252} + 27742317777372353535851937790883648493$; 54 | \item криптографическая хеш-функция SHA-256\index{хеш-функция!SHA-256} ($b = 256$). 55 | \end{itemize} 56 | 57 | Выбранная группа точек бирационально эквивалентна группе точек над эллиптической кривой в форме Монтгомери Curve25519 (\cite{Bernstein:2006}). Выбранная базовая точка также соответствует базовой точке, предложенной для Curve25519. Так как сложения в скрученной форме Эдвардса выполняются быстрее, чем в форме Вейерштрасса и в форме Монтгомери, группу Ed25519 можно использовать для ускорения вычислений в тех случаях, когда в качестве параметров выбрана группа точек кривой Curve25519. 58 | 59 | Схема EdDSA с параметрами Ed25519 используется (\cite{IANIX:Ed25519:2021}) в защищённых сетевых протоколах (SSH\index{протокол!SSH}, I2P\index{протокол!I2P}, IPSec\index{протокол!IPSec}, Tor\index{протокол!Tor}), криптографических библиотеках (GnuPG, Java 15 JCE, OpenSSH 6.5) и стандартах (S/MIME 4.0). 60 | -------------------------------------------------------------------------------- /public-key/GOST_R_34.10-2001.tex: -------------------------------------------------------------------------------- 1 | \subsection[Российский стандарт ЭП ГОСТ Р 34.10-2001]{Российский стандарт ЭП \protect\\ ГОСТ Р 34.10-2001} 2 | \selectlanguage{russian} 3 | 4 | Пусть имеются две стороны $A$ и $B$ и канал связи между ними. Сторона $A$ желает передать сообщение $M$ стороне $B$ и подписать его. Сторона $B$ должна проверить правильность подписи, то есть аутентифицировать сторону $A$. 5 | 6 | $A$ формирует открытый ключ следующим образом. 7 | 8 | \begin{enumerate} 9 | \item Выбирает простое\index{число!простое} число $p > 2^{255}$. 10 | \item Записывает уравнение эллиптической кривой: 11 | \[ E: ~ y^2 = x^3 + a x + b \mod p, \] 12 | которое определяет группу точек эллиптической кривой $\E(\Z_p)$. 13 | Выбирает группу, задавая либо случайные числа $0 < a, b < p-1$, либо инвариант $J(E)$: 14 | \[ J(E) = 1728 \frac{4 a^3}{4 a^3 + 27 b^2} \mod p. \] 15 | Если кривая задаётся инвариантом $J(E) \in \Z_p$, то он выбирается случайно из интервала $0 < J(E) < 1728$. Для нахождения $a,b$ вычисляется 16 | \[ K = \frac{J(E)}{1728 - J(E)}, \] 17 | \[ \begin{array}{l} 18 | a = 3 K \mod p, \\ 19 | b = 2 K \mod p. \\ 20 | \end{array} \] 21 | \item Пусть $m$ -- порядок группы точек эллиптической кривой $\E(\Z_p)$. ~Пользователь $A$ подбирает число $n$ и простое\index{число!простое} число $q$ такие, что 22 | \[ m = n q, ~ 2^{254} < q < 2^{256}, ~ n \geq 1, \] 23 | где $q$ -- делитель порядка группы. 24 | 25 | В циклической подгруппе порядка $q$ выбирается точка 26 | \[ P \in \E(\Z_p): ~ q P \equiv 0. \] 27 | \item Случайно выбирает число $d$ и вычисляет точку $Q = d P$. 28 | \item Формирует закрытый и открытый ключи: 29 | \[ \SK = (d), ~ \PK = (p, E, q, P, Q). \] 30 | \end{enumerate} 31 | 32 | Теперь сторона $A$ создаёт свою цифровую подпись $S(M)$ сообщения $M$, выполняя следующие действия. 33 | \begin{enumerate} 34 | \item Вычисляет $\alpha = h(M)$, где $h$ -- криптографическая хеш-функ\-ция, определённая стандартом ГОСТ Р 34.11-94. В российском стандарте длина $h(M)$ равна 256 бит. 35 | \item Вычисляет $e = \alpha \mod q$. 36 | \item Случайно выбирает число $k$ и вычисляет точку 37 | \[ C = k P = (x_c, y_c). \] 38 | \item Вычисляет $r = x_c \mod q$. 39 | Если $r = 0$, то выбирает другое $k$. 40 | \item Вычисляет $s = k e + r d \mod q$. 41 | \item Формирует подпись 42 | \[ S(M) = (r, s). \] 43 | \end{enumerate} 44 | Сторона $A$ передаёт стороне $B$ сообщение с подписью 45 | \[ (M, ~ S(M)). \] 46 | 47 | Сторона $B$ проверяет подпись $(r,s)$, выполняя процедуру проверки подписи. 48 | \begin{enumerate} 49 | \item Вычисляет $\alpha = h(M)$ и $e = \alpha \mod q$. Если $e = 0$, то определяет $e = 1$. 50 | \item Вычисляет $e^{-1} \mod q$. 51 | \item Проверяет условия $r < q, ~ r < s$. Если эти условия не выполняются, то подпись отвергается. Если условия выполняются, то процедура продолжается. 52 | \item Вычисляет переменные: 53 | \[ \begin{array}{l} 54 | a = s e^{-1} \mod q, \\ 55 | b = -r e^{-1} \mod q. \\ 56 | \end{array} \] 57 | \item Вычисляет точку: 58 | \[ \tilde{C} = a P + b Q = (\tilde{x}_c, \tilde{y}_c). \] 59 | Если подпись верна, то должны получить исходную точку $C$. 60 | \item Проверяет условие $\tilde{x}_{c} \mod q = r$. Если условие выполняется, то подпись принимается, в противном случае -- отвергается. 61 | \end{enumerate} 62 | 63 | Рассмотрим вычислительную сложность вскрытия подписи. Предположим, что криптоаналитик ставит своей задачей определение закрытого ключа $d$. Как известно, эта задача является трудной. Для подтверждения этого можно привести такой факт. Был поставлен следующий эксперимент: выбрали число $p = 2^{97}$ и 1200 персональных компьютеров, которые работали над этой задачей в 16 странах мира, используя процессоры с тактовой частотой 200 МГц. Задача была решена за 53 дня круглосуточной работы. Если взять $p = 2^{256}$, то на решение такой задачи при наличии одного компьютера с частотой процессора 2 ГГц потребуется $10^{22}$ лет. 64 | -------------------------------------------------------------------------------- /public-key/elliptic_curve_cryptography.tex: -------------------------------------------------------------------------------- 1 | \section{Эллиптические кривые}\label{section-elliptic-curve-cryptosystems} 2 | \selectlanguage{russian} 3 | 4 | Существуют аналоги криптосистемы Эль-Гамаля, в которых вместо проблемы дискретного логарифма в мультипликативных полях используется проблема дискретного логарифма в группах точек эллиптических кривых над конечными полями (обычно $GF(p)$ либо $GF(2^n)$). Математическое описание данных полей приведено в разделе~\ref{section-math-ec-groups}. Нас же интересует следующий факт: для группы точек эллиптической кривой над конечным полем $\group{E}$ существует быстро выполнимая операция -- умножение целого числа $x$ на точку $A$ (суммирование точки самой с собой целое число раз): 5 | \[ \begin{array}{l} 6 | x \in \group{Z}, \\ 7 | A, B \in \group{E}, \\ 8 | B = x \times A. \\ 9 | \end{array} \] 10 | 11 | И получение исходной точки $A$ при известных $B$ и $x$ (<<деление>> точки на целое число), и получение целого числа $x$ при известных $A$ и $B$ являются сложными задачами. На этом и основаны алгоритмы шифрования и электронной подписи с использованием эллиптических кривых над конечными полями. 12 | 13 | \input{ECIES.tex} 14 | 15 | \input{GOST_R_34.10-2001.tex} 16 | 17 | \input{EdDSA.tex} -------------------------------------------------------------------------------- /public-key/index_only.tex: -------------------------------------------------------------------------------- 1 | \input{../_settings} 2 | \addbibresource{../bibliography.bib} 3 | \begin{document} 4 | \selectlanguage{russian} 5 | 6 | \input{index} 7 | 8 | \printusedliterature 9 | 10 | \end{document} 11 | 12 | -------------------------------------------------------------------------------- /public-key/pic/X509-hierarchy.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/public-key/pic/X509-hierarchy.pdf -------------------------------------------------------------------------------- /public-key/pic/X509-hierarchy.vsd: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/public-key/pic/X509-hierarchy.vsd -------------------------------------------------------------------------------- /public-key/x509.tex: -------------------------------------------------------------------------------- 1 | \subsection{Структура сертификата X.509} 2 | \selectlanguage{russian} 3 | 4 | Ниже приведён пример сертификата X.509\index{сертификат!X509}, использовавшегося интернет-сервисом mail.google.com для предоставления защищённого SSL-соединения в 2009 г. Сертификат напечатан командой \texttt{openssl x509 -in file.crt -noout -text}: 5 | 6 | {\small \begin{verbatim} 7 | Certificate: 8 | Data: 9 | Version: 3 (0x2) 10 | Serial Number: 11 | 6e:df:0d:94:99:fd:45:33:dd:12:97:fc:42:a9:3b:e1 12 | Signature Algorithm: sha1WithRSAEncryption 13 | Issuer: C=ZA, O=Thawte Consulting (Pty) Ltd., 14 | CN=Thawte SGC CA 15 | Validity 16 | Not Before: Mar 25 16:49:29 2009 GMT 17 | Not After : Mar 25 16:49:29 2010 GMT 18 | Subject: C=US, ST=California, L=Mountain View, O=Google Inc, 19 | CN=mail.google.com 20 | Subject Public Key Info: 21 | Public Key Algorithm: rsaEncryption 22 | RSA Public Key: (1024 bit) 23 | Modulus (1024 bit): 24 | 00:c5:d6:f8:92:fc:ca:f5:61:4b:06:41:49:e8:0a: 25 | 2c:95:81:a2:18:ef:41:ec:35:bd:7a:58:12:5a:e7: 26 | 6f:9e:a5:4d:dc:89:3a:bb:eb:02:9f:6b:73:61:6b: 27 | f0:ff:d8:68:79:1f:ba:7a:f9:c4:ae:bf:37:06:ba: 28 | 3e:ea:ee:d2:74:35:b4:dd:cf:b1:57:c0:5f:35:1d: 29 | 66:aa:87:fe:e0:de:07:2d:66:d7:73:af:fb:d3:6a: 30 | b7:8b:ef:09:0e:0c:c8:61:a9:03:ac:90:dd:98:b5: 31 | 1c:9c:41:56:6c:01:7f:0b:ee:c3:bf:f3:91:05:1f: 32 | fb:a0:f5:cc:68:50:ad:2a:59 33 | Exponent: 65537 (0x10001) 34 | X509v3 extensions: 35 | X509v3 Extended Key Usage: TLS Web Server 36 | Authentication, TLS Web Client Authentication, 37 | Netscape Server Gated Crypto 38 | X509v3 CRL Distribution Points: 39 | URI:http://crl.thawte.com/ThawteSGCCA.crl 40 | Authority Information Access: 41 | OCSP - URI:http://ocsp.thawte.com 42 | CA Issuers - URI:http://www.thawte.com/repository/ 43 | Thawte_SGC_CA.crt 44 | X509v3 Basic Constraints: critical 45 | CA:FALSE 46 | Signature Algorithm: sha1WithRSAEncryption 47 | 62:f1:f3:05:0e:bc:10:5e:49:7c:7a:ed:f8:7e:24:d2:f4:a9: 48 | 86:bb:3b:83:7b:d1:9b:91:eb:ca:d9:8b:06:59:92:f6:bd:2b: 49 | 49:b7:d6:d3:cb:2e:42:7a:99:d6:06:c7:b1:d4:63:52:52:7f: 50 | ac:39:e6:a8:b6:72:6d:e5:bf:70:21:2a:52:cb:a0:76:34:a5: 51 | e3:32:01:1b:d1:86:8e:78:eb:5e:3c:93:cf:03:07:22:76:78: 52 | 6f:20:74:94:fe:aa:0e:d9:d5:3b:21:10:a7:65:71:f9:02:09: 53 | cd:ae:88:43:85:c8:82:58:70:30:ee:15:f3:3d:76:1e:2e:45: 54 | a6:bc 55 | \end{verbatim}} 56 | 57 | Как видно, сертификат действителен с 26.03.2009 до 25.03.2010, открытый ключ представляет собой ключ RSA\index{криптосистема!RSA} с длиной модуля $n = 1024$ бита и экспонентой $e = 65537$ и принадлежит компании Google Inc. Открытый ключ предназначен для взаимной аутентификации веб-сервера mail.google.com и веб-клиента в протоколе SSL/TLS. Сертификат подписан ключом удостоверяющего центра Thawte SGC CA, подпись вычислена с помощью криптографического хеша SHA-1\index{хеш-функция!SHA-1} и алгоритма RSA\index{электронная подпись!RSA}. В свою очередь, сертификат с открытым ключом Thawte SGC CA для проверки значения ЭП данного сертификата расположен по адресу: \url{http://www.thawte.com/repository/Thawte\_SGC\_CA.crt}. 58 | 59 | Электронная подпись вычисляется от всех полей сертификата, кроме самого значения подписи. 60 | -------------------------------------------------------------------------------- /rc4.tex: -------------------------------------------------------------------------------- 1 | \section{Шифр RC4}\label{rc4}\index{шифр!RC4|(} 2 | \selectlanguage{russian} 3 | 4 | Шифр RC4 был разработан Роном Ривестом (\langen{Ronald Linn Rivest}) в 1987 году для компании RSA Data Security. Описание алгоритма было впервые анонимно опубликовано в телеконференции Usenet sci.crypt в 1994 году\footnote{См. раздел 17.1. <<Алгоритм RC4>> в~\cite{Schneier:2002}.}. 5 | 6 | Генератор, используемый в шифре, хранит своё состояние в массиве из 256 ячеек $S_0, S_1, \dots, S_{255}$, заполненных значениями от 0 до 255 (каждое значение встречается только один раз), а также двух других переменных размером в 1 байт $i$ и $j$. Таким образом, количество различных внутренних состояний генератора равно $255! \times 255 \times 255 \approx 2.17 \times 10^{509} \approx 2^{1962}$. 7 | 8 | Процедура инициализации генератора. 9 | \begin{itemize} 10 | \item Для заполнения байтового массива из 256 ячеек $K_0, K_1, \dots, K_{255}$ используется предоставленный ключ. При необходимости (если размер ключа менее 256 байтов) ключ используется несколько раз, пока массив $K$ не будет заполнен целиком. 11 | \item Начальное значение $j$ равно $0$. 12 | \item Далее для значений $i$ от $0$ до $255$ выполняется: 13 | \begin{enumerate} 14 | \item $j:= (j + S_i + K_i) \mod 256$, 15 | \item поменять местами $S_i$ и $S_j$. 16 | \end{enumerate} 17 | \end{itemize} 18 | 19 | Процедура получения следующего псевдослучайного байта $result$ (следующего байта гаммы): 20 | \begin{enumerate} 21 | \item $ i := (i + 1) \mod 256$, 22 | \item $ j := (j + S_i) \mod 256$, 23 | \item поменять местами $S_i$ и $S_j$, 24 | \item $ t := ( S_i + S_j ) \mod 256$, 25 | \item $ result := S_t$. 26 | \end{enumerate} 27 | 28 | По утверждению Брюса Шнайера, алгоритм настолько прост, что большинство программистов могут закодировать его по памяти. Шифр RC4 использовался во многих программных продуктах, в том числе в IBM Lotus Notes, Apple AOCE, Oracle Secure SQL и Microsoft Office, а также в стандарте сотовой передачи цифровых данных CDPD. В настоящий момент шифр не рекомендуется к использованию~\cite{rfc7465}, в нём были найдены многочисленные, хотя и некритичные уязвимости~\cite{Fluhrer:Mantin:Shamir:2001,Mantin:Shamir:2002,Paul:Maitra:2007,Sepehrdad:Vaudenay:Vuagnoux:2011}. 29 | 30 | \index{шифр!RC4|)} 31 | -------------------------------------------------------------------------------- /secret-sharing/blackleys.tex: -------------------------------------------------------------------------------- 1 | \subsection[Схема Блэкли]{Схема разделения секрета Блэкли}\index{схема разделения секрета!Блэкли|(}\index{схема разделения секрета!векторная|(} 2 | \selectlanguage{russian} 3 | 4 | Схема разделения секрета Блэкли (\langen{George Robert Blakley},~\cite{Blackley:1979}, рис.~\ref{fig:blakley}), также называемая векторной схемой, основывается на том, что для восстановления всех координат точки в $K$-мерном пространстве, принадлежащей нескольким неколлинеарным гиперплоскостям, необходимо и достаточно знать уравнения $K$ таких плоскостей. То есть в двумерном пространстве нужны две пересекающиеся прямые, в трёхмерном -- три пересекающиеся в нужной точке плоскости и так далее. 5 | 6 | \begin{figure} 7 | \centering 8 | \subcaptionbox{}{\includegraphics[width=0.45\textwidth]{pic/blakley-2}} 9 | ~~~~ 10 | \subcaptionbox{}{\includegraphics[width=0.45\textwidth]{pic/blakley-3}} 11 | \caption{Для восстановления координат точки пересечения плоскостей в трёхмерном пространстве необходимо и достаточно знать уравнения трёх таких плоскостей. Данные изображения приведены только для иллюстрации идеи: в схеме Блэкли используется конечное поле, плоскости в котором сложно представить на графике. Рисунок участника English Wikipedia stib, доступно по \href{https://creativecommons.org/licenses/by-sa/3.0/deed.ru}{лицензии CC-BY-SA 3.0}}\label{fig:blakley} 12 | \end{figure} 13 | 14 | Для разделения секрета $M$ между $N$ сторонами таким образом, чтобы любые $K$ сторон могли восстановить секрет, доверенный центр выполняет следующие операции: 15 | \begin{itemize} 16 | \item выбирает несекретное большое простое число $p$ ($p > M$); 17 | \item выбирает случайную точку, одна из координат которой (например, первая) будет равна разделяемому секрету $M$: $(x_1 = M, x_2, \dots, x_K)$; 18 | \item для каждого участника $i$ выбирает $K$ случайных коэффициентов гиперплоскости $C^i_1, C^i_2, \dots, C^i_{K}$ ($\ne 0$), а последний коэффициент $C^i_{K+1}$ вычисляется таким образом, чтобы гиперплоскость проходила через выбранную точку: 19 | \[ \begin{array}{l} 20 | C^i_1 x_1 + C^i_2 x_2 + \dots + C^i_K x_K + C^i_{K+1} = 0 \mod p, \\ 21 | C^i_{K+1} = - ( C^i_1 x_1 + C^i_2 x_2 + \dots + C^i_K x_K ) \mod p; \\ 22 | \end{array} \] 23 | \item раздаёт каждой стороне по следу в виде коэффициентов общего уравнения гиперплоскости $C^i_1, C^i_2, \dots, C^i_{K}, C^i_{K+1}$ и общему модулю $p$. 24 | \end{itemize} 25 | 26 | Если стороны могут собраться вместе и получить не менее чем $K$ различных гиперплоскостей, то, составив и решив систему уравнений с $K$ неизвестными, они смогут получить все координаты точки $x_1, x_2, \dots, x_k$: 27 | \[ \left\{ \begin{array}{l} 28 | C^1_1 x_1 + C^1_2 x_2 + \dots + C^1_K x_K + C^1_{K+1} = 0 \mod p, \\ 29 | \dots, \\ 30 | C^K_1 x_1 + C^K_2 x_2 + \dots + C^K_K x_K + C^K_{K+1} = 0 \mod p. \\ 31 | \end{array} \right. \] 32 | 33 | Если собрано меньшее количество следов (уравнений гиперплоскостей), то их будет недостаточно для решения системы уравнений. 34 | 35 | \example 36 | Приведём пример разделения секрета по схеме Блэкли в $\GF{11}$. При разделении секрета $M$, используя $(3,N)$-по\-ро\-го\-вую схему Блэкли, участники получили следы: $(4, 8, 2, 6)$, $(2, 6, 8, 3)$, $(6, 8, 4, 1)$. Зная, что следы представляют собой коэффициенты в уравнении плоскости общего вида, а исходный секрет -- первую координату точки пересечения плоскостей, составляем систему уравнений для нахождения координаты этой точки: 37 | \[ \left\{\begin{aligned} 38 | \left( 4\cdot x_1 + 8\cdot x_2 + 2\cdot x_3 + 6 \right) &= 0 &\mod 11, \\ 39 | \left( 2\cdot x_1 + 6\cdot x_2 + 8\cdot x_3 + 3 \right) &= 0 &\mod 11, \\ 40 | \left( 6\cdot x_1 + 8\cdot x_2 + 4\cdot x_3 + 1 \right) &= 0 &\mod 11. \\ 41 | \end{aligned} \right. \] 42 | 43 | Решением данной системы будет являться точка (6, 4, 2), а её первая координата -- разделяемый секрет. 44 | \exampleend 45 | 46 | \index{схема разделения секрета!векторная|)}\index{схема разделения секрета!Блэкли|)} 47 | -------------------------------------------------------------------------------- /secret-sharing/index_only.tex: -------------------------------------------------------------------------------- 1 | \input{../_settings} 2 | \addbibresource{../bibliography.bib} 3 | \begin{document} 4 | \selectlanguage{russian} 5 | 6 | \tableofcontents 7 | 8 | \input{index} 9 | 10 | \printusedliterature 11 | 12 | \end{document} 13 | -------------------------------------------------------------------------------- /secret-sharing/pic/blakley-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/secret-sharing/pic/blakley-2.png -------------------------------------------------------------------------------- /secret-sharing/pic/blakley-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/secret-sharing/pic/blakley-3.png -------------------------------------------------------------------------------- /secret-sharing/pic/shamir.odg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/secret-sharing/pic/shamir.odg -------------------------------------------------------------------------------- /secret-sharing/pic/shamir.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/secret-sharing/pic/shamir.pdf -------------------------------------------------------------------------------- /secret-sharing/pic/shamir.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | -------------------------------------------------------------------------------- /secret-sharing/xor.tex: -------------------------------------------------------------------------------- 1 | \subsection[(N, N)-схема]{$(N, N)$-схема разделения секрета} 2 | \selectlanguage{russian} 3 | 4 | Рассмотрим пороговую схему распределения одного секрета между двумя легальными пользователями. Она обозначается как $(2, 2)$-схема -- это означает, что оба и только оба пользователя могут получить секрет. Предположим, что секрет $K_{0}$ -- это двоичная последовательность длины $M$, $K_{0} \in \Z_{M}$. 5 | 6 | Разделение секрета $K_{0}$ состоит в следующем. 7 | \begin{itemize} 8 | \item Первый пользователь в качестве секрета получает случайную двоичную последовательность $A_{1}$ длины $M$. 9 | \item Второй пользователь в качестве секрета получает случайную двоичную последовательность $A_{2} =K_{0} \oplus A_{1}$ длины $M$. 10 | \item Для получения секрета $K_{0}$ оба пользователя должны сложить по модулю 2 свои секретные ключи (последовательности) $K_{0} = A_{2} \oplus A_{1}$. 11 | \end{itemize} 12 | 13 | Теперь рассмотрим пороговую $(N,N)$-схему. 14 | 15 | Имеются общий секрет $K_{0} \in \Z_{M}$ и $N$ легальных пользователей, которые могут получить секрет только в случае, если одновременно предъявят свои секретные ключи. Распределение секрета $K_{0}$ происходит следующим образом. 16 | 17 | \begin{itemize} 18 | \item Первый пользователь в качестве секрета получает случайную двоичную последовательность $A_{1} \in \Z_{M}$. 19 | \item Второй пользователь в качестве секрета получает случайную двоичную последовательность $A_{2} \in \Z_{M}$ и~т.\,д. 20 | \item $(N-1)$-й пользователь в качестве секрета получает случайную двоичную последовательность $A_{N-1} \in \Z_{M}$. 21 | \item $N$-й пользователь в качестве секрета получает двоичную последовательность 22 | \[ K_0 \oplus A_1 \oplus A_2 \oplus \dots \oplus A_{N-1}. \] 23 | \item Для получения секрета $K_0$ все пользователи должны сложить по модулю 2 свои последовательности: 24 | \[ A_1 \oplus A_2 \oplus \dots \oplus A_{N-1} \oplus (K_0 \oplus A_1 \oplus A_2 \dots \oplus A_{N-1}) = K_0. \] 25 | \end{itemize} 26 | 27 | Предположим, что собравшихся вместе пользователей меньше общего числа $N$, например, всего $N-1$ пользователей. Тогда суммирование $N-1$ последовательностей не определяет секрета, а перебор невозможен, так как данная схема разделения секрета аналогична криптосистеме Вернама и обладает совершенной криптостойкостью. 28 | -------------------------------------------------------------------------------- /secure-systems-examples/gsm2.tex: -------------------------------------------------------------------------------- 1 | \subsection{GSM (2G)} 2 | \selectlanguage{russian} 3 | 4 | Регистрация телефона в сети GSM построена с участием трёх сторон: SIM-карты мобильного устройства, базовой станции и центра аутентификации. SIM-карта и центр аутентификации обладают общим секретным 128-битным ключом $K_i$. Вначале телефон сообщает базовой станции уникальный идентификатор SIM-карты IMSI открытым текстом. Базовая станция запрашивает в центре аутентификации для данного IMSI набор параметров для аутентификации. Центр генерирует псевдослучайное 128-битовое число $\textrm{RAND}$ и алгоритмами A3\index{алгоритм!A3} и A8\index{алгоритм!A8} создаёт симметричный 54-битовый ключ $K_c$ и 32-битовый аутентификатор $\textrm{RES}$. Базовая станция передаёт мобильному устройству число $\textrm{RAND}$ и ожидает результата вычисления SIM-картой числа $\textrm{XRES}$, которое должно совпасть с $\textrm{RES}$ в случае успешной аутентификации. Схема аутентификации показана на рис.~\ref{fig:gsm2}. 5 | 6 | \begin{figure}[!ht] 7 | \centering 8 | \includegraphics[width=0.85\textwidth]{pic/gsm2} 9 | \caption{Односторонняя аутентификация и шифрование в GSM\label{fig:gsm2}} 10 | \end{figure} 11 | 12 | Все вычисления для аутентификации выполняет SIM-карта. Ключ $K_c$ далее используется для создания ключа шифрования каждого фрейма $K = K_c ~\|~ n_F$, где $n_F$~--~22-битовый номер фрейма. Шифрование выполняет уже само мобильное устройство. Алгоритм шифрования фиксирован в каждой стране и выбирается из семейства алгоритмов A5\index{шифр!A5} (A5/1, A5/2, A5/3). В GSM применяется либо шифр A5/1 (используется в России), либо A5/2. Шифр A5/3 применяется уже в сети UMTS. 13 | 14 | Аутентификация в сети GSM односторонняя. При передаче данных не используются проверка целостности и аутентификация сообщений. Передача данных между базовыми станциями происходит в открытом незашифрованном виде. Алгоритмы шифрования A5/1 и A5/2 нестойкие, количество операций для взлома A5/1~--~$2^{40}$, A5/2~--~$2^{16}$. Кроме того, длина ключа $K_c$ всего 54 бита. Передача в открытом виде уникального идентификатора IMSI позволяет однозначно определить абонента. 15 | -------------------------------------------------------------------------------- /secure-systems-examples/gsm3.tex: -------------------------------------------------------------------------------- 1 | \subsection{UMTS (3G)} 2 | \selectlanguage{russian} 3 | 4 | В третьем поколении мобильных сетей, называемом UMTS, защищённость немного улучшена. Общая схема аутентификации (рис.~\ref{fig:gsm3}) осталась примерно такой же, как и в GSM. Жирным шрифтом на рисунке выделены новые добавленные элементы по сравнению с GSM. 5 | \begin{enumerate} 6 | \item Производится взаимная аутентификация SIM-карты и центра аутентификации по токенам $\textrm{RES}$ и $\MAC$. 7 | \item Добавлены проверка целостности и аутентификация данных (имитовставка\index{имитовставка}). 8 | \item Используются новые алгоритмы создания ключей, шифрования и имитовставки\index{имитовставка}. 9 | \item Добавлены счётчики на SIM-карте $\textrm{SQN}_{\textrm{T}}$ и в центре аутентификации $\textrm{SQN}_{\textrm{Ц}}$ для защиты от атак воспроизведения. Значения увеличиваются при каждой попытке аутентификации и должны примерно совпадать. 10 | \item Увеличена длина ключа шифрования до 128 бит. 11 | \end{enumerate} 12 | 13 | \begin{figure}[!ht] 14 | \centering 15 | \includegraphics[width=\textwidth]{pic/gsm3} 16 | \caption{Взаимная аутентификация и шифрование в UMTS (3G)\label{fig:gsm3}} 17 | \end{figure} 18 | 19 | Обозначения на рис.~\ref{fig:gsm3} следующие: 20 | \begin{itemize} 21 | \item K -- общий секретный 128-битовый ключ SIM-карты и центра аутентификации; 22 | \item RAND -- 128-битовое псевдослучайное число, создаваемое центром аутентификации; 23 | \item $\textrm{SQN}_{\textrm{T}}$, $\textrm{SQN}_{\textrm{Ц}}$ -- 48-битовые счётчики для защиты от атак воспроизведения; 24 | \item AMF -- 16-битовое значение окна для проверки синхронизации счётчиков; 25 | \item CK, IK, AK -- 128-битовые ключи шифрования данных CK, кода аутентификации данных IK, гаммы значения счётчика AK; 26 | \item MAC, XMAC -- 128-битовые аутентификаторы центра SIM-карте; 27 | \item RES, XRES -- 128-битовые аутентификаторы SIM-карты центру; 28 | \item AUTN -- вектор аутентификации. 29 | \end{itemize} 30 | 31 | Алгоритмы $fi$ не фиксированы стандартом и выбираются при реализациях. 32 | 33 | Из оставшихся недостатков защиты персональных данных можно перечислить. 34 | \begin{enumerate} 35 | \item Уникальный идентификатор SIM-карты IMSI (\langen{International Mobile Subscriber Identity}) по-прежнему передаётся в открытом виде, что позволяет злоумышленнику идентифицировать абонентов по началу сеанса регистрации SIM-карты в мобильной сети. 36 | \item Шифрование и аутентификация производятся только между телефоном и базовой станцией, а не между двумя телефонами. Это является необходимым условием для подключения СОРМ (Система технических средств для обеспечения функций оперативно-розыскных мероприятий) по закону <<О связи>>. С другой стороны, это повышает риск нарушения конфиденциальности персональных данных. 37 | \item Алгоритм шифрования A5/3\index{шифр!A5/3} (KASUMI)\index{шифр!KASUMI} на 128-би\-то\-вом ключе теоретически взламывается атакой на связанных ключах основе известного открытого текста для 64 MB данных с использованием 1 GiB памяти за $2^{32}$ операций (2 часа на обычном ПК 2010 года,~\cite{Dunkelman:Keller:Shamir:2010}). 38 | \end{enumerate} 39 | -------------------------------------------------------------------------------- /secure-systems-examples/index.tex: -------------------------------------------------------------------------------- 1 | \chapter{Примеры систем защиты} 2 | 3 | \input{kerberos} 4 | 5 | \input{pgp} 6 | 7 | \input{tls} 8 | 9 | \input{ipsec} 10 | 11 | \section[Защита информации в мобильной связи]{Защита информации \\в мобильной связи} 12 | 13 | \input{gsm2} 14 | 15 | \input{gsm3} 16 | 17 | %\section{Беспроводная сеть Wi-Fi} 18 | %\subsection{WPA-PSK2, 802.11n, Radix?} 19 | %\subsection{Wimax 802.16(?)} 20 | -------------------------------------------------------------------------------- /secure-systems-examples/index_only.tex: -------------------------------------------------------------------------------- 1 | \input{../_settings} 2 | \addbibresource{../bibliography.bib} 3 | \begin{document} 4 | \selectlanguage{russian} 5 | 6 | \tableofcontents 7 | 8 | \input{index} 9 | 10 | \printusedliterature 11 | 12 | \end{document} 13 | 14 | -------------------------------------------------------------------------------- /secure-systems-examples/pgp.tex: -------------------------------------------------------------------------------- 1 | \section{Pretty Good Privacy} 2 | \selectlanguage{russian} 3 | 4 | В качестве примера передачи файлов по сети с обеспечением аутентификации, конфиденциальности и целостности рассмотрим систему PGP (\langen{Pretty Good Privacy}), разработанную Филом Циммерманном (\langen{Phil Zimmermann}) в 1991 г. Изначально система предлагалась к использованию для защищённой передачи электронной почты. Стандартом PGP является OpenPGP. Примерами реализации стандарта OpenPGP являются GNU Privacy Guard (GPG) и netpgp, разработанные в рамках проектов GNU и NetBSD соответственно. 5 | 6 | Каждый пользователь обладает одной или несколькими парами из закрытого и открытого ключей. Ключи используются как для расшифрования получаемых пользователем сообщений, так и для генерации электронных подписей отправляемых сообщений. Также пользователь хранит открытые ключи других участников системы, чтобы иметь возможность отправлять им зашифрованные сообщения и аутентифицировать отправителей принимаемых сообщений. 7 | 8 | В системе PGP каждое передаваемое сообщение подписывается закрытым ключом отправителя, затем сообщение шифруется блочной криптосистемой на случайно выбранном секретном сеансовом ключе. Сам сеансовый ключ шифруется криптосистемой с открытым ключом на открытом ключе получателя. 9 | 10 | Свои закрытые ключи отправитель хранит в зашифрованном виде. Набор ключей называется связкой закрытых ключей. Шифрование закрытых ключей в связке производится симметричным шифром\index{шифр!симметричный}, ключом которого является функция от пароля, вводимого пользователем. Шифрование закрытых ключей, хранимых на компьютере, является стандартной практикой для защиты от утечки, например, в случае взлома ОС, утери ПК и~т.\,д. 11 | 12 | Набор открытых ключей других пользователей называется связкой открытых ключей. 13 | 14 | \begin{figure}[!ht] 15 | \centering 16 | \includegraphics[width=0.9\textwidth]{pic/pgp} 17 | \caption{Схема обработки сообщения в PGP\label{fig:pgp}} 18 | \end{figure} 19 | 20 | На рис.~\ref{fig:pgp} представлена схема обработки сообщения в PGP для передачи от $A$ к $B$. Использование аутентификации, сжатия и блочного шифрования является опциональным. Обозначения на рисунке следующие: 21 | \begin{itemize} 22 | \item Пароль -- пароль, вводимый отправителем для расшифрования связки своих закрытых ключей; 23 | \item $D$ -- расшифрование блочной криптосистемы для извлечения секретного ключа ЭП отправителя; 24 | \item $SK_A$ -- закрытый ключ ЭП отправителя; 25 | \item $ID_{SKa}$ -- идентификатор ключа ЭП отправителя, по которому получатель определяет, какой ключ из связки открытых ключей использовать для проверки подписи; 26 | \item $m$ -- сообщение (файл) для передачи; 27 | \item $h(m)$ -- криптографическая хеш-функция; 28 | \item $E_{SKa}$ -- схема ЭП на секретном ключе $SK_A$; 29 | \item $\|$ -- конкатенация битовых строк; 30 | \item $Z$ -- сжатие сообщения алгоритмом компрессии; 31 | \item $RND$ -- криптографический генератор псевдослучайной последовательности; 32 | \item $K_s$ -- сгенерированный псевдослучайный сеансовый ключ; 33 | \item $E_{Ks}$ -- блочное шифрование на секретном сеансовом ключе $K_s$; 34 | \item $PK_B$ -- открытый ключ получателя; 35 | \item $ID_{PKb}$ -- идентификатор открытого ключа получателя, по которому получатель определяет, какой ключ из связки закрытых ключей использовать для расшифрования сеансового ключа; 36 | \item $E_{PKb}$ -- шифрование сеансового ключа криптосистемой с открытым ключом на открытом ключе $B$; 37 | \item $c$ -- зашифрованное подписанное сообщение. 38 | \end{itemize} 39 | -------------------------------------------------------------------------------- /secure-systems-examples/pic/gsm2.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/secure-systems-examples/pic/gsm2.pdf -------------------------------------------------------------------------------- /secure-systems-examples/pic/gsm2.vsd: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/secure-systems-examples/pic/gsm2.vsd -------------------------------------------------------------------------------- /secure-systems-examples/pic/gsm3.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/secure-systems-examples/pic/gsm3.pdf -------------------------------------------------------------------------------- /secure-systems-examples/pic/gsm3.vsd: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/secure-systems-examples/pic/gsm3.vsd -------------------------------------------------------------------------------- /secure-systems-examples/pic/ipsec-ah-modes.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/secure-systems-examples/pic/ipsec-ah-modes.pdf -------------------------------------------------------------------------------- /secure-systems-examples/pic/ipsec-ah-modes.vsd: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/secure-systems-examples/pic/ipsec-ah-modes.vsd -------------------------------------------------------------------------------- /secure-systems-examples/pic/ipsec-ah.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/secure-systems-examples/pic/ipsec-ah.pdf -------------------------------------------------------------------------------- /secure-systems-examples/pic/ipsec-ah.vsd: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/secure-systems-examples/pic/ipsec-ah.vsd -------------------------------------------------------------------------------- /secure-systems-examples/pic/ipsec-esp-modes.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/secure-systems-examples/pic/ipsec-esp-modes.pdf -------------------------------------------------------------------------------- /secure-systems-examples/pic/ipsec-esp-modes.vsd: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/secure-systems-examples/pic/ipsec-esp-modes.vsd -------------------------------------------------------------------------------- /secure-systems-examples/pic/ipsec-esp.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/secure-systems-examples/pic/ipsec-esp.pdf -------------------------------------------------------------------------------- /secure-systems-examples/pic/ipsec-esp.vsd: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/secure-systems-examples/pic/ipsec-esp.vsd -------------------------------------------------------------------------------- /secure-systems-examples/pic/kerberos.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/secure-systems-examples/pic/kerberos.pdf -------------------------------------------------------------------------------- /secure-systems-examples/pic/kerberos.vsd: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/secure-systems-examples/pic/kerberos.vsd -------------------------------------------------------------------------------- /secure-systems-examples/pic/pgp.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/secure-systems-examples/pic/pgp.pdf -------------------------------------------------------------------------------- /secure-systems-examples/pic/pgp.vsd: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/secure-systems-examples/pic/pgp.vsd -------------------------------------------------------------------------------- /software-security/index_only.tex: -------------------------------------------------------------------------------- 1 | \input{../_settings} 2 | \addbibresource{../bibliography.bib} 3 | \begin{document} 4 | \selectlanguage{russian} 5 | 6 | \tableofcontents 7 | 8 | \input{index} 9 | 10 | \printusedliterature 11 | 12 | \end{document} 13 | 14 | -------------------------------------------------------------------------------- /software-security/pic/stack-overflow.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/software-security/pic/stack-overflow.pdf -------------------------------------------------------------------------------- /software-security/pic/stack-overflow.vsd: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/software-security/pic/stack-overflow.vsd -------------------------------------------------------------------------------- /software-security/sql-injections.tex: -------------------------------------------------------------------------------- 1 | \section{SQL-инъекции} 2 | \selectlanguage{russian} 3 | 4 | Второй классической уязвимостью веб-приложений являются SQL-инъекции (\langen{SQL injection}), когда пользователь имеет возможность поменять смысл запроса к базе данных веб-сервера. Запрос делается в виде текстовой строки на скриптовом языке SQL. Например, выражение 5 | \begin{verbatim} 6 | "SELECT * FROM Users WHERE Name = '" + username + "';" 7 | \end{verbatim} 8 | предназначено для получения информации о пользователе, имя (логин) которого задан переменной \texttt{username}. Однако если пользователь вместо имени введёт строку вида 9 | \begin{center} \begin{verbatim} 10 | john'; DELETE * FROM Users; SELECT * FROM Users WHERE 11 | Name = 'john, 12 | \end{verbatim} \end{center} 13 | то выражение превратится в три SQL-операции: 14 | 15 | \begin{verbatim} 16 | -- запрос о пользователе john 17 | SELECT * FROM Users WHERE Name = 'john'; 18 | -- удаление всех пользователей 19 | DELETE FROM Users; 20 | -- запрос о пользователе john 21 | SELECT * FROM Users WHERE Name = 'john'; 22 | \end{verbatim} 23 | При выполнении этого SQL-запроса к базе данных все записи пользователей будут удалены. 24 | 25 | Уязвимости в SQL-выражениях являются частными случаями уязвимостей, связанных с использованием сложных систем с разными языками управления данными и, следовательно, с разными системами экранирования специальных символов и контроля над типом данных. Когда веб-сервер принимает от клиента данные, закодированные обычно с помощью <>~\cite{html4:1999}, специальные символы (пробелы, неалфавитные символы и~т.\,д.) корректно экранируются браузером и восстанавливаются непосредственно веб-сервером или стандартными программными библиотеками. Аналогично, когда SQL-сервер передаёт данные клиентской библиотеке или принимает их от неё, внутренним протоколом общения с SQL-сервером происходит кодировка текста, который является частью пользовательских данных. Однако на стыке контекстов -- в тот момент, когда программа, выполняющаяся на веб-сервере, уже приняла данные от пользователя по HTTP-протоколу\index{протокол!HTTP} и собирается передать их SQL-серверу в качестве составной части SQL-команды -- перед программистом стоит сложная задача учёта в худшем случае трёх контекстов и кодировок: входного контекста протокола общения с клиентом (HTTP), контекста языка программирования (с соответствующим оформлением и экранированием специальных символов в текстовых константах) и контекста языка управления данными SQL-сервера. 26 | 27 | Ситуация усложняется тем, что программист может являться специалистом в языке программирования, но может быть не знаком с особенностями языка SQL или, что чаще, конкретным диалектом языка SQL, используемым СУБД. 28 | 29 | Метод защиты заключается в \emph{разделении} кода и данных. Для защиты от приведённых атак на базу данных следует использовать параметрические запросы к базе данных с \emph{фиксированным} SQL-выражением. Например, в JDBC~\cite{jdbc:2006}: 30 | \begin{verbatim} 31 | PreparedStatement p = conn.prepareStatement( 32 | "SELECT * FROM Users WHERE Name=?"); 33 | p.setString(1, username); 34 | \end{verbatim} 35 | 36 | Таким образом, задача корректного оформления текстовых данных для передачи на SQL-сервер перекладывается на драйвер общения с СУБД, в котором эта задача обычно решена корректно авторами драйвера, хорошо знающими особенности протокола и языка управления данными сервера. 37 | -------------------------------------------------------------------------------- /stream-ciphers.tex: -------------------------------------------------------------------------------- 1 | \chapter{Потоковые шифры}\label{chapter-stream-ciphers} 2 | \selectlanguage{russian} 3 | 4 | Потоковые шифры осуществляют посимвольное шифрование открытого текста. Под символом алфавита открытого текста могут пониматься как отдельные биты (побитовое шифрование), так и байты (побайтовое шифрование). Поэтому можно говорить о в какой-то мере условном разделении блочных и потоковых шифров: например, 64-битная буква - один блок. Общий вид большинства потоковых шифров приведён на рис.~\ref{fig:stream-cipher}. 5 | 6 | \begin{figure}[hb] 7 | \centering 8 | \includegraphics[width=0.66\textwidth]{pic/stream-cipher} 9 | \caption{Общая структура шифрования с использованием потоковых шифров} 10 | \label{fig:stream-cipher} 11 | \end{figure} 12 | 13 | \begin{itemize} 14 | \item Перед началом процедуры шифрования отправитель и получатель должны обладать общим секретным ключом. 15 | \item Секретный ключ используется для генерации инициализирующей последовательности (\langen{seed}) генератора псевдослучайной последовательности. 16 | \item Генераторы отправителя и получателя используются для получения одинаковой псевдослучайной последовательности символов, называемой \emph{гаммой}\index{гамма}. Последовательности одинаковые, если для их получения использовались одинаковые ГПСЧ, инициализированные одной и той же инициализирующей последовательностью, при условии, что генераторы детерминированные. 17 | \item Символы открытого текста на стороне отправителя складываются с символами гаммы, используя простейшие обратимые преобразования. Например, побитовое сложение по модулю 2 (операция <<исключающее или>>, \langen{XOR}). Полученный шифртекст передаётся по каналу связи. 18 | \item На стороне легального получателя с символами шифртекста и гаммы выполняется обратная операция (для XOR это будет просто повторный XOR) для получения открытого текста. 19 | \end{itemize} 20 | 21 | Очевидно, что криптостойкость потоковых шифров непосредственно основана на стойкости используемых ГПСЧ. Большой размер инициализирующей последовательности, длинный период, большая линейная сложность -- необходимые атрибуты используемых генераторов. Одним из преимуществ потоковых шифров по сравнению с блочными является более высокая скорость работы. 22 | 23 | Одним из примеров ненадёжных потоковых шифров является семейство A5\index{шифр!A5} (A5/1, A5/2), кратко рассмотренное в разделе~\ref{section:majority_generators}. Мы также рассмотрим вариант простого в понимании шифра RC4, не основанного на РСЛОС. 24 | 25 | \input{rc4} 26 | -------------------------------------------------------------------------------- /substitution_ciphers.tex: -------------------------------------------------------------------------------- 1 | \subsubsection{Шифры замены} 2 | \selectlanguage{russian} 3 | 4 | В шифрах \emph{замены} символы одного алфавита заменяются символами другого путём обратимого преобразования. В последовательности открытого текста символы входного алфавита заменяются на символы выходного алфавита. Такие шифры применяются как в симметричных, так и в асимметричных криптосистемах. Если при преобразовании используются однозначные функции, то такие шифры называются \emph{однозначными} шифрами замены. Если используются многозначные функции, то шифры называются \emph{многозначными} шифрами замены (омофонами). 5 | 6 | В \emph{омофоне}\index{омофон} символам входного алфавита ставятся в соответствие непересекающиеся подмножества символов выходного алфавита. Количество символов в каждом подмножестве замены пропорционально частоте встречаемости символа открытого текста. Таким образом, омофон создаёт равномерное распределение символов шифртекста, и прямой частотный криптоанализ невозможен. При шифровании омофонами символ входного алфавита заменяется на случайно выбранный символ из подмножества замены. 7 | 8 | Шифры называются \emph{моноалфавитными}, когда для шифрования используется одно отображение входного алфавита в выходной алфавит. Если алфавиты на входе и выходе одинаковы, и их размеры (число символов) равны $D$, тогда $D!$ -- количество всевозможных моноалфавитных шифров замены такого типа. 9 | 10 | \emph{Полиалфавитный} шифр задаётся множеством различных вариантов отображения входного алфавита на выходной алфавит. Шифры замены могут быть как потоковыми, так и блочными. Однозначный полиалфавитный потоковый шифр замены называется \emph{шифром гаммирования}\index{шифр!гаммирования}. Символом алфавита может быть, например, 256-битовое слово, а размер алфавита -- $2^{256}$ соответственно. 11 | -------------------------------------------------------------------------------- /user-authentication/http_auth.tex: -------------------------------------------------------------------------------- 1 | \section{Аутентификация в веб-сервисах} 2 | \selectlanguage{russian} 3 | 4 | В настоящий момент HTTP\index{протокол!HTTP} (вместе с HTTPS\index{протокол!HTTPS}) является основным протоколом, используемым в сети Интернет для доступа к веб-сервисам (например к социальным сетям или веб-клиентам электронной почты). Данный протокол является протоколом типа <<запрос-ответ>>\index{протокол!запрос-ответ}, причём для каждого запроса открывается новое соединение с сервером\footnote{Для версии протокола HTTP/1.0 существует неофициальное~\cite[p.~17]{Totty:2002} расширение в виде заголовка \texttt{Connection: Keep-Alive}, который позволяет использовать одно соединение для нескольких запросов. Версия протокола HTTP/1.1 по умолчанию~\cite[6.3.~Persistence]{rfc7230} устанавливает поддержку выполнения нескольких запросов в рамках одного соединения. Однако все запросы всё равно выполняются независимо друг от друга.}. То есть протокол HTTP не является сессионным протоколом\index{протокол!сессионный}. В связи с этим задачу аутентификации на веб-сервисах можно разделить на задачи первичной и вторичной аутентификаций. \emph{Первичной аутентификацией}\index{аутентификация!первичная} будем называть механизм обычной аутентификации пользователя в рамках некоторого HTTP-запроса, а \emph{вторичной}\index{аутентификация!вторичная} (или \emph{повторной}\index{аутентификация!повторная}) -- некоторый механизм подтверждения в рамках последующих HTTP-запросов, что пользователь уже был \emph{ранее} аутентифицирован веб-сервисом в рамках первичной аутентификации. 5 | 6 | Аутентификация в веб-сервисах также бывает \emph{односторонней}\index{аутентификация!односторонняя} (как со стороны клиента, так и со стороны сервиса) и \emph{взаимной}\index{аутентификация!взаимная}. Под аутентификацией веб-сервиса обычно понимается возможность сервиса доказать клиенту, что он является именно тем веб-сервисом, к которому хочет получить доступ пользователь, а не его мошеннической подменой, созданной злоумышленниками. Для аутентификации веб-сервисов используется механизм сертификатов открытых ключей\index{сертификат открытого ключа} протокола HTTPS\index{протокол!HTTPS} с использованием инфраструктуры открытых ключей\index{инфраструктура открытых ключей} (см. раздел~\ref{chapter-public-key-infrastructure}). 7 | 8 | При использовании протокола HTTPS\index{протокол!HTTPS} и наличии соответствующей поддержки со стороны веб-сервиса клиент также имеет возможность аутентифицировать себя с помощью своего сертификата открытого ключа\index{сертификат открытого ключа}. Данный механизм редко используется в публичных веб-сервисах, так как требует от клиента иметь на устройстве, с которого осуществляется доступ, файл сертификата открытого ключа. 9 | 10 | \subsection{Первичная аутентификация по паролю} 11 | 12 | Стандартная первичная аутентификация в современных веб-сервисах происходит посредством обычной передачи логина и пароля в открытом виде по сети. Если SSL-соединение не используется, логин и пароль могут быть перехвачены. Даже при использовании SSL-соединения веб-приложение имеет доступ к паролю в открытом виде. 13 | 14 | Более защищённым, но малоиспользуемым способом аутентификации является вычисление хеша от пароля $m$, <<соли>> $s$ и псевдослучайных одноразовых меток $n_1, n_2$ с помощью JavaScript в браузере и отсылка по сети только результата вычисления хеша. 15 | \[ \begin{array}{ll} 16 | \text{Браузер} ~\rightarrow~ \text{Сервис:} & \text{HTTP GET-запрос,} \\ 17 | \text{Браузер} ~\leftarrow~ \text{Сервис:} & s ~\|~ n_1, \\ 18 | \text{Браузер} ~\rightarrow~ \text{Сервис:} & n_2 ~\|~ h( h(s ~\|~ m) ~\|~ n_1 ~\|~ n_2). \\ 19 | \end{array} \] 20 | 21 | Если веб-сервис хранит хеш от пароля и <<соли>> $h(s ~\|~ m)$, то пароль не может быть перехвачен ни по сети, ни веб-сервисом, ни какими-либо прокси-серверами, находящимися между браузером и веб-сервисом. 22 | 23 | В массовых интернет-сервисах пароли часто хранятся в открытом виде на сервере, что не является хорошей практикой для обеспечения защиты персональных данных пользователей. 24 | 25 | \input{openid} 26 | 27 | \input{cookies_auth} 28 | -------------------------------------------------------------------------------- /user-authentication/index_only.tex: -------------------------------------------------------------------------------- 1 | \input{../_settings} 2 | \addbibresource{../bibliography.bib} 3 | \begin{document} 4 | \selectlanguage{russian} 5 | 6 | \tableofcontents 7 | 8 | \input{index} 9 | 10 | \printusedliterature 11 | 12 | \end{document} 13 | 14 | -------------------------------------------------------------------------------- /user-authentication/openid.tex: -------------------------------------------------------------------------------- 1 | \subsection{Первичная аутентификация в OpenID} 2 | \selectlanguage{russian} 3 | 4 | Из-за большого числа различных логинов, которые приходится использовать для доступа к различным сервисам, постепенно происходит внедрение единых систем аутентификации для различных сервисов (single sign-on), например OpenID. Одновременно происходит концентрация пользователей вокруг больших порталов с единой аутентификацией, например Google Account. Яндекс.Паспорт также уменьшает число используемых паролей для различных служб. 5 | 6 | Принцип аутентификации состоит в следующем. 7 | \begin{enumerate} 8 | \item Веб-сервисы доверяют аутентификацию пользователя третьей стороне -- центру аутентификации. Центров может быть несколько, но владельцы веб-сервиса могут ограничить выбор такого центра <<белым>> или <<чёрным>> списком. 9 | \item Когда пользователь заходит на интернет-ресурс, веб-при\-ло\-же\-ние перенаправляет его на центр аутентификации с защитой TLS-соединением. 10 | \item Центр аутентифицирует пользователя и выдаёт ему токен аутентификации, который пользователь предъявляет ин\-тер\-нет-сер\-ви\-су. 11 | \item Сервис по токену аутентификации определяет имя пользователя. 12 | \end{enumerate} 13 | 14 | \begin{figure}[!ht] 15 | \centering 16 | \includegraphics[width=0.9\textwidth]{pic/openid} 17 | \caption{Схема аутентификации в OpenID\label{fig:openid}} 18 | \end{figure} 19 | 20 | На рис.~\ref{fig:openid} показана схема аутентификации в OpenID версии 2 для доступа к стороннему интернет-сервису. 21 | 22 | Если сервис и центр вместе создают общий секретный ключ $K$ для имитовставки\index{имитовставка} $\MAC_K$, выполняются шаги 4, 5 по протоколу Диффи~---~Хеллмана\index{протокол!Диффи~---~Хеллмана}: 23 | \[ \begin{array}{l} 24 | \text{4. Сервис} ~\rightarrow~ \text{центр: модуль}~ p ~\text{группы}~ \Z_p^*, ~\text{генератор}~ g, \\ 25 | ~~~~~~~~~~~~~~~\text{число}~ g^a \mod p, \\ 26 | \text{5. Сервис} ~\leftarrow~ \text{центр: число}~ g^b \mod p, ~\text{гаммированный} \\ 27 | ~~~~~~~~~~~~~~~\text{ключ}~ K \oplus (g^{ab} \mod p), 28 | \end{array} \] 29 | то аутентификатор содержит $\MAC_K$, проверяемый шагом 10 на выданном ключе $K$\footnote{Более правильным подходом является использование в качестве ключа $K = g^{ab} \mod p$, так как в этом случае ключ создаётся совместно, а не выдаётся центром.}. Имитовставка\index{имитовставка} определяется как описанный ранее $\HMAC$ с хеш-функцией SHA-256. 30 | 31 | Если сервис и центр не создают общий ключ (этапы 4, 5 не выполняются), то сервис делает запрос на проверку аутентификатора в шагах 10, 11. 32 | 33 | В OpenID аутентификатор состоит из следующих основных полей: имени пользователя, URL сервиса, результата аутентификации в OpenID, одноразовой метки и, возможно, кода аутентификации от полей аутентификатора на секретном ключе $K$, если он был создан на этапах 4, 5. Одноразовая метка является \emph{одноразовым} псевдослучайным идентификатором результата аутентификации, который центр сохраняет в своей БД. По одноразовой метке сервис запрашивает центр о верности результата аутентификации на этапах 10, 11. Одноразовая метка дополнительно защищает от атак воспроизведения. 34 | 35 | Можно было бы исключить шаги 4, 5, 10, 11, но тогда сервису пришлось бы реализовывать и хранить в БД использованные одноразовые метки для защиты от атак воспроизведения. Цель OpenID -- предоставить аутентификацию с минимальными издержками на интеграцию. Поэтому в OpenID реализуется модель, в которой сервис делегирует все проверки центру с помощью соответствующих запросов. 36 | 37 | Важно отметить, что в аутентификации через OpenID необходимо использовать TLS-соединения\index{протокол!SSL/TLS} (то есть протокол HTTPS\index{протокол!HTTPS}) при всех взаимодействиях с центром, так как в самом протоколе OpenID не производится аутентификация сервиса и центра, конфиденциальность\index{конфиденциальность} и целостность\index{целостность} не поддерживаются. 38 | -------------------------------------------------------------------------------- /user-authentication/pic/openid.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/user-authentication/pic/openid.pdf -------------------------------------------------------------------------------- /user-authentication/pic/openid.vsd: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/vlsergey/infosec/24f713fdfb5f49736ad3bac62456a51312b1e0f1/user-authentication/pic/openid.vsd --------------------------------------------------------------------------------