├── .gitignore ├── apostila.pdf ├── imagens ├── cc.png ├── CBC.png ├── Ctr.png ├── ECB.png ├── Tux.jpg ├── CBC-MAC.png ├── OWF-PRG.png ├── PRG-PRF.png ├── Tux_ecb.jpg ├── bruno.jpg ├── feistel.png ├── trivium.png ├── ECClines.png ├── ECClines2.png ├── ShiftRows.png ├── SubBytes.png ├── AddRoundKey.png ├── MixColumns.png ├── OWF-diagrama.png ├── Tux_secure.jpg ├── aes-subbyte.jpg ├── tabula-recta.png ├── EllipticCurves.png ├── Merkle-Damgard.png └── feistel-function.png ├── README.md ├── apresentacao.tex ├── apostila.tex ├── sistemas-hibridos.tex ├── apostila.toc ├── primos.tex ├── dsa.tex ├── ciclicos.tex ├── criptoanalise.tex ├── assinaturas-digitais.tex ├── corpos-finitos.tex ├── owf.tex ├── sigilo-perfeito.tex ├── intro.tex ├── ref.bib ├── protocolos.tex ├── distribuicao-chaves.tex ├── cifras-fluxo.tex ├── criptografia-assimetrica.tex ├── hash.tex └── mac.tex /.gitignore: -------------------------------------------------------------------------------- 1 | *.aux 2 | *.fls 3 | *.log 4 | *.fdb_latexmk 5 | *.blg 6 | *.bbl 7 | *.toc 8 | -------------------------------------------------------------------------------- /apostila.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/marciomr/apostila-seginf/HEAD/apostila.pdf -------------------------------------------------------------------------------- /imagens/cc.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/marciomr/apostila-seginf/HEAD/imagens/cc.png -------------------------------------------------------------------------------- /imagens/CBC.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/marciomr/apostila-seginf/HEAD/imagens/CBC.png -------------------------------------------------------------------------------- /imagens/Ctr.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/marciomr/apostila-seginf/HEAD/imagens/Ctr.png -------------------------------------------------------------------------------- /imagens/ECB.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/marciomr/apostila-seginf/HEAD/imagens/ECB.png -------------------------------------------------------------------------------- /imagens/Tux.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/marciomr/apostila-seginf/HEAD/imagens/Tux.jpg -------------------------------------------------------------------------------- /imagens/CBC-MAC.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/marciomr/apostila-seginf/HEAD/imagens/CBC-MAC.png -------------------------------------------------------------------------------- /imagens/OWF-PRG.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/marciomr/apostila-seginf/HEAD/imagens/OWF-PRG.png -------------------------------------------------------------------------------- /imagens/PRG-PRF.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/marciomr/apostila-seginf/HEAD/imagens/PRG-PRF.png -------------------------------------------------------------------------------- /imagens/Tux_ecb.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/marciomr/apostila-seginf/HEAD/imagens/Tux_ecb.jpg -------------------------------------------------------------------------------- /imagens/bruno.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/marciomr/apostila-seginf/HEAD/imagens/bruno.jpg -------------------------------------------------------------------------------- /imagens/feistel.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/marciomr/apostila-seginf/HEAD/imagens/feistel.png -------------------------------------------------------------------------------- /imagens/trivium.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/marciomr/apostila-seginf/HEAD/imagens/trivium.png -------------------------------------------------------------------------------- /imagens/ECClines.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/marciomr/apostila-seginf/HEAD/imagens/ECClines.png -------------------------------------------------------------------------------- /imagens/ECClines2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/marciomr/apostila-seginf/HEAD/imagens/ECClines2.png -------------------------------------------------------------------------------- /imagens/ShiftRows.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/marciomr/apostila-seginf/HEAD/imagens/ShiftRows.png -------------------------------------------------------------------------------- /imagens/SubBytes.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/marciomr/apostila-seginf/HEAD/imagens/SubBytes.png -------------------------------------------------------------------------------- /imagens/AddRoundKey.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/marciomr/apostila-seginf/HEAD/imagens/AddRoundKey.png -------------------------------------------------------------------------------- /imagens/MixColumns.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/marciomr/apostila-seginf/HEAD/imagens/MixColumns.png -------------------------------------------------------------------------------- /imagens/OWF-diagrama.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/marciomr/apostila-seginf/HEAD/imagens/OWF-diagrama.png -------------------------------------------------------------------------------- /imagens/Tux_secure.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/marciomr/apostila-seginf/HEAD/imagens/Tux_secure.jpg -------------------------------------------------------------------------------- /imagens/aes-subbyte.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/marciomr/apostila-seginf/HEAD/imagens/aes-subbyte.jpg -------------------------------------------------------------------------------- /imagens/tabula-recta.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/marciomr/apostila-seginf/HEAD/imagens/tabula-recta.png -------------------------------------------------------------------------------- /imagens/EllipticCurves.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/marciomr/apostila-seginf/HEAD/imagens/EllipticCurves.png -------------------------------------------------------------------------------- /imagens/Merkle-Damgard.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/marciomr/apostila-seginf/HEAD/imagens/Merkle-Damgard.png -------------------------------------------------------------------------------- /imagens/feistel-function.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/marciomr/apostila-seginf/HEAD/imagens/feistel-function.png -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Apostila de Segurança da Informação 2 | Apostila para o curso de Segurança da Informação 3 | 4 | Essas são notas de aula da disciplina Segurança da Informação ministrados no segundo semestre de 2017 para as turmas do período diurno e noturno do curso de Sistemas de Informação da Escola de Artes Ciências e Humanidades (EACH) da USP. 5 | A primeira versão desta apostila foi escrita para o curso de verão ministrado entre os os dias 2 e 6 de fevereiro de 2015 também no campus leste da Universidade de São Paulo. 6 | O curso de verão foi oferecido como parte das atividades do projeto de Privacidade e Vigilância do Grupo de Políticas Públicas em Acesso à Informação (GPoPAI) e foi inspirado pelo curso online oferecido gratuitamente pela plataforma Coursera e ministrado pelo professor D. Boneh. 7 | 8 | # Contribuições 9 | Agradecemos contribuições como correções de erros ortográficos e gramaticais. Estamos também abertos a debater conceitos mal explicados ou com eventuais erros. As contribuições devem ser feitas por meio de pull requests como um projeto de software convencional. 10 | 11 | # Licença 12 | Alguns direitos sobre o conteúdo desta apostila são protegidos pelo autor sob licença Creative Commons 13 | Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0). Ou seja, você é livre para distribuir cópias e adaptar este trabalho desde que mantenha a mesma licença, dê o devido crédito ao autor e não faça uso comercial. 14 | 15 | -------------------------------------------------------------------------------- /apresentacao.tex: -------------------------------------------------------------------------------- 1 | \chapter*{Apresentação} 2 | 3 | Essas são notas de aula da disciplina Segurança da Informação ministrada no segundo semestre de 2017 para as turmas do período diurno e noturno do curso de Sistemas de Informação da Escola de Artes Ciências e Humanidades (EACH) da USP. 4 | A primeira versão desta apostila foi escrita para o curso de verão ministrado entre os os dias 2 e 6 de fevereiro de 2015 também no campus leste da Universidade de São Paulo. 5 | O curso de verão foi oferecido como parte das atividades do projeto de Privacidade e Vigilância do Grupo de Políticas Públicas em Acesso à Informação (GPoPAI) e foi inspirado pelo curso online oferecido gratuitamente pela plataforma Coursera e ministrado pelo professor D. Boneh. 6 | 7 | Aos alunos que pretendem se aprofundar no tema sugerimos as seguintes referências bibliográficas: 8 | 9 | \begin{itemize} 10 | \item J. Katz e Y. Lindell - {\em Introduction to Modern Cryptography} 11 | \item W. Stallings - {\em Criptografia e Segurança da Informação} 12 | \item C. Paar e J. Pelzl - {\em Understanding Cryptography} 13 | \end{itemize} 14 | 15 | Agradecemos aos alunos que participaram do curso de verão em 2015 e dos cursos de gradução em 2016, 2017 e 2018, suas contribuições serviram de importante feedback para escrita dessas notas. 16 | 17 | Alguns direitos sobre o conteúdo desta apostila são protegidos pelo autor sob licença Creative Commons 18 | Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0). Ou seja, você é livre para distribuir cópias e adaptar este trabalho desde que mantenha a mesma licença, dê o devido crédito ao autor e não faça uso comercial. 19 | 20 | \begin{center} 21 | \includegraphics[width=.3\textwidth]{imagens/cc.png} 22 | \end{center} -------------------------------------------------------------------------------- /apostila.tex: -------------------------------------------------------------------------------- 1 | \documentclass[a4,12pt]{book} 2 | \usepackage[portuguese]{babel} 3 | \usepackage[utf8x]{inputenc} 4 | \usepackage{graphicx} 5 | \usepackage{amsmath,amssymb,amsthm,mathtools} 6 | \usepackage{clrscode} 7 | \usepackage{tikz} 8 | \usepackage[hidelinks]{hyperref} 9 | \usepackage{multicol} 10 | 11 | \newtheorem{example}{Exemplo} 12 | \newtheorem{exercicio}{Exercício} 13 | \newtheorem{definition}{Definição} 14 | \newtheorem{theorem}{Teorema} 15 | \newtheorem{proposition}{Proposição} 16 | \newtheorem{corollary}{Corolário} 17 | \newtheorem{lemma}{Lema} 18 | 19 | \newcommand{\xor}{\oplus} 20 | 21 | \begin{document} 22 | 23 | \bibliographystyle{alpha} 24 | 25 | \author{Márcio Moretto Ribeiro} 26 | 27 | \title{Segurança da Informação} 28 | 29 | \maketitle 30 | 31 | \tableofcontents 32 | 33 | % lembrar de colocar em cada um dos algoritmos qual é sua entrada e qual é sua saída!!! 34 | 35 | \include{apresentacao} 36 | \include{intro} 37 | \include{cifras-classicas} 38 | %\include{criptoanalise} 39 | %\include{sigilo-perfeito} 40 | \include{criptografia-moderna} 41 | \include{cifras-fluxo} 42 | \include{cifras-bloco} 43 | \include{mac} 44 | \include{hash} 45 | \include{distribuicao-chaves} 46 | \include{criptografia-assimetrica} 47 | \include{assinaturas-digitais} 48 | 49 | \appendix 50 | \include{corpos-finitos} 51 | \include{owf} 52 | % \include{primos} 53 | \include{sistemas-hibridos} 54 | \include{ciclicos} 55 | \include{dsa} 56 | \include{protocolos} 57 | %\include{privacidade-diferencial} 58 | %\include{blockchain} 59 | 60 | \bibliography{ref} 61 | \end{document} 62 | 63 | % coisas que ficaram de fora 64 | % fatoração 65 | % teste de primalidade 66 | % criptoanálise diferencial 67 | % Zero knownledge proof of knowledge 68 | % Ideia: OWF e mais esses 4 temas em curso de pós 69 | -------------------------------------------------------------------------------- /sistemas-hibridos.tex: -------------------------------------------------------------------------------- 1 | \chapter{Sistemas Híbridos} 2 | \label{cha:sistemas-hibridos} 3 | 4 | Neste apêndice apresentamos duas construções concretas de sistemas híbridos: uma baseada no problema do logaritmo discreto e outra baseada no problema da fatoração. 5 | 6 | \section{El Gammal} 7 | \label{sec:el-gammal} 8 | 9 | O principal inconveniente do sistema de El Gammal é que $M = \mathbb{G}$. 10 | Ou seja, as mensagens devem ser elementos do grupo e não sequências arbitrárias de bits. 11 | Não se deve restringir que mensagens os usuários devem ser capazes de trocar por conta de uma questão técnica como essa. 12 | Uma forma de resolver esse problema é utilizando um sistema híbrido. 13 | 14 | Uma forma de obter um sistema híbrido é simplemente usando o sistema de El Gamal para criptografar uma chave. 15 | Ao invés disso, porém, podemos construir o seguinte KEM: 16 | 17 | \begin{itemize} 18 | \item $Gen(1^n) := \langle sk, pk \rangle$ em que e $\mathcal{G}(1^n) := \langle \mathbb{G}, g \rangle$, 19 | \begin{itemize} 20 | \item $sk = \langle \mathbb{G}, g, x \rangle$ com $x \leftarrow \mathbb{Z}_n$ e 21 | \item $pk = \langle \mathbb{G}, g, h, H \rangle$ com $H: \mathbb{G} \to \{0,1\}^{l(n)}$ e $h = g^x$ 22 | \end{itemize} 23 | \item $Encaps(pk, 1^n) = \langle g^y, H(h^y)\rangle$ em que $y \leftarrow \mathbb{Z}_n$ 24 | \item $Decaps(sk, c) = H(c^x)$ 25 | \end{itemize} 26 | 27 | A função $H$ é simplesmente uma função de hash. 28 | Temos assim que $Decaps(sk, g^y) = H((g^y)^x) = H(g^{xy}) = k$, pois $k = H(h^y) = H(g^{xy})$. 29 | É possível provar que este mecanismo de encapsulamento de chaves é tão seguro quanto o protocolo de Diffie-Helmann. 30 | Usamos então $k$ como chave para criptografar uma mensagem com um sistema de criptografia simétrica para produzir um sistema híbrido. 31 | Como já enunciamos, se o sistema de criptografia simétrico usado for seguro contra ataques ``ciphertext only'' então o sistema híbrido será seguro sob CPA. 32 | 33 | \section{RSA} 34 | \label{sec:rsa} 35 | 36 | Como no caso da cifra de El Gamal, podemos construir um Mecanismo de Encapsulamento a partir do RSA. 37 | A construção segue os seguintes passos: 38 | \begin{itemize} 39 | \item $Gen(1^n) := \langle sk, pk \rangle$ em que: 40 | \begin{itemize} 41 | \item $pk = \langle N, e \rangle$ 42 | \item $sk = \langle N, d' \rangle$ em que $d' = [d^n\ mod\ \phi(N)]$ 43 | \end{itemize} 44 | \item $Encaps(pk, 1^n) = \langle c_{n+1}, k \rangle$ em que $c_1 \leftarrow \mathbb{Z}_N^\star$: 45 | \begin{itemize} 46 | \item $k_i := \textrm{\tt lsb}(c_i)$ e 47 | \item $c_{i+1} := [c_i^e\ mod\ N]$ 48 | \end{itemize} 49 | \item $Decaps(sk, c) = k'$ em que $c_1' = [c^{d'}\ mod\ N]$ e: 50 | \begin{itemize} 51 | \item $k_i := \textrm{\tt lsb}(c_i)$ e 52 | \item $c_{i+1} := [c_i^e\ mod\ N]$ 53 | \end{itemize} 54 | \end{itemize} 55 | 56 | Em palavras, a ideia é criptografar o primeiro bit de $k$ usando o último bit de $[c^e\ mod\ N]$ para um $c$ escolhido aleatóriamente em $\mathbb{Z}_N^\star$. 57 | O segundo bit de $k$ é computado usando o último de $[c^{e^2}\ mod\ N]$ e assim por diante. 58 | Ao final o algoritmo $Encaps$ devole o $k$ obtido e $[c^{e^n}\ mod\ N]$. 59 | Para decifrar partimos de $[c^{e^n}\ mod\ N]$ e elevamos a $d^n$ para recuperar o $c$ original e então repetimos exatamente o mesmo processo do algoritmo $Encaps$ para extrair cada um dos bits de $k$. 60 | 61 | É possível mostrar que esta construção produz um KEM seguro e, portanto, pode ser usado para produzir um sistema híbrido seguro contra CPA como vimos. 62 | Construir um sistema RSA seguro contra CCA requer uma série de modificações nos esquemas que vimos até aqui, cujos detalhes omitiremos. 63 | A especificação de um sistema RSA seguro contra CCA foi formalizada em um sistema chamado {\tt RSA PKCS \#1 v2.0}. -------------------------------------------------------------------------------- /apostila.toc: -------------------------------------------------------------------------------- 1 | \select@language {portuguese} 2 | \contentsline {chapter}{\numberline {1}Introdu\IeC {\c c}\IeC {\~a}o}{9} 3 | \contentsline {section}{\numberline {1.1}Privacidade}{9} 4 | \contentsline {section}{\numberline {1.2}Vigil\IeC {\^a}ncia}{10} 5 | \contentsline {section}{\numberline {1.3}Marco Regulat\IeC {\'o}rio}{11} 6 | \contentsline {section}{\numberline {1.4}Vigil\IeC {\^a}ncia Digital em Massa}{12} 7 | \contentsline {section}{\numberline {1.5}Seguran\IeC {\c c}a da Informa\IeC {\c c}\IeC {\~a}o}{13} 8 | \contentsline {chapter}{\numberline {2}Cifras Cl\IeC {\'a}ssicas}{15} 9 | \contentsline {section}{\numberline {2.1}Cifra de Deslocamento}{18} 10 | \contentsline {section}{\numberline {2.2}Cifra de Substitui\IeC {\c c}\IeC {\~a}o}{20} 11 | \contentsline {section}{\numberline {2.3}Cifra de Vigen\IeC {\`e}re}{21} 12 | \contentsline {section}{\numberline {2.4}M\IeC {\'a}quinas de Criptografar}{23} 13 | \contentsline {section}{\numberline {2.5}Exerc\IeC {\'\i }cio}{24} 14 | \contentsline {chapter}{\numberline {3}Criptoan\IeC {\'a}lise}{27} 15 | \contentsline {section}{\numberline {3.1}Ataques For\IeC {\c c}a Bruta}{27} 16 | \contentsline {section}{\numberline {3.2}Ataques de Frequ\IeC {\^e}ncia}{28} 17 | \contentsline {section}{\numberline {3.3}Ataques \IeC {\`a} ``Cifra Invenc\IeC {\'\i }vel''}{29} 18 | \contentsline {section}{\numberline {3.4}Exerc\IeC {\'\i }cios}{30} 19 | \contentsline {chapter}{\numberline {4}Sigilo Perfeito}{33} 20 | \contentsline {section}{\numberline {4.1}One Time Pad}{35} 21 | \contentsline {section}{\numberline {4.2}Exerc\IeC {\'\i }cio}{38} 22 | \contentsline {chapter}{\numberline {5}Criptografia Moderna}{39} 23 | \contentsline {section}{\numberline {5.1}Abordagem Assint\IeC {\'o}tica}{41} 24 | \contentsline {section}{\numberline {5.2}Exerc\IeC {\'\i }cios}{42} 25 | \contentsline {chapter}{\numberline {6}Cifras de Fluxo}{43} 26 | \contentsline {section}{\numberline {6.1}Seguran\IeC {\c c}a das Cifras de Fluxo}{45} 27 | \contentsline {section}{\numberline {6.2}Constru\IeC {\c c}\IeC {\~o}es Pr\IeC {\'a}ticas}{46} 28 | \contentsline {subsection}{\numberline {6.2.1}Linear-Feedback Shift Registers}{46} 29 | \contentsline {subsection}{\numberline {6.2.2}Trivium}{47} 30 | \contentsline {section}{\numberline {6.3}Modos de Opera\IeC {\c c}\IeC {\~a}o}{48} 31 | \contentsline {section}{\numberline {6.4}Exercicios}{50} 32 | \contentsline {chapter}{\numberline {7}Cifras de Bloco}{51} 33 | \contentsline {section}{\numberline {7.1}Constru\IeC {\c c}\IeC {\~o}es Pr\IeC {\'a}ticas}{53} 34 | \contentsline {subsection}{\numberline {7.1.1}Data Encryption Standard (DES)}{53} 35 | \contentsline {subsection}{\numberline {7.1.2}Advanced Encryption Standard (AES)}{56} 36 | \contentsline {section}{\numberline {7.2}Modos de Opera\IeC {\c c}\IeC {\~a}o}{57} 37 | \contentsline {section}{\numberline {7.3}Exerc\IeC {\'\i }cios}{62} 38 | \contentsline {chapter}{\numberline {8}Integridade e Autenticidade}{63} 39 | \contentsline {section}{\numberline {8.1}C\IeC {\'o}digo de Autentica\IeC {\c c}\IeC {\~a}o de Mensagem}{64} 40 | \contentsline {subsection}{\numberline {8.1.1}CBC-MAC}{66} 41 | \contentsline {section}{\numberline {8.2}Criptografia Autenticada}{67} 42 | \contentsline {subsection}{\numberline {8.2.1}Comunica\IeC {\c c}\IeC {\~a}o Segura}{70} 43 | \contentsline {section}{\numberline {8.3}Exercicios}{70} 44 | \contentsline {chapter}{\numberline {9}Fun\IeC {\c c}\IeC {\~o}es de Hash}{71} 45 | \contentsline {section}{\numberline {9.1}Constru\IeC {\c c}\IeC {\~o}es}{73} 46 | \contentsline {subsection}{\numberline {9.1.1}SHA-1}{74} 47 | \contentsline {section}{\numberline {9.2}Aplica\IeC {\c c}\IeC {\~o}es}{75} 48 | \contentsline {subsection}{\numberline {9.2.1}HMAC}{75} 49 | \contentsline {subsection}{\numberline {9.2.2}Fingerprints e \IeC {\'A}rvores de Merkle}{76} 50 | \contentsline {subsection}{\numberline {9.2.3}Fun\IeC {\c c}\IeC {\~o}es de Deriva\IeC {\c c}\IeC {\~a}o de Chaves}{77} 51 | \contentsline {section}{\numberline {9.3}Exerc\IeC {\'\i }cios}{78} 52 | \contentsline {chapter}{\numberline {10}Fun\IeC {\c c}\IeC {\~o}es de M\IeC {\~a}o \IeC {\'U}nica*}{79} 53 | \contentsline {section}{\numberline {10.1}Exerc\IeC {\'\i }cios}{85} 54 | \contentsline {chapter}{\numberline {11}Distribui\IeC {\c c}\IeC {\~a}o de Chaves}{87} 55 | \contentsline {section}{\numberline {11.1}Centro de Distribui\IeC {\c c}\IeC {\~a}o de Chaves}{87} 56 | \contentsline {subsection}{\numberline {11.1.1}Kerberos}{88} 57 | \contentsline {section}{\numberline {11.2}Protocolo de Diffie-Hellman}{89} 58 | \contentsline {section}{\numberline {11.3}Exerc\IeC {\'\i }cios}{94} 59 | \contentsline {chapter}{\numberline {12}Criptografia Assim\IeC {\'e}trica}{95} 60 | \contentsline {section}{\numberline {12.1}El Gammal}{96} 61 | \contentsline {section}{\numberline {12.2}RSA}{97} 62 | \contentsline {section}{\numberline {12.3}Exerc\IeC {\'\i }cios}{102} 63 | \contentsline {chapter}{\numberline {13}Sistemas H\IeC {\'\i }bridos}{103} 64 | \contentsline {section}{\numberline {13.1}El Gammal}{104} 65 | \contentsline {section}{\numberline {13.2}RSA}{105} 66 | \contentsline {chapter}{\numberline {14}Assinaturas Digitais}{107} 67 | \contentsline {section}{\numberline {14.1}Esquemas de Identifica\IeC {\c c}\IeC {\~a}o}{108} 68 | \contentsline {section}{\numberline {14.2}Assinatura RSA}{109} 69 | \contentsline {section}{\numberline {14.3}Algoritmo de Assinatura Digital (DSA)}{110} 70 | \contentsline {section}{\numberline {14.4}Infraestrutura de Chaves P\IeC {\'u}blicas}{111} 71 | \contentsline {section}{\numberline {14.5}Exerc\IeC {\'\i }cios}{113} 72 | \contentsline {chapter}{\numberline {15}Protocolos}{115} 73 | \contentsline {section}{\numberline {15.1}Transport Layer Security}{115} 74 | \contentsline {section}{\numberline {15.2}Secure Shell}{116} 75 | \contentsline {section}{\numberline {15.3}Pretty Good Privacy}{117} 76 | \contentsline {section}{\numberline {15.4}Off The Record}{119} 77 | \contentsline {section}{\numberline {15.5}Signal}{120} 78 | -------------------------------------------------------------------------------- /primos.tex: -------------------------------------------------------------------------------- 1 | \chapter{Números Primos} 2 | \label{cha:primos} 3 | 4 | Para gerar uma chave no sistema RSA precisamos gerar primos grandes e aleatórios. 5 | Para garantir que o número tera uma quantidade $n$ de bits sorteamos $p' \leftarrow \{0,1\}^{n-1}$ e acrescentar um bit $1$ à esquerda. 6 | Caso o número não seja primos repetimos o processo. 7 | 8 | Um importante resultado de Teoria dos Números chamado {\em Teorema dos Nùmeros Primos} estabelece que dado um número $n$ escolhido ao acaso, a chance de ele ser primo é $\frac{1}{ln(n)}$. 9 | Se estamos buscando um número menor que $n$, precisamos em média chutar $ln(n)$ números até encontrar um primo ou metade disso se ignorarmos os pares. 10 | Para cada tentativa, porém, precisamos verificar se o valor gerado é de fato primo. 11 | A forma ingênua -- verificar cada um dos possíveis divisores -- é inviável. 12 | Assim, precisamos utilizar algum método eficiente de verificação de primos. 13 | 14 | A ideia que seguiremos é de procurar {\em testemunhas} de que um número é composto. 15 | Por exemplo, o Teorema de Euller garante que para todo $a \in \mathbb{Z}_n^\star$ temos que $a^{\phi(n)} \equiv 1\ mod\ n$. 16 | No caso em que $n$ é primo sabemos que $\phi(n) = n - 1$ que todo inteiro positivo $a$ é inversível em $\mathbb{Z}_n$. 17 | Podemos então escolher $a \leftarrow \mathbb{Z}_n$ e fazer $a^{n-1}\ mod\ n$, se este valor for diferente de $1$ sabemos que $n$ não é primo. 18 | Ou seja $a$ é uma testemunha de que $n$ não é primo. 19 | 20 | Infelizmente existe uma infinidade de números compostos que não possuem esse tipo de testemunha. 21 | Seja então $n - 1 = 2^ru$, temos que se $n$ é primo então a sequência $a^u, a^{2u}, \dots, a^{2^ru}$ em algum momento começa a produzir apenas $1$s. 22 | Mais do que isso, com este teste todo número composto possui uma quantidade grande de testemunhas -- metade dos valores $a$ são testemunhas. 23 | Assim, se testarmos $t$ valores de $a$ diferentes e escolhidos de maneira aleatória, a chance de todos os testes acusarem de maneira falsa que $a$ não é composto é $2^{-t}$. 24 | 25 | Essa estratégia dá origem ao algoritmo de Miller-Rabin \cite{Miller75,Rabin80} que é o teste de primalidade mais usado hoje em dia: 26 | 27 | \begin{codebox} 28 | \Procname{$\proc{MillerRabin}(n, t)$} 29 | \li \Comment Recebe $n, t \in \mathbb{Z}$ 30 | \li \Comment Devolve {\tt composto} se $n$ é composto 31 | \li \Comment Devolve {\tt primo} se $n$ é primo com probabilidade $1 - 2^{-t}$ 32 | \li \If $n$ for par 33 | \li \Then \Return {\tt composto} 34 | \End 35 | \li \If \proc{EhPotenciaPerfeita}(n) 36 | %$n = n'^e$ para algum $n'$ e algum $e$ 37 | \li \Then \Return {\tt composto} 38 | \End 39 | \li Calcule $r$ e $u$ tais que $n-1 = 2^ru$ 40 | \li \For $j = 1$ \To $t$ 41 | \li \Do sorteia $a$ em $\{1, \dots, n-1\}$ 42 | \li \For $i = 1$ \To $r-1$ 43 | \li \Do \If $a^u \neq \pm 1\ mod\ n$ e $a^{2^iu} \neq -1\ mod\ n$ 44 | \li \Then \Return {\tt composto} 45 | \End 46 | \End 47 | \End 48 | \li \Return {\tt primo} 49 | \end{codebox} 50 | 51 | % Daqui para baixo ainda não está bom 52 | 53 | Para mostrar que o algoritmo de Miller-Rabin é correto precisamos mostrar que pelo menos metade dos elementos em $\mathbb{Z}_n$ são testemunhas de que $n$ é primo. 54 | Para tanto precisamos provar alguns resultados preliminares. 55 | 56 | 57 | \begin{lemma} 58 | Se $H \subseteq G$ e $H$ é fechado então $H$ é um subgrupo de $G$. 59 | \end{lemma} 60 | \begin{proof} 61 | Associatividade segue do fato de $H \subseteq G$ a existência de inverso e da identidade seguem do fecho. 62 | \end{proof} 63 | 64 | \begin{lemma} 65 | Seja $H$ um subgrupo de $G$ tal que $H \neq G$, então $|H| \leq \frac{|G|}{2}$ 66 | \end{lemma} 67 | \begin{proof} 68 | Como $H \neq G$ então existe $g \in G$ tal que $g \notin H$. 69 | Considere o conjunto $\bar{H} := \{gh : h \in H\}$. 70 | 71 | Se $gh_1 = gh_2$ então $h_1 = h_2$ (basta multiplicar os dois lados por $g^{-1}$), portanto, cada elemento distinto de $H$ corresponde a um elemento distinto em $\bar{H}$. 72 | Ou seja, $|H| = |\bar{H}|$. 73 | 74 | Agora suponha que $gh \in H$ para algum $h$. 75 | Neste caso $gh = h'$ para algum $h' \in H$ e, portanto, $g = h'h^{-1}$. 76 | Como $h', h^{-1} \in H$ e como $H$ é um grupo então $g \in H$, mas isso contradiz a definição de $g$ e portanto não existe $gh \in H$ para nenhum $h$. 77 | Em outras palavras $\bar{H} \cap H = \emptyset$. 78 | 79 | Juntando tudo temos que $H \subseteq G$ e $\bar{H} \subseteq G$ e, portanto, $|G| \geq |H| + |\bar{H}|$. 80 | Como $|H| = |\bar{H}|$, concluimos que $|G| \geq 2|H|$. 81 | \end{proof} 82 | 83 | Seja $i \in \{0, \dots r-1\}$ o maior inteiro tal que existe $a$ que não é testemunha e $a^{2^iu} \equiv -1\ mod\ n$. 84 | Note que $i$ deve existir, pois $-1$ não é testemunha e $(-1)^{2^0u} \equiv -1\ mod\ n$ 85 | Vamos agora construir um conjunto $B$ que é um subgrupo de $\mathbb{Z}_n^\star$ e que $B \neq \mathbb{Z}_n^\star$: 86 | 87 | \begin{displaymath} 88 | B := \{a : a^{2^iu} \equiv \pm 1\ mod\ n\} 89 | \end{displaymath} 90 | 91 | Seja $a$ um elemento que não é testemunha de que $n$ é primo i.e. $a^u \equiv 1\ mod\ n$ ou $a^{2^ju} \equiv -1\ mod\ n$ para algum $j \in \{0, \dots, r-1\}$. 92 | No primeiro caso $a \in B$. 93 | No segundo caso $j \leq i$. 94 | Se $i =j$ então $a \in B$, caso contrário, $a^{2^iu} \equiv (2^{2^ju})^{2^{i-j}} \equiv 1\ mod\ n$ e temos que $a \in B$. 95 | Concluímos que todo elemento que não é testemunha pertence a $B$. 96 | 97 | Resta mostrar que $B$ é um subgrupo de $\mathbb{Z}_n^\star$ e que $B \neq \mathbb{Z}_n^\star$. 98 | Para o primeiro basta notar que para quaisquer $a,b \in B$ temos que $a \cdot b \equiv (\pm 1)(\pm 1) \equiv \pm 1\ mod\ n$. 99 | A demostração de que $B \neq \mathbb{Z}_n^\star$ é mais complicada e será omitida. 100 | 101 | 102 | 103 | % concluimos que existem no máximo n/2 elementos de Z_n^* não são testemunhas de que n é primo 104 | % provar a correção do algoritmo de Miller-Rabin 105 | 106 | % mostrar o algoritmo EhPotenciaPerfeita e sua complexidade -------------------------------------------------------------------------------- /dsa.tex: -------------------------------------------------------------------------------- 1 | \chapter{Algoritmo de Assinaturas Digitais} 2 | \label{cha:dsa} 3 | 4 | Neste apêndice nos aprofundaremos no tema das assinaturas digitais apresentando esquemas de identificação e o algoritmo DSA. 5 | 6 | \section{Esquemas de Identificação} 7 | \label{sec:esqu-de-ident} 8 | 9 | Um esquema de identificação é um protocolo em que uma parte tem como objetivo provar sua identidade para a outra. 10 | Chamamos de {\em provador} aquele que deseja provar sua identidade e {\em verificador} aquele que deseja verificá-la. 11 | Assumimos que o verificador possui a chave pública do provador e vamos focar em protocolos com três interações e três algoritmos $langle \mathcal{P}_1, \mathcal{P}_2, \mathcal{V} \rangle$: 12 | \begin{enumerate} 13 | \item O provador usa $\mathcal{P}_1$ com sua chave secreta $sk$ para gerar uma {\em mensagem inicial} $I$ e um estado $st$ e envia $I$ para o verificador. 14 | \item O Verificador escolhe um {\em desafio} $r$ aleatoriamente de um conjunto $\Omega_{pk}$ gerado a partida da chave pública do Provador e envia $r$ de volta. 15 | \item O Provador usa $\mathcal{P}_2$ com entradas $sk$, $st$ e $r$ para gerar uma resposta $s$ que ele envia para o Verificador. 16 | \item Por fim, o Verificador testa se $\mathcal{V}(pk, r, s)$ computa $I$. 17 | \end{enumerate} 18 | 19 | % DIAGRAMA!!! 20 | 21 | A ideia por trás do esquema de identificação é que apenas que possui a chave secreta seria capaz de $s$ a partir do desafio $r$. 22 | A mensagem $I$ e o estado $st$ servem para garantir que um adversário não copie os mesmos passos de identificação e seja bem sucedido. 23 | Um esquema de identificação seguro deve garantir que seja computacionalmente inviável para um adversário enganar o sistema de identificação mesmo que ele observe vários processos similares. 24 | 25 | % agora que isso ficou no apêndice talvez faça sentido colocar a parte da transformação de Fiat-Shamir 26 | 27 | A partir de um sistema de identificação seguro é possível gerar um sistema de assinatura digital seguro usando a {\em transformação de Fiat-Shamir} \cite{Fiat87}. 28 | Na hora de assinar uma mensagem $I$ e $st$ são computados e calculamos $H(I, m)$ para gerar $r$ e usamos $r$, $sk$ e $st$ para gerar $s$. 29 | A assinatura será exatamente o par $\langle r, s \rangle$. 30 | O algoritmo de verificação deve rodar $\mathcal{V}$ com $pk$, $r$ e $s$ como entrada para produzir $I$ e então verifica-se se $H(I, m) = r$: 31 | 32 | \begin{itemize} 33 | \item $Gen(1^n) := \langle sk, pk \rangle$ e assumimos que $H: \{0,1\}^* \to \Omega_{pk}$ é uma função de hash específica 34 | \item $Sign(sk, m) = \langle r, s \rangle$ tal que 35 | \begin{itemize} 36 | \item $\mathcal{P}_1(sk) := \langle I, st \rangle$, 37 | \item $r := H(I, m)$ e 38 | \item $s := \mathcal{P}_2(sk, st, r)$ 39 | \end{itemize} 40 | \item $Ver(pk, m, \langle r, s \rangle) = \left\{ 41 | \begin{array}{lcl} 42 | 1 & \textrm{se} & H(\mathcal{V}(pk, r, s), m) = r\\ 43 | 0 & \textrm{c.c.} &\\ 44 | \end{array} 45 | \right.$ 46 | \end{itemize} 47 | 48 | Considerando que o esquema de identificação $\langle \mathcal{P}_1, \mathcal{P}_2, \mathcal{V} \rangle$ seja seguro, podemos provar que o sistema de assinatura digital acima também é seguro, mas para esta prova é necessário supor não que $H$ seja resistente a colisões, mas que ele seja um {\em oráculo aleatório}, uma suposição muito mais forte e difícil de validar empiricamente. 49 | 50 | \section{Algoritmo de Assinatura Digital (DSA)} 51 | \label{sec:dsa} 52 | 53 | O esquema de assinatura RSA depende da dificuldade do problema da fatoração. 54 | Podemos também construir sistemas que dependem da dificuldade do problema do logaritmo discreto. 55 | Este é o caso do popular esquema DSA e do ECDSA que usa curvas elípticas. 56 | Antes de apresentar o sistema de assinatura digital, apresentaremos um esquema de identificação em que assumimos que a chave secreta é $x$ e a chave pública é $\langle \mathbb{G}, g, y, n \rangle$ com $\mathbb{G}$ um grupo cíclico, $g$ um gerador e $y = g^x$: 57 | 58 | \begin{enumerate} 59 | \item O Provador sorteia $k \leftarrow \mathbb{Z}_n^\star$ e envia $I := g^k$ para o Verificador. 60 | \item O Verificador sorteia $a, r \leftarrow \mathbb{Z}_q$ como desafios e envia de volta. 61 | \item O Provador envia $s := [k^{-1} \cdot (\alpha + xr)\ mod\ q]$ como resposta. 62 | \item O Verificador aceita se $s \neq 0$ e $g^{\alpha s^{-1}} \cdot y^{rs^{-1}} = I$ 63 | \end{enumerate} 64 | 65 | A probabilidade de $s = 0$ é desprezível. 66 | Se assumirmos que $s \neq 0$ a correção do esquema segue, pois: 67 | \begin{displaymath} 68 | g^{\alpha s^{-1}} \cdot y^{rs^{-1}} = g^{\alpha s^{-1}} \cdot g^{xrs^{-1}} = g^{(\alpha + xr)\cdot s^{-1}} = g^{(\alpha + xr)\cdot k \cdot (\alpha + xr)^{-1}} = g^k = I 69 | \end{displaymath} 70 | 71 | É possível provar que este esquema é seguro considerando que o problema do logaritmo discreto seja seguro. 72 | 73 | Podemos transformar esse esquema de identificação em um sistema de assinatura usando a transformação de Fiat-Shamir, mas o popular esquema DSA segue um caminho um pouco diferente. 74 | Assumiremos a existência de duas funções $H: \{0,1\}^* \to \mathbb{Z}_n$ e $F: \mathbb{G} \to \mathbb{Z}_n$: 75 | 76 | \begin{itemize} 77 | \item $Gen(1^n) = \langle sk, pk \rangle$ em que: 78 | \begin{itemize} 79 | \item $sk := x \leftarrow \mathbb{Z}_n$ e 80 | \item $pk := \langle \mathbb{G}, g, y, n \rangle$ com $y = g^x$ 81 | \end{itemize} 82 | \item $Sign(sk, m) = \langle r, s \rangle$ em que: 83 | \begin{itemize} 84 | \item $r := F(g^k)$ com $k \leftarrow \mathbb{Z}_n$ e 85 | \item $s := [k^{-1} \cdot (H(m) + xr)\ mod\ q]$ (sorteamos outro $r$ caso $s = 0$) 86 | \end{itemize} 87 | \item $Ver(pk, m, t) := \left\{ 88 | \begin{array}{lcl} 89 | 1 & \textrm{se} & r = F(g^{H(m) \cdot s^{-1}} y^{r \cdot s^{-1}})\\ 90 | 0 & \textrm{c.c.} &\\ 91 | \end{array} 92 | \right.$ 93 | \end{itemize} 94 | 95 | A correção desse sistema é muito similar ao esquema de identificação apresentado anteriormente. 96 | É possível provar sua segurança assumindo a dificuldade do problema do logaritmo discreto e tratando $H$ e $F$ como oráculos aleatórios. 97 | No caso de $F$ isso é particularmente difícil de aceitar e não se conhece uma prova de segurança melhor do que essa até hoje. -------------------------------------------------------------------------------- /ciclicos.tex: -------------------------------------------------------------------------------- 1 | \chapter{Grupos Cíclicos} 2 | \label{cha:ciclicos} 3 | 4 | No Capítulo \ref{cha:distribuicao-chaves} vimos que uma condição necessária para a segurança do protocolo de Diffie-Hellman é a dificuldade do problema do logaritmo discreto (DLog). 5 | Tanto o protocolo de Diffie-Hellman quanto o sistema de criptografia assimétrica de El Gammal assumem que podemos construir grupos cíclicos cujo problema DLog seja difícil. 6 | Nesta seção apresentaremos duas construção de grupos cíclicos em que DLog é considerado difícil e ambas são usadas na prática. 7 | 8 | \section{Grupos de ordem prima} 9 | \label{sec:grupos-de-ordem} 10 | 11 | O primeiro modelo parte de um teorema que estabelece que grupos com tamanho primo são necessariamente cíclicos e, além disso, qualquer elemento diferente da identidade é um gerador. 12 | 13 | Vamos começar generalizando o Corolário \ref{cor:euler} do Teorema de Euler usado para provar a correção do algoritmo RSA. 14 | Naquela situação estávamos usando um grupo específico, a saber, $\mathbb{Z}_n^\star$, mas o resultado vale para qualquer grupo finito: 15 | 16 | 17 | \begin{lemma} 18 | Seja $\mathbb{G}$ um grupo finito e $g \in \mathbb{G}$ um elemento de ordem $i$. 19 | Então para todo $x$ temos que $g^x = g^{[x\ mod\ i]}$. 20 | \end{lemma} 21 | \begin{proof} 22 | Pelo algoritmo da divisão temos que $x = qi +r$ em que $r = [x\ mod\ i]$. 23 | Portanto temos que: 24 | \begin{displaymath} 25 | g^x = g^{qi + r} = g^{qi} \circ g^r = (g^i)^q \circ g^{[x\ mod\ i]} = g^{[x\ mod\ i]} 26 | \end{displaymath} 27 | \end{proof} 28 | 29 | Agora podemos provar o seguinte teorema: 30 | 31 | \begin{theorem} 32 | Se $\mathbb{G}$ é um grupo de ordem prima $p$ então $\mathbb{G}$ é cíclico e qualquer $g \in \mathbb{G}$ diferente de $1$ é um gerador. 33 | \end{theorem} 34 | \begin{proof} 35 | Seja $p = |\mathbb{G}|$ a ordem do grupo $\mathbb{G}$ e $i$ a ordem de um elemento qualquer $g \in \mathbb{G}$. 36 | Pelo lema temos que $g^p = g^{[p\ mod\ i]}$ e pelo Teorema \ref{theo:gen-euler} temos que $g^p = 1$. 37 | Como $[p\ mod\ i] < i$ e como, por definição, $i$ é o menor inteiro tal que $g^i = 1$ temos que $[p\ mod\ i] = 0$, ou seja, $i|p$. 38 | Mas, uma vez que $p$ é primo, temos que $i = 1$ ou $i = p$. 39 | O único elemento que tem ordem $1$ é a identidade, todos os demais tem ordem $p$ e, portanto, são geradores de $\mathbb{G}$. 40 | \end{proof} 41 | 42 | Esse resultado sugere que uma boa forma de encontrar grupos cíclicos é por buscando grupos de ordem prima. 43 | Note, porém, que os candidatos naturais $\mathbb{Z}_p^\star$ tem ordem $p - 1$ o que quase nunca é primo\footnote{A única exceção é $p = 3$.}. 44 | O que se costuma fazer é trabalhar com algum subgrupo de $\mathbb{Z}_p^\star$ de ordem prima. 45 | O teorema a seguir, que não será provado, estabelece que se $p = qr + 1$ para algum $q$ primo, então o conjunto dos {\em $r$-ésimos resíduos módulo $p$}formam um grupo de tem tamanho $q$: 46 | 47 | \begin{theorem} 48 | Se $p = qr + 1$ e $p$ e $q$ são primos, então temos que 49 | \begin{displaymath} 50 | \mathbb{G} = \{[h^r\ mod\ p] : h \in \mathbb{Z}_p\} 51 | \end{displaymath} 52 | é um subgrupo de $\mathbb{Z}_p^\star$ de ordem $q$. 53 | \end{theorem} 54 | 55 | Este teorema é o que garante a correção do seguinte algoritmo: 56 | 57 | \begin{codebox} 58 | \Procname{$\proc{GeradorDeGruposCiclicos}(1^n)$} 59 | \li \Comment Recebe um parâmetro de segurança $1^n$ que estabelece $l = l(n)$ 60 | \li \Comment Devolve um grupo cíclico $\mathbb{G}$ cuja ordem é $q$ e um gerador $g$ 61 | \li escolhe aleatoriamente $q$ primo com $l$ bits 62 | \li gera um primo $p$ tal que $q|(p-1)$ 63 | \li escolhe aleatoriamente $h \in \mathbb{Z}_p^\star$ tal que $h \neq 1$ 64 | \li $g \gets [h^{\frac{p-1}{q}}\ mod\ p]$ 65 | \li \Return $p, q, g$ 66 | \end{codebox} 67 | 68 | O problema do logaritmo discreto para grupos gerados por esse algoritmo é considerado difícil. 69 | 70 | \section{Curvas Elípticas} 71 | \label{sec:curvas-elipticas} 72 | 73 | Uma curva elíptica é formada por todos os pontos $(x,y)$ que satisfazem a seguinte equação, dados os parâmetro $a$ e $b$: 74 | 75 | \begin{displaymath} 76 | y^2 = x^3 + ax + b 77 | \end{displaymath} 78 | 79 | \begin{figure}[htbp] 80 | \centering 81 | \includegraphics[width=.8\textwidth]{imagens/EllipticCurves.png} 82 | \caption{Curvas elípticas com diferentes parâmetros} 83 | \label{fig:curvas-elipticas} 84 | \end{figure} 85 | 86 | Podemos definir a adição de pontos em uma curva elíptica de maneira geometricamente natural. 87 | A soma de dois pontos distintos é dada pelo ponto que intersecciona a reta que passa pelos dois (Figura \ref{fig:soma-eliptica} - quadro 1). 88 | No caso extremo em que queremos somar o mesmo ponto duas vezes pegamos a reta tangente ao ponto e verificamos em qual ponto ela cruza com a reta (Figura \ref{fig:soma-eliptica} - quadro 2). 89 | Nos casos degenerados em que a reta não cruza com a curva vamos atribuir um valor especial $0$ (Figura \ref{fig:soma-eliptica} - quadro 3). 90 | 91 | \begin{figure}[htbp] 92 | \centering 93 | \includegraphics[width=\textwidth]{imagens/ECClines2.png} 94 | \caption{Soma de pontos em curvas elípticas} 95 | \label{fig:soma-eliptica} 96 | \end{figure} 97 | 98 | Algebricamente definimos a soma dos pontos da seguinte forma: $(x_1, y_1) + (x_2, y_2) = (x_3, y_3)$ tal que: 99 | 100 | \begin{eqnarray*} 101 | x_3 & = & s^2 - x_1 - x_2\\ 102 | y_3 & = & s(x_1 - x_3) - y_1 103 | \end{eqnarray*} 104 | 105 | e $s$ (a inclinação da reta) na apresentação geométrica é dada por: 106 | 107 | \begin{displaymath} 108 | s =\left\{ 109 | \begin{array}{cl} 110 | \frac{y_2 - y_1}{x_2 - x_1} & \textrm{se os pontos são distintos}\\ 111 | \frac{3x_1^2 + a}{2y_1} & \textrm{caso contrário}\\ 112 | \end{array}\right . 113 | \end{displaymath} 114 | 115 | 116 | O conjunto $(\mathbb{R} \times \mathbb{R}) \cup \{0\}$ junto da operação que acabamos de definir é um grupo, porém, infinito. 117 | 118 | Para nos mantermos no mundo dos grupos finitos estabeleceremos um número primo $p$ e faremos todas as contas acima módulo $p$ -- o que faz com que não sejamos mais capazes de expressar nossas contas de maneira geometricamente intuitiva. 119 | 120 | Vamos então escrever o conjunto dos elementos de uma curva elíptica como: 121 | \begin{displaymath} 122 | E(\mathbb{Z}_p) = \{(x,y) : x, y \in \mathbb{Z}_p \textrm{ e } y^2 \equiv x^3 + ax + b\ mod\ p\} \cup \{0\} 123 | \end{displaymath} 124 | 125 | O teorema a seguir nos dá algumas pistas sobre o tamanho deste conjunto: 126 | 127 | 128 | \begin{theorem}[Hasse] 129 | Seja $p$ um número primo, então temos que: 130 | \begin{displaymath} 131 | p + 1 - 2\sqrt{p} \leq |E(\mathbb{Z}_p)| \leq p + 1 + 2\sqrt{p} 132 | \end{displaymath} 133 | \end{theorem} 134 | 135 | Ou seja, o número de pontos em $E(\mathbb{Z}_p)$ é mais ou menos da mesma ordem do que $p$. 136 | Podemos então construir o seguinte algoritmo análogo ao apresentado na seção anterior para computar um grupo cíclico: 137 | 138 | 139 | \begin{codebox} 140 | \Procname{$\proc{GeradorDeGruposCiclicos2}(1^n)$} 141 | \li \Comment Recebe um parâmetro de segurança $1^n$ 142 | \li \Comment Devolve um grupo cíclico $\mathbb{G}$ cuja ordem é $q$ e um gerador $g$ 143 | \li escolhe aleatoriamente $p$ primo com $n$ bits 144 | \li \While $q$ não for primo 145 | \li \Do escolha $a, b$ aleatoriamente em $\mathbb{Z}_p$ tal que $4a^3 + 27b^2 \neq 0\ mod\ p$ 146 | \li defina a curva elíptica $E(\mathbb{Z}_p)$ 147 | \li seja $q = |E(\mathbb{Z}_p)|$ 148 | \End 149 | \li escolha um elemento qualquer $g \in E(\mathbb{Z}_p) \setminus \{0\}$ 150 | \li \Return $(a, b, p), q, g$ 151 | \end{codebox} 152 | 153 | O logaritmo discreto de um grupo tal qual construído pelo algoritmo acima é considerado difícil. -------------------------------------------------------------------------------- /criptoanalise.tex: -------------------------------------------------------------------------------- 1 | \chapter{Criptoanálise} 2 | \label{cha:criptoanalise} 3 | 4 | Nos capítulos anteriores vimos uma série de cifras que a história deu conta de mostrar que não são seguras. 5 | Neste capítulo focaremos nas técnicas para quebrar essas cifras. 6 | O estudo e a análise dos sistemas de informação com a intenção de desvelar seus segredos é o que chamamos de {\em criptoanálise}. 7 | 8 | \section{Ataques Força Bruta} 9 | \label{sec:forca-bruta} 10 | 11 | Uma forma universal de quebrar uma cifra é conhecido como {\em ataque força bruta}. 12 | Ele consiste no seguinte procedimento. 13 | O adversário utiliza o esquema $D$, que sempre assumimos ser de conhecimento público, numa cifra $c$ com uma primeira tentativa de chave $k_0$ para produzir $D(k_0, c) = m_0$. 14 | A mensagem $m_0$ provavelmente não fará nenhum sentido, então o adversário repete o processo com uma outra chave $k_1$ e em seguida com $k_2$ e assim por diante até que mensagem produzida seja coerente. 15 | 16 | Consideremos a cifra de deslocamento. 17 | Estabelecemos que uma chave nesse tipo de sistema é escolhida aleatoriamente no conjunto $\mathbb{Z}_{26}$. 18 | Assim existem exatamente 26 possibilidades de chave, porque $|\mathbb{Z}_{26}| = 26$. 19 | O número esperado de tentativas até se encontrar a chave procurada é $\frac{|K|}{2}$, neste caso 13. 20 | Ou seja, a cifra de deslocamento é muito vulnerável a ataques de força bruta porque seu universo de chaves é extremamente pequeno. 21 | 22 | Em contraste vamos calcular o universo de chaves da cifra de substituição. 23 | Vimos que o universo das chaves de uma cifra de susbstituição é $Perm(\mathbb{Z}_{26})$. 24 | Calcular $|Perm(\mathbb{Z}_{26})|$ é um exercício simples de {\em análise combinatória}. 25 | 26 | \begin{eqnarray*} 27 | |Perm(\mathbb{Z}_{26}|) & = & 26!\\ 28 | & = & 26.25.24 \dots 1\\ 29 | & \approx & 4.10^{26}\\ 30 | & \approx & 2^{88} 31 | \end{eqnarray*} 32 | 33 | O universo de chaves na cifra de deslocamento é tão pequeno que é possível testar na mão todas as possibilidades de chaves. 34 | Certamente não é possível testar as possibilidades de chaves da cifra de substituição na mão. 35 | Ataques força bruta, porém, são facilmente automatizáveis. 36 | Voltaremos a pergunta sobre o tamanho do universo de chaves para uma comunicação segura no capítulo \ref{chap:senhas}. 37 | 38 | 39 | \begin{example} 40 | Muitos dos roteadores modernos possuem um mecanismo chamado de WPS (Wi-Fi Protected Setup) que supostamente simplificaria o processo de conexão, especialmente na configuração do hardware. 41 | O WPS permite que um usuário se conecte remotamente e sem fio no roteador desde que possua um PIN (Personal Identification Number). 42 | Esse PIN é uma sequência de oito digitos de 0 a 9. 43 | Ou seja, o universo das chaves é $10^8 \approx 2^{27}$. 44 | Neste contexto, um ataque força-bruta é possível e toma entre 4 e 8 horas. 45 | \end{example} 46 | 47 | 48 | \section{Ataques de Frequência} 49 | \label{sec:frequencia} 50 | 51 | A cifra de substituição é suficientemente segura contra ataques de força-bruta. 52 | Como vimos, porém, ela não é tão segura quanto a rainha Mary da Escócia gostaria. 53 | A forma como os funcionários da rainha Elizabeth quebraram a cifra de substituição é o que chamamos de {\em ataque de frequência}. 54 | A ideia por trás desse tipo de ataque é bastante simples. 55 | Na cifra de substituição, cada letra é substituída por um símbolo. 56 | Portanto, a frequência de cada símbolo em um texto suficientemente longo deve ser parecida com a frequência média de cada letra naquela língua. 57 | Por exemplo, no português, esperamos que os símbolos mais comuns sejam o {\tt a}, o {\tt e} e o {\tt o}. 58 | Para piorar -- ou melhorar dependendo da perspectiva -- na maioria das línguas há digrafos particulares, por exemplo, no português dois símbolos repetídos provavelmente representam o {\tt r} ou o {\tt s} e o {\tt h} quase sempre vem depois do {\tt l} ou do {\tt n}. 59 | Se o texto a ser decifrado for suficientemente longo, essas pistas podem ser suficientes para quebrar a cifra. 60 | 61 | No seguinte trecho de ``O escaravelho de ouro'' de Edgar Allan Poe a personagem descreve essa técnica que ela utilizou para decifrar um texto em inglês \cite{}: 62 | 63 | \begin{quote} 64 | ``Ora, no inglês, a letra que ocorre com mais frequência é a letra {\tt e}. 65 | Depois dela, a sucessão é: {\tt a o i d h n r s t u y c f g l m w b k p q x z}. 66 | O e prevalece de tal maneira que quase nunca se vê uma frase isolada em que ele não seja predominante. 67 | Aqui nós temos, portanto, bem no início, uma base que permite mais do que um mero palpite. 68 | O uso que se pode fazer da tabela é óbvio, mas, neste criptograma em particular, não precisamos nos valer dela por inteiro. 69 | Como nosso caractere dominante é o {\tt 8}, começaremos assumindo que este é o {\tt e} do alfabeto normal. (...)'' 70 | \end{quote} 71 | 72 | Em português, faz sentido separar as letras em cinco blocos, com frequência de ocorrência decrescente: 73 | \begin{enumerate} 74 | \item {\tt a}, {\tt e} e {\tt o} 75 | \item {\tt s}, {\tt r} e {\tt i} 76 | \item {\tt n}, {\tt d}, {\tt m}, {\tt u}, {\tt t} e {\tt c} 77 | \item {\tt l}, {\tt p}, {\tt v}, {\tt g}, {\tt h}, {\tt q}, {\tt b} e {\tt f} 78 | \item {\tt z}, {\tt j}, {\tt x}, {\tt k}, {\tt w} e {\tt y} 79 | \end{enumerate} 80 | 81 | \section{Ataques à ``Cifra Invencível''} 82 | \label{sec:criptoanalise-vegenere} 83 | 84 | Apesar da fama de ``inquebrável'' que a cifra de Vigenère ostentou até o começo do século XX, desde a metade do século anterior já eram conhecidos métodos de criptoanálise capazes de derrotar esse tipo de cifra. 85 | 86 | Em 1854 John Hall Brock Thwaites submeteu um texto cifrado utilizando uma cifra supostamente por ele inventada. 87 | Charles Babbage, o inventor das máquinas que precederam o computador moderno, mostrou que no fundo a cifra de Thwaites era equivalente a cifra de Vigenère. 88 | Após ser desafiado, Babbage, decifrou uma mensagem criptografada por Thwaites duas vezes com chaves diferentes. 89 | 90 | Em 1863 Friedrich Kasiski formalizou um ataque contra a cifra de Vigenère que ficou conhecido como {\em teste de Kasiski}. 91 | O ataque considera o fato de que a chave se repete com uma frequência fixa e, portanto, há uma probabilidade de produzir padrões reconhecíveis. 92 | Considere o exemplo extraído da Wikipédia: 93 | 94 | \begin{example} 95 | \begin{verbatim} 96 | Mensagem: cryptoisshortforcryptography 97 | Chave: abcdabcdabcdabcdabcdabcdabcd 98 | Cifra: CSASTPKVSIQUTGQUCSASTPIUAQJB 99 | \end{verbatim} 100 | \end{example} 101 | 102 | Note que o padrão CSASTP se repete na cifra. 103 | Isso ocorre porque o prefixo {\tt crypto} foi criptografado com a mesma chave. 104 | Uma vez encontrado um padrão como este, é calculada a distância entre as repetições. 105 | Neste caso a distância é 16, o que significa que o tamanho da chave deve ser um divisor de 16 (2, 4, 8 ou 16). 106 | Com esta informação, podemos aplicar um ataque de frequência nos caracteres de 2 a 2, de 4 a 4, de 8 a 8 e de 16 a 16. 107 | 108 | \section{Exercícios} 109 | \label{sec:exercicios} 110 | 111 | 112 | \begin{exercicio} 113 | Calcule o tamanho do universo das chaves em uma cifra de Vigenère da forma como usada normalmente (escolhendo um palavra) e na forma como apresentamos formalmente (sequência aleatória com tamanho fixo $l$)? 114 | \end{exercicio} 115 | 116 | 117 | \begin{exercicio} 118 | Construa um script que extraia um corpus do português moderno (por exemplo, textos da wikipedia) e calcule a frequência de ocorrência das letras do alfabeto. 119 | \end{exercicio} 120 | 121 | \begin{exercicio} 122 | Em 2017 um rapaz que ficou conhecido como menino do Acre ficou dias desaparecido e deixou uma serie de livros criptografados com cifra de substituição em seu quarto. 123 | Na Figura \ref{fig:menino-do-acre} está reproduzida uma página de um desses livros. 124 | Utilize a análise de frequência para decifrar o texto. 125 | \end{exercicio} 126 | 127 | \begin{figure}[htbp] 128 | \centering 129 | \includegraphics[width=.8\textwidth]{imagens/bruno.jpg} 130 | \caption{Texto criptografado pelo Menino do Acre} 131 | \label{fig:menino-do-acre} 132 | \end{figure} 133 | 134 | % Colocar aqui a frequência das letras em português, de preferência com um gráfico 135 | % Inserir o exemplo do menino do Acre a partir do trabalho que eles enviarem 136 | % Técnica para quebrar a cifra de Vigenère 137 | 138 | -------------------------------------------------------------------------------- /assinaturas-digitais.tex: -------------------------------------------------------------------------------- 1 | \chapter{Assinaturas Digitais e PKI} 2 | \label{cha:assinaturas-digitais} 3 | 4 | No capítulo anterior vimos que é possível construir um sistema de criptografia em que as partes não precisam trocar um segredo de antemão. 5 | Os esquemas da criptografia assimétrica pressupõe a geração de um par de chaves, uma pública e outra secreta. 6 | As assinaturas digitais, que veremos neste capítulo, seriam o equivalente àos códigos de autenticação de mensagem que vimos no Capítulo \ref{cha:mac} no contexto da criptografia assimétrica. 7 | 8 | \begin{center} 9 | \begin{tikzpicture}[node distance=2cm,auto,>=latex] 10 | \node (alice) at (0, 2){Alice}; 11 | \node (bob) at (10, 2) {Bob}; 12 | \node (eva) at (5, 2) {Eva}; 13 | 14 | \node (m1) at (0,1) {$m$}; 15 | \node (pk1) at (0,-2) {$pk$}; 16 | \node (Sign) at (2,0) {$Sign(sk,m) = t$}; 17 | \node (Ver) at (8,0) {$Ver(pk, m, t)$}; 18 | \node (sk) at (0,-1) {$sk$}; 19 | \node (pk2) at (10,-2) {$pk$}; 20 | 21 | \path[->] (eva) edge (5,1); 22 | \draw[->] (m1) -> (Sign); 23 | \draw[->] (sk) -> (Sign); 24 | \draw[->] (pk2) -> (Ver); 25 | \draw[->] (pk1) -> (pk2); 26 | \draw[->] (Sign) -> node[above]{$m, t$} (Ver); 27 | \end{tikzpicture} 28 | \end{center} 29 | 30 | Um {\em sistema de assinatura digital} consiste de três algoritmos: 31 | \begin{itemize} 32 | \item $Gen$ recebe o parâmetro de segurança $1^n$ e produz um par de chaves $\langle sk, pk \rangle$. 33 | A primeira deve ser mantida em sigilo e a segunda pode ser publicada. 34 | \item $Sign$ recebe a chave secreta $sk$ e uma mensagem $m$ e produz uma assinatura $t$. 35 | \item $Ver$ recebe a chave pública $pk$, uma mensagem $m$ e uma assinatura $t$ e verifica se essa assinatura é válida para mensagem $m$ e de fato da pessoa que possui a chave secreta. 36 | Em caso positivo o algritmo deve devoler $1$ e em caso negativo $0$. 37 | \end{itemize} 38 | 39 | Note que no meio digital, para cada mensagem direferente uma mesma pessoa produz assinaturas diferentes. 40 | Um sistema de assinatura digital é {\em correto} se: 41 | \begin{displaymath} 42 | Ver(pk, m, Sign(sk, m)) = 1 43 | \end{displaymath} 44 | 45 | Um sistema como esse é {\em seguro contra falsificação} se qualquer adversário eficiente, mesmo com acesso a um oráculo que lhe entregue assinaturas para mensagens diferentes de $m$, não é capaz de produzir uma assinatura válida para $m$ com probabilidade considerável. 46 | 47 | Da mesma forma que os sistemas de criptografia assimétrica, produzir uma assinatura digital para uma mensagem muito grande pode ser um processo lento. 48 | Uma técnica usada na prática para mitigar este problema é assinar não a mensagem $m$ em si, mas um hash da mensagem $H(m)$. 49 | Neste caso, para verificar a integridade e autenticidade da mensagem, basta gerar $H(m)$ e verificar a assinatura. 50 | Essa construção é chamada de {\em paradigma Hash-and-Sign}. 51 | É possível provar a segurança contra falsificação em uma construção como essa no caso em que o esquema de assinatura usado é seguro contra falsificação e o hash é resistente à colisão. 52 | 53 | 54 | \section{Assinatura RSA} 55 | \label{sec:assinatura-rsa} 56 | 57 | Um sistema de assinatura digital $\Pi = \langle Gen, Sign, Ver \rangle$ pode ser construído invertendo o esquema de criptografia assimétrica que vimos no capítulo anterior. 58 | Ou seja, criptografamos a mensagem com a chave secreta para gerar a assinatura e descriptografamos com a chave pública para verificar. 59 | Esse esquema não é seguro até aplicarmos o paradigma {\em hash-and-sign}. 60 | O esquema todo segue: 61 | \begin{itemize} 62 | \item $Gen(1^n) := \langle sk, pk \rangle$ em que: 63 | \begin{itemize} 64 | \item $sk := \langle N, d \rangle$ e 65 | \item $pk := \langle N, e \rangle$ 66 | \end{itemize} 67 | \item $Sign(sk, m) := [H(m)^d\ mod\ N]$ 68 | \item $Ver(pk, m, t) := \left\{ 69 | \begin{array}{lcl} 70 | 1 & \textrm{se} & t^e \equiv H(m)\ mod\ N\\ 71 | 0 & \textrm{c.c.} &\\ 72 | \end{array} 73 | \right.$ 74 | \end{itemize} 75 | 76 | A correção deste sistema segue os mesmos passos da correção do sistema de criptografia RSA que vimos no capítulo anterior. 77 | Além disso, podemos provar que se o sistema RSA é seguro e o hash $H$ usado é resistente à colisão então o sistema acima é seguro contra falsificação. 78 | Esse sistema é a base do sistema de assinatura do protocolo {\tt RSA PKCS \#1 v2.1}. 79 | 80 | \section{Infraestrutura de Chaves Públicas} 81 | \label{sec:pki} 82 | 83 | O protocolo de Diffie-Hellman e a criptografia assimétrica garantem a segurança da comunicação contra ataques passivos sem precisarmos supor que as partes compartilhe um segredo {\em a priori}. 84 | Um problema que ainda não tratamos até aqui é como garantir a segurança contra um ataque ativo, ou seja, contra um modelo de ameaça em que o adversario não só é capaz de observar a comunicação, como também é capaz de interferir nela. 85 | Um ataque que os sistemas que vimos até aqui estão particularmente sujeitos é o seguinte. 86 | Digamos que Alice pretende se comunicar com Bob usando um sistema de criptografia assimétrico. 87 | O primeiro passo para Alice é obter a chave pública de Bob. 88 | Neste momento Eva pode enviar a sua chave pública como se fosse a de Bob, receber as mensagens que Alice enviaria para Bob, copiá-las e re-encaminhá-las para Bob. 89 | Este tipo de ataque é chamado de {\em Man In The Middle} e nada do que vimos até aqui o previne. 90 | 91 | Não há como evitar este tipo de ataque sem algum encontro físico em que algum segredo seja compartilhado de maneira segura, mas os sistemas de assinatura digitais podem facilitar bastante esse processo. 92 | A ideia é confiar a alguma autoridade a identificação das chaves públicas. 93 | A autoridade $A$ teria então a responsabilidade de verificar se a entidade portadora da identidade $Id_B$ é de fato a o pessoa que possui a chave secreta correspondente à chave pública $pk_B$. 94 | Neste caso a autoridade $A$ pode emitir um {\em certificado} $cert_{A \to B}$ que nada mais é do que uma assinatura de $A$ conectando $Id_B$ a $pk_B$: 95 | \begin{displaymath} 96 | cert_{A \to B} := Sign(sk_A, Id_B || pk_B) 97 | \end{displaymath} 98 | 99 | Existem diversos modelos de {\em infraestrutura de chaves públicas} (PKI): 100 | \begin{itemize} 101 | \item {\em autoridade certificadora única:} Neste cenário assumimos que todos possuem a chave pública da autoridade certificadora $A$ que foi obtida de maneira segura. 102 | Sempre que algum novo ator $B$ precisar publicar sua chave pública ele deve se apresentar à essa autoridade e comprovar sua identidade para obter o certificado $cert_{A \to B}$ 103 | \item {\em múltiplas autoridades certificadoras:} Neste cenário existem várias autoridades certificadoras e assumimos que todos possuem chaves públicas de algumas ou todas elas. 104 | Quando um novo ator precisar publicar sua chave ele pode procurar uma ou mais autoridades para gerar o certificado que será válido para aqueles que confiarem na autoridade certificadora que o emitiu. 105 | Neste cenário a comunicação é tão segura quanto a menos confiável das autoridades incluídas na lista das partes. 106 | \item {\em delegação de autoridade:} Neste cenário as autoridades certificadoras não apenas podem certificar a autenticidade de uma chave pública como podem também produzir um certificado especial $cert^*$ que dá o poder a outro de produzir certificados. 107 | Assim digamos que $C$ consiga um certificado de $B$ sobra a autenticidade de sua chave $cert_{B \to C}$ e suponha que $B$ possui um certificado especial de $A$ que o autorize a produzir certificados em seu nome $cert^*_{A \to B}$. 108 | Assim alguém que possui a chave pública de $A$ pode verificar o certificado $cert^*_{A \to B}$ e usar a chave pública assinada de $B$ para verificar $cert_{B \to C}$. 109 | \item {\em rede de confiança:} Neste cenário, todas as partes atuam como autoridades certificadoras e podem assinar certificados para qualquer chave que elas verificaram. 110 | Cabe a cada um avaliar a confiança que tem em seus colegas quanto a edoniedade em produzir certificados. 111 | \end{itemize} 112 | 113 | Um certificado pode e deve conter uma {\em data de expiração} que limite seu tempo de validade. 114 | Depois dessa data o certificado não dever ser mais considerado válido e precisa ser renovado. 115 | Em alguns modelos o portador pode comprovar sua identidade com a autoridade que emitiu o certificado e esta pode assinar e publicar um {\em certificado de revogação} anunciando que a chave não deve mais ser considerada válida -- por exemplo no caso de ela ser perdida ou roubada. 116 | 117 | Veja o apêndice \ref{cha:dsa} para outros exemplos de assinatura digital e esquemas de identificação. 118 | 119 | \section{Exercícios} 120 | %\label{sec:exercicios} 121 | 122 | \begin{exercicio} 123 | Explique com suas palavras o que é uma autoridade certificadora e qual sua importância para garantir a segurança na comunicação. 124 | \end{exercicio} 125 | -------------------------------------------------------------------------------- /corpos-finitos.tex: -------------------------------------------------------------------------------- 1 | \chapter{Corpos Finitos} 2 | \label{cha:corpos-finitos} 3 | 4 | Um {\em corpo} é uma estrutura matemática formada por um conjunto $F$ e duas operações ($+$ e $\cdot$) tal que: 5 | \begin{itemize} 6 | \item Os elementos de $F$ formam um grupo\footnote{Ver capítulo \ref{cha:criptografia-assimetrica}} com a operação $+$ e o elemento neutro é o $0$. 7 | \item Os elementos de $F$, com exceção do $0$, formam um grupo com a operação $\cdot$ e o elemento neutro é o $1$. 8 | \item Para todo $a, b, c \in F$ temos que $a \cdot(b + c) = a \cdot b + a \cdot c$ (distributividade). 9 | \end{itemize} 10 | 11 | O conjunto dos números reais com as operações convencionais de soma e multiplicação é um corpo. 12 | 13 | Estamos interessados, porém, em corpos finitos, também conhecidos como {\em corpos de Galois}. 14 | Um teorema interessante, mas cuja demonstração foge ao escopo dessas notas, estabelece que a cardinalidade de um corpo finito é necessariamente uma potência de um primo. 15 | Em símbolos, se $\langle F, +, \cdot \rangle$ é um corpo então $|F| = p^m$ em que $p$ é um número primo e $m$ um inteiro. 16 | 17 | Vamos representar por $GF(p)$ o corpo definido pelo conjunto $\mathbb{Z}_p$ e as operações de soma e multiplicação modulo o número primo $p$. 18 | Não é difícil mostrar que $GF(p)$ é um corpo, a parte mais complicada é mostrar que todos os elementos diferentes de $0$ possuem inverso em relação a operação de multiplicação. 19 | Essa parte, porém, segue diretamente da Proposição \ref{prop:inverso} e pelo fato de que, com exceção do $0$, para qualquer elemento $a \in \mathbb{Z}_p$ temos que $mdc(a,p) = 1$ uma vez que $p$ é primo. 20 | 21 | \begin{example} 22 | Vamos considerar o corpo $GF(5)$. 23 | Neste corpo temos que: 24 | 25 | 26 | \begin{eqnarray*} 27 | 4 + 4 &=& 3\\ 28 | 2 + 3 &=& 0\\ 29 | -2 &=& 3\\ 30 | 3 \cdot 3 &=& 4\\ 31 | 2 \cdot 3 &=& 1\\ 32 | 2^{-1} &=& 3 33 | \end{eqnarray*} 34 | 35 | Com um valor pequeno assim, podemos pré-computar sem grandes problemas toda as tabelas de soma e multiplicação: 36 | 37 | \begin{table}[htbp] 38 | \centering 39 | \begin{tabular}{c|ccccc} 40 | + & 0 & 1 & 2 & 3 & 4\\ 41 | \hline 42 | 0 & 0 & 1 & 2 & 3 & 4\\ 43 | 1 & 1 & 2 & 3 & 4 & 0\\ 44 | 2 & 2 & 3 & 4 & 0 & 1\\ 45 | 3 & 3 & 4 & 0 & 1 & 2\\ 46 | 4 & 4 & 0 & 1 & 2 & 3\\ 47 | \end{tabular} 48 | \end{table} 49 | 50 | \begin{table}[htbp] 51 | \centering 52 | \begin{tabular}{c|ccccc} 53 | $\cdot$ & 0 & 1 & 2 & 3 & 4\\ 54 | \hline 55 | 0 & 0 & 0 & 0 & 0 & 0\\ 56 | 1 & 0 & 1 & 2 & 3 & 4\\ 57 | 2 & 0 & 2 & 4 & 1 & 3\\ 58 | 3 & 0 & 3 & 1 & 4 & 2\\ 59 | 4 & 0 & 4 & 3 & 2 & 1\\ 60 | \end{tabular} 61 | \end{table} 62 | 63 | \end{example} 64 | 65 | O corpo de ordem $p^m$ para $m>1$ será denominado $GF(p^m)$ e é formado pelo conjunto dos polinômios de de grau $m-1$ e cujos coeficientes são elementos em $\mathbb{Z}_p$. 66 | A soma de dois elementos em $GF(p^m)$ é dada pela soma dos polinômios. 67 | 68 | 69 | \begin{example} 70 | Considere o corpo $GF(2^4)$ e os elementos $x^3 + x + 1$ (que podemos representar como $1011$) e $x^2 + x$ (que podemos representar como $0110$). 71 | A soma desses elementos é: 72 | \begin{displaymath} 73 | \begin{array}{cccc} 74 | x^3 & & x & 1\\ 75 | & x^2 & x & \\ 76 | \hline 77 | x^3 & x^2 & & 1 78 | \end{array} 79 | \end{displaymath} 80 | \end{example} 81 | 82 | Um {\em elemento irredutível} em $GF{p^m}$ é um polinômio que não pode ser quebrado como a multiplicação de dois polinômios de grau estritamente menor\footnote{Pense como uma espécie de número primo no contexto dos polinômios.}. 83 | 84 | \begin{example} 85 | O polinômio $x^4 + x^3 + x + 1$ não é irredutível em $GF(2^4)$ pois: 86 | \begin{displaymath} 87 | x^4 + x^3 + x + 1 = (x^2 + x + 1)(x^2 + 1) 88 | \end{displaymath} 89 | 90 | Por outro lado o polinômio $x^4 + x + 1$ é irredutível. 91 | \end{example} 92 | 93 | Para multiplicar elementos em $GF(p^m)$ primeiro é preciso fixar um polinômio irredutível de grau $m$. 94 | A multiplicação em $GF(p^m)$ é dada então pela multiplicação dos dois polinômios módulo o polinômio irredutível fixado. 95 | 96 | 97 | \begin{example} 98 | Vamos fixar o polinômio irredutível $P(x) = x^4 + x + 1$ e vamos calcular a multiplicação entre $x^2 + x$ e $x^3 + x^2 + 1$. 99 | \begin{displaymath} 100 | (x^2 + x)(x^3 + x^2 + 1) = x^5 + x^3 + x^2 + x 101 | \end{displaymath} 102 | 103 | Note que o resultado da operação não é um elemento de $GF(2^4)$, por isso dividimos o resultado por $P(x)$ e ficamos com o resto. 104 | 105 | Para isso note que $x^4 = P(x) + x + 1$ e, portanto, $x^5 = xP(x) + x^2 + x$. 106 | Concluímos que $x^5 \equiv x^2 + x\ mod(P(x))$. 107 | Agora podemos reescrever o resultado da multiplicação como: 108 | \begin{eqnarray*} 109 | (x^2 + x)(x^3 + x^2 + 1) & \equiv & (x^2 + x) + x^3 + x^2 + x\ mod(P(x))\\ 110 | & \equiv & x^3 \ mod(P(x))\\ 111 | \end{eqnarray*} 112 | \end{example} 113 | 114 | Como vimos no Capítulo \label{sec:aes} a cifra de bloco padrão desde 2000, o AES, funciona em turnos que repetem as operações {\em AddRoundKey}, {\em SubBytes}, {\em ShiftRow} e {\em MixColumns}. 115 | A operação {\em SubBytes} é onde ocorre a fase de confusão. 116 | Seja $A_i$ um vetor de um byte (8 bits) que representa um dos 16 elementos do estado que alimenta o turno do algoritmo AES. 117 | A operação {\em SubBytes} tem duas etapas: 118 | \begin{enumerate} 119 | \item calcula $A_i^{-1}$, o inverso de $A_i$ em $GF(2^8)$ cujo polinômio irredutível é $x^8 + x^4 + x^3 + x + 1$ 120 | \item multiplica $A_i^{-1}$ por uma matriz e somado por uma constante ({\em afince mapping}) 121 | \end{enumerate} 122 | 123 | \begin{example} 124 | Seja $A_i = 11000010_2 = C2_{16}$ (usamos o subscrito para indicar a notação binária ou hexadecimal). 125 | Note que $A_i^{-1} = 00101111_2 = 2F_{16}$. 126 | Para verificar isso vamos multiplicar os dois: 127 | 128 | \begin{eqnarray*} 129 | (x^7 + x^6 + x)(x^5 + x^3 + x^2 + x + 1) & = & (x^{12} + x^{10} + x^9 + x^8 + x^7) + \\ 130 | & & (x^{11} + x^9 + x^8 + x^7 + x^6) + \\ 131 | & & (x^6 + x^4 + x^3 + x^2 + x)\\ 132 | & = & x^{12} + x^{11} + x^{10} + x^4 + x^3 + x^2 + x\\ 133 | & = & (x^8 + x^7 + x^5 + x^4) + \\ 134 | & & (x^7 + x^6 + x^4 + x^3) + \\ 135 | & & (x^6 + x^5 + x^3 + x^2) + \\ 136 | & & x^4 + x^3 + x^2 + x\\ 137 | & = & x^8 + x^4 + x^3 + x\\ 138 | & = & (x^4 + x^3 + x + 1) + x^4 + x^3 + x\\ 139 | & = & 1 140 | \end{eqnarray*} 141 | 142 | O resultado deve passar agora pela fase {\em affine mapping}: 143 | \begin{displaymath} 144 | \left(\begin{array}{cccccccc} 145 | 1 & 0 & 0 & 0 & 1 & 1 & 1 & 1 \\ 146 | 1 & 1 & 0 & 0 & 0 & 1 & 1 & 1 \\ 147 | 1 & 1 & 1 & 0 & 0 & 0 & 1 & 1 \\ 148 | 1 & 1 & 1 & 1 & 0 & 0 & 0 & 1 \\ 149 | 1 & 1 & 1 & 1 & 1 & 0 & 0 & 0 \\ 150 | 0 & 1 & 1 & 1 & 1 & 1 & 0 & 0 \\ 151 | 0 & 0 & 1 & 1 & 1 & 1 & 1 & 0 \\ 152 | 0 & 0 & 0 & 1 & 1 & 1 & 1 & 1 \\\end{array} \right) 153 | \left( \begin{array}{c} 154 | 0\\ 0\\ 1\\ 0\\ 1\\ 1\\ 1\\ 1\\\end{array} \right) 155 | + 156 | \left( \begin{array}{c} 157 | 1\\ 1\\ 0\\ 0\\ 0\\ 1\\ 1\\ 0\\\end{array} \right) 158 | = 159 | \left( \begin{array}{c} 160 | 0\\ 0\\ 1\\ 0\\ 0\\ 1\\ 0\\ 1\\\end{array} \right) 161 | \end{displaymath} 162 | 163 | Na prática, porém, é possível e mais simples computar os resultados de SubBytes em uma tabela (Figura \ref{fig:subbyte}). 164 | No caso a entrada é $C2_{16}$ e a saída $25_{16}$ exatamente conforme computamos. 165 | \end{example} 166 | 167 | 168 | \begin{figure}[!htp] 169 | \centering 170 | \includegraphics[width=\textwidth]{imagens/aes-subbyte.jpg} 171 | \caption{Tabela SubByte precomputada.} 172 | \label{fig:subbyte} 173 | \end{figure} 174 | 175 | Na fase de descriptografia do AES outra matriz e outra constante são aplicadas e em seguida é calculado o inverso em GF($2^8$) de forma a reverter o processo. 176 | 177 | Na fase {\em MixColumn} são selecionados quatro bytes que são dispostos em um vetor para ser multiplicado por uma matriz, cada passo da multiplicação é calculado em $GF(2^8)$. 178 | 179 | 180 | \begin{example} 181 | Considere que os bytes $B_0, B_5, B_{10}$ e $B_{15}$ foram selecionados. 182 | Fazemos a seguinte conta: 183 | 184 | \begin{displaymath} 185 | \left(\begin{array}{cccc} 186 | 02_{16} & 03_{16} & 01_{16} & 01_{16} \\ 187 | 01_{16} & 02_{16} & 03_{16} & 01_{16} \\ 188 | 01_{16} & 01_{16} & 02_{16} & 03_{16} \\ 189 | 03_{16} & 01_{16} & 01_{16} & 02_{16} \\ 190 | \end{array} \right) 191 | \left( \begin{array}{c} 192 | B_0\\ B_5\\ B_{10}\\ B_{15}\\\end{array} \right) 193 | = 194 | \left( \begin{array}{c} 195 | C_0\\ C_1\\ C_2\\ C_3\\\end{array} \right) 196 | \end{displaymath} 197 | 198 | Para facilitar as contas suponha que todos os bytes selecionados ($B_0, B_5, B_{10}$ e $B_{15}$)são $25_{16}$. 199 | Neste caso precisamos calcular $02_{16} \cdot 25_{16}$ e $03 \cdot 25_{16}$: 200 | 201 | 202 | \begin{eqnarray*} 203 | 02_{16} \cdot 25_{16} & = & x(x^5 + x^2 + 1)\\ 204 | & = & x^6 + x^3 + x\\ 205 | 03_{16} \cdot 25_{16} & = & (x + 1)(x^5 + x^2 + 1)\\ 206 | & = & x^6 + x^5 + x^3 + x^2 + x + 1\\ 207 | \end{eqnarray*} 208 | 209 | Neste caso, como todos $B_i$ são iguais, todos os $C_i$ também o são e são calculados da seguinte forma: 210 | 211 | \begin{displaymath} 212 | \begin{array}{cccccccccc} 213 | 01_{16} \cdot 25_{16} & = & & x^5 + & & & x^2 + & & 1\\ 214 | 01_{16} \cdot 25_{16} & = & & x^5 + & & & x^2 + & & 1\\ 215 | 02_{16} \cdot 25_{16} & = & x^6 + & & & x^3 + & & x & \\ 216 | 03_{16} \cdot 25_{16} & = & x^6 + & x^5 + & & x^3 + & x^2 + & x + & 1\\ 217 | \hline 218 | C_i & = & & x^5 + & & & x^2 + & & 1\\ 219 | \end{array} 220 | \end{displaymath} 221 | \end{example} 222 | 223 | No processo de descriptografia uma outra matriz é usada para calcular o {\em MixCloumn}, uma que reverte o que foi calculado neste passo. -------------------------------------------------------------------------------- /owf.tex: -------------------------------------------------------------------------------- 1 | \chapter{Funções de Mão Única} 2 | \label{cha:owf} 3 | 4 | Nos Capítulos \ref{cha:cifras-de-fluxo}, \ref{cha:cifras-de-bloco} e \ref{cha:mac} demonstramos que dadas certas suposições determinados sistemas de criptografia garantem a segurança contra determinados modelos de ataque. 5 | Argumentamos que essas supoções -- a saber, a existência de geradores de números pseudoaleatórios, de funções pseudoaleatórias e de permutações pseudoaleatórias -- não são provadas, mas validadas empiricamente. 6 | Neste capítulo argumentaremos porque não construimos sistemas que comprovadamente satisfazem essas suposições. 7 | Para tanto apresentaremos uma condição necessária e suficiente para a existência de sistemas seguros: a existência de funções de mão única. 8 | Por fim mostraremos que uma demonstração da existência de funções de mão única implicam que $P \neq NP$, ou seja, esse resultado teria como consequência um dos problemas em aberto mais relevantes na matemática hoje. 9 | 10 | Uma {\em função de mão única} é uma função $f: \{0,1\}^n \to \{0,1\}^n$ que pode ser computada de maneira eficiente, mas que é inviável de ser invertida. 11 | Ou seja, para todo adversário eficiente $\mathcal{A}$ que recebe $y := f(x)$ só consegue encontrar $x'$ tal que $f(x') = y$ com probabilidade desprezível \cite{Diffie76,Yao82}. 12 | 13 | Formalmente definimos função de mão única por meio do seguinte jogo: 14 | \begin{enumerate} 15 | \item O sistema escolhe $x \leftarrow \{0,1\}^n$ e computa $y := f(x)$. 16 | \item O adversário $\mathcal{A}$ recebe $1^n$ e $y$. 17 | \item $\mathcal{A}$ devolve $x' \in \{0,1\}^n$. 18 | \end{enumerate} 19 | 20 | O desafio do adversário é produzir uma pré-imagem de $f$, ou seja, um $x'$ tal que $f(x') = y$: 21 | 22 | \begin{displaymath} 23 | Inv_{\mathcal{A}, f}(n) := \left\{ 24 | \begin{array}{lcl} 25 | 1 & \textrm{se} & f(x') = y\\ 26 | 0 & \textrm{c.c.} &\\ 27 | \end{array} 28 | \right. 29 | \end{displaymath} 30 | 31 | Uma função $f: \{0,1\}^n \to \{0,1\}^n$ é de mão única se: 32 | \begin{enumerate} 33 | \item $f$ pode ser computada de maneira eficiente (polinomial) e 34 | \item Para todo adversário eficiente $\mathcal{A}$ existe $\varepsilon$ desprezível tal que: 35 | \begin{displaymath} 36 | Pr[Inv_{\mathcal{A}, f}(n) = 1] \leq \varepsilon(n) 37 | \end{displaymath} 38 | \end{enumerate} 39 | 40 | 41 | \begin{example} 42 | Uma candidata a função de mão é única é a seguinte função para $x$ e $y$ de mesmo tamanho e primos: 43 | \begin{displaymath} 44 | f(x,y) := x \cdot y 45 | \end{displaymath} 46 | A dificuldade de inverter $f$ está a associada ao {\em problema da fatoração} que é considerado um problema difícil. 47 | 48 | Veremos no Capítulo \ref{cha:distribuicao-chaves} que para certos grupos $G$ com gerador $g$ temos que a seguinte função $f$ é de mão única: 49 | \begin{displaymath} 50 | f_g(x) := g^x 51 | \end{displaymath} 52 | 53 | A dificuldade de inverter esta função está associada ao chamado {\em problema do logarítmo discreto}. 54 | \end{example} 55 | 56 | 57 | Note que para derrotar o desafio de uma função de mão única $\mathcal{A}$ precisa calcular a pré-imagem $x'$, não basta conhecer alguma informação parcial sobre $x'$. 58 | Um {\em predicado hard-core} é um bit de informação sobre a $x'$ que é mantido escondido pela função de mão única $f$ \cite{Blum84}. 59 | Formalmente, um predicado hard core é uma função $hc:\{0,1\}^n \to \{0,1\}$ se qualquer adversário eficiente que conhece $y := f(x)$ consegue acertar o valor de $hc(x)$ apenas com change desprezivelmente maior do que $\frac{1}{2}$. 60 | 61 | 62 | Seja $f:\{0,1\}^n \to \{0,1\}^n$ uma função de mão única. 63 | Considere a função $g(x,r) := \langle f(x), r \rangle$ em que $|x| = |r|$ e defina $hc(x,r) := \bigoplus_{i=1}^nx_i \cdot r_i$. 64 | É possível mostrar que $g$ é uma função de mão única e $hc$ é um predicado hard-core de $g$ \cite{Goldreich89}. 65 | Esta construção é a base do seguinte teorema\footnote{Neste capítulo seguiremos essa abordagem de apresentar as construções e omitir as demonstrações. O leitor interessado deve procurar o livro do Goldreich \cite{Goldreich07} para uma apresentação completa sobre os temas tratados neste capítulo.}: 66 | 67 | \begin{theorem}[Goldreich-Levin] 68 | Assuma que uma função de mão única existe. Então existe uma função de mão única com um predicado hard-core. 69 | \end{theorem} 70 | 71 | Uma vez extraído um bit ``seguro'' a partir de uma função de mão única, podemos usá-lo na construção de um PRG com fator de expanção $l(n) = n + 1$. 72 | 73 | \begin{theorem} 74 | Seja $f$ uma função de mão única com um predicado hard-crore $hc$. 75 | A função $G(s) := f(s)||hc(s)$ é um PRG com fator de expansão $l(n) = n+1$. 76 | \end{theorem} 77 | 78 | Agora que somos capazes de gerar um PRG com fator de expansão mínimo, é possível expandi-lo para um PRG com fator de expansão $l(n) = p(n)$ em que $p$ é um polinomio qualquer. 79 | Seja $G$ um PRG com fator de expansão mínimo, construimos $G'$ da seguinte maneira. 80 | Usamos $G$ para gerar $l(n)+1$ bits, o último bit é usado como primeiro bit da sáida de $G'$ e os demais são usados como uma nova semente para $G$ e repetimos o processo quantas vezes forem nescessárias. 81 | Esta construção é a base do seguinte teorema: 82 | 83 | 84 | \begin{theorem} 85 | Se existe PRG com fator de expansão $l(n) = n + 1$ então para todo polinômio $p$ existe PRG $G'$ com fator de expansão $l(n) = p(n)$. 86 | \end{theorem} 87 | 88 | \begin{figure}[htbp] 89 | \centering 90 | \includegraphics[width=.5\textwidth]{imagens/OWF-PRG.png} 91 | \caption{Diagrama da construção de $G'$} 92 | \label{fig:owf-prg} 93 | \end{figure} 94 | % Este diagrama está ruim!! 95 | 96 | É possível construir uma função pseudoaleatória a partir de um PRG com fator de expansão $2n$. 97 | Seja $G(k) = y_0 \dots y_{2n}$ um PRG e defina $G_0(k) := y_0 \dots y_n$ e $G_1(k) := y_{n+1} \dots y_{2n}$. 98 | Construiremos uma PRF $f_k: \{0,1\}^n \to \{0,1\}^n$ da seguinte maneira: 99 | \begin{displaymath} 100 | f_k(x_1 \dots x_n) := G_{x_n}(\dots (G_{x_1}(k))\dots) 101 | \end{displaymath} 102 | 103 | \begin{theorem}[Yao] 104 | Se $G$ é um PRG com fator de expansão $l(n) = 2n$ então a construção acima é um PRF. 105 | \end{theorem} 106 | 107 | \begin{figure}[htbp] 108 | \centering 109 | \includegraphics[width=.7\textwidth]{imagens/PRG-PRF.png} 110 | \caption{Construção de Yao} 111 | \label{fig:owf-prg} 112 | \end{figure} 113 | 114 | Para completar, a partir de uma PRF é possível construir uma PRP usando uma rede de Feistel com três passos em que cada passo usa uma chave distinta. 115 | \begin{displaymath} 116 | f_{k_1,k_2,k_3}^{(3)}(x) := Feistel_{f_{k_1},f_{k_2},f_{k_3}}(x) 117 | \end{displaymath} 118 | Lembrando que: 119 | 120 | \begin{eqnarray*} 121 | Feistel_{f_1,\dots,f_n}(x) & := & L_nR_n\\ 122 | L_i & := & R_{i-1}\\ 123 | R_i & := & L_{i-1} \xor f_i(R_{i-1}) 124 | \end{eqnarray*} 125 | 126 | 127 | \begin{theorem} 128 | Se $f$ é uma PRF então $f^{(3)}$ é uma permutação pseudoaleatória. 129 | \end{theorem} 130 | 131 | % DIAGRAMA DA CONSTRUÇÃO DE F3 132 | 133 | Resumindo, a existência de uma função de mão única é uma condição suficiente para a existência de PRG, PRF e PRP. 134 | No Capítulos \ref{cha:cifras-de-fluxo} vimos que a existência de um PRG é condição suficiente para construir um sistema seguro contra ataques {\em ciphertext only} e nos Capítulos \ref{cha:cifras-de-bloco} e \ref{cha:mac} vimos que a existência de uma PRF é condição suficiente para construção de sistemas de criptografia seguros contra CPA e contra CCA, bem como para construção de sistemas autenticados. 135 | 136 | O teorema a seguir mostra a condição reversa, ou seja, que a existência de função de mão única é condição necessária para existência de todas essas construções: 137 | 138 | 139 | \begin{theorem} 140 | Se existe um sistema seguro contra ataques {\em ciphertext only} que protega uma mensagem duas vezes maior do que sua chave então existe uma função de mão única. 141 | \end{theorem} 142 | 143 | \begin{proof} 144 | Seja $\Pi = \langle Gen, E, D \rangle$ um sistema de criptografia seguro contra ataques ``ciphertext only''. 145 | Seja $|k| = n$, $|m| = 2n$ e $r$ os bits aleatórios usados em $E$ (nos casos que vimos seria o IV) com $|r| = l(n)$ onde $l$ é um polinômio qualquer. 146 | Construímos uma função da seguinte forma: 147 | \begin{displaymath} 148 | f(k, m, r) := E(k, m||r)||m 149 | \end{displaymath} 150 | 151 | Vamos mostrar que $f$ é uma função de mão única. 152 | Seja $\mathcal{A}$ um adversário para o problema de inverter $f$. 153 | Vamos construir $\mathcal{A}'$ um adversário para $\Pi$ da seguinte forma: 154 | \begin{enumerate} 155 | \item Escolhe $m_0, m_1 \leftarrow \{0,1\}^{2n}$ e devolve $c$ 156 | \item Roda $\mathcal{A}(c||m_0)$ para obter $k'$, $m'$ e $r'$. 157 | Se $f(k', m', r') = c ||m_0$ devolve $0$, se não devolve $1$. 158 | \end{enumerate} 159 | 160 | Note que se $E(k,m_0) = c$ então $c||m_0$ tem distribuição identica a $f(k, m_0, r)$. 161 | Portanto, temos que $\mathcal{A}'$ perde o jogo com probabilidade $Pr[Inv_{\mathcal{A}, f}(n) = 1]$. 162 | Por outro lado se $E(k, m_1) = c$ então $c$ é independente de $m_0$ e portanto a probabilidade de $D(k, c) = m_0 $ é $\frac{2^n}{2^{2n}} = 2^{-n}$. 163 | Temos então o seguinte: 164 | 165 | 166 | \begin{eqnarray*} 167 | Pr[PrivK_{\Pi, \mathcal{A}'}^{eav}(n) = 1] & = & \frac{Pr[\mathcal{A}' = 0 | b = 0]}{2} + \frac{Pr[\mathcal{A}' = 1 | b = 1]}{2}\\ 168 | & \geq & \frac{Pr[Inv_{\mathcal{A},f}(n) = 1]}{2} + \frac{1 - 2^{-n}}{2}\\ 169 | & = & \frac{1}{2} + \frac{Pr[Inv_{\mathcal{A},f}(n) = 1] - 2^{-n}}{2} 170 | \end{eqnarray*} 171 | 172 | Nossa suposição de que $\Pi$ é seguro contra ataques do tipo ``chosen plaintext'' implica que existe $\varepsilon$ desprezível tal que $Pr[PrivK_{\Pi, \mathcal{A}'}^{eav}(n) = 1] \leq \frac{1}{2} + \varepsilon(n)$ e portanto: 173 | 174 | \begin{eqnarray*} 175 | \frac{1}{2} + \frac{Pr[Inv_{\mathcal{A},f}(n) = 1] - 2^{-n}}{2} & \leq & \frac{1}{2} + \varepsilon(n)\\ 176 | \frac{Pr[Inv_{\mathcal{A},f}(n) = 1] - 2^{-n}}{2} & \leq & \varepsilon(n)\\ 177 | Pr[Inv_{\mathcal{A},f}(n) = 1] & \leq & 2\varepsilon(n) + 2^{-n}\\ 178 | \end{eqnarray*} 179 | 180 | Como $2\varepsilon(n) + 2^{-n}$ é desprezível, concluímos que $f$ é uma função de mão única. 181 | 182 | \end{proof} 183 | 184 | \begin{figure}[htbp] 185 | \centering 186 | \includegraphics[width=.7\textwidth]{imagens/OWF-diagrama.png} 187 | \caption{Cadeia de consequências da existência de funções de mão única} 188 | \label{fig:owf-seguranca} 189 | \end{figure} 190 | 191 | Acreditamos que certas função são de mão única, hipótese esta que é validada empiricamente. 192 | Porém, não temos uma demonstração matemática desta afirmação. 193 | Suponha que conseguissemos mostrar que $f$ é uma função de mão única. 194 | Por definição temos que $f(x)$ deve ser computável em tempo polinomial. 195 | Se sabemos que $f^{-1}(x) = y$ então podemos verificar isso em tempo polinomial testando se $f(y) = x$. 196 | Em outras palavras, $f$ é um oráculo polinomial para $f^{-1}$, ou seja, $Inv_f(n) \in NP$. 197 | A definiçao de função de mão única estabelece que $Inv_f(n) \notin P$. 198 | Portanto, se existe uma função de mão única temos que $P \neq NP$. 199 | A relação entre os problemas polinomais $P$ e os problemas para os quais existe um oráculo polinomial $NP$ é o problema em aberto mais importante na ciência da computação e um dos mais importantes em aberto na matemática. 200 | 201 | %\section{Exercícios} 202 | %\label{sec:exercicios} 203 | 204 | %\begin{exercicio} 205 | % Mostre que $f(x,y) = x \cdot y$ sem as restrições de que $x$ e $y$ sejam primos e do mesmo tamanho não é uma função de mão única. 206 | %\end{exercicio} 207 | 208 | 209 | %\begin{exercicio} 210 | % Mostre um grupo cíclico com gerador $g$ (ver Capítulo \ref{cha:distribuicao-chaves}) em que $f_g(x) = g^x$ não é uma função de mão única. 211 | %\end{exercicio} 212 | -------------------------------------------------------------------------------- /sigilo-perfeito.tex: -------------------------------------------------------------------------------- 1 | \chapter{Sigilo Perfeito} 2 | \label{cha:sigilo-perfeito} 3 | 4 | No final dos anos 40, com o desenvolvimento dos primeiros computadores e a experiência da quebra das cifras mecanicamente produzidas por poderosas máquinas desenvolvidas pelo esforço de guerra do nazismo, alguns cientístas se voltaram para um problema central no campo da criptografia: o que torna um sistema de criptografia seguro? 5 | As cifras que vimos até agora são conhecidas como ``cifras clássicas'' exatamente porque elas precedem desse debate moderno, e não a toa foram todas derrotadas cedo ou tarde. 6 | Informalmente, poderíamos dizer que o problema dos esquemas clássicos de criptografia é que eles guardam muita informação sobre a mensagem (frequência das letras, dos dígrafos, letras duplas etc.). 7 | Não é uma coincidência, portanto, que a primeira tentativa de formalizar o conceito de segurança tenha sido proposto por Claude Shannon, o fundador da teoria da informação. 8 | Shannon definiu o que hoje chamamos de {\em sigilo perfeito}. 9 | Um esquema de criptografia garante o sigilo perfeito se a cifra não guarda nenhuma informação sobre a mensagem que a gerou. 10 | Ou, de maneira um pouco mais descritiva, se a probabilidade da cifra ocorrer é independente da probabilidade da mensagem: 11 | 12 | \begin{definition} 13 | Um esquema de criptografia simétrica $\Pi = \langle Gen, E, D \rangle$ garante o {\em sigilo perfeito} se, supondo que $Pr[C=c] > 0$, para toda distribuição de probabilidade sobre $M$ temos que: 14 | \begin{displaymath} 15 | Pr[M = m | C = c] = Pr[M = m] 16 | \end{displaymath} 17 | 18 | Ou de maneira equivalente se para todo $m_0, m_1 \in M$ e todo $c \in C$ temos que: 19 | \begin{displaymath} 20 | Pr[C = c | M = m_0] = Pr[C = c | M = m_1] 21 | \end{displaymath} 22 | \end{definition} 23 | 24 | Essa segunda formulação é mais intuitiva, ela estabelece que um sistema garante o sigilo perfeito se a probabilidade de $m_0$ produzir a cifra $c$ é idêntica a probabilidade de qualquer outra mensagem $m_1$ produzir a mesma cifra $c$. 25 | O exemplo a seguir mostra que a cifra de substituição não garante o sigilo perfeito: 26 | 27 | \begin{example} 28 | Seja $\Pi = \langle Gen, E, D \rangle$ o sistema de criptografia de substituição e sejam $c = \textrm{\tt ANA}$, $m_0 = \textrm{\tt OVO}$ e $m_1 = \textrm{\tt EVA}$. 29 | Como o sistema $\Pi$ substitui cada letra da mensagem por uma letra na cifra, existem chaves $k$ tal que $E(k, m_0) = c$ -- basta que $k(\textrm{\tt O}) = \textrm{\tt A}$ e $k(\textrm{\tt V}) = \textrm{\tt N}$, de fato a chance de escolher uma chave assim é $\frac{1}{26 \cdot 25} = \frac{1}{650}$ --, mas não existe nenhuma chave $k'$ tal que $E(k', m_1) = c$. 30 | Portanto temos que: 31 | \begin{displaymath} 32 | Pr[C = c | M = m_0] = \frac{1}{650} \neq Pr[C = c | M = m_1] = 0 33 | \end{displaymath} 34 | \end{example} 35 | 36 | Uma forma equivalente, e útil como veremos mais para frente, de definir sigilo perfeito é a partir de um jogo. 37 | Imaginamos que há um adversário $\mathcal{A}$ cujo objetivo é quebrar a cifra produzida pelo sistema $\Pi$. 38 | O jogo funciona da seguinte maneira: 39 | \begin{enumerate} 40 | \item $\mathcal{A}$ escolhe duas mensagens $m_0$ e $m_1$ com o mesmo tamanho ($|m_0| = |m_1|$) e envia para o sistema $\Pi$. 41 | \item O sistema gera uma chave $k$ usando o algoritmo $Gen$ e sorteia aleatoriamente uma das mensagens para criptografar ($\Pi$ sorteia $b \leftarrow \{0, 1\}$ e criptografa $m_b$). 42 | \item A cifra produzida $E(k, m_b) = c$ é enviada de volta para o adversário. 43 | \item O adversário $\mathcal{A}$ produz um bit $b' \in \{0,1\}$. 44 | \end{enumerate} 45 | 46 | O desafio do adversário é acertar qual das duas mensagens foi cifrada. 47 | O diagrama abaixo ilustra o processo: 48 | 49 | \begin{center} 50 | \begin{tikzpicture}[node distance=2cm,auto,>=latex] 51 | \tikzset{ 52 | player/.style={draw,shape=rectangle,rounded corners,minimum width=4em,minimum height=6em} 53 | } 54 | \node[player] (system) {$\Pi$}; 55 | \node[player] (adversary) at (10,0) {$\mathcal{A}$}; 56 | \draw[->] (9,.5) -> node[above]{$m_0, m_1 \in M : |m_0| = |m_1|$} (1,.5); 57 | \draw[->] (1,-.5) -> node[above]{$E(k,m_b) = c$} (9,-.5); 58 | \draw[->] (0,2) -> node{$b \leftarrow \{0,1\}$} (system); 59 | \draw[->] (adversary) -> node{$b' \in \{0,1\}$} (10,-2); 60 | \end{tikzpicture} 61 | \end{center} 62 | 63 | Chamamos o experimento ilustrado pelo diagrama de $PrivK^{eav}_{\Pi, \mathcal{A}}$. 64 | Os subscritos indicam que o experimento depende do sistema $\Pi$ e do adversário $\mathcal{A}$. 65 | O resultado do experimento deve ser $0$ se o adversário perdeu o desafio e $1$ caso contrário. 66 | Formalmente temos que: 67 | \begin{displaymath} 68 | PrivK^{eav}_{\Pi, \mathcal{A}} = \left\{ 69 | \begin{array}{lcl} 70 | 1 & \textrm{se} & b = b'\\ 71 | 0 & \textrm{c.c.} &\\ 72 | \end{array} 73 | \right. 74 | \end{displaymath} 75 | 76 | É possível provar que um sistema $\Pi$ garante o {\em sigilo perfeito} se e somente se para qualquer adversário $\mathcal{A}$ temos que: 77 | \begin{displaymath} 78 | Pr[PrivK^{eav}_{\Pi, \mathcal{A}} = 1] = \frac{1}{2} 79 | \end{displaymath} 80 | 81 | Em palavras, o sistema possui sigilo perfeito se nenhum adversário é capaz de acertar qual das mensagens produziu a cifra $c$ com probabilidade melhor do que um meio. 82 | 83 | \section{One Time Pad} 84 | \label{sec:otp} 85 | 86 | Temos agora uma definição formal de segurança. 87 | Vimos que a cifra de substituição não satisfaz essa definição, mas na verdade nenhuma das cifras clássicas a satisfaz. 88 | Não seria desejável que essas cifras satisfizessem a definição, pois vimos no capítulo anterior que nenhuma das cifras clássicas é segura e todas podem ser derrotadas se o adversário tiver acesso a uma cifra de tamanho suficientemente grande. 89 | Ficamos então com o desafio de encontrar algum sistema que satisfaça essa definição, caso tal sistema exista. 90 | 91 | No que segue, apresentaremos um sistema chamado {\em One Time Pad} (OTP), também conhecido como {\em cifra de Vernan}, e mostraremos que ele garante o sigilo perfeito. 92 | A partir deste ponto, conforme começarmos a investigar sistemas a serem implementados computacionalmente, consideraremos que o espaço $M$ das mensagens (assim como o espaço $C$ das cifras) será representado como sequências de bits. 93 | No caso específico do OTP assumiremos que as mensagens e a cifras possuem um tamanho fixo $n$. 94 | Mais importante é o fato de que o universo das chaves é também um conjunto de sequências de bits do mesmo tamanho. 95 | Assim temos que $M = C = K = \{0,1\}^n$. 96 | O sistema $\Pi = \langle Gen, E, D \rangle$ é definido pelos seguintes algoritmos: 97 | \begin{itemize} 98 | \item $Gen := k \leftarrow \{0,1\}^n$ 99 | \item $E(k,m) = [m_0 + k_0\ mod\ 2] \dots [m_n + k_n\ mod\ 2] = m \xor k$ 100 | \item $D(k,c) = [c_0 + k_0\ mod\ 2] \dots [c_n + k_n\ mod\ 2] = c \xor k$ 101 | \end{itemize} 102 | 103 | Para verificar a corretude do sistema basta notar que: 104 | 105 | \begin{eqnarray*} 106 | D(k, E(k, m)) & = & D(k, k \xor m)\\ 107 | & = & k \xor (k \xor m)\\ 108 | & = & (k \xor k) \xor m\\ 109 | & = & m 110 | \end{eqnarray*} 111 | 112 | A derivação usa o fato de que a operação de {\em ou exclusivo} $\xor$ é associativa, que $x \xor x = 1$ e $1 \xor x = x$ para todo sequência de bits $x \in \{0,1\}^*$. 113 | Deixamos como exercício mostrar essas três propriedades da operação. 114 | 115 | \begin{example} 116 | Considere uma mensagem $m = 101010$ e uma chave $k = 010001$. 117 | Usando o sistema One Time Pad a cifra produzida é a seguite: 118 | 119 | \begin{displaymath} 120 | \begin{array}{ccccc} 121 | m & \xor & k & = & c \\ 122 | 101010 & \xor & 010001 & = & 111011 123 | \end{array} 124 | \end{displaymath} 125 | \end{example} 126 | 127 | Como antecipado, é possível, e relativamente simples provar que o OTP possui sigilo perfeito. 128 | 129 | \begin{theorem} 130 | O sistema de criptografia {\em One Time Pad} possui sigilo perfeito. 131 | \end{theorem} 132 | 133 | \begin{proof} 134 | Seja $K = M = C = \{0,1\}^n$. 135 | Dada uma cifra $c \in C$ e uma mensagem qualquer $m \in M$, existe uma única chave $k \in K$ tal que $E(k,m) = c$. 136 | A chave é exatamente $k = m \xor c$, pois: 137 | 138 | \begin{eqnarray*} 139 | E(k, m) & = & k \xor m \\ 140 | & = & (m \xor c) \xor m\\ 141 | & = & (m \xor m) \xor c\\ 142 | & = & c 143 | \end{eqnarray*} 144 | 145 | Como existe exatamente uma chave possível que faz com que $E(k,m) = c$, temos que a probabilidade de se produzir $c$ dado uma mensagem qualquer $m$ é igual a probabilidade de sortear uma chave específica no universo $K = \{0,1\}^n$ que é $\frac{1}{2^n}$: 146 | \begin{displaymath} 147 | Pr[C = c | M = c] = \frac{1}{2^n} 148 | \end{displaymath} 149 | 150 | Essa probabilidade é idêntica para qualquer $m \in M$. 151 | Portanto, temos que $Pr[C = c| M = m_0] = Pr[C = c | M = m_1] = \frac{1}{2^n}$. 152 | \end{proof} 153 | 154 | O {\em One Time Pad} possui duas severas limitações. 155 | A primeira é indicada pelo próprio nome do sistema. 156 | O sistema supõe que a chave de criptografia $k$ seja usada exatamente uma vez (``one time''). 157 | Caso a mesma chave $k$ seja usada para criptografar duas mensagens distintas $m_1$ e $m_2$, o sistema se torna completamente inseguro. 158 | 159 | Para ilustrar essa limitação considere que duas cifras $c_0$ e $c_1$ foram produzidas usando a mesma chave $k$. 160 | Assim temos que $c_0 = k \xor m_0$ e $c_1 = k \xor m_1$. 161 | Note o que acontece quando aplicamos o ou exclusivo entre as duas cifras eliminamos a chave: 162 | 163 | 164 | \begin{eqnarray*} 165 | c_0 \xor c_1 & = & (k \xor m_0) \xor (k \xor m_1)\\ 166 | & = & (k \xor k) \xor (m_0 \xor m_1)\\ 167 | & = & m_0 \xor m_1 168 | \end{eqnarray*} 169 | 170 | Uma vez eliminada a chave, é fácil separar as mensagens $m_0$ de $m_1$ utilizando uma técnica similar ao ataque de frequência. 171 | 172 | A segunda e mais crítica limitação do OTP é o tamanho de sua chave. 173 | A suposição que fizemos é que o tamanho da chave deve ser tão grande quanto a mensagem a ser cifrada. 174 | Há uma série de problemas práticos com isso. 175 | Computacionalmente não é possível gerar chaves aleatórias muito grandes, o que limita o tamanho das mensagens que podemos cifrar. 176 | Além disso, assumimos que as chaves são compartilhadas entre as partes. 177 | Deixamos os detalhes sobre a distribuição de chaves para o Capítulo \ref{cha:distribuicao-chaves}, mas por ora podemos adiantar que se nossa chave é tão grande quanto a mensagem, porque não enviamos a mensagem pelo mesmo canal que enviaríamos a chave? 178 | Enfim, um sistema cuja a chave seja tão grande quanto a mensagem é de muito pouca utilidade prática. 179 | 180 | Encerramos este capítulo mostrando que esta segunda limitação do OTP infelizmente não é uma peculiaridade do sistema. 181 | Na verdade todo sistema que possua sigilo perfeito está fadado a ter chaves tão grandes ou maiores do que a mensagem. 182 | Esse resultado negativo foi proposto e demonstrado pelo próprio Shannon ainda nos anos 40. 183 | 184 | 185 | \begin{theorem}[Shannon] 186 | Seja $\Pi = \langle Gen, E, D \rangle$ um sistema que garante o sigilo perfeito, então temos que $|K| \geq |M|$. 187 | \end{theorem} 188 | \begin{proof} 189 | Consideraremos $M(c)$ como o conjuto de todas as mensagens que podem produzir $c$, ou seja, as mensagens $m \in M$ tal que $E(k, m) = c$ para algum $k \in K$. 190 | Se existissem $m' \neq m''$ tais que $E(k, m') = E(k, m'') = c$ então $\Pi$ não poderia ser correto, pois $D(k, c)$ não poder ser $m'$ e $m''$ ao mesmo tempo. 191 | Portanto o número de mensagens que podem ser cifradas como $c$ é menor ou igual ao número de chaves, ou em símbolos, $|M(c)| \leq |K|$. 192 | Agora suponha por absurdo que $|K| < |M|$. 193 | Neste caso existiria uma mensagem $m \notin M(c)$ e, portanto, $Pr[M = m] \neq 0$. 194 | Mas, por definição, temos que $Pr[C = c | M = m] = 0$ contradizendo a hipótese deu que $\Pi$ garante o sigilo perfeito. 195 | \end{proof} 196 | 197 | A definição de Shannon foi a primeira tentativa séria de definir segurança de sistemas de criptografia, mas o próprio autor da definição foi capaz de demonstrar suas limitações. 198 | Nos próximos capítulos apresentaremos definições de segurança mais fracas e mais úteis para nossos propósitos. 199 | 200 | \section{Exercício} 201 | \label{sec:exercicio} 202 | 203 | \begin{exercicio} 204 | Mostre que o $0$ é elementro neutro na operação $\xor$, ou seja, que para todo $x \in \{0,1\}^*$ temos que $x \xor 0 = 0 \xor x = x$. 205 | \end{exercicio} 206 | 207 | \begin{exercicio} 208 | Mostre que a operação $\xor$ é {\em associativa}, ou seja, que para todo $x,y,z \in \{0,1\}^*$ temos que $x \xor (y \xor z) = (x \xor y) \xor z$. 209 | \end{exercicio} 210 | 211 | \begin{exercicio} 212 | Mostre que a operação $\xor$ é {\em comutativa}, ou seja, que para todo $x,y \in \{0,1\}^*$ temos que $x \xor y = y \xor x$. 213 | \end{exercicio} 214 | 215 | \begin{exercicio} 216 | Mostre que para qualquer sequência de bits $x \in \{0,1\}^*$ temos que $x \xor x = 0$. 217 | \end{exercicio} 218 | 219 | \begin{exercicio} 220 | Mostre que a cifra de deslocamento não garante sigilo perfeito. 221 | \end{exercicio} 222 | 223 | -------------------------------------------------------------------------------- /intro.tex: -------------------------------------------------------------------------------- 1 | \chapter{Introdução} 2 | 3 | \section{Privacidade} 4 | \label{sec:privacidade} 5 | 6 | As primeiras tentativas de conceitualizar a privacidade datam do final do século XIX. 7 | Em um famoso artigo de 1890, os colegas da faculdade de direito de Boston, Louis Brandeis e Samuel Warren denunciam que o advento da fotografia instantânea e o jornalismo haviam ``invadido o recinto sagrado da vida privada'' ferindo o que eles apontam como o direito individual de ``ser deixado em paz''. 8 | Assim, eles argumentam que o escopo do direito comum ({\em Common Law}), que originalmente se concentrava apenas na proteção contra agressões e já havia sido ampliado para incluir a proteção à propriedade deveria ser novamente alargado para finalmente reconhecer a ``natureza espiritual do homem'' \cite{Warren1890}. 9 | 10 | Essa visão da privacidade como proteção à intimidade ou, nas palavras dos autores, como o ``direito de ser deixado em paz'' é a chave de interpretação que prevalece no debate público. 11 | Duas contribuições que não fogem a esse espírito, porém, merecem destaque nessas notas introdutórias. 12 | Em um influente artigo de 1977, Richard Posner propõe que as disputas sobre direito à privacidade sejam interpretadas em sua dimensão econômica. 13 | Para Posner, as informações privadas possuem valor. 14 | De um lado há o interesse de quem busca construir uma imagem pública sobre si, uma reputação e, de outro, há o interesse de se conhecer o outro para melhor saber como se relacionar com ele ou aprender sobre sua trajetória. 15 | Caso fosse permitido qualquer tipo de intrusão à privacidade, o efeito seria um esforço maior em não revelar, ou inclusive não produzir, dados potencialmente valiosos. 16 | Assim, a questão da privacidade, se resumiria a uma questão de eficiência econômica. 17 | Caberia ao legislador regular o direito ao controle da reputação procurando um equilíbrio que maximizasse os fluxos de informação \cite{Posner77}. 18 | 19 | O risco tanto para o indivíduo cuja paz é perturbada pelas fotos não autorizadas, quanto para aquele que perde o controle sobre sua reputação é de que algo que pertencia a sua esfera privada se tornasse pública. 20 | Para Nissenbaum, essa dicotomização entre público e privado não dá conta dos problemas associados à quebra de privacidade. 21 | Por exemplo, um paciente espera que as informações sobre sua condição de saúde sejam eventualmente compartilhadas com outros médicos ou médicas com o intuito de melhor diagnosticá-lo, assim como um cliente espera que seu gerente de banco use suas informações bancárias para sugerir-lhe melhores investimentos. 22 | Porém, há uma flagrante quebra de privacidade se as informações médicas forem compartilhadas com o banco, com quem eventualmente o paciente negociará um plano de saúde. 23 | Esse cenário exemplifica o que a autora chama de rompimento da ``integridade contextual do fluxo de informações'' \cite{Nissenbaum09}. 24 | 25 | \section{Vigilância} 26 | \label{sec:vigilancia} 27 | % Foucalt e Deleuze 28 | 29 | Associado ao tema da privacidade, mas ligado a outra matriz teórica, estão os debates sobre vigilância. 30 | Diferente dos estudos sobre privacidade cujos principais autores são juristas preocupados com o direito individual, os estudos sobre vigilância focam em relações de poder. 31 | Foucault descreve a vigilância como uma técnica que teria alterado profundamente as formas de exercer o poder durante os séculos XVII e XIX. 32 | O poder do senhor feudal durante a idade média era exercido por meio do suplício, a pena corporal em que o açoitado pedia misericórdia eventualmente concedida. 33 | Após a revolução francesa o suplício foi sendo substituído pela prisão e aos poucos seria desenvolvida a técnica da disciplina e da vigilância. 34 | Para o autor, a imagem que melhor descreve a técnica é uma estrutura arquitetônica proposta por Jeremy Bentham no final do século XVII. 35 | Bentham arquitetou um modelo de prisão em que os vigias ficariam no centro aonde poderiam observar todas as celas, porém, aqueles que ocupam as celas não poderiam observar o vigia. 36 | A sensação constante de estar sendo vigiado introjetaria a disciplina, outra técnica deste período, nos condenados. 37 | O propósito da vigilância e da disciplina é o de produzir corpos dóceis e obedientes \cite{Foucault96}. 38 | 39 | Em 1992, em um curto texto, Giles Deleuze propôs uma atualização dos conceitos de Foucault que antecipariam o que hoje compreendemos como vigilância. 40 | Na sociedade disciplinar, descrita por Foucault, durante a vida o indivíduos passa de uma instituição disciplinar a outra: da escola, ao exército, do exército à fábrica e da fábrica ao hospital. 41 | Cada instituição disciplina o indivíduo e o modela da maneira mais eficiente à instituição. 42 | Na sociedade do controle, conforme descrita por Deleuze, o poder é exercido de maneira mais intermitente e mais sutil. 43 | O indivíduo prototípico da sociedade do controle seria o endividado cujo controle atravessa as instituições \cite{Deleuze92}. 44 | 45 | Desde os trabalhos de Foucault, a vigilância se tornou um tema importante de investigação dentro das ciências sociais. 46 | Diversos autores escreveram trabalhos mais ou menos importantes sobre o tema. 47 | Um autor particularmente proeminente e que merece ser citado é David Lyon que escreveu uma serie de livros e organizou diversas coletâneas de artigos \cite{Lyon94,Lyon05}. 48 | Uma entrevista de Lyon a outro importante sociólogo contemporâneo, Zigmund Bauman, produziu um livro com tradução para o português \cite{Bauman14}. 49 | 50 | \section{Marco Regulatório} 51 | \label{sec:marco-regulatorio} 52 | % Mayer-Schonberger 53 | 54 | Antes ainda dos primeiros computadores, as chamadas máquinas Hollerith revolucionaram a capacidade de processamento de dados. 55 | Durante a década de trinta elas dinamizaram o processamento dos dados do censo nos EUA e na década de 40 foram usadas pelos nazistas para classificar aqueles, principalmente judeus, mas também comunistas e homossexuais, que deveriam ser transportados para os guetos, dos guetos para os campos de concentração e finalmente para as câmaras de gás \cite{Black01}. 56 | Finda a guerra, a evolução dos modernos Estados de bem estar social Europeu e seu necessário processamento massivo de dados casou muito bem com o desenvolvimento computacional e assustou os cidadãos com sua centralidade de processamento. 57 | Assim, começaram a surgir as primeiras leis de proteção de dados pessoais. 58 | 59 | Mayer-Schonberger argumenta que, uma vez que as leis de proteção de dados pessoais na Europa partem todas das mesmas bases e diferem apenas em detalhes, é mais frutífero estudá-las em conjunto do que seguindo uma análise comparativa. 60 | Ele propõe uma abordagem geracional como se existisse uma tendência evolutiva das normas. 61 | A primeira geração, no começo dos anos 70, focou na regulamentação técnica dessas bases centralizadas de dados. 62 | O surgimento de minicomputadores, que favorecia o processamento descentralizado, levou a uma adaptação na legislação. 63 | A segunda geração, no final dos anos 70, focou na liberdade negativa, o direito civil de "ser deixado em paz" nas palavras de Brandeis e Warren. 64 | A autonomia do indivíduo é, porém, contraposta a sua inclusão nos programas sociais do Estado. 65 | Então, a terceira geração legislativa, em meados dos anos 80, foge um pouco das liberdades negativas e foca em uma abordagem participativa de autodeterminação informacional. 66 | A pergunta deixa de ser se alguém quer participar ou não de processos sociais, mas como. 67 | Ainda assim, porém, os indivíduos estavam em uma posição frágil nas relações de negociação o que os levava, via de regra, a abdicar dos seus direitos. 68 | A quarta geração, de meados dos ano 90, procurou de um lado equalizar as posições de negociação ainda apostando na autonomia do indivíduo, mas também incluiu diversos mecanismos mais paternalistas excluindo certas liberdades participativas e as sujeitando à proteção jurídica obrigatória. 69 | Nessa fase surgem órgãos de defesa, não apenas de auxílio aos cidadãos, mas com papel decisório para deliberar contra violações \cite{Mayer-Schonberger97}. 70 | 71 | No Brasil, o Marco Civil da Internet aprovado em 2013 não aborda diretamente as questões de proteção de dados pessoais. 72 | Carecemos de um marco legal que imponha, pelo menos, que o uso de dados pessoais dependa necessariamente do consentimento explícito e informado e cuja autorização seja dada para um fim específico. 73 | 74 | \section{Vigilância Digital em Massa} 75 | \label{sec:vigil-digital} 76 | 77 | Em 2013 Edward Snowden revelou ao mundo o alcance dos programas de vigilância em massa das agências de espionagem dos EUA. 78 | O jornalista Glenn Greenwald e a cineasta Laura Poitras divulgaram o caso em uma serie de matérias e um documentário \cite{Greenwald14, Poitras14}. 79 | O vazamento demonstra que a agência de segurança nacional dos EUA (NSA) tem acesso a toda a comunicação por telefone e pelos principais meios de comunicação online do mundo. 80 | O moderno modelo de negócios das empresas de internet baseado na propaganda direcionada depende da construção de perfis digitais que por sua vez dependem da produção e aquisição de uma grande escala de dados pessoais. 81 | Essa competição por dados pessoais cria o que chamamos de pontos únicos de falha. 82 | A violação dessas bases permitiu à NSA produzir um banco de dados pesquisável da agência que possui toda comunicação pública e privada que passa pelos servidores da Google, do Facebook, da Microsoft e da Apple. 83 | 84 | A vigilância digital em massa eleva o problema da privacidade para um outro patamar. 85 | Não se trata apenas de proteger a intimidade, ou a inviolabilidade do lar, ou do controle na construção da reputação. 86 | Nesse contexto, o problema da privacidade é também coletivo. 87 | A privacidade deve ser também enxergada como um direito civil, uma limitação ao poder do estado de antecipar as ações de grupos políticos. 88 | Para tanto, é preciso de ação política de conscientização, de regulamentação para restringir o poder das empresas que controlam o armazenamento dos dados pessoais e também desenvolvimento técnico. 89 | 90 | \section{Segurança da Informação} 91 | \label{sec:seg-inf} 92 | 93 | A internet é um meio intrinsecamente promíscuo \cite{}. 94 | Por uma decisão de projeto, não temos controle por onde nossas informações passam quando nos comunicamos pela rede. 95 | Conforme produzimos mais informações pessoais e permitimos que elas circulem, maior o risco de quebra da integridade dos fluxos contextuais. 96 | Em particular há atores poderosos com capacidade conhecida de observar a comunicação em escala global o que traz um risco coletivo tanto à soberania nacional dos países periféricos, como o Brasil, quanto à democracia. 97 | A regulamentação, absolutamente necessária para controlar minimamente esses processos e garantir pelo menos o consentimento no uso de nossas informações pessoais, certamente não é suficiente. 98 | A compreensão, o desenvolvimento e a difusão de ferramentas de segurança da informação, combinada com a incorporação de uma cultura de segurança \cite{CulturaDeSeguranca} podem colaborar nesse sentido. 99 | Concluiremos o capítulo com uma história motivadora. 100 | 101 | Após as denúncias de Snowden houve uma espécie de consenso nos meios ativistas sobre a importância de focar forças em desenvolver ferramentas que garantissem a criptografia ponta a ponta. 102 | O paradigma mais comum de comunicação na rede é criptografar a comunicação entre cada cliente e o servidor. 103 | Como já dissemos, conforme poucos servidores concentram a maior parte da comunicação online, a informação armazenada nesses servidores passa a ser um bem muito requisitado. 104 | A ideia para superar isso seria criptografar a comunicação entre clientes. 105 | Assim, a informação armazenada nos servidores não seria compreensível seja pelos engenheiros das empresa que controla a comunicação, seja para um ator externo como um hacker ou a NSA. 106 | O principal protocolo de criptografia ponta a ponta na época era o PGP, que havia sido criado no começo da década de 90, antes do advento da web. 107 | As tentativas mal sucedidas de ressuscitar o protocolo logo foram substituídas por um esforço em atualizá-lo. 108 | Duas aplicações que garantiam criptografia ponta a ponta em celulares se popularizaram nesse período: Telegram e o Textsecure. 109 | A primeira foi desenvolvida por uma companhia russa e oferece serviço de criptografia ponta a ponta em comunicação síncrona usando um protocolo desenvolvido por seus engenheiros. 110 | A segunda foi desenvolvida por uma pequena empresa no Vale do Silício e se inspirou no protocolo OTR, que por sua vez se inspirou no PGP, adaptando-o para o contexto assíncrono mais adequado para a comunicação móvel. 111 | Os esforços de ativistas em promover esse tipo de ferramenta culminou com a adoção do protocolo do Textsecure, rebatizado como Signal, no Whatsapp, a ferramenta de comunicação móvel mais usada no mundo todo. 112 | A popularização da criptografia ponta a ponta em grande parte da comunicação interpessoal muda muito o cenário de proteção de direitos civis e de liberdade de organização. 113 | É certo que os metadados das comunicações - quem fala com quem, quando e de onde - não estão protegidos, é certo que a maior parte da comunicação interpessoal não está livre de intrusão seja de hackers, seja de agências governamentais, é certo que há serviços - como agenda online - em que simplesmente não há alternativa segura e, portanto, é necessária muita ação política e desenvolvimento técnico nessa área. 114 | -------------------------------------------------------------------------------- /ref.bib: -------------------------------------------------------------------------------- 1 | @article{Warren1890, 2 | added-at = {2008-07-30T18:55:01.000+0200}, 3 | author = {Warren, Samuel D. and Brandeis, Louis D.}, 4 | journal = {Harward Law Review}, 5 | month = {December}, 6 | number = 5, 7 | pages = {193--220}, 8 | title = {The Right to Privacy}, 9 | volume = 4, 10 | year = 1890 11 | } 12 | 13 | @Article{Posner77, 14 | author = {Posner, Richard A.}, 15 | title = {The Right of Privacy}, 16 | journal = {Sibley Lecture Series}, 17 | year = {1977}, 18 | volume = {22}, 19 | } 20 | 21 | @book{Nissenbaum09, 22 | title={Privacy in Context: Technology, Policy, and the Integrity of Social Life}, 23 | author={Nissenbaum, Hellen}, 24 | isbn={9780804772891}, 25 | lccn={2009026320}, 26 | series={Stanford Law Books}, 27 | year={2009}, 28 | publisher={Stanford University Press} 29 | } 30 | 31 | @book{Foucault96, 32 | title={Vigiar e punir: hist{\'o}ria da viol{\^e}ncia nas pris{\~o}es}, 33 | author={Foucault, Michel}, 34 | year={1996}, 35 | publisher={Vozes} 36 | } 37 | 38 | @article{Deleuze92, 39 | title={Postscript on the Societies of Control}, 40 | author={Deleuze, Gilles}, 41 | journal={October}, 42 | volume={59}, 43 | pages={3--7}, 44 | year={1992}, 45 | publisher={JSTOR} 46 | } 47 | 48 | @book{Black01, 49 | title={IBM e o Holocausto: a alian{\c{c}}a estrat{\'e}gica entre a Alemanha nazista e a mais poderosa empresa americana}, 50 | author={Black, Edwin}, 51 | isbn={9788535207590}, 52 | year={2001}, 53 | publisher={Editora Campus} 54 | } 55 | 56 | @incollection{Mayer-Schonberger97, 57 | author = {Mayer-Sch\"{o}nberger, Viktor}, 58 | chapter = {Generational Development of Data Protection in Europe}, 59 | title = {Technology and Privacy}, 60 | editor = {Agre, Philip E. and Rotenberg, Marc}, 61 | year = {1997}, 62 | isbn = {0-262-01162-X}, 63 | pages = {219--241}, 64 | numpages = {23}, 65 | acmid = {275292}, 66 | publisher = {MIT Press}, 67 | address = {Cambridge, MA, USA}, 68 | } 69 | 70 | @book{Greenwald14, 71 | title={No Place to Hide: Edward Snowden, the NSA, and the U.S. Surveillance State}, 72 | author={Greenwald, Glenn}, 73 | isbn={9781627790741}, 74 | year={2014}, 75 | publisher={Henry Holt and Company} 76 | } 77 | 78 | @Misc{Poitras14, 79 | author = {Laura Poitras}, 80 | title = {Citizenfour}, 81 | howpublished = {Docummentary}, 82 | year = {2014}, 83 | } 84 | 85 | @Misc{CulturaDeSeguranca, 86 | title = {Cultura de Segurança: Um manual para ativistas}, 87 | year = {2001}, 88 | note = {Acessado em http://bit.ly/2wBcCDe em 11 de agosto de 2017} 89 | } 90 | 91 | @book{Singh04, 92 | title={O livro dos c{\'o}digos}, 93 | author={Singh, Simon}, 94 | isbn={9788501055989}, 95 | year={2004}, 96 | publisher={RECORD} 97 | } 98 | 99 | @book{Kahn96, 100 | title={The Codebreakers: The Comprehensive History of Secret Communication from Ancient Times to the Internet}, 101 | author={Kahn, David}, 102 | isbn={9781439103555}, 103 | year={1996}, 104 | publisher={Scribner} 105 | } 106 | 107 | @book{Lyon94, 108 | title={The Electronic Eye: The Rise of Surveillance Society}, 109 | author={Lyon, David}, 110 | isbn={9781452901732}, 111 | year={1994}, 112 | publisher={University of Minnesota Press} 113 | } 114 | 115 | @book{Lyon05, 116 | title={Surveillance as Social Sorting: Privacy, Risk and Automated Discrimination}, 117 | author={Lyon, David}, 118 | isbn={9781134469048}, 119 | year={2005}, 120 | publisher={Taylor \& Francis} 121 | } 122 | 123 | @book{Bauman14, 124 | title={Vigil{\^a}ncia L{\'\i}quida}, 125 | author={Bauman, Zigmund}, 126 | isbn={9788537811771}, 127 | year={2014}, 128 | publisher={Zahar} 129 | } 130 | 131 | @inproceedings{DeCanniere06, 132 | author = {De Canni\`{e}re, Christophe}, 133 | title = {Trivium: A Stream Cipher Construction Inspired by Block Cipher Design Principles}, 134 | booktitle = {Proceedings of the 9th International Conference on Information Security}, 135 | series = {ISC'06}, 136 | year = {2006}, 137 | isbn = {3-540-38341-7, 978-3-540-38341-3}, 138 | location = {Samos Island, Greece}, 139 | pages = {171--186}, 140 | numpages = {16}, 141 | doi = {10.1007/11836810_13}, 142 | acmid = {2079946}, 143 | publisher = {Springer-Verlag}, 144 | address = {Berlin, Heidelberg}, 145 | } 146 | 147 | @article{Rivest16, 148 | author = {Ronald L. Rivest and 149 | Jacob C. N. Schuldt}, 150 | title = {Spritz - a spongy {R}{C}4-like stream cipher and hash function}, 151 | journal = {{IACR} Cryptology ePrint Archive}, 152 | volume = {2016}, 153 | pages = {856}, 154 | year = {2016}, 155 | } 156 | 157 | @Inbook{Fluhrer01, 158 | author="Fluhrer, Scott and Mantin, Itsik and Shamir, Adi", 159 | editor="Vaudenay, Serge and Youssef, Amr M.", 160 | title="Weaknesses in the Key Scheduling Algorithm of RC4", 161 | bookTitle="Selected Areas in Cryptography: 8th Annual International Workshop, SAC 2001 Toronto, Ontario, Canada, August 16--17, 2001 Revised Papers", 162 | year="2001", 163 | publisher="Springer Berlin Heidelberg", 164 | address="Berlin, Heidelberg", 165 | pages="1--24", 166 | isbn="978-3-540-45537-0", 167 | doi="10.1007/3-540-45537-X_1" 168 | } 169 | 170 | @article{Goldwasser84, 171 | author = "Shafi Goldwasser and Silvio Micali", 172 | title = "Probabilistic encryption", 173 | journal = "Journal of Computer and System Sciences", 174 | volume = "28", 175 | number = "2", 176 | pages = "270 - 299", 177 | year = "1984", 178 | issn = "0022-0000", 179 | doi = "http://dx.doi.org/10.1016/0022-0000(84)90070-9" 180 | } 181 | 182 | @article{Blum84, 183 | author = {Blum, Manuel and Micali, Silvio}, 184 | title = {How to Generate Cryptographically Strong Sequences of Pseudo-random Bits}, 185 | journal = {SIAM J. Comput.}, 186 | issue_date = {Nov. 1984}, 187 | volume = {13}, 188 | number = {4}, 189 | month = nov, 190 | year = {1984}, 191 | issn = {0097-5397}, 192 | pages = {850--864}, 193 | numpages = {15}, 194 | doi = {10.1137/0213053}, 195 | acmid = {2068}, 196 | publisher = {Society for Industrial and Applied Mathematics}, 197 | address = {Philadelphia, PA, USA}, 198 | } 199 | 200 | @inproceedings{Yao82, 201 | author = {Yao, Andrew C.}, 202 | title = {Theory and Application of Trapdoor Functions}, 203 | booktitle = {Proceedings of the 23rd Annual Symposium on Foundations of Computer Science}, 204 | series = {SFCS '82}, 205 | year = {1982}, 206 | pages = {80--91}, 207 | numpages = {12}, 208 | doi = {10.1109/SFCS.1982.95}, 209 | acmid = {1382790}, 210 | publisher = {IEEE Computer Society}, 211 | address = {Washington, DC, USA}, 212 | } 213 | 214 | @inproceedings{Bellare97, 215 | author = {Bellare, Mihir and Desai, Anand and Jokipii, Eron and Rogaway, Phillip}, 216 | title = {A Concrete Security Treatment of Symmetric Encryption}, 217 | booktitle = {Proceedings of the 38th Annual Symposium on Foundations of Computer Science}, 218 | series = {FOCS '97}, 219 | year = {1997}, 220 | isbn = {0-8186-8197-7}, 221 | pages = {394--}, 222 | acmid = {796360}, 223 | publisher = {IEEE Computer Society}, 224 | address = {Washington, DC, USA}, 225 | } 226 | 227 | @article{Goldreich86, 228 | author = {Goldreich, Oded and Goldwasser, Shafi and Micali, Silvio}, 229 | title = {How to Construct Random Functions}, 230 | journal = {J. ACM}, 231 | issue_date = {Oct. 1986}, 232 | volume = {33}, 233 | number = {4}, 234 | month = aug, 235 | year = {1986}, 236 | issn = {0004-5411}, 237 | pages = {792--807}, 238 | numpages = {16}, 239 | doi = {10.1145/6490.6503}, 240 | acmid = {6503}, 241 | publisher = {ACM}, 242 | address = {New York, NY, USA}, 243 | } 244 | 245 | @inproceedings{Naor90, 246 | author = {Naor, Mori and Yung, Moti}, 247 | title = {Public-key Cryptosystems Provably Secure Against Chosen Ciphertext Attacks}, 248 | booktitle = {Proceedings of the Twenty-second Annual ACM Symposium on Theory of Computing}, 249 | series = {STOC '90}, 250 | year = {1990}, 251 | isbn = {0-89791-361-2}, 252 | location = {Baltimore, Maryland, USA}, 253 | pages = {427--437}, 254 | numpages = {11}, 255 | doi = {10.1145/100216.100273}, 256 | acmid = {100273}, 257 | publisher = {ACM}, 258 | address = {New York, NY, USA}, 259 | } 260 | 261 | @article{Bellare00, 262 | author = "Mihir Bellare and Joe Kilian and Phillip Rogaway", 263 | title = "The Security of the Cipher Block Chaining Message Authentication Code", 264 | journal = "Journal of Computer and System Sciences", 265 | volume = "61", 266 | number = "3", 267 | pages = "362 - 399", 268 | year = "2000", 269 | issn = "0022-0000", 270 | doi = "http://dx.doi.org/10.1006/jcss.1999.1694", 271 | } 272 | 273 | @article{Shannon49, 274 | author = {Shannon, Claude E.}, 275 | journal = {Bell Systems Technical Journal}, 276 | keywords = {master, secrecy\_systems, teoria-informacao, theory\_communication, theory\_cryptography}, 277 | pages = {656--715}, 278 | title = {{Communication Theory of Secrecy Systems}}, 279 | volume = {28}, 280 | year = {1949} 281 | } 282 | 283 | @Article{Feistel73, 284 | author = "Horst Feistel", 285 | title = "Cryptography and Computer Privacy", 286 | volume = "228", 287 | number = "5", 288 | pages = "15--23", 289 | month = may, 290 | year = "1973", 291 | CODEN = "SCAMAC", 292 | DOI = "http://dx.doi.org/10.1038/scientificamerican0573-15", 293 | ISSN = "0036-8733 (print), 1946-7087 (electronic)", 294 | ISSN-L = "0036-8733", 295 | journal = "Scientific American", 296 | keywords = "code security; computer privacy; cryptography", 297 | } 298 | 299 | @inproceedings{Merkle89, 300 | author = {Merkle, Ralph C.}, 301 | title = {One Way Hash Functions and DES}, 302 | booktitle = {Proceedings of the 9th Annual International Cryptology Conference on Advances in Cryptology}, 303 | series = {CRYPTO '89}, 304 | year = {1990}, 305 | isbn = {3-540-97317-6}, 306 | pages = {428--446}, 307 | numpages = {19}, 308 | publisher = {Springer-Verlag}, 309 | address = {London, UK, UK}, 310 | } 311 | 312 | @inproceedings{Damgard89, 313 | author = {Damg{\aa}rd, Ivan}, 314 | title = {A Design Principle for Hash Functions}, 315 | booktitle = {Proceedings of the 9th Annual International Cryptology Conference on Advances in Cryptology}, 316 | series = {CRYPTO '89}, 317 | year = {1990}, 318 | isbn = {3-540-97317-6}, 319 | pages = {416--427}, 320 | numpages = {12}, 321 | publisher = {Springer-Verlag}, 322 | address = {London, UK, UK}, 323 | } 324 | 325 | @Inbook{Damgard88, 326 | author="Damg{\aa}rd, Ivan Bjerre", 327 | editor="Chaum, David and Price, Wyn L.", 328 | title="Collision Free Hash Functions and Public Key Signature Schemes", 329 | bookTitle="Advances in Cryptology --- EUROCRYPT' 87: Workshop on the Theory and Application of Cryptographic Techniques Amsterdam, The Netherlands, April 13--15, 1987 Proceedings", 330 | year="1988", 331 | publisher="Springer Berlin Heidelberg", 332 | address="Berlin, Heidelberg", 333 | pages="203--216", 334 | isbn="978-3-540-39118-0", 335 | doi="10.1007/3-540-39118-5_19", 336 | } 337 | 338 | @article{Diffie76, 339 | author = {Diffie, Withfield and Hellman, Martin}, 340 | title = {New Directions in Cryptography}, 341 | journal = {IEEE Trans. Inf. Theor.}, 342 | volume = {22}, 343 | number = {6}, 344 | month = sep, 345 | year = {1976}, 346 | issn = {0018-9448}, 347 | pages = {644--654}, 348 | numpages = {11}, 349 | doi = {10.1109/TIT.1976.1055638}, 350 | publisher = {IEEE Press}, 351 | address = {Piscataway, NJ, USA}, 352 | } 353 | 354 | @book{Goldreich07, 355 | title={Foundations of Cryptography: Volume 1, Basic Tools}, 356 | author={Goldreich, Oded}, 357 | isbn={9781139430234}, 358 | year={2007}, 359 | publisher={Cambridge University Press} 360 | } 361 | 362 | @inproceedings{Goldreich89, 363 | author = {Goldreich, Oded and Levin, Leonid A.}, 364 | title = {A Hard-core Predicate for All One-way Functions}, 365 | booktitle = {Proceedings of the Twenty-first Annual ACM Symposium on Theory of Computing}, 366 | series = {STOC '89}, 367 | year = {1989}, 368 | isbn = {0-89791-307-8}, 369 | location = {Seattle, Washington, USA}, 370 | pages = {25--32}, 371 | numpages = {8}, 372 | doi = {10.1145/73007.73010}, 373 | acmid = {73010}, 374 | publisher = {ACM}, 375 | address = {New York, NY, USA}, 376 | } 377 | 378 | @Inbook{Krawczyk10, 379 | author="Krawczyk, Hugo", 380 | editor="Rabin, Tal", 381 | title="Cryptographic Extraction and Key Derivation: The HKDF Scheme", 382 | bookTitle="Advances in Cryptology -- CRYPTO 2010: 30th Annual Cryptology Conference, Santa Barbara, CA, USA, August 15-19, 2010. Proceedings", 383 | year="2010", 384 | publisher="Springer Berlin Heidelberg", 385 | address="Berlin, Heidelberg", 386 | pages="631--648", 387 | isbn="978-3-642-14623-7", 388 | doi="10.1007/978-3-642-14623-7_34", 389 | } 390 | 391 | @inproceedings{ElGamal85, 392 | author = {El Gamal, Taher}, 393 | title = {A Public Key Cryptosystem and a Signature Scheme Based on Discrete Logarithms}, 394 | booktitle = {Proceedings of CRYPTO 84 on Advances in Cryptology}, 395 | year = {1985}, 396 | isbn = {0-387-15658-5}, 397 | location = {Santa Barbara, California, USA}, 398 | pages = {10--18}, 399 | numpages = {9}, 400 | publisher = {Springer-Verlag New York, Inc.}, 401 | address = {New York, NY, USA}, 402 | } 403 | 404 | @article{Rivest78, 405 | author = {Rivest, Ron L. and Shamir, Adi and Adleman, Leonard}, 406 | title = {A Method for Obtaining Digital Signatures and Public-key Cryptosystems}, 407 | journal = {Commun. ACM}, 408 | issue_date = {Feb. 1978}, 409 | volume = {21}, 410 | number = {2}, 411 | month = feb, 412 | year = {1978}, 413 | issn = {0001-0782}, 414 | pages = {120--126}, 415 | numpages = {7}, 416 | doi = {10.1145/359340.359342}, 417 | acmid = {359342}, 418 | publisher = {ACM}, 419 | address = {New York, NY, USA}, 420 | keywords = {authentication, cryptography, digital signatures, electronic funds transfer, electronic mail, factorization, message-passing, prime number, privacy, public-key cryptosystems, security}, 421 | } 422 | 423 | @inproceedings{Miller75, 424 | author = {Miller, Gary L.}, 425 | title = {Riemann's Hypothesis and Tests for Primality}, 426 | booktitle = {Proceedings of the Seventh Annual ACM Symposium on Theory of Computing}, 427 | series = {STOC '75}, 428 | year = {1975}, 429 | location = {Albuquerque, New Mexico, USA}, 430 | pages = {234--239}, 431 | numpages = {6}, 432 | doi = {10.1145/800116.803773}, 433 | acmid = {803773}, 434 | publisher = {ACM}, 435 | address = {New York, NY, USA}, 436 | } 437 | 438 | @article{Rabin80, 439 | author={Michael O. Rabin}, 440 | ISSN={0022--314X}, 441 | journal={Journal of Number Theory}, 442 | pages={128--138}, 443 | title={{Probabilistic algorithm for testing primality}}, 444 | volume={12}, 445 | year={1980} 446 | } 447 | 448 | @Inbook{Fiat87, 449 | author="Fiat, Amos and Shamir, Adi", 450 | editor="Odlyzko, Andrew M.", 451 | title="How To Prove Yourself: Practical Solutions to Identification and Signature Problems", 452 | bookTitle="Advances in Cryptology --- CRYPTO' 86: Proceedings", 453 | year="1987", 454 | publisher="Springer Berlin Heidelberg", 455 | address="Berlin, Heidelberg", 456 | pages="186--194", 457 | isbn="978-3-540-47721-1", 458 | doi="10.1007/3-540-47721-7_12", 459 | } 460 | 461 | @inproceedings{Borisov04, 462 | author = {Borisov, Nikita and Goldberg, Ian and Brewer, Eric}, 463 | title = {Off-the-record Communication, or, Why Not to Use PGP}, 464 | booktitle = {Proceedings of the 2004 ACM Workshop on Privacy in the Electronic Society}, 465 | series = {WPES '04}, 466 | year = {2004}, 467 | isbn = {1-58113-968-3}, 468 | location = {Washington DC, USA}, 469 | pages = {77--84}, 470 | numpages = {8}, 471 | url = {http://doi.acm.org/10.1145/1029179.1029200}, 472 | doi = {10.1145/1029179.1029200}, 473 | acmid = {1029200}, 474 | publisher = {ACM}, 475 | address = {New York, NY, USA}, 476 | keywords = {deniability, perfect forward secrecy, private communication}, 477 | } 478 | 479 | @book{Paar09, 480 | title={Understanding Cryptography: A Textbook for Students and Practitioners}, 481 | author={Paar, C. and Pelzl, J.}, 482 | isbn={9783642041013}, 483 | lccn={2009940447}, 484 | url={https://books.google.com.br/books?id=f24wFELSzkoC}, 485 | year={2009}, 486 | publisher={Springer Berlin Heidelberg} 487 | } 488 | 489 | -------------------------------------------------------------------------------- /protocolos.tex: -------------------------------------------------------------------------------- 1 | \chapter{Protocolos} 2 | \label{cha:protocolos} 3 | 4 | Para fechar essas notas apresentaremos uma serie de protocolos que utilizam as primitivas criptograficas que vimos até aqui. 5 | Um {\em protocolo} propriamente dito deveria descrever os passos de comunicação em um nível de detalhes suficiente para ser implementado sem ambiguidades. 6 | Este não é nosso propósito. 7 | Pretendemos aqui apenas apresentar aplicações práticas de uso de criptografia forte e como as primitivas são usadas para resolver problemas de comunicação digital. 8 | 9 | % Ao invés de tentar cobrir todos os protocolos, acho melhos focar 10 | % PGP -> OTR -> Signal 11 | % PGP é um excelente exemplo de PKI, aqui vale a pena citar o TLS como modelo alternativo 12 | % quando falar do Signal mencionar TOFU do SSH que é no fundo a única parte que interessa desse protocolo 13 | 14 | %\section{Transport Layer Security} 15 | %\label{sec:tls} 16 | 17 | %O {\em Transport Layer Security} (TLS) é a evolução do protobolo {\em Secure Socket Layer} (SSL) usado amplamente em todo o mundo nas conexões web suguras (sempre que conectamos em um site {\tt https}). 18 | %A primeira versão do SSL data de meados dos anos 90 e foi desenvolvida por programadores da Netscape. 19 | %A primeira versão do TLS é de 1999 e sua versão atual é de 2006. 20 | 21 | %O protocolo se divide em duas fases: {\em handshake} responsável por estabelecer as chaves de critpografia simétrica entre cliente e servidor %e {\em record-layer} responsavel por garantir a confidencialidade, integridade e autenticidade na comunicação. 22 | %Na comunicação usando TLS o cliente possui a chave pública de uma série de autoridades certificadoras que tipicamente vem junto do navegador e o servidor deve possuir um certificado $cert_{CA \to S}$ que obteve junto a alguma dessas entidades certificadoras para um par de chaves $\langle sk_S, pk_S \rangle$. 23 | %O {\em handshake} consiste dos seguintes passos: 24 | 25 | %\begin{enumerate} 26 | %\item O Cliente $C$ envia uma mensagem a $S$ contendo informando a versão do protocolo e os esquemas de criptografia suportados e um {\em nonce} $N_C$ 27 | %\item $S$ seleciona a última versão do protocolo compatível com $C$ e envia de volta sua chave pública $pk_S$ com o certificado $cert_{CA \to S}$ e outro nonce $N_S$ 28 | %\item $C$ verifica o certificado $cert_{CA \to S}$ então usa $pk_S$ para encapsular uma chave ({\em pre-master key}) $Encaps(pk_S, 1^k) = \langle c_{pmk}, pmk \rangle$. 29 | % Por meio de uma função de derivação de chave $KDF$ é então produzida outra chave $mk$ ({\em master key}) usando $pmk$, $N_C$ e $N_S$. 30 | %Um PRG é usado para gerar quatro chaves $k_C$, $k_C'$, $k_S$ e $k_S'$. 31 | %Por fim, $C$ produz um mac $t_C$ com a chave $mk$ de toda a comunicação entre as partes até este ponto e envia $t_C$ e $c_{pmk}$ para $S$. 32 | %\item $S$ computa $Decaps(sk_S, c_{pmk})$ para gerar $pmk$ e então segue os mesmos passos de $C$ para recuperar $k_C$, $k_C'$, $k_S$ e $k_S'$. 33 | %Em seguida $S$ verifica $t_C$ e aborta o processo em caso de falha. 34 | %Por fim, $S$ produz outro mac $t_S$ de toda a comunicação até aqui com a chave $mk$ e envia para $C$. 35 | %\item $C$ verifica $t_S$ e aborta o processo se falhar. 36 | %\end{enumerate} 37 | 38 | %% DIAGRAMA ? 39 | 40 | %No fim deste processo $S$ e $C$ compartilham dois pares de chaves autênticos. 41 | %Quando $C$ envia uma mensagem para $S$ ele a autentica com $k_C'$ e a criptografa com $k_C$ e quando $S$ responde ele autentica a mensagem com $k_S'$ e criptografa tudo com $k_S$. 42 | %Note que o protocolo segue o paradigma {\em mac then encrypt} que não é demononstradamente seguro. 43 | 44 | 45 | %\section{Secure Shell} 46 | %\label{sec:ssh} 47 | 48 | %O protocolo {\em Secure Shell} (SSH) para comunicação segura para login e transferência de arquivos em servidores remotos. 49 | 50 | %Antes da fase de troca de chaves, as partes passam por uma fase de negociação de algoritmos. 51 | %Nesta fase cada qual envia para a outra parte uma lista dos algortimos de criptografia suportados $I_S$ e $I_C$. 52 | %Nesta fase eles definem um grupo $\mathbb{G}$ com ordem $n$ e gerador $g$ e uma função de hash $H$. 53 | %A fase de troca de chaves segue os seguintes passos: 54 | %\begin{enumerate} 55 | %\item $C$ sorteia $x \leftarrow \{2, \dots, n-1\}$ e envia $e = g^x$ para $S$. 56 | %\item $S$ sorteia $y \leftarrow \{2, \dots, n-1\}$, calcula $f = g^y$ e computa $k = e^y$, $h = H(Id_C || Id_S || I_C || I_S || pk_S || e || f || k)$ e $s = Sign(sk_S, H)$. 57 | %$S$ então envia $pk_S$, $f$ e $s$ para $C$ 58 | %\item $C$ pode verificar a autenticidade de $pk_S$ neste passo, então computa $k = f^x$ e $h = H(Id_C || Id_S || I_C || I_S || pk_S || e || f || k)$ e, por, fim verifica a assinatura $Ver(pk_S, h, s)$. 59 | %\end{enumerate} 60 | 61 | %O protocolo SSH permite o uso de certificados para verificar $pk_S$. 62 | %Tipicamente, porém, o modelo de segurança que é seguido é chamado de {\em Trust On First Use} (TOFU): a primeira vez que o cliente $C$ se conecta com o servidor $S$ uma aviso é exibido e a identidade do servidor é salva em uma base de dados no cliente, assim as próximas conexões podem verificar a autenticidade da chave apenas verificando essa base. 63 | %A conexão apresenta também um {\em fingreprint} da chave pública que pode ser enviado de maneira segura para verificação manual. 64 | 65 | %No final da fase de troca de chaves servidor e cliente compartilham $k$, $h$ e uma identificação da seção $Id$. 66 | %A partir desses valores são geradas as chaves de criptografia $k_S$ e $k_C$, as chaves de autenticação $k_S'$ e $k_C'$ e os vetores inciais $IV_S$ e $IV_C$. 67 | %Todos valores são obtidos usando um hash $H$ com $k$, $h$, $Id$ e uma constante diferente para cada chave. 68 | 69 | %Antes das partes começarem a fase de troca de mensagens {\em protocolo de conexão}, o servidor precisa autenticar o cliente. 70 | %Isso é feito na fase de {\em autenticação} de três formas alternativas: 71 | %\begin{itemize} 72 | %\item {\em chave pública}: $C$ envia uma mensagem assinada para $S$ contendo $pk_C$. 73 | %O servidor então verifica se a chave é aceitável para a autenticação e então verifica a assinatura. 74 | %\item {\em senha}: $C$ envia uma mensagem com uma senha protegida pelo esquema apresentado acima. 75 | %\item {\em hostbased}: O host de $C$ realiza a autenticação por meio de algum protocolo de verificação de assinatura. 76 | %O servidor verifica o host e confia que ele autenticou $C$. 77 | %\end{itemize} 78 | 79 | \section{Pretty Good Privacy} 80 | \label{sec:pgp} 81 | 82 | O PGP foi desenvolvido no começo dos anos 90 por Phil Zimmermann, um ativista do movimento contra o uso de armas nucleares. 83 | A intenção do autor era combinar tecnologias conhecidas para construir um protocolo seguro e livre para proteção dos ativistas. 84 | No começo dos anos 90 o algoritmo RSA era patenteado -- algo pouco convencional e alvo de controversas. 85 | Depois que a RSA Security, dona da patente, entrou em uma disputa legal com Zimmermann, o governo dos EUA o processou por tráfico de armamento militar. 86 | Em 1996 os EUA desistiram do caso. 87 | 88 | Contrastando com o protocolo TLS/SSL que utiliza o modelo de delegação de autoridade, o protocolo PGP é o protótipo de protocolo que utiliza o modelo de {\em rede de confiança} para certificação das chaves públicas. 89 | Em poucas palavras, o protocolo combina o mais simples modelo híbrido de criptografia, compactação de arquivos, assinaturas digitais e o modelo de rede de confiança para certificação de chaves. 90 | 91 | Concretamente, cada usuário possui um par de chaves $\langle sk, pk \rangle$ e disponibiliza $pk$ em um servidor de chaves. 92 | Qualquer um pode verificar a autenticidade de uma chave -- conferindo seu {\em fingerprint} manualmente e a identidade do titular -- e publicar no mesmo servidor de chaves um certificado. 93 | Apesar da idade, o PGP é ainda hoje o principal protocolo de criptografia ponta a ponta para e-mails. 94 | 95 | Com protocolo PGP um usuário pode: criptografar uma mensagem, assinar uma mensagem ou assinar e criptografar a mensagem. 96 | \begin{itemize} 97 | \item {\em criptografia:} Alice sorteia uma chave de seção $k$, compacta a mensagem $m$ e criptografa o resultado $Z(m)$ com uma cifra de bloco em modo {\em Cipher Feedback} (CFB) $c = E(k, Z(m))$ então a chave $k$ é criptografada usando uma versão do algoritmo RSA ou de El Gamal $c_k = E'(pk_B, k)$ e ambos $c$ e $c_k$ são enviados para Bob. 98 | Bob então usa sua chave secreta $sk_B$ para recuperar $k$ e então usa $k$ para desctiptografar e por fim então descompatar $m$. 99 | Em poucas palavras, trata-se de um KEM tradicional com um passo de compactação. 100 | \item {\em autenticação}: Alice computa $H(m)$ e assina com sua chave secreta $sk_A$ usando o algoritmo RSA ou DSA $Sign(sk_A, H(m))$, junta isso com a mensagem $m$ e compacta tudo $Z(m||Sign(sk_A, H(m)))$ para mandar para Bob. 101 | Bob então decompacta a mensagem, calcula o hash e verifica a assinatura. 102 | Ou seja, trata-se de uma implementação simples do modelo {\em hash-and-sign}. 103 | \item {\em autenticação e criptografia}: Alice autentica a mensagem e em seguida criptografa $E(k, Z(m||Sign(sk_A, H(m))))$ e Bob faz os passos na ordem reversa. 104 | \end{itemize} 105 | 106 | O modo {\em cipher feedback} (CFB) se assemelha bastante ao modo CBC que vimos anteriormente: 107 | 108 | \begin{eqnarray*} 109 | c_0 & := & IV \leftarrow \{0,1\}^n\\ 110 | c_i & := & E(k, c_{i-1}) \xor m_i 111 | \end{eqnarray*} 112 | 113 | 114 | \section{Off The Record} 115 | \label{sec:otr} 116 | 117 | Enquanto o protocolo PGP foi concebido para comunicação assíncrona, estilo e-mail, modelando essencialmente o que seria o envio de uma carta selada, o protocolo OTR procura modelar uma conversa privada em uma comunicação síncrona, como um chat \cite{Borisov04}. 118 | Como o PGP, o OTR busca garantir autenticidade, integridade e confidencialidade na comunicação, mas além disso o protocolo tenta também garantir: 119 | \begin{itemize} 120 | \item {\em perfect foward secrecy}: caso alguém grave a comunicação cifrada entre as partes e eventualmente tenha acesso a chave de comunicação não será possível decifrar as mensagens antigas 121 | \item {\em negação plausível}: o destinatário da mensagem não deve ser capaz de provar a um terceiro quem foi o remetente da mensagem 122 | \end{itemize} 123 | 124 | Como outros protocolos que vimos, o OTR começa com um handshake. 125 | \begin{itemize} 126 | \item Alice gera $x_0$, produz $g^{x_0}$, assina com sua chave secreta e envia $Sig(sk_A, g^{x_0})$ e $g^{x_0}$ para Bob 127 | \item Bob então verifica a assinatura, gera $y_0$, produz $g^{y_0}$ e envia $Sign(sk_B, g^{y_0})$ e $g^{y_0}$ para Alice 128 | \end{itemize} 129 | 130 | Assumimos que Alice e Bob possuem cada qual a chave pública do outro. 131 | Eles podem verificar manualmente o fingerprint dessa chave ou usar algum outro protocolo para isso\footnote{No caso da comunicação síncrona é possível usar, por exemplo, o protocolo do milionário socialista para verificar se as partes compartilham alguma informação secreta}. 132 | Uma vez que as partes foram autenticadas, elas podem usar $k_{00} = H(g^{x_0y_0})$ como chave efêmera para encriptar as mensagens. 133 | O esquema de criptografia usado no OTR é o AES em modeo contador que é propositalmente maleável -- ou seja, é fácil injetar uma mensagem. 134 | A comuncação então segue os seguintes passos: 135 | \begin{itemize} 136 | \item Alice gera $x_1$, calcula $E(k_{00}, m_1) = c_1$ e $MAC(H(k_{00}), c_1 || g^{x_1}) = t_1 $ e envia $c_1$, $t_1$ e $g^{x_1}$ para Bob. 137 | \item Bob gera $y_1$ e calcula $k_{10} = H(g^{x_1y_0})$ e $g^{y_1}$ e então manda $E(k_{10}, m_2) = c_2$, $g^{y_1}$, $MAC(H(k_{10}), c_2 || g^{y_1}) = t_2$ e $H(k_{00})$ para Alice. 138 | O ponto importante aqui é que $t_1$ já cumpriu seu papel e então sua chave pode ser transmitida pelo canal inseguro. 139 | \item Alice então pode esquecer (apagar) $x_1$ e gerar um novo $x_2$, caluclar $g^{x_2}$ e repitir todo o processo. 140 | \end{itemize} 141 | 142 | O {\em perfect foward secrecy} é garantido no processo de troca e esquecimento de chaves ({\em rechaveamento}). 143 | Já a {\em negação plausível} é ao se revelar a chave de do MAC e no uso de um esquema de criptografia maleável. 144 | 145 | Além de poder conferir manualmente o {\em fingerprint} dos usuários, a comunicação síncrona, pressoposta pelo protocolo, permite formas mais sofisticadas de certificação de chaves. 146 | Uma dessas formas é a implementação do protocolo do {\em milionário socialista} cuja descrição foge ao escopo dessas notas. 147 | 148 | \section{Signal} 149 | \label{sec:signal} 150 | 151 | O OTR foi concebido como um protocolo para criptografia ponta a ponta para comunicação síncrona. 152 | Os mensageiros modernos, porém, operam tipicamente de maneira assíncrona -- ou seja o usuário não precisa saber se a outra parte está ou não conectada na hora em que a mensagem é enviada. 153 | Essa característica traz alguns desafios particulares em termos de segurança. 154 | O protocolo do Signal (originalmente chamado de Axolotl) soluciona alguns desses problemas. 155 | 156 | Como seus antecessores, ele opera em duas fases: handshake e troca de mensagens. 157 | Quando o aplicativo é instalado, Alice gera uma chave permanente $A$ que fica armazenada no servidor responsável por distribui-la para seus contatos (no nosso exemplo Bob). 158 | Diferente do OTR, o handshake do Signal não usa assinaturas digitais e segue os seguintes passos.: 159 | \begin{itemize} 160 | \item Alice sorteia uma chave efêmera $a_0$ e envia $g^{a_0}$ para Bob. 161 | \item Bob sorteia uma chave efêmera $b_b$ e envia $g^{b_0}$ para Alice. 162 | \item Amabas as partes produzem três valores combinando suas chaves permanentes e efêmeras $g^{Ab_0}$, $g^{Ba_0}$ e $g^{a_0b_0}$. 163 | Esses valores alimentam um HKDF que gera uma chave $rk_0$ chamada de chave raiz ({\em root key}). 164 | \end{itemize} 165 | 166 | Essa forma de handshake dispensa a implementação delicada de assinaturas digitais e fortalece a negação plausível. 167 | Alice pode garantir a autenticidade pois apenas Bob poderia gerar $g^{Ba_0}$, mas ela não tem como provar isso pois $a_0$ é um valor aleatório que não tem qualquer conexão com sua identidade. 168 | 169 | No OTR o rechaveamento ocorre sempre que uma comunicação se completa, ou seja, Alice escreve para Bob e Bob responde para Alice. 170 | Caso Alice escreva múltiplas mensagens para Bob sem resposta, a mesma chave é usada. 171 | A solução {\em ad hoc} que o OTR oferece para essa limitação é forçar que Bob responda uma mensagem vazia depois de um número máximo de mensagens recebidas. 172 | O Signal resolve esse problema de uma forma mais elegante. 173 | 174 | A chave raiz alimenta o KDF para gerar uma {\em chain key} $ck$ que por sua vez alimenta um MAC para gerar uma chave mestra ({\em master key}) $mk$. 175 | A {\em master key}, por fim, alimenta o KDF e gera as chaves para criptografar $k$ e autenticar $k'$ a mensagem a ser enviada. 176 | Quando um ciclo de comunicação se fecha, a rechaveamos a raiz (exatamente como no OTR), mas quando a mesma parte envia mais de uma mensagem geramos uma nova {\em chain key} e esquecemos a anterior. 177 | As chaves mestras são armazenadas até que sua mensagem correspondente chegue (por isso as mensagem precisam ser numeradas), mas note que a partir delas não é possível derivar as chaves das próximas mensagens ou das mensagens anteriores. 178 | Esse esquema chama-se {\em ratchet}. 179 | 180 | Os servidores do Signal armazenam um número de {\em pré-chaves} $g^a$ para cada usuário para o caso em que um handshake ocorra quando eles estão offline. 181 | O modelo de certificação de chaves é chamado de {\em Trust On First Use} (TOFU): a primeira vez que o cliente $C$ se conecta com o servidor $S$ uma aviso é exibido e a identidade do servidor é salva em uma base de dados no cliente, assim as próximas conexões podem verificar a autenticidade da chave apenas verificando essa base. 182 | Esse é o modelo seguido pelo protocolo SSH. 183 | Alternativamente é possível verificar manualmente o {\em fingerprint} da chave. 184 | Por fim, as mensagens armazenadas no aparelho são criptografadas localmente com uma cifra de bloco AES e autenticação HMAC cujas chaves são geradas aleatóriamente e armazenadas também de maneira criptografada usando o PBKDF2. 185 | 186 | O protocolo do Signal foi originalmente implementado em um aplicativo open source de troca de SMS chamado Textsecure. 187 | Em 2014 o Textsecure incorporou a capacidade de envio de mensagens via internet e em 2015 mudou de nome para Signal. 188 | Em 2016 os desenvolvedores do Signal implementaram esse protocolo no Whatsapp. 189 | Além de ser um aplicativo de código aberto, o Signal se diferencia do Whatsapp por sua política de privacidade. 190 | Enquanto o aplicativo do Facebook se reserva o direito de usar os metadados da comunicação comercialmente, o Signal armazena o mínimo desses dados -- apenas a data e hora da instalação e a data e hora da última conexão. 191 | 192 | %\section{Telegram} 193 | %\label{sec:telegram} 194 | 195 | %\section{Blockchain} 196 | %\label{sec:blockchain} 197 | 198 | 199 | -------------------------------------------------------------------------------- /distribuicao-chaves.tex: -------------------------------------------------------------------------------- 1 | \chapter{Distribuição de Chaves} 2 | \label{cha:distribuicao-chaves} 3 | 4 | Todos os sistemas criptográficos que vimos até aqui são simétricos, ou seja, eles assumem que as partes compartilham um dado sigiloso que chamamos de {\em chave}. 5 | Discutimos como gerar chaves, mas não tratamos ainda de um problema central da criptograia: como distribuir as chaves. 6 | Nesta seção veremos dois modelos bastantes distintos, o primeiro pressupõe a existência de uma autoridade central capaz de assumir a tarefa, o segundo inaugura um novo paradigma de critpografia chamado {\em criptografia assimétrica} que será mais extensamente discutido nos próximos dois capítulos. 7 | 8 | \section{Centro de Distribuição de Chaves} 9 | \label{sec:kdc} 10 | 11 | No modelo de Centro de Distribuição de Chaves (KDC), cada usuário possui uma {\em chave permanente}. 12 | Essas chaves são gerenciadas por um administrador que centraliza a responsabilidade sobre a distribuição de chaves. 13 | As chaves são criadas pelo administrador que as entrega pessoalmente para cada usuário verificando sua identidade. 14 | Quando Alice quer se comunicar com Bob os seguintes passos são seguidos: 15 | 16 | \begin{enumerate} 17 | \item Alice faz uma requisição para o administrador de que pretende falar com Bob. 18 | \item O administrador gera uma chave efêmera $k$ para a comunicação e envia duas cópias para Alice, uma criptografada pela chave permanente de Alice $E(k_A, k)$ e uma criptografada com a chave permanente de Bob $E(k_B, k)$. 19 | \item Alice então encaminha $E(k_B, k)$ para Bob. 20 | \end{enumerate} 21 | 22 | \begin{center} 23 | \begin{tikzpicture}[node distance=2cm,auto,>=latex] 24 | \node (alice) at (0, 2){Alice}; 25 | \node (bob) at (10, 2) {Bob}; 26 | \node (servidor) at (5, 2) {Administrador}; 27 | 28 | \node (k1) at (0,0) {$k$}; 29 | \node (k2) at (10,-1) {$k$}; 30 | 31 | \path[->] (0,1) edge node[above]{$Id_B$} (5,1); 32 | \path[->] (5,0) edge node[above]{$E(k_A,k), E(k_B,k)$} (k1); 33 | \path[->] (0,-1) edge node[above]{$E(k_B,k)$} (k2); 34 | \end{tikzpicture} 35 | \end{center} 36 | 37 | Depois da conversa Alice deve descartar a chave efêmera e eventualmente pedir uma nova para o administrador quando precisar voltar a se comunicar com Bob. 38 | 39 | Uma implementação bastante popular do modelo KDC é o protocolo Kerberos\footnote{Uma apresentação compreensível do protocolo está disponível no livro de Paar e Pelzl \cite{Paar09} ou em uma aula gravada e disponível em: https://www.youtube.com/watch?v=iaH8UG2yMg4}. 40 | 41 | Além de pressupor a existência de um administrador confiável que gerencie todas as chaves permanentes, os modelo baseados em KDC possuem o que chamamos de {\em ponto único de falha}. 42 | Se o servidor do administrador sair do ar, por exemplo, todas as comunicações seguras ficarão impedidas. 43 | Ou seja, mesmo em um ambiente fechado e com hierarquia estabelecida, esse modelo não é ideal, em um ambiente aberto ele é totalmente inadequado. 44 | 45 | \section{Protocolo de Diffie-Hellman} 46 | \label{sec:diffie-hellman} 47 | 48 | Em um ambiente aberto não é realista imaginar que as partes podem encontrar o administrador de antemão. 49 | Surpreendentemente existem formas de trocar chaves que podem ser feitas diretamente pelas partes por meio de um canal inseguro. 50 | O esquema que mostraremos nesta seção é conhecido como {\em protocolo de Diffie-Hellman} e inaugura o paradigma revolucionário da {\em criptografia assimétrica} que veremos nos próximos capítulos \cite{Diffie76}. 51 | Informalmente, o protocolo funciona da seguinte forma: Alice envia um dado público para Bob e vice-versa, ao fim do processo ambas as partes são capazes de gerar um mesmo valor que pode ser usado em um KDF para gerar uma chave, porém, para um observador (Eva) que só teve acesso aos dados públicos, isso não é possível. 52 | Para explicar o protocolo precisamos definir o que são grupos, geradores e grupos cíclicos e precisamos apresentar o {\em problema do logaritmo discreto} cuja dificuldade é condição necessária -- apesar de insuficiente -- para a segurança do protocolo. 53 | 54 | Um {\em grupo} é uma estrutura algébrica $\mathbb{G} = \langle G, \circ \rangle$ em que $G$ é um conjunto e $\circ$ uma operação binária que satisfaz as seguintes propriedades: 55 | \begin{itemize} 56 | \item[] {\bf (fecho)} Se $f, g \in G$ então $f \circ g \in G$. 57 | \item[] {\bf (identidade)} Existe um elemento $1 \in G$ tal que $1 \circ f = f \circ 1 = f$ para todo $f \in G$. 58 | \item[] {\bf (inverso)} Para todo $g \in G$ existe $h \in G$ tal que $g \circ h = 1$ (é possível mostrar que $h$ é único para cada $g$ e, portanto, o denotaremos $g^{-1}$). 59 | \item[] {\bf (associatividade)} Para todo $f,g,h \in G$ temos que $(f \circ g) \circ h = f \circ (g \circ h)$. 60 | \end{itemize} 61 | 62 | Um grupo é dito {\em finito} se $G$ é finito, neste caso, $|G|$ é a {\em ordem} do grupo. 63 | Um grupo é {\em abeliano} se satisfaz o seguinte: 64 | \begin{itemize} 65 | \item[] {\bf (comutatividade)} Para todo $f, g \in G$ temos que $f \circ g = g \circ f$. 66 | \end{itemize} 67 | 68 | Diversas estruturas familiares como $\langle \mathbb{Z}, + \rangle$ e $\langle \mathbb{Q}^\star, \cdot \rangle$ são grupos abelianos, mas não são finitos. 69 | No próximo capítulo demonstraremos que certas estruturas são grupos finitos. 70 | Por ora vamos apenas apresentar um grupo finito como exemplo sem uma demonstração para esse fato: 71 | \begin{example} 72 | A estrutura $\langle \mathbb{Z}_p^\star, \cdot \rangle$ em que $p$ é primo, $\mathbb{Z}_p^\star = \{1, 2, \dots, p - 1 \}$ e a operação de multiplicação é calculada módulo $p$ é um grupo. 73 | \begin{multicols}{2} 74 | \begin{itemize} 75 | \item[] $1^{-1} \equiv 1\ mod\ 7$ 76 | \item[] $2^{-1} \equiv 4\ mod\ 7$ 77 | \item[] $3^{-1} \equiv 5\ mod\ 7$ 78 | \end{itemize} 79 | \begin{itemize} 80 | \item[] $4^{-1} \equiv 2\ mod\ 7$ 81 | \item[] $5^{-1} \equiv 3\ mod\ 7$ 82 | \item[] $6^{-1} \equiv 6\ mod\ 7$ 83 | \end{itemize} 84 | \end{multicols} 85 | \end{example} 86 | 87 | Nos será útil expressar a operação de {\em exponenciação} de um elemento do grupo $g \in G$ em relação a um inteiro positivo $m$: 88 | \begin{displaymath} 89 | g^m := \underbrace{g \circ \dots \circ g}_m 90 | \end{displaymath} 91 | 92 | 93 | \begin{theorem} 94 | \label{theo:gen-euler} 95 | Seja $\mathbb{G} = \langle G, \circ \rangle$ um grupo abeliano finito e $m = |G|$, então para qualquer $g \in G$ temos que $g^m = 1$. 96 | \end{theorem} 97 | \begin{proof} 98 | Note que se $g \circ g_i = g \circ g_j$ então $g_i = g_j$ (basta multiplicar ambos os lados por $g^{-1}$). 99 | Assim temos que $\{(g \circ g_1), \dots, (g \circ g_m)\} = G$, porque todos os elementos do conjunto da esquerda são elementos de $G$ e são distintos. 100 | O seja: 101 | 102 | \begin{eqnarray*} 103 | g_1 \circ \dots \circ g_m & = & (g \circ g_1) \circ \dots \circ (g \circ g_m)\\ 104 | & = & g^m \circ (g_1 \circ \dots \circ g_m) 105 | \end{eqnarray*} 106 | Multiplicando ambos os lados pelo inverso de $g_1 \circ \dots \circ g_m$ temos que $g^m = 1$. 107 | \end{proof} 108 | 109 | Se $\mathbb{G} = \langle G, \circ \rangle$ é um grupo finito e $g \in G$ então definimos o conjunto dos elementos {\em gerados} por $g$ da seguinte forma: 110 | 111 | \begin{displaymath} 112 | \langle g \rangle := \{g^0, g^1, \dots \} 113 | \end{displaymath} 114 | 115 | A {\em ordem} de um elemento $g \in G$ é o menor $i$ tal que $g^i = 1$. 116 | Pelo teorema anterior temos que $i \leq |G|$ e, portanto, se $G$ é finito, $\langle g \rangle$ é sempre finito. 117 | Um grupo é chamado de {\em cíclico} se existe um elemento $g$, chamado de {\em gerador} cuja ordem é $|G|$. 118 | Ou seja, em um grupo cíclico temos que $\langle g \rangle = G$ para algum $g$. 119 | 120 | Se $\mathbb{G}$ é um grupo cíclico e $g$ é um gerador então para qualquer $h \in G$ existe um inteiro $x$ tal que $g^x = h$. 121 | Dizemos que $x$ é o {\em logaritmo} de $h$ na base $g$. 122 | 123 | 124 | \begin{example} 125 | Considere o grupo $\langle \mathbb{Z}_7^\star, \cdot \rangle$: 126 | \begin{itemize} 127 | \item $\langle 2 \rangle = \{1, 2, 4\}$. A ordem de $2$ é $3$ e, portanto, $2$ não é um gerador de $\mathbb{Z}_7^\star$. 128 | Além disso, neste grupo $log_2(1) = 0$, $log_2(2) = 1$ e $log_2(4) = 2$. 129 | \item $\langle 3 \rangle = \{1, 3, 2, 6, 4, 5\}$. A ordem de $3$ é $6$, portanto $3$ é um gerador de $\mathbb{Z}_7^\star$ e o grupo é cíclico. 130 | Além disso, neste grupo $log_3(1) = 0$, $log_3(2) = 2$ e $log_3(3) = 1$, $log_3(4)= 4$, $log_3(5) = 5$ e $log_3(6) = 3$. 131 | \end{itemize} 132 | \end{example} 133 | 134 | 135 | O {\em protocolo de Diffie-Hellman} que funciona da seguinte maneira: 136 | \begin{enumerate} 137 | \item Alice roda $\mathcal{G}(1^n)$ para gerar um grupo cíclico $\mathbb{G}$ e um gerador $g$ 138 | \item Alice sorteia $x \leftarrow \mathbb{Z}_n$ e computa $h_A = g^x$ usando o algoritmo eficiente de exponenciação 139 | \item Alice envia $\mathbb{G}$, $g$ e $h_A$ para Bob 140 | \item Bob sorteia $y \leftarrow \mathbb{Z}_n$, computa $h_B = g^y$ e envia para Alice. 141 | \item Ao fim do processo Alice computa $h_B^x = (g^y)^x = g^{xy}$ e Bob computa $h_A^y = (g^x)^y = g^{xy}$. 142 | \end{enumerate} 143 | 144 | Ao fim do procedimento tanto Alice, quanto Bob são capazes de produzir $g^{xy}$, a primeira porque possui $x$ e $g^y$ e o segundo porque possui $y$ e $g^x$. 145 | Quem observa a comunicação, porém, só possui $g^x$ e $g^y$. 146 | Caso esse observador seja capaz de calcular o $log_g(g^x) = x$ então ele seria capaz de quebrar o protocolo. 147 | O ataque força bruta neste caso seria testar todos os valores possíveis de $x$ até encontar o correto. 148 | Este ataque é linear no valor de $x$, mas é exponencial no tamanho de $x$ (note que para escrever o número $x$ em notação binária usamos espaço proporcional a $log_2(x)$). 149 | 150 | Porém, quando Bob calcula $(g^{y})^x$ ele pode usar um algoritmo muito mais eficiente, um que é linear no tamanho de $x$. 151 | A maneira ingênua de calcular a exponenciação se baseia no seguinte invariante: 152 | \begin{displaymath} 153 | g^m = g^{m-1} \circ g 154 | \end{displaymath} 155 | Com isso reduzimos o problema a um problema um pouco mais simples e paramos quando $m = 0$, pois neste caso $g^0 = 1$. 156 | Essa constatação dá origem ao seguinte algoritmo: 157 | 158 | \begin{codebox} 159 | \Procname{$\proc{Exp}(g, m)$} 160 | \li \Comment Recebe $g \in \mathbb{G}$ e $m \in \mathbb{N}$ 161 | \li \Comment Devolve $g^m$ 162 | \li \If $m = 0 $ 163 | \li \Then \Return $1$ 164 | \End 165 | \li \Return $\proc{Exp}(g, m-1) \circ g$ 166 | \End 167 | \end{codebox} 168 | 169 | Podemos estimar o tempo de $\proc{Exp}$ resolvendo a seguinte recorrência: 170 | 171 | \begin{eqnarray*} 172 | T(m) & = & T(m - 1) + \Theta(1)\\ 173 | T(1) & = & \Theta(1) 174 | \end{eqnarray*} 175 | 176 | Não é difícil mostrar que $T(m) = \Theta(m)$. 177 | Ou seja, esse algoritmo é linear em relação a $m$ e exponencial em relação ao tamanho de $m$. 178 | 179 | Podemos fazer bem melhor do que isso usando o seguinte invariante: 180 | \begin{displaymath} 181 | g^m = \left\{ 182 | \begin{array}{lcl} 183 | g^{\lfloor \frac{m}{2} \rfloor} \circ g^{\lfloor \frac{m}{2} \rfloor} & \textrm{se} & m \textrm{ é par}\\ 184 | g^{\lfloor \frac{m}{2} \rfloor} \circ g^{\lfloor \frac{m}{2} \rfloor} \circ g & \textrm{se} & m \textrm{ é ímpar}\\ 185 | \end{array} 186 | \right. 187 | \end{displaymath} 188 | 189 | Esse invariante produz o seguinte algoritmo: 190 | \begin{codebox} 191 | \Procname{$\proc{FastExp}(g, m)$} 192 | \li \Comment Recebe $g \in \mathbb{G}$ e $m \in \mathbb{N}$ 193 | \li \Comment Devolve $g^m$ 194 | \li \If $m = 0 $ 195 | \li \Then \Return $1$ 196 | \End 197 | \li $x \gets \proc{FastExp}(g, \lfloor \frac{m}{2} \rfloor)$ 198 | \li \If $m$ é par 199 | \li \Then \Return $x \circ x$ 200 | \li \Else \Return $x \circ x \circ g$ 201 | \End 202 | \end{codebox} 203 | 204 | 205 | Estimamos o tempo de $\proc{FastExp}$ resolvendo a seguinte recorrência: 206 | 207 | \begin{eqnarray*} 208 | T(m) & = & T(\lfloor \frac{m}{2} \rfloor) + \Theta(1)\\ 209 | T(1) & = & \Theta(1) 210 | \end{eqnarray*} 211 | 212 | Vimos no curso de Introdução à Análise de Algoritmos que $T(m) = \Theta(log_2(m))$. 213 | Em outras palavras, o problema da exponenciação pode ser resolvido lineramente no tamanho da entrada. 214 | 215 | \begin{example} 216 | Simularemos a execução de $\proc{FastExp}(2, 10)$ em $\langle \mathbb{Q}, \cdot \rangle$. 217 | \begin{displaymath} 218 | \begin{array}{ll} 219 | FastExp(2, 10) = x \cdot x = 2^{10} & x = FastExp(2, 5) = 2^5 \\ 220 | FastExp(2, 5) = x \cdot x \cdot 2 = 2^5 & x = FastExp(2, 2) = 2^2\\ 221 | FastExp(2, 2) = x \cdot x = 2^2 & x = FastExp(2, 1) = 2\\ 222 | FastExp(2, 1) = x \cdot x \cdot 2 = 2 & x = FastExp(2, 0) = 1\\ 223 | FastExp(2, 0) = 1 \\ 224 | \end{array} 225 | \end{displaymath} 226 | \end{example} 227 | 228 | O {\em problema do logaritmo discreto} pode ser descrito pelo seguinte jogo: 229 | \begin{enumerate} 230 | \item O sistema recebe o parâmetro de segurança $1^n$ e usa $\mathcal{G}$ para gerar um grupo cíclico $\mathbb{G} = \langle G, \circ \rangle$ com gerador $g$ e ordem $n$ 231 | \item O sistema escolhe $h \leftarrow G$ e manda para o adversário $\mathbb{G}$, $g$ e $h$. 232 | \item O adversário produz $x \in \mathbb{Z}_n$ 233 | \end{enumerate} 234 | 235 | O desafio do adversário é produzir $x$ tal que $g^x = h$. 236 | Ou seja: 237 | \begin{displaymath} 238 | DLog_{\mathcal{A}, \mathcal{G}}(n) = \left\{ 239 | \begin{array}{lcl} 240 | 1 & \textrm{se} & g^x = h\\ 241 | 0 & \textrm{c.c.} &\\ 242 | \end{array} 243 | \right. 244 | \end{displaymath} 245 | 246 | Dizemos que o {\em problema do logaritmo discreto é difícil} se para todo adversário eficiente $\mathcal{A}$ existe uma função desprezível $\varepsilon$ tal que: 247 | \begin{displaymath} 248 | Pr[DLog_{\mathcal{A}, \mathcal{G}}(n) = 1] \leq \varepsilon(n) 249 | \end{displaymath} 250 | 251 | A dificuldade do problema do logaritmo discreto é condição necessária, porém insuficiente, para a segurança do protocolo de Diffie-Hellman. 252 | Algumas estruturas matemáticas são adequadas para produzir grupos cíclicos cujo problema do logaritmo discreto é considerado difícil. 253 | Duas muito usadas na prática são os {\em resíduos quadráticos de grupos de tamanho primo} e as {\em curvas elípticas} (Apêndice \ref{cha:ciclicos}). 254 | 255 | Caso o problema do logaritmo discreto não seja difícil, Eva seria capaz de produzir $x$ e $y$ a partir de $g^x$ e $g^y$ e descobrir o valor de $g^{xy}$. 256 | Se o sistema for seguro, porém, o melhor que Eva pode fazer é tentar todos os valores de $\mathbb{Z}_n$ até encontrar $x$ ou $y$. 257 | Escolhendo grupos de ordem suficientemente grande, essa tarefa é computacionalmente inviável. 258 | Uma vez que as partes possuem o mesmo valor secreto, elas podem utilizá-lo para alimentar um KDF e gerar chaves para um sistema de criptografia simétrico. 259 | 260 | No modelo, assumimos que o grupo e o gerador são criados sempre que as partes decidem se comunicar. 261 | Na prática o mais comum é que esses parâmetros sejam definidos pelo protocolo e reutilizados em todas as comunicações. 262 | Isso não deve afetar de nenhuma forma na segurança do sistema. 263 | 264 | O protocolo de Diffie-Hellman permite às partes compartilharem uma chave secreta sem a necessidade de se encontrarem pessoalmente, ou de confiarem em alguma autoridade que as encontrou separadamente. 265 | Note que o protocolo não garante que as partes saibam se a chave que receberam foi de fato enviada por quem eles imaginam que as enviou. 266 | No Capítulo \ref{cha:assinaturas-digitais} voltaremos a este problema chamado de {\em ataque Man In The Middle}. 267 | 268 | \section{Exercícios} 269 | %\label{sec:exercicios} 270 | 271 | \begin{exercicio} 272 | Mostre que se $n|a$ e $n|b$ então para quaisquer $r$ e $s$ temos que $n|(a \cdot r + b \cdot s)$. 273 | \end{exercicio} 274 | 275 | \begin{exercicio} 276 | \label{ex:grupo} 277 | Considere a estrutura $\langle \mathbb{Z}_{12}, \cdot \rangle$ em que a multiplicação é calculada módulo 12. 278 | Mostre que $6$ não possui inverso nesta estrutura e, portanto, ela não é um grupo. 279 | \end{exercicio} 280 | 281 | \begin{exercicio} 282 | Considere as estruturas $\langle \mathbb{Z}_n, + \rangle$ formadas pelo conjunto $\mathbb{Z}_n := \{0, \dots, n-1\}$ e a operação de soma ($+$) módulo $n$. 283 | Mostre essa estrutura é um grupo cíclico para qualquer valor de $n \geq 1$ e que o número $1$ é sempre um gerador nesses grupos. (Dica: Você precisa mostrar que a operação satisfaz fecho, associatividade, possui elemento neutro e inverso. Depois você deve mostrar que o elemento $1$ gera todos os elementos do grupo.) 284 | 285 | Por que o grupo $\langle \mathbb{Z}_n, +\rangle$ não é um bom candidato para ser usado no protocolo de Diffie-Hellmann. 286 | \end{exercicio} 287 | 288 | \begin{exercicio} 289 | Descreva um ataque força-bruta contra o protocolo de Diffie-Hellman. 290 | Em termos assintóticos em relação ao tamanho da entrada, qual é o consumo de tempo deste ataque? 291 | \end{exercicio} 292 | -------------------------------------------------------------------------------- /cifras-fluxo.tex: -------------------------------------------------------------------------------- 1 | \chapter{Cifras de Fluxo} 2 | \label{cha:cifras-de-fluxo} 3 | 4 | No capítulo anterior apresentamos uma definição formal para segurança contra ataques em que o adversário tem acesso apenas ao texto cifrado. 5 | Neste capítulo vamos apresentar uma forma de construir um sistema que satisfaz essa definição. 6 | A ideia geral da construação é a seguinte: partimos de uma sequência aleatória de bits chamado de {\em semente} e a partir dela geramos uma sequência maior de bits a ser usada para encriptar a mensagem usando o ou exclusivo como no OTP. 7 | Apesar desta sequência ser gerada de maneira determinística, a segurança do sistema depende do fato de que ela se pareça aleatória. 8 | Informalmente, um {\em gerador de números pseudoaleatórios} (PRG) é essa função que recebe uma semente aleatória e a expande em uma sequência com cara de aleatória. 9 | 10 | Sistemas de cifra de fluxo foram estudados extensamente nos anos 80 \cite{Blum84,Yao82}. 11 | A abordagem para verificar se o gerador de números pseudoaleatórios é suficientemente forte consistia em aplicar uma série de testes estatísticos na sequência gerada para tentar distinguí-lo de uma sequência aleatória. 12 | Assim, por exemplo, um teste pode verificar se a probabilidade de o primeiro bit da sequência ser igual $1$ é $\frac{1}{2}$ ou que a probabilidade de ocorrência de pelos menos três $0$s em qualquer subsequência de tamanho $4$ deve ser $\frac{5}{16}$ -- existem uma sequência em que o $0$ ocorre quatro vezes e mais quatro sequências possíveis em que ele ocorre três vezes. 13 | Um teste recebe uma sequencia produzida por um PRG e deve retornar $1$ se o passar e $0$ se falhar. 14 | O objetivo do teste é distinguir as sequências de bits produzidas por um PRG de uma sequência realmente aleatória. 15 | Por este motivo, esses testes são chamados {\em distinguidores}. 16 | 17 | Uma bateria de distinguidores pode ser usada para verificar a qualidade de um PRG. 18 | Idealmente nenhum teste eficiente deveria ser capaz de distinguir o PRG de uma sequência aleatória, ou pelo menos incapaz de fazê-lo com probabilidade considerável\footnote{Usaremos o termo considerável para probabilidades não despreziveis.}. 19 | Definiremos um gerador de números pseudo-aleatórios como um algoritmo $G$ que recebe uma semente $s$ de tamanho $n$ e produz $G(s)$ de tamanho $l(n)$ onde $l$ é um polinômio que define o {\em fator de expansão} do PRG -- quão maior é a sequência produzida em relação a semente -- e tal que nenhum algoritmo polinomial $D$ é capaz de distinguir $G(s)$ de um sequencia $r$ escolhida aleatóriamente em $\{0,1\}^{l(n)}$ com probabilidade não desprezível. 20 | Formalmente temos o seguinte: 21 | 22 | 23 | \begin{definition} 24 | Seja $l$ um polinômio e $G$ um algoritmo determinístico polinomial que recebe $s \in \{0,1\}^n$ e retorna $G(s) \in \{0,1\}^{l(n)}$ e seja $r \leftarrow \{0,1\}^{l(n)}$. 25 | O algoritmo $G$ é um {\em gerador de números pseudo-aleatórios} se: 26 | \begin{enumerate} 27 | \item $l(n) > n$ para todo $n$ e 28 | \item para todo algoritmo polinomial $D$ existe uma função desprezível $\varepsilon$ tal que: 29 | \begin{displaymath} 30 | |Pr[D(r) = 1] - Pr[D(G(s)) = 1]| \leq \varepsilon(n) 31 | \end{displaymath} 32 | \end{enumerate} 33 | \end{definition} 34 | 35 | 36 | \begin{example} 37 | Considere um algoritmo $G$ que recebe $s \in \{0,1\}^n$ e devolve $0^{l(n)}$. 38 | Certamente $G$ não é um PRG e podemos mostrar isso com um distinguidor $D$ que recebe $w \in \{0,1\}^{l(n)}$ e devolve $1$ se $w = 0^{l(n)}$ e $0$ caso contrário. 39 | É fácil ver que para $r \leftarrow \{0,1\}^{l(n)}$ e $s \leftarrow \{0,1\}^n$ temos que $Pr[D(r) = 1] = \frac{1}{2^{l(n)}}$ e $Pr[D(G(s)) = 1] = 1$ e, portanto, temos que: 40 | \begin{displaymath} 41 | |Pr[D(r) = 1] - Pr[D(G(s)) = 1]| = 1 - \frac{1}{2^{l(n)}} 42 | \end{displaymath} 43 | 44 | \end{example} 45 | 46 | 47 | A restrição de que o distinguidor seja eficiente é extritamente necessária. 48 | Em particular é sempre possível construir um distinguidor usando uma espécie de ataque de força bruta. 49 | Dado uma sequência $w$, o algoritmo $D$ testa todos as possíveis sementes $s$, verifica se $G(s) = w$ e devolve $1$ caso essa semente exista e $0$ se todas falharem. 50 | Esse teste é eficaz pois $Pr[D(G(s)) = 1] = \frac{1}{2^n}$, mas $Pr[D(r) = 1] = \frac{1}{2^{l(n)}}$ -- existem muito menos sequências em $\{0,1\}^{l(n)}$ geradas por alguma semente do que geradas aleatóriamente. 51 | Porém, o teste não é eficiente. 52 | De fato o tempo esperado para testar todos os valores de $s$ é exponencial, mais precisamente $2^{n-1}$. 53 | 54 | \section{Segurança das Cifras de Fluxo} 55 | \label{sec:streamcipher-sec} 56 | 57 | Como adiantamos no capítulo anterior, uma vez definida claramente a suposição que estamos fazendo podemos tentar provar que com essa suposição somos capazes de construir um sistema seguro. 58 | A abordagem para este tipo de prova é uma redução aos moldes das reduções que vimos em Teoria da Computação. 59 | Neste caso vamos reduzir o problema de construir um sistema seguro contra ataques {\em ciphertext only} ao problema de construir um PRG. 60 | 61 | 62 | \begin{theorem} 63 | \label{theo:stream} 64 | Se $G$ é um gerador de números pseudo-aleatórios com fator de expansão $l$ então o seguinte sistema $\Pi = \langle Gen, E, D \rangle$ é seguro contra ataques {\em ciphertext only} para mensagens de tamanho fixo $m \in \{0,1\}^{l(n)}$: 65 | \begin{itemize} 66 | \item $Gen(1^n) := k \leftarrow \{0,1\}^n$ 67 | \item $E(k,m) = G(k) \xor m$ 68 | \item $D(k,c) = G(k) \xor c$ 69 | \end{itemize} 70 | \end{theorem} 71 | \begin{proof} 72 | Seja $\mathcal{A}$ um algoritmo polinomial. 73 | Construiremos um distinguidor $D$ que recebe um string $w \in \{0,1\}^{l(n)}$ e faz o seguinte: 74 | \begin{itemize} 75 | \item Roda $\mathcal{A}(1^n)$ para obter o par de mensagens $m_0, m_1 \in \{0,1\}^{l(n)}$ 76 | \item Escolhe $b \leftarrow \{0,1\}$ e computa $c = w \xor m_b$. 77 | \item Entrega $c$ para $\mathcal{A}$ e devolve $1$ se o resultado for igual a $b$ e $0$ caso contrário. 78 | \end{itemize} 79 | 80 | Pela definição, $D$ devolve $1$ exatamente nas mesmas situações em que $\mathcal{A}$ vence o desafio. 81 | Portanto temos que: 82 | \begin{displaymath} 83 | Pr[D(G(k)) = 1] = Pr[PrivK^{eav}_{\Pi, \mathcal{A}}(n) = 1] 84 | \end{displaymath} 85 | 86 | Além disso, sendo $\Pi'$ o sistema do OTP e $w \leftarrow \{0,1\}^{l(n)}$ temos que: 87 | \begin{displaymath} 88 | Pr[D(w) = 1] = Pr[PrivK^{eav}_{\Pi', \mathcal{A}}(n)] = \frac{1}{2} 89 | \end{displaymath} 90 | 91 | Como $G$ é um PRG temos que existe uma função desprezível $\varepsilon$ tal que $|Pr[D(G(k)) = 1] - Pr[D(w) = 1]| \leq \varepsilon(n)$ e, portanto: 92 | \begin{displaymath} 93 | |Pr[PrivK^{eav}_{\Pi, \mathcal{A}}(n) = 1] - \frac{1}{2}| \leq \varepsilon(n) 94 | \end{displaymath} 95 | 96 | Ou equivalentemente: 97 | \begin{displaymath} 98 | Pr[PrivK^{eav}_{\Pi, \mathcal{A}}(n) = 1] \leq \frac{1}{2} + \varepsilon(n) 99 | \end{displaymath} 100 | \end{proof} 101 | 102 | Algoritmos validados empiricamente como bons PRG podem ser usados portanto para gerar cifras seguras, ao menos contra ataques {\em ciphertext-only}. 103 | Nos próximos capítulos exploraremos definições mais fortes de segurança e suas respectivas suposições. 104 | Para fechar este capítulo lembramos que as cifras de fluxo sofrem do mesmo problema do OTP quanto à repetição do uso de uma mesma chave. 105 | 106 | \section{Modos de Operação} 107 | \label{sec:modos-de-operacao} 108 | 109 | Há uma pequena distância entre o resultado do Teorema \ref{theo:stream} e as aplicações práticas das cifras de fluxo da seção \ref{sec:lfsr}, pois o resultado do teorema vale apenas para mensagens de tamanho fixo previamente conhecido. 110 | Em todas situações práticas estamos interessados em criptografar cifras de tamanho arbitrário. 111 | Há duas possíveis soluções para este problema, dois {\em modos de operação} para as cifras de fluxo: síncrono e assíncrono. 112 | 113 | Tipicamente, um PRG é formado por um par de algoritmos $\langle Init, GenBits \rangle$. 114 | O primeiro recebe a semente $s$ como entrada e opcionalmente um vetor inicial $IV$ (ver seção seguinte) e devolve um estado inicial $st_0$. 115 | O segundo algoritmo recebe como entrada o estado atual $st_i$, devolve um bit $y$ e atualiza o estado para $st_{i+1}$. 116 | Para cada semente, então, o algoritmo produz um {\em fluxo} de bits -- sendo os $l(n)$ primeiros bits geram $G(s)$. 117 | 118 | No modo {\em síncrono} consideramos uma sequência de mensagens $m_0, m_1, \dots$ como uma única grande mensagem $m$. 119 | O algoritmo $Init(s)$ gera o estado inicial $st_0$ e a cada comunicação $GetBits$ parte do estado anterior e gera os bits necessários para encriptar a nova parte da mensagem enviada na comunicação. 120 | A limitação desta abordagem é que as partes precisam mater o estado atual sincronizado, ou seja, quando Alice atualiza $st$, Bob precisa atualizar também. 121 | 122 | O outro modo é {\em assíncrono}. 123 | Neste assumimos que além da semente $s$ a algoritmo $G$ recebe uma sequência de bits chamada {\em vetor inicial} $IV$. 124 | O vetor inicial não é sigiloso, mas deve mudar cada vez que uma nova mensagem é criptografada. 125 | Desta forma garantimos que a sequência produzida por $G$ com a mesma chave seja distinta e assim impedimos que ataques de repetição de chaves como mostramos no Capítulo \ref{cha:sigilo-perfeito}. 126 | 127 | % CITAR OS ARTIGOS QUE APRESENTAM O TRIVIUM, O RC4 E O ATAQUE CONTRA O WEP 128 | 129 | \begin{example} 130 | O Wired Equivalent Privacy (WEP) era o padrão para segurança em conexões WiFi desde 97 e é essencialmene uma cifra de fluxo que opera de modo assíncrono. 131 | Para gerar um fluxo de bits pseudo-aleatórios o WEP utiliza o RC4 \cite{Rivest16} -- um PRG proposto por Ron Rivest em 87 -- que recebe como entrada a semente de 40 ou 104 bits e um vetor inicial não sigiloso de 24 bits. 132 | Para cada pacote transimitido, o WEP gera um novo $IV$ e utiliza a mesma chave para criptografar seu conteúdo. 133 | Acontece que 24 bits é um tamanho consideravelmente pequeno e se repete com 50\% de chance a cada 5000 pacotes tornando-o completamente inseguro \cite{Fluhrer01}. 134 | 135 | Hoje em dia, um script que implementa este tipo de ataque chamado {\tt aircrack-ng}\footnote{http://www.aircrack-ng.org/} é capaz de quebrar uma senha WEP usando uma computador pessoal em questão de minutos. 136 | Esse tipo de vulnerabilidade do protocolo WEP levou-o a ser substituído em pelo protocolo WPA e em seguida pelo WPA2 entre 2004 e 2006. 137 | \end{example} 138 | 139 | \section{Construções Práticas} 140 | \label{sec:construcoes-praticas} 141 | 142 | A existência de PRGs não foi demonstrada matematicamente. 143 | No Apêndice \ref{cha:owf} mostraremos porque é tão difícil encontrar uma PRG demonstradamente seguro. 144 | O importante por enquanto é que é difícil demonstrar a segurança de um sistema e, portanto, a abordagem utilizada em relação a PRG é empírica. 145 | Ou seja, os candidatos a PRG são empiricamente validados a cada tentativa frustrada de construir um distinguidor para eles. 146 | 147 | 148 | \subsection{Linear-Feedback Shift Registers} 149 | \label{sec:lfsr} 150 | 151 | Uma classe de exemplos deste tipo de algoritmo são os chamados {\em Linear-Feedback Shift Registers} (LFSRs). 152 | Um LFSR consiste de um vetor de registradores $s_{n-1} \dots s_0$, que guardam exatamente um bit cada, e uma sequência de bits $c_{n-1} \dots c_0$ chamada {\em coeficientes de feedback}. 153 | A cada passo o estado é atualizado deslocando todo vetor uma posição para a direita e produzindo um novo bit que é calculado como 154 | \begin{displaymath} 155 | s_{n-1} := \bigoplus_{i=0}^{n-1}c_is_i 156 | \end{displaymath} 157 | 158 | \begin{example} 159 | Considere um LFSR com quatro registradores sendo o primeiro e o terceiro parte do coeficiete de feedback. 160 | Se a configuração inicial dos registradores é $\langle 0,0,1,1 \rangle$ os próximos passos são os seguintes: 161 | \begin{displaymath} 162 | \langle 0,0,1,1 \rangle \vdash 163 | \langle 1,0,0,1 \rangle \vdash 164 | \langle 1,1,0,0 \rangle \vdash 165 | \langle 1,1,1,0 \rangle \vdash 166 | \langle 1,1,1,1 \rangle 167 | \end{displaymath} 168 | \end{example} 169 | 170 | Um LSFR com $n$ registradores é capaz de gerar no máximo $2^n$ bits até começar a repetir sua sequência. 171 | Bons LFSR são aqueles que geram a maior quantidade de bits antes de começar a repetir -- essa quantidade de bits é chamada de {\em tamanho do ciclo}. 172 | 173 | O segredo do LFSR, sua ``chave'', é a semente $s_{n-1} \dots s_0$ -- lembrem que assumimos que o mecanismo (neste caso os coeficiente de feedback) são sempre conhecidos. 174 | Um ataque relativamente simples a um LFSR consiste em observar os $n$ primeiros bits gerados $y_{n+1} \dots y_{2n}$ e resolver o seguinte sistema linear: 175 | 176 | \begin{eqnarray*} 177 | y_{n+1} & = & c_{n-1}y_n \xor \dots \xor c_0 y_1\\ 178 | & \vdots & \\ 179 | y_{2n} & = & c_{n-1}y_{2n-1} \xor \dots \xor c_0 y_n\\ 180 | \end{eqnarray*} 181 | 182 | 183 | É possível mostrar que essas equações são linearmente independentes e, portanto, elas determinam unicamente os coefientes. 184 | Uma vez determinados os valores $y_0 \dots y_n = s_0 \dots s_n$, podemos prever cada novo bit da sequência. 185 | Com isso torna-se simples a tarefa de construir um distinguidor para o gerador. 186 | 187 | Resumindo, o LFSR não é seguro pois a operação que gera novos bits é linear, o que permite que ela seja previsível. 188 | LFSRs não são PRG seguros, mas muitos PRGs nada mais são do que versões alteradas deste esquema geral. 189 | Tipicamente os PRGs usados na prática substituem a operação de ou exclusivo por alguma operação não linear. 190 | 191 | \subsection{Trivium} 192 | \label{sec:trivium} 193 | 194 | Em um concurso científico de 2008 para produção de cifras de fluxo seguras, uma série de algoritmos foram apresentados como alternativas seguras e eficientes para este problema. 195 | Um dos algoritmos selecionados pelo projeto eSTREAM é o {\em Trivium} \cite{DeCanniere06}. 196 | Este algoritmo recebe dois valores como entrada ambos com 80 bits, a semente e o vetor incial. 197 | Um estado no Tivium é um vetor com 288 bits e seu ciclo tem tamanho $2^{64}$, ou seja, $Triv: \{0,1\}^{80}\times \{0,1\}^{80} \to \{0,1\}^{2^{64}}$. 198 | 199 | O Trivium possui três registradores A, B e C de tamanhos de 93, 84 e 111 respectivamente, somando 288 bits. 200 | Em cada passo cada registrador: 201 | \begin{enumerate} 202 | \item calcula o AND do penúltimo com o ante-penúltimo bit e calcula o XOR do bit resultante com o último bit e com mais um bit de uma certa posição fixa chamado {\em feedfoward bit} para produzir um bit chamado {\em bit de saída}, 203 | \item o bit de saída é enviado para o registrador adjacente -- A envia para B, B para C e C para A, 204 | \item cada registrador move seus bits uma posição para a direita, como no LFSR, 205 | \item cada registrador aplica o XOR do bit que recebeu com um bit de uma certa posição fixa, chamado {\em feedbackward bit}, e insere bit resultante na primeira posição e, por fim, 206 | \item calcula-se o XOR dos três bits de saída para produzir um bit do fluxo. 207 | \end{enumerate} 208 | 209 | A chave do Trivium é inserida nas primeiras posições do registrador A, e o vetor inicial nas úlitmas posições do registrador B. 210 | As demais posições são preenchidas com $0$ excetos as últimas três do registrador C que são preenchidas com $1$. 211 | Antes de começar a produzir o fluxo de bits, o processo roda $4 \times 288 = 1152$ no que é chamado de {\em fase de aquecimento}. 212 | Até a escrita destas notas, não existem ataques conhecidos ao algoritmo mais eficientes do que o ataque de força-bruta. 213 | 214 | 215 | \begin{figure} 216 | \centering 217 | \includegraphics[width=.5\textwidth]{imagens/trivium.png} 218 | \caption{Estrutura circular do Trivium} 219 | \end{figure} 220 | 221 | 222 | A escolha de um bom gerador de números pseudo-aleatórios é central para a segurança de uma cifra de fluxo. 223 | Um erro típico é utilizar funções padrão, como a função {\tt rand} da biblioteca padrão do {\tt C}, que não são adequadas para aplicações de segurança. 224 | A orientação geral é buscar os geradores selecionados pelo projeto eSTREAM como o Trivium mencionado nesta seção ou o SALSA20. 225 | 226 | 227 | \section{Exercicios} 228 | \label{sec:exercicios} 229 | 230 | \begin{exercicio} 231 | O que precisamos assumir para que um sistema de criptografia baseado em cifra de fluxo seja seguro? 232 | 233 | Em que sentido podemos considerá-lo seguro? 234 | \end{exercicio} 235 | 236 | \begin{exercicio} 237 | Mostre que o gerador $G$ com fator de expansão $l(n) = n + 1$ que recebe $s \in \{0,1\}^n$ e devolve $s$ concatenado com $\bigoplus_{i=0}^ns_i$ não é um PRG. 238 | \end{exercicio} 239 | 240 | \begin{exercicio} 241 | Construa um dintinguidor eficiente $D$ para o LFSR simples. 242 | \end{exercicio} 243 | 244 | \begin{exercicio} 245 | Por que em uma cifra de fluxo não podemos criptografar duas mensagens distintas com a mesma chave? 246 | \end{exercicio} 247 | 248 | \begin{exercicio} 249 | Sejam $y_0, y_1, y_2 \dots$ os bits gerados pelo algoritmo RC4. 250 | É possível mostrar que para uma distribuição uniforme de sementes e vetores iniciais, a probabilidade dos bits $y_9, \dots, y_{16}$ serem todos iguais a $0$ é $\frac{2}{256}$. 251 | Mostre como construir um algoritmo eficiente $D$ capaz de distinguir as sequências de bits produzidas pelo RC4 de uma sequência realmente aleatória. 252 | \end{exercicio} 253 | 254 | \begin{exercicio} 255 | Considere a seguinte implementação de uma cifra de fluxo: 256 | \begin{enumerate} 257 | \item Utilizamos o número de segundos desde primeiro de janeiro de 1970 até o momento atual para gerar uma semente $s$ que armazenamos em um local seguro. 258 | \item Utilizamos, então, a implementação {\tt rand} da biblioteca padrão do {\tt C} para gerar uma sequência de $n$ bits $G(s)$. 259 | \item Produzimos a cifra $c = G(s) \xor m$ supondo que $|m| = n$. 260 | \item Para descriptografar recuperamos $s$, aplicamos $G(s) \xor c$. 261 | \end{enumerate} 262 | 263 | Descreva duas vulnerabilidades deste protocolo. 264 | \end{exercicio} 265 | 266 | 267 | -------------------------------------------------------------------------------- /criptografia-assimetrica.tex: -------------------------------------------------------------------------------- 1 | \chapter{Criptografia Assimétrica} 2 | \label{cha:criptografia-assimetrica} 3 | 4 | Concluímos o capítulo anterior apresentando um protocolo de troca de chaves que não requer que as partes se encontrem pessoalmente -- ou com um terceiro confiável -- em nenhum momento. 5 | Essa ideia revolucionária foi proposta inicialmente em um artigo seminal de Diffie e Hellman \cite{Diffie76}. 6 | Neste mesmo artigo os autores propõe a possibilidade de construção de um esquema de {\em criptografia assimétrico}. 7 | O modelo sugerido pela dupla se assemelha ao esquema de um cadeado em que qualquer um pode usar para trancar, mas apenas o dono da chave possui a forma de abrir. 8 | No modelo assimétrico cada ator possui duas chaves: uma pública (cadeado) que pode ser exposta no meio inseguro e uma secreta. 9 | Quando Alice quer se comunicar com Bob ela precisa acessar a chave pública $pk$ de Bob que pode estar disponível publicamente em um site ou Bob pode enviá-la por qualquer canal inseguro. 10 | Com a chave pública de Bob, Alice pode criptografar uma mensagem que apenas ele será capaz de descifrar com sua chave secreta $sk$. 11 | O esquema está representado no digrama a seguir: 12 | 13 | \begin{center} 14 | \begin{tikzpicture}[node distance=2cm,auto,>=latex] 15 | \node (alice) at (0, 2){Alice}; 16 | \node (bob) at (10, 2) {Bob}; 17 | \node (eva) at (5, 2) {Eva}; 18 | 19 | \node (m1) at (0,1) {$m$}; 20 | \node (pk1) at (0,-2) {$pk$}; 21 | \node (E) at (2,0) {$E(pk,m) = c$}; 22 | \node (D) at (8,0) {$D(sk,c) = m$}; 23 | \node (sk) at (10,-1) {$sk$}; 24 | \node (pk2) at (10,-2) {$pk$}; 25 | \node (m2) at (10,1) {$m$}; 26 | 27 | \path[->] (eva) edge (5,1); 28 | \draw[->] (m1) -> (E); 29 | \draw[->] (pk1) -> (E); 30 | \draw[->] (D) -> (m2); 31 | \draw[->] (k2) -> (D); 32 | \draw[->] (pk2) -> (pk1); 33 | \draw[->] (E) -> node[above]{$c$} (D); 34 | \end{tikzpicture} 35 | \end{center} 36 | 37 | Formalmente, o {\em sistema de criptografia assimétrico} $\Pi$ é formado por três algoritmos $\langle Gen, E, D \rangle$, $Gen(1^n)$ produz um par de chaves $\langle sk, pk \rangle$ e precisamos garantir que: 38 | \begin{displaymath} 39 | D(sk, E(pk, m)) = m 40 | \end{displaymath} 41 | 42 | Um sistema de criptografia assimétrico é {\em seguro} se não é viável para um adversário distinguir duas mensagens a partir de uma cifra mesmo na posse da chave pública. 43 | A posse da chave pública dá ao adversário um capacidade equivalente ao CPA, mesmo que ele não tenha acesso à um oráculo. 44 | 45 | 46 | \section{El Gammal} 47 | \label{sec:el-gammal} 48 | O primeiro sistema de criptografia assimétrico foi descoberto por Rivest, Shamir e Adelman um ano depois do trabalho de Diffie e Hellman. 49 | Essa solução será apresentada em seguida, antes disso mostraremos um esquema que se assemelha muito ao protocolo apresentado no capítulo anterior. 50 | Apesar das semelhanças, esse sistema só foi formalizado em 1985 por Taher El Gamal \cite{ElGamal85}. 51 | O sistema parte do modelo de criptografia assimétrica e é definido como $\Pi= \langle Gen, E, D\rangle$: 52 | \begin{itemize} 53 | \item $Gen(1^n) := \langle sk, pk \rangle$ em que $\mathcal{G}(1^n) = \langle \mathbb{G}, g \rangle$, 54 | \begin{itemize} 55 | \item $sk = \langle \mathbb{G}, g, x \rangle$ com $x \leftarrow \mathbb{Z}_{|\mathbb{G}|}$ e 56 | \item $pk = \langle \mathbb{G}, g, h \rangle$ com $h := g^x$. 57 | \end{itemize} 58 | 59 | \item $E(pk, m) = \langle g^y, h^y \cdot m\rangle$ em que $y \leftarrow \mathbb{Z}_n$ e $m \in \mathbb{G}$ 60 | \item $D(sk, \langle c_1, c_2 \rangle) = \frac{c_2}{c_1^x}$ 61 | \end{itemize} 62 | 63 | A correção do sistema segue abaixo: 64 | \begin{displaymath} 65 | D(sk, E(pk, m)) = \frac{h^y \cdot m}{(g^y)^x} = \frac{(g^x)^y \cdot m}{g^{y \cdot x}} = m 66 | \end{displaymath} 67 | 68 | Como no caso do protocolo de Diffie-Hellman, normalmente os valores $\mathbb{G}$ e $g$ são definidos pelo protocolo e reutilizados por todos os usuários. 69 | Isso não causa nenhum efeito deletério à segurança do sistema. 70 | 71 | \section{RSA} 72 | \label{sec:rsa} 73 | 74 | Em 1978 Rivest, Shamir e Adelman apresentaram o primeiro sistema de criptografia assimétrica conforme concebido um ano antes por Diffie e Hellman \cite{Rivest78}. 75 | Diferente do protocolo de seus colegas e do sistema de El Gamal que se baseiam na dificuldade do problema do logaritmo discreto, o sistema RSA dependende da dificuldade de outro problema matemático, o problema da fatoração. 76 | 77 | Antes de apresentar o sistema precisamos fazer uma pequena digressão matemática e aproveitaremos para dar um exemplo concreto de grupo finito. 78 | 79 | Primeiro lembremos o que é chamado de Algoritmo da Divisão. 80 | Para quaisquer $a, b \in \mathbb{Z}$ temos que existem $q, r \in \mathbb{Z}$ tal que $0 \leq r < b$ e: 81 | \begin{displaymath} 82 | a = bq + r 83 | \end{displaymath} 84 | 85 | O inteiro $q$ é chamado {\em quociente da divisão} e $r$ o {\em resto}. 86 | Além disso, usaremos diversas vezes o seguinte resultado: 87 | 88 | \begin{proposition} 89 | Se $n|a$ e $n|b$ então $n|(ax + by)$. 90 | \end{proposition} 91 | \begin{proof} 92 | Por definição existem $n'$ e $n''$ tais que $nn' = a$ e $nn'' = b$. 93 | Segue que $n(n'x + n''y) = ax + by$ e portanto $n|(ax + by)$. 94 | \end{proof} 95 | 96 | Com esses resultados podemos mostrar a chamada {\em Identidade de Bezout}: 97 | 98 | \begin{proposition}[Identidade de Bezout] 99 | Para quaisquer $a,b \in \mathbb{Z}$ existem $X, Y \in \mathbb{Z}$ tais que $Xa + Yb = mdc(a,b)$. 100 | \end{proposition} 101 | \begin{proof} 102 | Considere o conjunto $I = \{X'a + Y'b: X', Y' \in \mathbb{Z}\}$ e seja $d = Xa + Yb$ o menor inteiro positivo em $I$. 103 | Seja $c \in I$, ou seja, $c = X'a + Y'b$. 104 | Usando o algoritmo da divisão temos que $c = qd + r$ e, então: 105 | \begin{displaymath} 106 | r = c - qd = X'a + Y'b - q(Xa + Yb) = (X' - qX)a + (Y' - qY)b \in I 107 | \end{displaymath} 108 | Se $r \neq 0$ então como $r < d$ isso contradiria o fato de que $d$ é o menor inteiro positivo em $I$, logo, $r = 0$ e, portanto $d|c$. 109 | Ou seja, para qualquer $c \in I$ temos que $d|c$. 110 | 111 | Como $a, b \in I$ temos que $d|a$ e $d|b$. 112 | Agora assuma por absurdo que existe $d' > d$ tal que $d'|a$ e $d'|b$. 113 | Neste caso, pela propriedade acima teríamos que $d'|(Xa + Yb)$, ou seja, $d'|d$, mas isso é impossível porque $d' > d$. 114 | Concluímos que $d = mdc(a,b)$. 115 | \end{proof} 116 | 117 | Podemos considerar $\langle \mathbb{Z}_n, \cdot \rangle$ em que a multiplicação é calculada módulo $n$, neste caso, porém, nem todo $n$ forma um grupo (o Exercício \ref{ex:grupo} pede para mostrar que $6$ não possui inverso em $\langle \mathbb{Z}_{12}, \cdot \rangle$). 118 | A seguinte proposição estabelece uma condição necessária e suficiente para que $a$ possua inverso em $\langle \mathbb{Z}_n, \cdot \rangle$: 119 | 120 | \begin{proposition} 121 | \label{prop:inverso} 122 | Um número $a$ possui inverso em $\langle \mathbb{Z}_n, \cdot \rangle$ se e somente se $mdc(a,n) = 1$. 123 | \end{proposition} 124 | \begin{proof} 125 | Se $mdc(a, n) = 1$ usando o {\em Identidade de Bezout} temos $1 = aX + nY$ para $X, Y \in Z$. 126 | Neste caso $aX \equiv 1\ (mod\ n)$, ou seja, $X$ é o inverso de $a$ em $\langle \mathbb{Z}_n, \cdot \rangle$. 127 | 128 | Agora considere que $mdc(a, n) = b \neq 1$ e suponha por absurdo que $X$ é o 129 | inverso de $a$ em $\langle \mathbb{Z}_n , \cdot \rangle$. 130 | Então temos que $1 \equiv Xa\ (mod\ n)$, ou equivalentemente, $Xa - 1 \equiv 0\ (mod\ n)$ e, portanto, $n|(Xa - 1)$. 131 | Portanto, existe $n'$ tal que $nn' = Xa - 1$ e então $1 = Xa - n \cdot n'$. 132 | Como $b \in D(a,n)$ então $b|(Xa - nn')$, ou seja, $b|1$, mas isso é impossível se $b \neq 1$. 133 | \end{proof} 134 | 135 | Será útil para isso apresentar uma versão extendida do algoritmo de Euclides que calcula o {\em máximo divisor comum} entre dois valores $a$ e $b$ e calcula os coeficientes $X$ e $Y$ tais que $Xa + Yb = mdc(a,b)$. 136 | 137 | \begin{codebox} 138 | \Procname{$\proc{AEE}(a, b)$} 139 | \li \Comment Recebe $a, b \in \mathbb{Z}$ com $a > b$ 140 | \li \Comment Devolve $t$, $X$ e $Y$ tais que $t = mdc(a,b) = Xa + Yb$ 141 | \li \If $b|a$ 142 | \li \Then 143 | \Return $b, 0, 1$ 144 | \li \Comment $a = bq + r$ 145 | \li \Else $t, X, Y \gets \proc{AEE}(b, r)$ 146 | \li \Return $t, Y, X - Y \cdot q$ 147 | \End 148 | \end{codebox} 149 | 150 | Para mostrar a correção do algoritmo primeiro considere a seguinte proposição: 151 | 152 | \begin{proposition} 153 | Seja $a = bq + r$ com $r < b$ e $D(a, b) := \{ x \in \mathbb{Z} : x|a$ e $x|b \}$ então $D(a,b) = D(b,r)$. 154 | \end{proposition} 155 | 156 | \begin{proof} 157 | Por definição temos que $r = a - qb$ e, portanto, $x|a$ e $x|b$ sse $x|r$. 158 | Além disso, $x|b$ e $x|r$ sse $x|a$, pois $a = bq + r$. 159 | Concluímos que $x|a$ e $x|b$ sse $x|b$ e $x|r$. 160 | \end{proof} 161 | 162 | \begin{corollary} 163 | Se $a = bq + r$ então: 164 | \begin{displaymath} 165 | mdc(a,b) = mdc(b, r) 166 | \end{displaymath} 167 | \end{corollary} 168 | 169 | O corolário acima justifica que $t = mdc(a,b)$ no Algoritmo Extendido de Euclides. 170 | Agora note que se o algoritmo for correto na linha 5 temos que $Xb + Yr$ e o valor devolvido será: 171 | 172 | \begin{eqnarray*} 173 | Ya + (X - Yq)b & = & Ya + Xb + Xqb \\ 174 | & = & Xb + Y(a + qb) \\ 175 | & = & Xb + Yr 176 | \end{eqnarray*} 177 | 178 | Ou seja, o valor $Xa + Yb$ é um invariante. 179 | 180 | Na base temos que $b|a$ e, portanto, $mdc(a,b) = b$. 181 | Além disso, $X = 0$ e $Y = 1$, logo $Xa + Yb = b = mdc(a,b)$. 182 | Concluímos que o algoritmo é correto. 183 | 184 | \begin{example} 185 | Simularemos a execução de $\proc{AEE}(42, 22)$: 186 | \begin{displaymath} 187 | \proc{AEE}(42, 22) \vdash \proc{AEE}(22, 20) \vdash \proc{AEE}(20, 2) 188 | \end{displaymath} 189 | Neste ponto temos que $2|20$ então calculamos recursivamentes: 190 | \begin{displaymath} 191 | \begin{array}{lllr} 192 | t \gets 2 & r \gets 0 & s \gets 1 & 0 \cdot 20 + 1 \cdot 2 = 2\\ 193 | t \gets 2 & r \gets 1 & s \gets -1 & 1 \cdot 22 - 1 \cdot 20 = 2\\ 194 | t \gets 2 & r \gets -1 & s \gets 2 & -1 \cdot 42 + 2 \cdot 22 = 2\\ 195 | \end{array} 196 | \end{displaymath} 197 | \end{example} 198 | 199 | 200 | 201 | Definimos enfim $\mathbb{Z}_n^\star$ como os elementos em $\mathbb{Z}_n$ que possuem inverso multiplicativo: 202 | \begin{displaymath} 203 | \mathbb{Z}_n^\star := \{a \in \mathbb{Z}_n : mdc(a,n) = 1\} 204 | \end{displaymath} 205 | 206 | Note que se $mdc(a,n) = 1$ então o Algoritmo Extendido de Euclides devolve $X$ e $Y$ tais que $Xa + Yn = 1$. 207 | Se fizermos essa conta em $\mathbb{Z}_n$ temos que $Xa \equiv 1\ (mod\ n)$. 208 | Ou seja, para os elementos $a \in \mathbb{Z}_n^\star$ o AEE nos dá uma forma de computar o inverso. 209 | 210 | Não é difícil mostrar que $\langle \mathbb{Z}_n^\star, \cdot \rangle$ é um grupo visto que todos os elementos possuem inverso por definição (Exercício \ref{ex:euler}). 211 | A {\em função de Euler} atribui a cada $n$ o tamanho de $\mathbb{Z}_n^\star$: 212 | 213 | \begin{displaymath} 214 | \phi(n) := |\mathbb{Z}_n^\star| 215 | \end{displaymath} 216 | 217 | No caso em que $n$ é o produto de dois número primos calcular a função de Euler é relativamente simples: 218 | 219 | \begin{proposition} 220 | Sejam $p$ e $q$ números primos: 221 | \begin{displaymath} 222 | \phi(pq) = (p - 1)(q - 1) 223 | \end{displaymath} 224 | \end{proposition} 225 | \begin{proof} 226 | Seja $a \in \mathbb{Z}_n$ e $mdc(a, n) \neq 1$ então $p|a$ ou $q|a$ (se ambos dividissem então $n|a$, mas como $a \in \mathbb{Z}_n$ então $a < n$). 227 | Os elementos de $\mathbb{Z}_n$ divisíveis por $p$ são $p, 2p, \dots , (q - 1) \cdot p$ e os elementos divisíveis por $q$ são $q, 2q, \dots , (p - 1) \cdot q$. 228 | Assim, o total de elementos que não são divizíveis por nenhum dos dois é: 229 | \begin{displaymath} 230 | \phi(n) = n - 1 - (p - 1) - (q - 1) = p \cdot q - p - q + 1 = (p - 1)(q - 1) 231 | \end{displaymath} 232 | 233 | 234 | \end{proof} 235 | 236 | A geração de chaves no sistema RSA segue os seguintes passos: 237 | \begin{enumerate} 238 | \item Recebe o parâmetro de segurança $1^n$ e sorteia dois primos $p$ e $q$ com $n$ bits. 239 | \item Calcula $N = pq$ e $\phi(N) := (p - 1)(q - 1)$ 240 | \item Escolhe $e > 1$ de forma que $mdc(e, \phi(N)) = 1$ 241 | \item Computa $d = [e^{-1}\ mod\ \phi(N)]$ 242 | \item Devolve $N$, $e$ e $d$ 243 | \end{enumerate} 244 | 245 | Na prática podemos fixar a escolha de $e$ e computar $d$ de acordo. 246 | Se lembrarmos o algoritmo que $\proc{FastExp}$ notaremos que uma boa escolha para $e$ deve possuir poucos bits $1$ para tornar esse procedimento mais eficiente. 247 | Dois valores usados na prática são $3$ e $2^{16}+1$. 248 | 249 | Vimos que para calcular $d$ basta usar o Algoritmo Extendido de Euclides. 250 | Falta uma forma eficiente de sortear primos de tamanho $n$, o que está fora do escopo destas notas. 251 | %Voltaremos a este problema na Seção \ref{}. 252 | 253 | Em sua versão crua, o sistema de RSA é definido pela seguinte tripla de algoritmos: 254 | 255 | \begin{itemize} 256 | \item $Gen(1^n) = \langle sk, pk \rangle$. Conforme descrito acima temos: 257 | \begin{itemize} 258 | \item $sk = \langle N, d \rangle$ 259 | \item $pk = \langle N, e \rangle$ 260 | \end{itemize} 261 | \item $E(pk, m) = [m^e\ mod\ N]$ para $m \in \mathbb{Z}_n^\star$ 262 | \item $D(sk, c) = [c^d\ mod\ N]$ 263 | \end{itemize} 264 | 265 | Como $\langle \mathbb{Z}_n^\star, \cdot \rangle$ é um grupo, segue do Teorema \ref{theo:gen-euler} que para qualquer $a$ temos que: 266 | \begin{displaymath} 267 | a^{\phi(n)} \equiv 1\ (mod\ n) 268 | \end{displaymath} 269 | 270 | Esse resultado é chamado de {\em Teorema de Euler}. 271 | 272 | \begin{corollary} 273 | Para todo $a \in \mathbb{Z}_n^\star$ temos que $a^x \equiv a^{[x\ mod\ \phi(n)]}\ (mod\ n)$. 274 | \end{corollary} 275 | \begin{proof} 276 | Seja $x = q \cdot \phi(n) + r$ em que $r = [x\ mod\ \phi(n)]$: 277 | \begin{displaymath} 278 | a^x \equiv a^{q \cdot \phi(n) + r} \equiv a^{q \cdot \phi(n)} \cdot a^r \equiv (a^{\phi(n)})^q \cdot a^r \equiv 1^q \cdot a^r \equiv a^r\ (mod\ n) 279 | \end{displaymath} 280 | \end{proof} 281 | 282 | 283 | \begin{corollary} 284 | \label{cor:euler} 285 | Seja $x \in \mathbb{Z}_n^\star$, $e > 0$ tal que $mdc(e, \phi(n)) = 1$ e $d \equiv e^{-1}\ (mod\ \phi(n))$ então $(x^e)^d \equiv x\ (mod\ n)$ 286 | \end{corollary} 287 | 288 | \begin{proof} 289 | \begin{displaymath} 290 | x^{ed} \equiv x^{[ed\ mod\ \phi(n)]} \equiv x\ (mod\ n) 291 | \end{displaymath} 292 | \end{proof} 293 | 294 | Esses são os resultados necessários para mostrar a corretude do sistema RSA: 295 | \begin{displaymath} 296 | D(sk, E(pk, m)) = [(m^e)^d\ mod\ N] = [m^{ed}\ mod\ N] = [m\ mod\ N] = m 297 | \end{displaymath} 298 | 299 | Notem que uma condição necessária, porém não suficiente, para a segurança dos sistemas RSA é a dificuldade do {\em problema da fatoração} que pode ser descrito formalmente da seguinte forma: 300 | \begin{itemize} 301 | \item O sistema gera dois números primos aleatórios $p$ e $q$ de tamanho $n$ e envia $N = pq$ para o adversário 302 | \item O adversário $\mathcal{A}$ deve produzir $p'$ e $q'$ 303 | \end{itemize} 304 | 305 | Dizemos que o adversário venceu o desafio se $p' \cdot q' = N$. 306 | O problema da fatoração é considerado {\em difícil} pois não se conhece nenhum adversário eficiente capaz de vencer o jogo com probabilidade considerável. 307 | 308 | Caso um adversário eficiente fosse capaz de fatorar $N$, ele produziria $p$ e $q$ e seria então capaz de gerar $\phi(N) = (p-1)(q-1)$ sem nenhuma dificuldade. 309 | Com isso o sistema se torna completamente inseguro. 310 | Ou seja, a dificuldade do problema da fatoração é necessária para garantir a segurança do sistema. 311 | Não sabemos, porém, se essa condição é suficiente. 312 | 313 | A construção apresentada acima é chamada de RSA simples ({\em plain RSA}) e é insegura por uma série de motivos. 314 | Um mecanismo para torná-la mais segura é sortear uma sequência de bits $r$ aleatóriamente e usar $m' = r||m$ como mensagem. 315 | O mecanismo segue de maneira identica, a única diferença é que ao decifrar se recupera $r||m$ e então é preciso descartar os primeiros bits. 316 | Essa versão é chamada {\em padded RSA} e uma adaptação dela é usada no padrão {\tt RSA PKCS \#1 v1.5} usada na prática. 317 | 318 | \section{Sistemas Híbridos} 319 | \label{sec:sistemas-hibridos} 320 | 321 | Os sistemas de criptografia assimétricos que vimos são pelo menos uma ordem de grandesa menos eficientes do que os sistemas de criptografia simétrica que vimos anteriormente. 322 | Além disso, é difícil garantir a segurança desses sistemas pra mensagens em qualquer distribuição de probabilidades. 323 | Por esses motivos, o modelos mais popular de criptografia assimétrica segue um modelo híbrido dividido em duas fases: uma fase de encapsulamento de chave (KEM) seguido de uma fase de encapsulamento dos dados (DEM). 324 | 325 | Um {\em mencanismo de encapsulamento de chave} (KEM) é um sistema $\Pi = \langle Gen, Encaps, Decaps \rangle$ tal que: 326 | \begin{itemize} 327 | \item $Gen(1^n) := \langle sk, pk \rangle$ em que $pk$ é uma chave pública e $sk$ uma chave secreta 328 | \item $Encaps$ recebe a chave pública $pk$ e o parâmetro de segurânça $1^n$ e produz uma cifra $c$ e uma chave $k \in \{0,1\}^{l(n)}$ 329 | \item $Decaps$ recebe a chave secreta $sk$ e a cifra $c$ e produz uma chave. 330 | \end{itemize} 331 | 332 | Um sistema KEM em que $Encaps(pk, 1^n) = \langle c, k \rangle$ é {\em correto} se: 333 | \begin{displaymath} 334 | Decaps(sk, c) = k 335 | \end{displaymath} 336 | 337 | Um sistema KEM é {\em seguro contra CPA} se um adversário polinomial não é capaz de distinguir com probabilidade considerável a chave produzida por $Encaps$ de uma chave de mesmo tamanho escolhida aleatóriamente. 338 | Se $\Pi_K = \langle Gen_K, Encaps, Decaps \rangle$ é um KEM seguro contra CPA, e $\Pi' = \langle Gen', E', D' \rangle$ é um sistema de criptografia simétrica seguro contra ataques ``ciphertext only'' então o seguinte sistema $\Pi = \langle Gen, E, D \rangle$, chamado de {\em híbrido}, é seguro contra CPA: 339 | 340 | \begin{itemize} 341 | \item $Gen(1^n) := Gen_k(1^n) = \langle sk, pk \rangle$ 342 | \item $E(pk, m) := \langle c_k, c \rangle$ em que: 343 | \begin{itemize} 344 | \item $Encaps(pk, 1^n) = \langle c_k, k \rangle$ e 345 | \item $E'(k, m) = c$ 346 | \end{itemize} 347 | \item $D(sk,\langle c_k, c \rangle) = m$ tal que: 348 | \begin{itemize} 349 | \item $Decaps(sk, c_k) = k$ e 350 | \item $D'(k, c) = m$ 351 | \end{itemize} 352 | \end{itemize} 353 | 354 | Uma forma natural de produzir um KEM é produzir uma chave $k$ e usar um sistema de criptografia assimétrica $\Pi$ para criptografar a chave. 355 | Esse esquema é seguro desde que o sistema desde que $\Pi$ seja seguro, mas veremos que existem sistemas mais eficientes em determinados casos. 356 | O Apêndice \ref{cha:sistemas-hibridos} apresenta dois sistemas híbridos: um baseado no problema do logartimo discreto e outro no problema da fatoração. 357 | 358 | 359 | 360 | \section{Exercícios} 361 | \label{sec:exercicios} 362 | 363 | 364 | \begin{exercicio} 365 | \label{ex:euler} 366 | Mostre que para qualquer $n \in \mathbb{Z}$ a estrutra $\langle \mathbb{Z}_n^\star, \cdot \rangle$ é um grupo. 367 | \end{exercicio} 368 | 369 | 370 | %\begin{exercicio} 371 | % sobre a distribuição dos primos 372 | %\end{exercicio} 373 | -------------------------------------------------------------------------------- /hash.tex: -------------------------------------------------------------------------------- 1 | \chapter{Funções de Hash} 2 | \label{cha:hash} 3 | 4 | Uma função de hash mapeia uma sequência de bits de tamanho arbitrário em uma sequência curta e de tamanho fixo chamada {\em digest} ou {\em checksum}. 5 | Em Estrutura de Dados estudamos funções de hash com o propósito de acessar uma lista em tempo $O(1)$. 6 | Minimizar as colisões naquele contexto garantia que as listas ligadas de objetos associadas a cada índice de um vetor fosse a menor possível tornando a consulta mais eficiente. 7 | Em aplicações de criptografia, evitar colisões é mais crítico, pois pode levar a vulnerabilidades no sistema. 8 | 9 | Assim, uma função de hash é simplesmente uma função $H: \{0,1\}^* \to \{0,1\}^n$. 10 | Para definir o conceito de resistência a colisão vamos introduzir artificialmete uma chave na função de hash que não precisa ser guardada em segredo. 11 | Além disso, nosso modelo precisa conter além de $H$ um algoritmo $Gen$ que gera a chave. 12 | O modelo, portanto, difere da construção prática. 13 | 14 | Definiremos resistência à colisão para um sistema $\Pi = \langle Gen, H \rangle$ a partir do jogo que já nos abituamos: 15 | \begin{enumerate} 16 | \item O sistema usa $Gen$ que recebe $1^n$ e gera uma chave $s$. 17 | \item O adversário $\mathcal{A}$ recebe $s$. 18 | \item A devolve um par de mensagens $\langle x, x' \rangle$. 19 | \end{enumerate} 20 | 21 | \begin{center} 22 | \begin{tikzpicture}[node distance=2cm,auto,>=latex] 23 | \tikzset{ 24 | player/.style={draw,shape=rectangle,rounded corners,minimum width=5em,minimum height=5em} 25 | } 26 | \node[player] (system) {$\Pi$}; 27 | \node[player] (adversary) at (10,0) {$\mathcal{A}$}; 28 | \draw[->] (1,0) -> node[above]{$s$} (9,0); 29 | \draw[->] (0,2) -> node{$Gen(1^n) := s$} (system); 30 | \draw[->] (adversary) -> node{$\langle x, x' \rangle$} (10,-2); 31 | \end{tikzpicture} 32 | \end{center} 33 | 34 | O desafio de $\mathcal{A}$ é achar uma {\em colisão}, ou seja, um par $\langle x, x' \rangle$ tal que $H_s(x) = H_s(x')$ 35 | \begin{displaymath} 36 | HashCol_{\mathcal{A}, \Pi}(n) := \left\{ 37 | \begin{array}{lcl} 38 | 1 & \textrm{se} & H_s(x) = H_s(x')\\ 39 | 0 & \textrm{c.c.} &\\ 40 | \end{array} 41 | \right. 42 | \end{displaymath} 43 | 44 | O sistema $\Pi$ é {\em resistente à colisão} \cite{Damgard88} se para todo adversário polinomial $\mathcal{A}$ existe uma função desprezível $\varepsilon$ tal que: 45 | \begin{displaymath} 46 | Pr[HashCol_{\mathcal{A}, \Pi}(n) = 1] \leq \varepsilon(n) 47 | \end{displaymath} 48 | 49 | A necessidade de inserir uma chave é puramente técnica. 50 | Sem uma chave não seria possível evitar que o adversário simplesmente pré-compute uma colisão e use-a para derrotar o jogo. 51 | Na prática usamos funções sem chave e tratamos como resistentes a colisão quando isso for validade empiricamente. 52 | 53 | Note que a resistência à colisão é uma propriedade mais forte do que outras propriedades desejáveis em funções de hash: 54 | \begin{itemize} 55 | \item {\em resistência contra colisões em alvos específicos}: dado $s$ e $x$ nenhum adversário eficiente é capaz de encontrar $x'$ tal que $H_s(x) = H_s(x')$ com probabilidade considerável. 56 | \item {\em resistência contra preimagem}: dados $s$ e $y$ aleatório, nenhum adversário eficiente é capaz de encontrar $x$ tal que $h_s(x) = y$ com probabilidade considerável. 57 | \end{itemize} 58 | 59 | Toda a função de hash está sujeita a ataques do tipo força bruta. 60 | Ou seja, se $H: \{0,1\}^* \to \{0,1\}^n$ podemos calcular $H(x)$ para uma sequência de strings distintas $x_0, x_1, \dots, x_{2^n+1}$. 61 | Pelo {\em princípio da casa dos pombos} necessariamente encontraremos neste caso uma colisão. 62 | Na verdade se assumirmos que $H$ é uma função aleatória, podemos mostrar que para que a probabilidade de encontrar uma colisão seja maior do que $\frac{1}{2}$ precisamos nossa sequência strings deve ter cerca de $\Theta(\sqrt{n})$. 63 | Esse resultado é chamado de {\em paradoxo do aniversário}, pois bastam 23 pessoas para garantir que a probabilidade de duas fazerem aniversário no mesmo dia seja maior que meio. 64 | Assim, se quisermos um sistema que garanta a segurança equivalente a uma função aleatória com chave de 128 bits, precisamos usar uma função de hash muito confiável que produz uma saída com pelo menos 256 bits. 65 | 66 | O ataque do aniversariante nos dá uma colisão qualquer $\langle x, x' \rangle$ a primeira vista isso pode parecer inofencivo, pois não podemos controlar os valores de $x$ e $x'$. 67 | Note, porém, que o ataque requer uma serie de pelo menos $\sqrt{n}$ mensagens, mas elas não precisam ser aleatórias. 68 | Precisamos, portanto, apenas gerar um número suficente de mensagens equivalentes para que o ataque seja efetivo. 69 | Essa é uma tarefa relativamente simples. 70 | Considere o seguinte exemplo de um conjunto de mensagens equivalentes: 71 | 72 | 73 | \begin{quote} 74 | É {\em difícil/impossível/desafiador/complicado} {\em imaginar/acreditar} que {\em encontraremos/localizaremos/contrataremos} outra {\em pessoa/empregada} com a mesma {\em capacidade/versatilidade/destreza} que Eva. 75 | Ela fez um trabalho {\em incrível/excelente}. 76 | \end{quote} 77 | 78 | % mudar esse exemplo que está identico ao do livro 79 | 80 | As palavras em itálico podem umas substituir as outras sem mudar significativamente o espírito da mensagem que pode ser escrita de 288 formas distintas. 81 | Se nosso conjunto precisa ser $2^{32}$ basta escrever um texto com pelo menos 32 palavras em que cada uma possua um sinônimo. 82 | \section{Construções} 83 | \label{sec:construcoes} 84 | 85 | A maioria das funções de hash seguem uma construção chamada {\em Merkle-Damg\aa rd} que assume a existância de uma {\em função de compressão} resistente à colisão para mensagens de tamanho fixo e a extende para mensagens de tamanho arbitrário \cite{Merkle89,Damgard89}. 86 | Seja $\langle Gen, h \rangle$ um sistema de hash que comprime o tamanho de uma mensagem pela metade $h_s:\{0,1\}^{2n} \to \{0,1\}^n$. 87 | Construimos $\langle Gen, H \rangle$ da seguinte maneira: 88 | \begin{itemize} 89 | \item Sejam $m \in \{0,1\}^*$, $|m| = L < 2^n$ e $l := \lceil \frac{L}{n} \rceil$ o número de blocos de $m$ de tamanho $n$ (se o tamanho de $m$ não for múltiplo de $n$ complete-o com um {\em pad} de $0$s) e insira $L$ ao fim de $x$ i.e. $x = x_0 \dots x_l L$. 90 | \item Defina $z_0 := 0^n$. 91 | \item Compute $z_i := h_s(z_{i-1}x_i)$ para $i = 1, \dots, l + 1$. 92 | \item Devolva $z_{l+1}$. 93 | \end{itemize} 94 | 95 | \begin{center} 96 | \begin{tikzpicture}[node distance=2cm,auto,>=latex] 97 | \node (IV) at (0,-2) {$0^n$}; 98 | \node (m1) at (2,0) {$m_1$}; 99 | \node (h1) at (2,-2) {$h_s$}; 100 | \node (m2) at (4,0) {$m_2$}; 101 | \node (h2) at (4,-2) {$h_s$}; 102 | \node at (6,0) {\dots}; 103 | \node at (6,-2) {\dots}; 104 | \node (ml) at (8,0) {$m_{l+1} = L$}; 105 | \node (hl) at (8,-2) {$h_s$}; 106 | \node (H) at (10,-2) {$H_s(m)$}; 107 | \draw[->] (IV) -> node[above]{$z_0$}(h1); 108 | \draw[->] (m1) -> (h1); 109 | \draw[->] (h1) -> node[above]{$z_1$}(h2); 110 | \draw[->] (m2) -> (h2); 111 | \draw[->] (ml) -> (hl); 112 | \draw[->] (7,-2) -> node[above]{$z_l$}(hl); 113 | \draw[->] (hl) -> node[above]{$z_{l+1}$}(H); 114 | \end{tikzpicture} 115 | \end{center} 116 | 117 | 118 | \begin{theorem}[Merkle-Damg\aa rd] 119 | Se $\langle Gen, h \rangle$ é resistente a colisão então $\langle Gen, H \rangle$ da forma como definido acima também é resistente a colisão. 120 | \end{theorem} 121 | 122 | Construir uma função de hash resistente a colisão para uma mensagem de tamanho arbitrário se resume, portanto, a encontrar uma para mensagem de tamanho fixo que a comprima pela metade. 123 | 124 | \subsection{SHA-1} 125 | \label{sec:sha-1} 126 | 127 | O {\em Secure Hash Algorithm} (SHA-1) é um algoritmo da família MD4 que recebe uma entrada de tamanho arbitrário $l < 2^{64}$ e produz um {\em digest} de $160$ bits. 128 | Antes de processar a mensagem é inserido um {\em pad} que consiste em uma sequência $10 \dots 0l$ em que $l = |x|$ é o número de bits da mensagem e $|x10 \dots 0l|$ é um múltiplo de 512. 129 | Essa codificação de $x$ é então dividida em blocos $x_0, \dots, x_n$ tais que $|x_i| = 512$. 130 | 131 | A função de hash $h$ que alimenta a construção de Merkle-Damg\aa evrd consiste de 80 rodadas. 132 | Um {\em message schedule} é responsavel por gerar 80 strings $W_0, \dots, W_{79}$ de 32 bits cada a partir do bloco $x_i$ sendo processado. 133 | Começamos com valores iniciais fixos $A =$ {\tt 67452301}, $B =$ {\tt EFCDAB89}, $C =$ {\tt 98BADCFE}, $D =$ {\tt 10325476}, $E =$ {\tt C3D2E1F0} e alteramos esses valores em cada rodada da seguinte maneira: 134 | 135 | \begin{displaymath} 136 | A, B, C, D, E := (E + f_t(B,C,D) + A_{\lll 5} + W_j + K_t), A, B_{\lll 30}, C, D 137 | \end{displaymath} 138 | 139 | A cada 20 rodadas mudamos o valor da constante $K_t$ e da função $f_t$ de forma que o algoritmo precisa definir 4 constantes e quatro funções. 140 | Apenas para matar a curiosidade seguem suas definições: 141 | \begin{enumerate} 142 | \item $K_t :=$ {\tt 5A827999} e $f_t(B,C,D) := (B \land C) \lor (B \land D)$ para $t = 0, \dots, 19$ 143 | \item $K_t :=$ {\tt 6ED9EBA1} e $f_t(B,C,D) := B \xor C \xor D$ para $t = 20, \dots, 39$ 144 | \item $K_t :=$ {\tt 8F1BBCDC} e $f_t(B,C,D) := (B \land C) \lor (B \land D) \lor (C \land D)$ para $t = 40, \dots, 59$ 145 | \item $K_t :=$ {\tt CA62C1D6} e $f_t(B,C,D) := B \xor C \xor D$ para $t = 60, \dots, 79$ 146 | \end{enumerate} 147 | 148 | Em fevereiro de 2017 um grupo de pesquisadores da Google e de uma faculdade holandesa anunciaram um ataque prático contra o SHA-1 capaz de encontrar colisões\footnote{https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html}. 149 | Os autores estimaram que um ataque força-bruta em uma ano requereria cerca de 12 milhões de processadores gráficos para encontrar uma colisão, mas explorando as vulnerabilidades apontadas isso pode ser executado com apenas 110 processadores. 150 | Como prova do conceito eles produziram dois documentos PDF com um infográfico explicando sobre o ataque. 151 | Cada um desses arquivos possui uma cor diferente, mas ambos produzem o mesmo hash quando processados pelo SHA-1. 152 | A orientação hoje é utilizar sistemas de hash mais seguros como o SHA-256 e o SHA-3. 153 | 154 | \section{Aplicações} 155 | \label{sec:aplicacoes} 156 | 157 | Funções de hash são amplamente utilizadas em protocolos de segurança. 158 | Nesta seção veremos quatro aplicações bastante distintas desses sistemas: um sistema de autenticação bastante popular chamado HMAC e derivação de subchaves a partir de outras chaves e a partir de uma senha. 159 | 160 | \subsection{HMAC} 161 | \label{sec:hmac} 162 | 163 | No capítulo anterior vimos como construir um sistema de autenticação para mensagens de tamanho arbitrário aplicando um esquema similar ao modo CBC. 164 | Alternativamente poderíamos utilizar um hash para produzir um {\em digest} da mensagem de tamanho fixo e então aplicar um sistema de autenticação para mensagens de tamanho fixo no resultado. 165 | Esse sistema é conhecido como {\em Hash-and-MAC}. 166 | 167 | Considere um sistema de autenticação $\Pi_M = \langle Gen_M, Mac_M, Ver_M \rangle$ para mensagens de tamanho fixo $l(n)$ e um sistema de hash $\langle Gen_H, H \rangle$ que produz um {\em digest} de tamanho $l(n)$. 168 | O sistema {\em Hash-and-MAC} $\Pi = \langle Gen, Mac, Ver \rangle$ para mensagens de tamanho arbitrário é definido como: 169 | \begin{itemize} 170 | \item $Gen(1^n) := k = \langle k_M, s \rangle$ em que $Gen_M(1^n) := k_M$ e $Gen_H(1^n) := s$ 171 | \item $Mac(k, m) := Mac_M(k_M, H_s(m))$ 172 | \item $Ver(k, m, t) := \left\{ 173 | \begin{array}{lcl} 174 | 1 & \textrm{se} & Mac(k,m) = t\\ 175 | 0 & \textrm{c.c.} &\\ 176 | \end{array} 177 | \right.$ 178 | \end{itemize} 179 | 180 | 181 | \begin{theorem} 182 | Se $\Pi_M$ é um sistema de autenticação seguro contra falsificação e $\Pi_H$ é um sistema de hash resistente a colisão então a construção $\Pi$ acima é seguro contra falsificação. 183 | \end{theorem} 184 | 185 | \begin{proof} 186 | Vamos apenas esboçar a prova e deixar os detalhes para o leitor. 187 | A ideia é a seguinte, suponha que o adversário $\mathcal{A}$ consulte o tag de uma série de mensagens $Q$ e então suponha por absurdo que ele consiga produzir um código válido para uma mensagem $m \notin Q$. 188 | Neste caso temos duas possibilidades: 189 | \begin{enumerate} 190 | \item existe uma mensagem $m' \in Q$ tal que $H_s(m') = H_s(m)$, mas isso contradiz a hipótese que $\Pi_H$ é resistente a colisões 191 | \item caso contrário $\mathcal{A}$ conseguiu falsificar um código para uma mensagem nova $H_s(m)$ de tamanho $l(n)$ contradizendo a hipótese que $\Pi_M$ é seguro contra falsificação. 192 | \end{enumerate} 193 | \end{proof} 194 | 195 | O popular sistema de autenticação HMAC se inspira no esquema apresentado acima usando duas vezes uma função de hash e duas constantes distintas {\tt ipad} e {\tt opad}. 196 | Formalmente definimos o sistema HMAC da seguinte forma: 197 | \begin{itemize} 198 | \item $Gen(1^n) := k \leftarrow \{0,1\}^n$ 199 | \item $Mac(k, m) := H_s((k \xor \textrm{\tt opad}) || H_s(k \xor \textrm{\tt ipad}) || m)$ 200 | \item $Ver(k, m, t) := \left\{ 201 | \begin{array}{lcl} 202 | 1 & \textrm{se} & Mac(k,m) = t\\ 203 | 0 & \textrm{c.c.} &\\ 204 | \end{array} 205 | \right.$ 206 | \end{itemize} 207 | 208 | % argumentar sobre a importância das duas constantes e a relação com o sistema anterior 209 | 210 | %\subsection{Fingerprints e Árvores de Merkle} 211 | %\label{label} 212 | 213 | %Um hash seguro contra colisão pode ser usado para identificar um arquivo ou uma mensagem qualquer de maneira eficiente. 214 | %Esse identificador costuma ser chamado de {\em fingerprint} ou impressão digital do arquivo. 215 | %Fingerprints são utilizados em diversas aplicações como para identificação de malwares, para encontrar arquivos duplicados em um HD, para encontrar um arquivo em uma rede P2P (um {\em link magnético} nada mais é do que um fingerprint de um arquivo) e para verificar chaves (veremos isso no Capítulo \ref{cha:protocolos}). 216 | 217 | %Considere agora a situação em que temos uma série de $n$ arquivos em um servidor e gostaríamos de identificá-los localmente para verificar se o arquivo recuperado não foi corrompido. 218 | %Uma solução simples seria guardar localmente um fingerprint de cada um dos arquivos. 219 | %Essa solução requer o armazenamento e gerenciamento de $n$ fingerprints. 220 | %Uma solução mais eficiente é usar uma {\em árvore de Merkle}. 221 | %Uma árvore de Merkle é uma árvore binária em que as folhas são os arquivos e cada nó é o hash dos seus dois filhos. 222 | %Assim podemos armazenar localmente apenas o valor da raiz da árvore. 223 | %Toda vez que recuperarmos um arquivo o servidor deve enviar uma prova de que o arquivo não foi corrompido. 224 | %Essa prova consiste dos valores da árvore de Merkle no caminho da raíz até a folha (note que são necessários $lg(n)$ valores). 225 | %Com isso locamente conseguimos recuperar o valor da raíz e comparar com o que armazenamos localmente. 226 | %Veremos no Capítulo \ref{cha:protocolos} como as árvores de Merkle são usadas nos protocolos de criptomoeadas. 227 | 228 | \subsection{Funções de Derivação de Chaves} 229 | \label{sec:kdf} 230 | 231 | Uma {\em função de derivação de chaves} (KDF) tem como objeto produzir uma chave segura a partir de algum material contendo uma boa quantidade de entropia chamado {\em key material}. 232 | Isso pode ser útil seja porque o {\em key material} não está suficientemente preparado para ser usado como uma chave -- por exemplo no caso de uma senha -- ou quando queremos derivar {\em subchaves} a partir de uma chave inicial. 233 | 234 | Formalmente, uma função de derivação de chaves recebe com entrada o {\em key material} $\delta$, o tamanho $l$ da chave a ser produzida e opcionalmente um valor $r$ chamado de {\em salt} e um valor contextual $c$. 235 | Um KDF seguro deve produzir a partir desses valores uma sequência {\em pseudoaleatória} de tamanho $l$. 236 | Tipicamente um KDF consiste de duas etapas: 237 | \begin{enumerate} 238 | \item {\em extração}: recebe o {\em key material} e opcionalmente uma chave pública ({\em salt}) e produz uma sequência pseudoaleatória de bits de tamanho fixo 239 | \item {\em expansão}: expande o que foi produzido na fase de extração para uma sequência de bits de tamanho $l$. 240 | \end{enumerate} 241 | 242 | Uma implementação popular deste modelo é o HKDF \cite{Krawczyk10} que usa apenas o HMAC como primitiva: 243 | 244 | \begin{eqnarray*} 245 | \textrm{PRK} & := & \textrm{HMAC}(r, \delta)\\ 246 | \textrm{HKDF}(r, \delta, c, l) & := & K(1)||K(2) \dots ||K(t)\\ 247 | K(1) & := & \textrm{HMAC}(\textrm{PRK}, c||0)\\ 248 | K(i + 1) & := & \textrm{HMAC}(\textrm{PRK}, K(i)||c||i)\\ 249 | \end{eqnarray*} 250 | 251 | No caso $\delta$ seja uma senha proposta por um usuário, temos um problema a mais, pois tipicamente essas possuem uma entropia baixa e, portanto, estão sujeitas a {\em ataques de dicionário}. 252 | Para mitigar este problema podemos utilizar uma função de derivação de chaves lenta. 253 | Um {\em password based key derivation function} recebe como parâmetro, além do salt $r$, do tamanho $l$ e da senha $\delta$, um valor que estipula o número de ciclos $n$. 254 | Uma implementação popular deste modelo é o PBKDF2: 255 | 256 | \begin{eqnarray*} 257 | \textrm{PBKDF2}(r, \delta, c, n, l) & := & K(1)||K(2)|| \dots ||K(t)\\ 258 | K(i) & := & U_0^i \xor U_1^i \xor \dots \xor U_n^i\\ 259 | U_0^i & := & H(\delta||r||i)\\ 260 | U_j^i & := & H(\delta||U_{j-1}^1)\\ 261 | \end{eqnarray*} 262 | 263 | Note que a primitiva neste caso é uma função de hash $H$ e que cada $K(i)$ roda $n$ vezes essa função. 264 | O salt impede o preprocessamento de um dicionário e $n$ deve ser grande o suficiente para impedir sua construção {\em a posteriori}. 265 | 266 | 267 | \section{Exercícios} 268 | \label{sec:exercicios} 269 | 270 | 271 | \begin{exercicio} 272 | Mostre que resistência contra colisões garante a resistência contra preimagem. 273 | \end{exercicio} 274 | 275 | \begin{exercicio} 276 | Mostre que o seguinte sistema não é seguro contra falsificação considerando que o sistema de hash foi construído a partir do paradigma de Merkle-Damgard: 277 | \begin{itemize} 278 | \item $Gen(1^n) := k \leftarrow \{0,1\}^n$ 279 | \item $Mac(k,m) := H(k||m)$ 280 | \item $Ver(k,m,t) := \left\{ 281 | \begin{array}{lcl} 282 | 1 & \textrm{se} & Mac(k,m) = t\\ 283 | 0 & \textrm{c.c.} &\\ 284 | \end{array} 285 | \right.$ 286 | \end{itemize} 287 | \end{exercicio} 288 | 289 | \begin{exercicio} 290 | {\em Prova de trabalho} é uma medida para garantir que um determinado usuário tenha que executar uma certa quantidade de processamento durante a excecução de um protocolo. 291 | Essa ideia é usada na mineração de bitcoins e para evitar spams. 292 | No segundo caso, brevemente, a ideia é exigir uma quantidade mínima de processamento para um cliente que envie um email. 293 | Essa quantidade é desprezível para quem manda algumas dezenas de emails por dia, mas é muito cara para quem deseja mandar milhões de spams. 294 | 295 | Uma forma de prova de trabalho é entregar para o cliente a saída de um hash e pedir para que ele compute uma entrada que produza aquela saída. 296 | Argumente que, se a função de hash escolhida é segura contra colisão, o melhor que o cliente pode fazer é gerar valores aleatórios de entrada até encontrar um cuja a saída coincida com o resultado esperado. 297 | \end{exercicio} 298 | 299 | \begin{exercicio} 300 | Explique com suas palavras a definição de segurança de hashes. 301 | Por que o SHA-1 não é mais considera segura? 302 | \end{exercicio} 303 | -------------------------------------------------------------------------------- /mac.tex: -------------------------------------------------------------------------------- 1 | \chapter{Integridade e Autenticidade} 2 | \label{cha:mac} 3 | Até agora nos focamos em sistemas de criptografia simétricos que garantem a {\em confidencialidade} da comunicação entre as partes. 4 | No modelo de ataque mais poderoso que vimos até aqui o adversário tem a capacidade de verificar como mensagens escolhidas seriam cifradas e mostramos sistemas seguros contra este modelo. 5 | Neste capítulo nos voltamos pra outros dois problemas: 6 | \begin{itemize} 7 | \item {\em integridade:} garantia de que a mensagem recebida não foi alterada durante o tráfego e 8 | \item {\em autenticidade:} grantia de que a mensagem recebida foi enviada por quem esperamos. 9 | \end{itemize} 10 | 11 | A importância dessas duas garantias é evidente. 12 | Por exemplo, considere uma comunicação entre um cliente e um banco. 13 | O banco envia um mensagem cobrando uma dívida do cliente com um terceiro e o cliente autoriza o pagamento, digamos, de R\$1000,00. 14 | É de suma importância para o cliente saber que a mensagem recebida foi de fato enviada pelo banco e não se trata de um golpe (autenticidade) e é de suma importância para o cliente e para o banco que não seja possível a um terceiro alterar o valor autorizado. 15 | 16 | Um erro muito frequênte é assumir que os sistemas de criptografia que vimos até aqui são suficientes para garantir a integridade de uma mensagem. 17 | Não apenas os sistemas não oferecem nenhuma garantia quanto a isso, como alguns deles são {\em maleáveis}, ou seja, sua cifra é fácil de ser alterada para produzir o efeito desejado pelo adversário. 18 | Para ilustrar isso considere o caso em que utilizamos uma cifra de fluxo para encriptar uma mensagem $m$ e suponha que o adversário conheça uma parte do texto, por exemplo o cabeçalho $m_0$. 19 | Ou seja, $m = m_0||m_r$ em que $m_0$ é o cabeçalho e $m_r$ é o resto da mensagem. 20 | Assim temos que $E(k, m) = c_0||c_r$ em que, por definição, $c_0 = m_0 \xor G(k)_0$ e $G(k)_0$ são os primeiros bits de $G(k)$. 21 | Como o adversário conhece $m_0$ ele pode alterar $c = c_0||c_r$ por $c' = (c_0 \xor m_0 \xor m')c_r$ onde $m'$ é a mensagem que ele quer inserir no cabeçalho. 22 | Quando a nova cifra for descriptografada ela produzirá a seguinte mensagem: 23 | 24 | \begin{eqnarray*} 25 | D(k,c) & = & (G(k)_0 \xor c')||(G(k)_r \xor c_r)\\ 26 | & = & (G(k)_0 \xor c_0 \xor m_0 \xor m')||m_r\\ 27 | & = & (G(k)_0 \xor G(k_0) \xor m_0 \xor m_0 \xor m')||m_r\\ 28 | & = & m'||m_r 29 | \end{eqnarray*} 30 | 31 | Desta forma, mesmo sem conhecer a chave $k$, o adversário foi capaz de alterar o cabeçalho da cifra. 32 | O mesmíssimo ataque funciona nas cifras de bloco em modo Ctr que também são maleáveis. 33 | Em modo CBC a criptografia é menos maleável, mas não garante nenhuma defesa contra esse tipo de ataque. 34 | 35 | Outro erro comum é inserir um {\em checksum} junto com a mensagem cifrada. 36 | Um cehcksum nada mais é do que um hash da mensagem, é um sequência de bits que identificam quase univocamente a mensagem (veremos isso em detalhes no próximo capítulo). 37 | Seja $h$ a função de hash usada, colocaríamos $h(m)$, digamos, no fim de $m$ e só então criptografaríamos $E(k, m||h(m)) = c$. 38 | A ideia, insitimos errada (!), é que ao receber a cifra Bob pode descriptografar e recuperar $m$ e $h(m)$ e verificar que $h(m)$ identifica $m$. 39 | Se $m$ for alterado para $m'$, $h(m')$ não será igual a $h(m)$ e então Bob deve descartar a mensagem. 40 | Checksums são usados e funcionam bem no caso de produção acidental de erros, para acusar um pequeno ruído que tenha alterado a integridade de um arquivo ou mensagem. 41 | Eles não garantem nenhum tipo de segurança contra adversários maliciosos, pois, se o adversário pode alterar $m$, ele pode muito bem alterar $h(m)$ de acordo. 42 | 43 | 44 | \section{Código de Autenticação de Mensagem} 45 | \label{sec:mac} 46 | 47 | Para garantir a integridade de uma mensagem usaremos um {\em Sistema Autenticador de Mensagem} (MAC). 48 | O MAC é um sistema $\Pi$ formado por três algoritmos $\langle Gen, Mac, Ver \rangle$: 49 | \begin{itemize} 50 | \item $Gen$ gera uma chave $k \in K$. 51 | \item $Mac$ recebe uma chave $k$ e uma mensagem $m$ e devolve um código ({\em tag}) $t$. 52 | \item $Ver$ receve uma chave $k$, uma mensagem $m$ e um código $t$ e devolve um bit que indica se a mensagem é váilda $1$ ou inválida $0$. 53 | \end{itemize} 54 | 55 | Um sistema de MAC é {\em correto} se o código $t$ produzido por uma chave $k$ e uma mensagem $m$ é válido, ou seja, se: 56 | \begin{displaymath} 57 | Ver(k, m, Mac(k,m)) = 1 58 | \end{displaymath} 59 | 60 | Consideraremos um modelo de ameaças bem poderoso contra um sistema MAC. 61 | Como no modelo CPA, vamos supor que o adversário tem acesso a um oráculo que lhe dá o código de autenticação de mensagens escolhidas por ele. 62 | O desafio do adversário é produzir qualquer par $\langle m, t \rangle$ válido para a chave escolhida pelo sistema. 63 | Um sistema em que nenhum adversário polinomial é capaz de derrotar desta maneira com probabilidade considerável será chamado de {\em seguro contra falsificação} \cite{Bellare00}. 64 | Formalmente: 65 | \begin{enumerate} 66 | \item O sistema gera uma chave $k$ usando o algoritmo $Gen$ 67 | \item O adversário $\mathcal{A}$ recebe $1^n$ e tem acesso a um oráculo $Mac_k$ que ele pode usar para verificar o código que o sistema produziria. Seja $Q$ o conjunto das mensagens consultadas por $\mathcal{A}$. 68 | \item O adversário $\mathcal{A}$ produz um par $\langle m, t \rangle$ tal que $m \notin Q$. 69 | \end{enumerate} 70 | 71 | \begin{center} 72 | \begin{tikzpicture}[node distance=2cm,auto,>=latex] 73 | \tikzset{ 74 | player/.style={draw,shape=rectangle,rounded corners,minimum width=4em,minimum height=6em} 75 | } 76 | \node[player] (system) {$\Pi$}; 77 | \node[player] (adversary) at (10,0) {$\mathcal{A}$}; 78 | \draw[->] (9,0.5) -> node[above]{$q_0, \dots, q_{n'-1} \in M \setminus \{m\}$} (1,0.5); 79 | \draw[->] (1,-0.5) -> node[above]{$Mac(k, q_0), \dots, Mac(k, q_{n'-1})$} (9,-0.5); 80 | \draw[->] (0,2) -> node{$Gen(1^n) = k$} (system); 81 | \draw[->] (adversary) -> node{$\langle m, t \rangle$} (10,-2); 82 | \end{tikzpicture} 83 | \end{center} 84 | 85 | O desafio de $\mathcal{A}$ é produzir um par válido. 86 | Chamamos o experimento de $MacForge_{\mathcal{A}, \Pi}$: 87 | \begin{displaymath} 88 | MacForge_{\Pi, \mathcal{A}}(n) = Ver(k, m, t) 89 | \end{displaymath} 90 | 91 | Um sistema de autenticação de mensagem $\Pi = \langle Gen, Mac, Ver \rangle$ é {\em seguro contra falsificação} se para todo adversário eficiente $\mathcal{A}$ existe uma função desprezível $\varepsilon$ tal que: 92 | \begin{displaymath} 93 | Pr[MacForge_{\Pi, \mathcal{A}}(n) = 1] \leq \frac{1}{2} + \varepsilon(n) 94 | \end{displaymath} 95 | 96 | O modelo de ataque considerado garante que um adversário não seja capaz de gerar código para uma mensagem nova, isto é, uma mensagem que não foi consultada. 97 | Em alguns casos espeíficos queremos garantir também que o adversário não seja capaz de produzir outros tags válidos para uma mesma mensagem. 98 | Este modelo de ataque é mais poderoso e chamaremos de {\em segurança forte contra falsificação}. 99 | 100 | \subsection{CBC-MAC} 101 | \label{sec:cbc-mac} 102 | 103 | Agora que conhecemos o sistema de autenticação de mensagem e definimos uma noção de segurança, resta mostrar concretamente como construir tal sistema explicitando nossas suposições. 104 | Começaremos com uma construção básica para uma mensagem de tamanho fixo baseada no modo CBC. 105 | Vamos supor que $|m| = l.n$ em que $n$ é o tamanho do bloco de uma PRF $f$ e escreveremos $m = m_1 \dots m_l$ tal que $|m_i| = n$. 106 | Temos então que: 107 | 108 | 109 | \begin{itemize} 110 | \item $Mac(k, m) := t_l$ em que: 111 | \begin{eqnarray*} 112 | t_0 & := & 0^n \\ 113 | t_i & := & f_k(t_{i-1} \xor m_i) \textrm{ para i } = 1, \dots, l 114 | \end{eqnarray*} 115 | Além disso, $|m_i| = n$ e $f_k: \{0,1\}^n \to \{0,1\}^n$ é uma função pseudoaleatória. 116 | \item $Ver(k, m, t) := \left\{ 117 | \begin{array}{lcl} 118 | 1 & \textrm{se} & t = Mac(k,m)\\ 119 | 0 & \textrm{c.c.} &\\ 120 | \end{array} 121 | \right.$ 122 | \end{itemize} 123 | 124 | \begin{center} 125 | \begin{tikzpicture}[node distance=2cm,auto,>=latex] 126 | \node (m1) at (0,0) {$m_1$}; 127 | \node (m2) at (2,0) {$m_2$}; 128 | \node (xor2) at (2,-2) {$\xor$}; 129 | \node (m3) at (4,0) {$m_3$}; 130 | \node (xor3) at (4,-2) {$\xor$}; 131 | \node at (6,0) {\dots}; 132 | \node at (6,-2) {\dots}; 133 | \node (ml) at (8,0) {$m_l$}; 134 | \node (xorl) at (8,-2) {$\xor$}; 135 | \node (t) at (10,-2) {$t$}; 136 | \draw[-] (m1) -> (0,-2); 137 | \draw[->] (0,-2) -> node[above]{$f_k$}(xor2); 138 | \draw[->] (m2) -> (xor2); 139 | \draw[->] (xor2) -> node[above]{$f_k$}(xor3); 140 | \draw[->] (m3) -> (xor3); 141 | \draw[->] (ml) -> (xorl); 142 | \draw[->] (7,-2) -> node[above]{$f_k$}(xorl); 143 | \draw[->] (xorl) -> (t); 144 | \end{tikzpicture} 145 | \end{center} 146 | 147 | 148 | \begin{theorem} 149 | O sistema de autenticação $\Pi = \langle Gen, Mac, Ver \rangle$ como definido acima é seguro contra falsificação para mensagens de tamanho fixo $l.n$. 150 | \end{theorem} 151 | 152 | O sistema CBC-MAC é diferente do modo de operação CBC em dois aspectos essenciais: o MAC usa um bloco de $0$s onde o modo de operação usa um vetor inicial aleatório e o MAC expõe apenas o bloco final enquanto o modo de operação expõe cada um dos blocos cifrados. 153 | É possível mostrar que ambas as diferenças são cruciais para garantir a segurança contra falsificação. 154 | 155 | Para extender esta construção para mensagens de tamanho arbitrários temos duas opções para as quais há demonstração de segurança contra falsificação: 156 | \begin{enumerate} 157 | \item concatenar o tamanho da mensagem $|m|$ no começo da mensagem antes de produzir $t$ (concatenar no final não é seguro!). 158 | \item gerar duas chaves independentes $k_1$ e $k_2$, usar a primeira no sistema apresentado acima e então computar $f_{k_2}(t)$ para gerar o código de autenticação. 159 | \end{enumerate} 160 | 161 | \section{Criptografia Autenticada} 162 | \label{label} 163 | 164 | O modelo de ameaças CPA assume que o adversário tem acesso a um oráculo $E_k$ que indica como mensagens escolhidas por ele podem seria criptografadas pelo sistema. 165 | Com autenticação somos capaz de construir sistemas contra um modelo de ameaça ainda mais poderoso em que o adversário tem acesso a um oráculo em que ele pode consultar como determinadas cifras seriam decifradas. 166 | Esse modelo de ameaças supõe um enorme poder por parte do adversário e é difícil encontrar exemplos práticos em que esse tipo de situação ocorra. 167 | Ainda assim, é bastante interessante saber que é possível construir sistemas seguros contra este tipo de ameaça \cite{Naor90}. 168 | 169 | Formalmente definimos um jogo da seguinte maneira: 170 | \begin{enumerate} 171 | \item O adversário $\mathcal{A}$ escolhe duas mensagens $m_0$ e $m_1$ com o mesmo tamanho ($|m_0| = |m_1|$) e envia para o sistema $\Pi$. 172 | \item O sistema gera uma chave $k$ usando o algoritmo $Gen$ e sorteia aleatoriamente uma das mensagens para criptografar ($\Pi$ sorteia $b \leftarrow \{0, 1\}$ e criptografa $m_b$). 173 | \item Durante todo o processo $\mathcal{A}$ possui acesso a um oráculo $E_k$ que ele pode usar para verificar como seria criptografadas qualquer mensagem $m$ e outro oráculo $D_k$ que ele pode usar para verificar como qualquer cifra $c$, exceto a cifra devolvida pelo sistema, seria decifrada. 174 | \item A cifra produzida $E(k, m_b) = c$ e enviada de volta para o adversário. 175 | \item O adversário $\mathcal{A}$ produz um bit $b' \in \{0,1\}$. 176 | \end{enumerate} 177 | 178 | \begin{center} 179 | \begin{tikzpicture}[node distance=2cm,auto,>=latex] 180 | \tikzset{ 181 | player/.style={draw,shape=rectangle,rounded corners,minimum width=6em,minimum height=15em} 182 | } 183 | \node[player] (system) {$\Pi$}; 184 | \node[player] (adversary) at (10,0) {$\mathcal{A}$}; 185 | \draw[->] (8.8,2) -> node[above]{$m_0, m_1 \in M : |m_0| = |m_1|$} (1.2,2); 186 | \draw[->] (8.8,1) -> node[above]{$q_0, \dots, q_{n'-1} \in M$} (1.2,1); 187 | \draw[->] (1.2,0) -> node[above]{$E(k, q_0), \dots, E(k, q_{n'-1})$} (8.8,0); 188 | \draw[->] (8.8,-1) -> node[above]{$q_0', \dots q_{n'-1}' \in C \setminus\{c\}$} (1.2,-1); 189 | \draw[->] (1.2,-2) -> node[above]{$D(k,q_1'), \dots, D(k,q_{n'-1}')$} (8.8,-2); 190 | \draw[->] (1.2,-3) -> node[above]{$E(k,m_b) = c$} (8.8,-3); 191 | \draw[->] (0,4) -> node{$b \leftarrow \{0,1\}$} (system); 192 | \draw[->] (adversary) -> node{$b' \in \{0,1\}$} (10,-4); 193 | \end{tikzpicture} 194 | \end{center} 195 | 196 | 197 | O desafio de $\mathcal{A}$ é acertar qual das mensagens foi criptografada. 198 | Como nos outros casos temos: 199 | \begin{displaymath} 200 | PrivK^{cca}_{\Pi, \mathcal{A}}(n) = \left\{ 201 | \begin{array}{lcl} 202 | 1 & \textrm{se} & b = b'\\ 203 | 0 & \textrm{c.c.} &\\ 204 | \end{array} 205 | \right. 206 | \end{displaymath} 207 | 208 | Dizemos que um sistema $\Pi = \langle Gen, E, D \rangle$ é seguro contra ataques do tipo {\em chosen ciphertext} (CCA) se para todo adversário eficiente $\mathcal{A}$ existe uma função desprezível $\varepsilon$ tal que: 209 | \begin{displaymath} 210 | Pr[PrivK^{cca}_{\Pi, \mathcal{A}}(n) = 1] \leq \varepsilon(n) 211 | \end{displaymath} 212 | 213 | Note que os sistemas que não protegem a integridade da mensagem não são seguros contra CCA. 214 | Por exemplo considere uma cifra de bloco no modo Ctr. 215 | O adversário pode derrotar o jogo acima da seguinte forma: 216 | \begin{enumerate} 217 | \item $\mathcal{A}$ envia $m_0 = 0^n$ e $m_1 = 1^n$ para o sistema. 218 | \item $\mathcal{A}$ recebe $c = E(k, m_b)$ e altera o primeiro bit de $c$ para produzir $c' \neq c$. 219 | \item $\mathcal{A}$ consulta o oráculo $D_k(c')$ e verifica o resultado. 220 | \item Se o resultado for $10^{n-1}$ o adversário devolve $0$, caso seja $01^{n-1}$ ele devolve $1$. 221 | \end{enumerate} 222 | 223 | Em um {\em sistema de criptografia autenticado} $\Pi$ o sistema ao descriptografar uma cifra $c$ deve acusar se ela não é válida devolvendo uma mensagem de erro. 224 | Em nossa apresentação formal, $D(k,c) = \bot$ nestes casos. 225 | Uma noção de segurança útil neste contexto é a capacidade de um sistema impedir que um adversário produza uma cifra válida. 226 | Um sistema de criptografia $\Pi = \langle Gen, E, D \rangle$ é {\em seguro contra falsificação} se satisfizer essa noção de segurança. 227 | (Omitiremos a formalização da definição de segurança contra falsificação que é análga a definição apresentada no final da Seção \ref{sec:mac}). 228 | Por fim, chamaremos um sistema $\Pi$ de {\em sistema autenticado de criptografia} se $\Pi$ é seguro contra CCA e contra falsificação. 229 | 230 | %Formalmente temos o seguinte jogo: 231 | %\begin{enumerate} 232 | %\item O sistema gera uma chave $k$ usando o algoritmo $Gen$. 233 | %\item Durante todo o processo $\mathcal{A}$ possui acesso a um oráculo $E_k$ que ele pode usar para verificar como seria criptografadas qualquer mensagem $m$. 234 | %\item O adversário $\mathcal{A}$ produz uma cifra $c$ tal que $E(k,m) \neq c$ para todos as consultas $m$ que o adversário fez ao oráculo. 235 | %\end{enumerate} 236 | 237 | %O desafio de $\mathcal{A}$ é produzir $c$ tal que $D(k,c) \neq \bot$: 238 | %\begin{displaymath} 239 | % EncForge_{\Pi, \mathcal{A}}(n) = \left\{ 240 | % \begin{array}{lcl} 241 | % 1 & \textrm{se} & D(k,c) \neq \bot\\ 242 | % 0 & \textrm{c.c.} &\\ 243 | % \end{array} 244 | % \right. 245 | %\end{displaymath} 246 | 247 | %Um sistema de criptografia $\Pi = \langle Gen, E, D \rangle$ é {\em seguro contra falsificação} se para todo adversário $\mathcal{A}$ eficiente temos que existe uma função desprezível $\varepsilon$ tal que: 248 | %\begin{displaymath} 249 | % Pr[EncForge_{\mathcal{A},\Pi}(n) = 1] \leq \varepsilon(n) 250 | %\end{displaymath} 251 | 252 | 253 | Um sistema autenticado de criptografia é uma combinação de um esquema de criptografia com um sistema de autenticação. 254 | Existem várias formas de combinar esses sistemas: 255 | \begin{itemize} 256 | \item {\em mac then encrypt}: produzimos um código de autenticação, juntamos esse código com a mensagem e criptografamos tudo. 257 | \item {\em encrypt and mac}: enviamos separadamente a cifra e um código de autenticação da mensagem. 258 | \item {\em encrypt then mac}: primeiro criptografamos e depois geramos o código da cifra. 259 | \end{itemize} 260 | 261 | Se nossa esquema de criptografia $\Pi_E = \langle Gen_E, E, D\rangle$ for seguro contra CPA e nosso sistema de autenticação $\Pi_M = \langle Gen_M, Mac, Ver \rangle$ for fortemente seguro contra falsificação, podemos demonstrar que o paradigma {\em encrypt then mac} é um {\em sistema autenticado de criptografia}, ou seja, é seguro contra CCA e contra falsificação. 262 | Formalmente construimos o sistema $\langle Gen, E, D \rangle$ da seguinte forma: 263 | \begin{itemize} 264 | \item $Gen(1^n) := k = \langle k_E, k_M \rangle$ em que $Gen_E(1^n) := k_E$ e $Gen_M(1^n) := k_M$. 265 | \item $E(k,m) := \langle c, t \rangle$ em que $E(k_E, m) := c$ e $Mac(k_M, c) := t$. 266 | \item $D(k,c) := \left\{ 267 | \begin{array}{lcl} 268 | D(k_E, c) & \textrm{se} & Ver(k_M, c, t)\\ 269 | \bot & \textrm{c.c.} &\\ 270 | \end{array} 271 | \right.$ 272 | \end{itemize} 273 | 274 | O sistema acima gera chaves independentes $k_E$ e $k_M$ para os sistemas. 275 | Isso não é apenas um detalhe, o uso da mesma chave de criptografia e autenticação pode causar sérios problemas de segurança. 276 | 277 | 278 | \begin{example} 279 | Considere uma permutação pseudoaleatória $p$, escolha $r \leftarrow\{0,1\}^{n/2}$ e criptografe $m \in \{0,1\}^{n/2}$ da seguinte forma: 280 | \begin{displaymath} 281 | E(k,m) = p_k(m||r) 282 | \end{displaymath} 283 | É possível mostrar que um sistema como esse é seguro contra CPA. 284 | 285 | Agora considere um MAC que usa $p^{-1}$ para produzir o código: 286 | \begin{displaymath} 287 | Mac(k,c) = p_k^{-1}(c). 288 | \end{displaymath} 289 | Também é possível mostrar que esse MAC é seguro contra falsificação. 290 | Porém, quando aplicamos o pardigma {\em encrypt then mac} nesses sistemas temos que: 291 | \begin{eqnarray*} 292 | E(k,m), Mac(k, E(k,m)) & = & p_k(m||r), p_k^{-1}(p_k(m||r))\\ 293 | & = & p_k(m||r), m||r 294 | \end{eqnarray*} 295 | Neste caso o código de autenticação vaza todo o conteúdo da mensagem! 296 | \end{example} 297 | 298 | \subsection{Comunicação Segura} 299 | \label{sec:comunicacao-segura} 300 | 301 | Um sistema autenticado de criptografia garante a confidencialidade, a integridade e a autenticidade na comunicação. 302 | Existem, porém, outros tipos de ameaça que esse sistema não garante por si só: 303 | \begin{itemize} 304 | \item {\em ataque de reordenação:} um adversário pode embaralhar a ordem de mensagens seguras de forma a produzir um resultado malicioso. 305 | \item {\em ataque de repetição:} um adversário pode encaminhar duas vezes uma mensma mensagem segura, por exemplo exigindo duas vezes um mesmo pagamento legítimo. 306 | \item {\em ataque de reflexão:} um adversário pode enviar de volta para o próprio remetente uma mensagem como se fosse do destinatário. 307 | \end{itemize} 308 | 309 | Esses ataques tem soluções simples, mas que precisam ser tratadas quando produzimos um protocolo completo de comunicação segura. 310 | Para resolver os dois primeiros problemas podemos manter um contador do número de mensagens $ctr_{AB}$ de $A$ para $B$ e $ctr_{BA}$ de $B$ para $A$. 311 | O terceiro ataque pode ser resolvido inserindo um bit na mensagem que indique sua direção $b_{AB}$ é $1$ se a mensagem foi de $A$ para $B$ e $0$ caso contrário. 312 | Outra possível solução para o terceiro problema é manter duas chaves independentes: uma $k_{AB}$ para a comunicação de $A$ para $B$ e outra $k_{BA}$ para a comunicação de $B$ para $A$. 313 | Tanto o contador $ctr_{AB}$ quanto o bit de direção $b_{AB}$ devem ser concatenados a mensagem antes de criptografá-la. 314 | No Capítulo \ref{cha:protocolos} veremos protocolos completos de segurança e voltaremos nesses detalhes. 315 | 316 | Aqui encerramos os sistemas de criptografias que se baseiam no modelo simétrico. 317 | Seguindo a abordagem moderna explicitamos as suposições necessária para provar a segurança de diversos sistemas de criptografia e autenticação. 318 | O apêndice \ref{cha:owf} busca encontrar a suposição mínima que precisamos fazer para conseguir construir os sistemas que vimos até aqui, a saber, a existência de {\em funções de mão única}. 319 | Além de servir como um bom resumo do que vimos até aqui, o apêndice procure justificar o porquê precisamos partir de determinadas suposições e não simplesmente provamos essas propriedades para cada sistema. 320 | 321 | \section{Exercicios} 322 | \label{sec:exercicios} 323 | 324 | 325 | \begin{exercicio} 326 | Considere que o adversário sabe que a mensagem $m = 101010$ foi cifrada por uma cifra de fluxo e produziu $c = 110001$. 327 | Que sequencia de bits $c'$ ele precisa enviar para o destinatário para fazer com que ele ache que a mensagem original era $m' = 001011$? 328 | \end{exercicio} 329 | 330 | 331 | \begin{exercicio} 332 | Mostre que a função $encode$ que insere o tamanho da mensagem no começo e completa o último bloco com uma sequência de $0$s não admite prefixo. 333 | \end{exercicio} 334 | 335 | \begin{exercicio} 336 | Seja $f$ uma função pseudo-aleatória e considere o sistema $\Pi = \langle Gen, E, D \rangle$ uma cifra de bloco que aplica $f$ no modo contador. 337 | Suponha que Alice e Bob compartilham uma chave secreta $k$. 338 | Considere os seguintes cenários: 339 | \begin{enumerate} 340 | \item Alice enviar $E(k, m)$ para Bob que descriptografa usando a chave $k$ 341 | \item Alice gera um checksum $H(m)$ da mensagem e envia $H(m)||m$ para Bob que pode verificar o checksum antes de ler a mensagem 342 | \end{enumerate} 343 | Algum desses cenários garante que a mensagem lida por Bob é idêntica a mensagem que foi enviada por Alice? Por que? Caso nenhum dos cenários garanta isso, descreva como poderíamos fazê-lo. 344 | \end{exercicio} 345 | --------------------------------------------------------------------------------