Exercícios MT2

O texto cifrado é $01101100$.

No one-time pad, cada bit do texto cifrado é o XOR do bit da mensagem com o bit da chave: $1oplus1=0$, $0oplus1=1$, $0oplus1=1$, $1oplus1=0$, $1oplus0=1$, $1oplus0=1$, $0oplus0=0$, $0oplus0=0$, obtendo $01101100$.

• $01101100$. O one-time pad faz XOR bit a bit: $10011100 oplus 11110000 = 01101100$.
• $11111100$. Esse valor resulta de somar em vez de fazer XOR.
• $10010000$. Esse valor resulta de aplicar AND aos bits.
• $10010011$. Esse valor não corresponde a nenhuma operação bit a bit entre a mensagem e a chave.

Porque os textos cifrados revelam padrões (por exemplo, frequências de letras) das mensagens originais.

Numa cifra de substituição monoalfabética, cada letra é sempre substituída pela mesma letra do alfabeto, pelo que as frequências relativas se mantêm. Um atacante pode explorar esses padrões com análise de frequências para recuperar a mensagem.

• Porque a cifra substitui letras por outras, permitindo ler parte da mensagem original. A substituição em si não torna a mensagem legível sem a chave.
• Porque o espaço de chaves é demasiado pequeno e um computador moderno testa a chave por força bruta. O problema não é o tamanho do espaço de chaves, mas a preservação de padrões estatísticos.
• Porque um adversário pode adulterar a mensagem subjacente alterando o texto cifrado. Isso descreve um problema de integridade, não de confidencialidade.
• Porque os textos cifrados resultantes revelam padrões das mensagens cifradas. A substituição preserva frequências de letras, permitindo análise de frequências.

Uma colisão ocorre quando $m_1 \neq m_2$ mas $H(m_1) = H(m_2)$.

Uma função de hash não é injetiva em geral: o espaço de entradas é maior que o de saídas. Uma colisão é precisamente um par de mensagens distintas com o mesmo valor de hash, e a resistência a colisões exige que seja computacionalmente inviável encontrar esse par.

• Se $m_1 \neq m_2$ e $H(m_1)$ produz uma saída com um prefixo semelhante ao de $H(m_2)$. Semelhança de prefixos não é o conceito de colisão.
• Se $m_1 \neq m_2$ e $H(m_1)$ produz a mesma saída que $H(m_2)$. É a definição exata de colisão.
• Acontece quando duas funções de hash percorrem direções opostas. Não tem significado criptográfico.
• Se $m_1 = m_2$ e $H(m_1)$ produz a mesma saída que $H(m_2)$. Entradas iguais não são uma colisão.

O não repúdio não é assegurado.

A cifragem autenticada simétrica garante confidencialidade (cifra) e integridade/autenticidade de origem (MAC com chave partilhada). Como a mesma chave secreta é conhecida pelas duas partes, nenhuma delas pode negar ter gerado a etiqueta, pelo que o não repúdio exige criptografia de chave pública com assinatura digital.

• Não repúdio. Como a chave é partilhada, qualquer das partes pode ter produzido o MAC, logo não há não repúdio.
• Integridade. É precisamente o que o MAC acrescenta à cifra.
• Correção. A decifra devolve a mensagem original quando a verificação passa.
• Confidencialidade. É a garantia base da cifra simétrica.

O RSA simples não garante confidencialidade porque é determinístico.

Como c = m^e mod n não usa qualquer valor aleatório, cifrar a mesma mensagem duas vezes produz o mesmo texto cifrado, o que permite detetar repetições e facilita ataques. Na prática usa-se RSA-OAEP, com preenchimento aleatório (padding), que torna a cifra probabilística.

• Este esquema não garante confidencialidade porque é determinístico. Sem aleatoriedade, cifrar duas vezes a mesma mensagem dá o mesmo texto cifrado.
• Este esquema não garante confidencialidade porque, dada um texto cifrado, um adversário recupera a mensagem. Recuperar $m$ a partir de $c$ sem $d$ equivale a resolver o problema RSA.
• Este esquema é seguro contra computadores quânticos. O algoritmo de Shor quebra o RSA com um computador quântico.
• Este esquema é seguro se a fatorização de inteiros for um problema computacionalmente difícil. Essa é a condição de segurança do RSA, mas não resolve por si a falta de confidencialidade da cifra determinística.

O não repúdio.

Um MAC usa uma chave simétrica partilhada, pelo que qualquer conhecedor da chave pode produzi-lo: não permite atribuir a autoria a uma entidade concreta. Uma assinatura digital usa a chave privada do signatário, pelo que só esse signatário a pode ter gerado, garantindo não repúdio.

• Unicidade. Não é o conceito em causa.
• Não repúdio. Só o titular da chave privada pode assinar, logo não pode negar a autoria.
• Anonimato. As assinaturas não dão anonimato.
• Integridade. Tanto a assinatura como o MAC garantem integridade.

Cifra-se com $pk_B$ e assina-se com $sk_A$.

Para confidencialidade, cifra-se com a chave pública do destinatário ($pk_B$), de modo a que só o Bob, com $sk_B$, decifre. Para autenticidade e não repúdio, assina-se com a própria chave privada ($sk_A$), que só a Alice possui.

• Cifrar com $sk_B$; assinar com $pk_A$. Usa as chaves no papel errado: cifra com a privada e assina com a pública.
• Cifrar com $pk_B$; assinar com $sk_A$. Só o Bob pode decifrar (chave privada $sk_B$) e só a Alice pode ter assinado ($sk_A$).
• Cifrar com $sk_A$; assinar com $pk_B$. Usa as chaves no papel errado.
• Cifrar com $pk_A$; assinar com $sk_B$. A cifra ficaria apenas decifrável pela Alice e a assinatura seria do Bob.

$k \leftarrow \mathrm{Dec}(sk, c_2)$ e depois $m \leftarrow \mathrm{Dec}(k, c_1)$.

A chave de sessão $k$ foi cifrada com a chave pública do destinatário, logo só a chave privada correspondente ($sk$) a recupera. Com $k$ recuperada, decifra-se o corpo $c_1$ com a cifra simétrica. Assim, a morosidade da cifra assimétrica aplica-se apenas a uma chave curta.

• $k \leftarrow \mathrm{Dec}(pk, c_2)$; $m \leftarrow \mathrm{Dec}(k, c_1)$. A decifra de $c_2$ exige a chave privada, não a pública.
• $k \leftarrow \mathrm{Dec}(sk, c_2)$; $m \leftarrow \mathrm{Dec}(k, c_1)$. O destinatário usa a sua chave privada para recuperar $k$ e depois decifra o corpo da mensagem.
• $m \leftarrow \mathrm{Dec}(sk, c_1, c_2)$. Não existe uma decifra conjunta assim.
• $k \leftarrow \mathrm{Dec}(sk, c_1)$; $m \leftarrow \mathrm{Dec}(c_1, c_2)$. Troca os papéis de $c_1$ e $c_2$.

3 bits da mensagem original ficam afetados.

No modo CTR, $c_i = p_i oplus E(k, N | i)$, pelo que a decifra é $p_i = c_i oplus E(k, N | i)$. Alterar 3 bits de $c_1$ altera apenas os mesmos 3 bits de $p_1$; não há propagação de erro como no CBC.

• 19 bits. Esse valor não corresponde a nenhum efeito do CTR.
• 0 bits. Os bits alterados propagam-se para a mensagem.
• 16 bits. No CTR não há encadeamento de blocos, logo não se perde o bloco inteiro.
• 3 bits. No modo CTR cada bloco de texto cifrado é XOR com o keystream; alterar 3 bits do bloco afeta exatamente esses 3 bits da mensagem.

É MAC-then-Encrypt (MtE).

A etiqueta $t$ é calculada sobre a mensagem em claro $m$ e só depois o conjunto $m | t$ é cifrado com a chave $k_2$. Essa ordem, MAC sobre o texto em claro seguido de cifra, caracteriza o modo MAC-then-Encrypt.

• MAC-and-Encrypt. Nesse modo o MAC de $m$ é enviado ao lado do texto cifrado de $m$, não dentro dele.
• MAC-then-Encrypt. Calcula-se primeiro o MAC sobre $m$ e depois cifra-se $m | t$.
• Encrypt-and-MAC. Nesse modo cifra-se $m$ e calcula-se o MAC em paralelo.
• Encrypt-then-MAC. Nesse modo cifra-se primeiro e calcula-se o MAC sobre o texto cifrado.

A Alice calcula $Y^x = g^{xy}$ e o Bob calcula $X^y = g^{xy}$; esse valor comum é o segredo partilhado.

Cada parte eleva o valor recebido à sua chave privada: $Y^x = (g^y)^x = g^{xy}$ e $X^y = (g^x)^y = g^{xy}$. Um atacante que só vê $g$, $g^x$ e $g^y$ enfrenta o problema do logaritmo discreto para obter $g^{xy}$.

• $g^x$ e $g^y$ são o mesmo valor e podem ser usados como segredo. Em geral $g^x \neq g^y$.
• A Alice calcula $Y^x$ e o Bob calcula $X^y$, sendo ambos iguais a $g^{xy}$. $(g^y)^x = g^{xy} = (g^x)^y$.
• A Alice calcula $g^{xy}$ e envia-o ao Bob. A Alice não conhece $y$, logo não pode calcular $g^{xy}$ diretamente.
• O segredo é $g$ dividido por $x y$. Não existe essa operação no protocolo.

Estabelecer o material criptográfico e os parâmetros para a comunicação.

Durante o handshake, cliente e servidor autenticam-se (tipicamente o servidor via certificado), concordam cifras e parâmetros e derivam as chaves de sessão que o protocolo de registo usa depois para cifrar e autenticar os dados.

• Divulgar a identidade dos participantes no canal. A identidade não é o objetivo central do handshake.
• Notificar regularmente a vitalidade do canal. Isso não é função do handshake.
• Estabelecer o material criptográfico e os parâmetros da comunicação. É o que o handshake negoceia antes da troca de dados.
• Cifrar e decifrar as mensagens trocadas no canal. Isso é papel do protocolo de registo, não do handshake.

O TLS valida as chaves públicas através de certificados da PKI e usa-as para estabelecer uma chave simétrica de sessão.

Numa sessão HTTPS habitual, o servidor apresenta um certificado X.509 emitido por uma autoridade de certificação; o cliente valida a assinatura desse certificado (confiando na raiz da PKI) e usa a chave pública autenticada do servidor para estabelecer, por exemplo via (EC)DHE, uma chave simétrica de sessão.

• A Alice e o Bob usam canais TLS para trocar chaves simétricas, que depois cifram as chaves públicas. As chaves públicas não são cifradas com chaves de sessão.
• As PKI usam canais TLS para comunicar certificados, que transportam chaves simétricas. Os certificados transportam chaves públicas, não simétricas.
• As assinaturas digitais autenticam chaves simétricas, que depois autenticam os utilizadores no protocolo TLS. Confunde o papel das assinaturas no handshake.
• O TLS usa certificados de uma PKI para validar chaves públicas, que são depois usadas para estabelecer uma chave simétrica e criar um canal seguro. Descreve corretamente a cadeia de confiança e a derivação da chave de sessão.

Porque o IPsec opera na camada de rede e autentica o conteúdo dos cabeçalhos IP.

Com o Authentication Header (AH), o IPsec calcula um MAC sobre o cabeçalho IP (incluindo os endereços de origem e destino), pelo que pacotes com endereços forjados falham a verificação. O TLS opera acima da camada de rede e não protege o cabeçalho IP.

• Porque o IPsec usa mecanismos de cifra mais fortes que o TLS. A força da cifra não é o que impede o spoofing.
• Porque o IPsec existe na camada de rede e pode validar o conteúdo dos cabeçalhos IP. O AH/ESP autenticam o cabeçalho IP, detetando endereços forjados.
• Porque o IPsec é usado em firewalls, que validam origem e destino dos pacotes. Isso descreve a filtragem da firewall, não o IPsec.
• Devido ao protocolo de acordo de algoritmos usado no IPsec. O acordo de algoritmos não impede o spoofing.

Um Rogue DHCP é um servidor DHCP falso na rede local que responde aos pedidos dos clientes antes do servidor legítimo, distribuindo como gateway ou servidor DNS uma máquina do atacante. Assim, o tráfego da vítima passa pela máquina do atacante, que pode intercetá-lo ou modificá-lo (man-in-the-middle).

O DHCP não autentica as respostas: o cliente aceita o primeiro servidor que responder. Se o atacante colocar um servidor falso na rede, consegue indicar-se a si próprio como gateway padrão ou como DNS, fazendo passar por si todo o tráfego da vítima, que pode então ler ou alterar antes de reencaminhar.

O código é vulnerável a injeção SQL: os valores de username e userpassword são concatenados diretamente no texto da consulta, sem qualquer escapagem ou consulta parametrizada.

Se o utilizador introduzir " OR "1"="1 no campo do nome, a consulta torna-se SELECT * FROM Users WHERE Name ="" OR "1"="1" AND Pass ="...", que é verdadeira para todas as linhas, permitindo autenticação sem palavra-passe. A correção passa por consultas parametrizadas (prepared statements), que tratam os dados como dados e nunca como código SQL.

No XSS refletido, o script malicioso é injetado num pedido da vítima (por exemplo, num parâmetro do URL) e o servidor devolve-o na resposta, sem o validar. No XSS armazenado, o script é guardado permanentemente no servidor (por exemplo, num comentário ou perfil) e é servido a todas as vítimas que acedem à página afetada.

Em ambos os casos o navegador da vítima executa código JavaScript do atacante no contexto da origem legítima. A diferença está na persistência: o refletido exige enganar a vítima para seguir um link especial, enquanto o armazenado persiste no servidor e atinge automaticamente todos os visitantes, sendo potencialmente muito mais grave. A defesa comum é a sanitização/validação de todas as entradas e a codificação das saídas consoante o contexto.

No servidor A, uma fuga expõe diretamente as palavras-passe. No servidor B, os hashes sem salt podem ser atacados com tabelas rainbow ou dicionários pré-computados, e utilizadores com a mesma palavra-passe têm o mesmo hash. No servidor C, o salt aleatório e único por utilizador inviabiliza as tabelas pré-computadas e obriga a um ataque de força bruta individual por conta, aumentando muito o custo do ataque.

O salt não torna o hash mais forte por si só, mas elimina os atalhos coletivos: sem salt, um atacante calcula $H(p)$ para milhões de palavras-passe uma única vez e compara com todos os hashes da base de dados. Com salt único por utilizador, cada hash exige um ataque separado, pelo que a fuga de credenciais fica contida.