Cando escoitas a palabra "criptografía", algunhas persoas lembran o seu contrasinal de WiFi, o cadeado verde ao lado do enderezo do seu sitio web favorito e o difícil que é entrar no correo electrónico doutra persoa. Outros lembran unha serie de vulnerabilidades dos últimos anos con abreviaturas indicativas (DROWN, FREAK, POODLE...), logotipos elegantes e un aviso para actualizar urxentemente o teu navegador.

A criptografía abarcao todo, pero esencia de noutro. A cuestión é que hai unha fina liña entre simple e complexo. Algunhas cousas son fáciles de facer, pero difíciles de recompoñer, como romper un ovo. Outras cousas son fáciles de facer pero difíciles de recuperar cando falta unha parte pequena, importante e crucial: por exemplo, abrir unha porta pechada cando a "parte crucial" é a clave. A criptografía estuda estas situacións e como se poden empregar na práctica.

Nos últimos anos, a colección de ataques criptográficos converteuse nun zoolóxico de logotipos rechamantes, cheos de fórmulas de artigos científicos, e orixinou a sensación xeral sombría de que todo está roto. Pero, de feito, moitos dos ataques baséanse nalgúns principios xerais, e moitas páxinas interminables de fórmulas adoitan reducirse a ideas fáciles de entender.

Nesta serie de artigos, analizaremos os diferentes tipos de ataques criptográficos, facendo fincapé nos principios básicos. En termos xerais e non exactamente nesta orde, pero trataremos o seguinte:

• Estratexias básicas: forza bruta, análise de frecuencia, interpolación, degradación e protocolos cruzados.
• Vulnerabilidades de marca: FREAK, CRIME, POODLE, DROWN, Logjam.
• Estratexias avanzadas: ataques de oráculo (ataque Vodenet, ataque Kelsey); método meet-in-the-middle, ataque de aniversario, sesgo estatístico (criptanálise diferencial, criptoanálise integral, etc.).
• Ataques de canles laterais e os seus parentes próximos, métodos de análise de fallos.
• Ataques á criptografía de clave pública: raíz cúbica, transmisión, mensaxe relacionada, ataque Coppersmith, algoritmo Pohlig-Hellman, criba numérico, ataque Wiener, ataque Bleichenbacher.

Este artigo en particular cobre o material anterior ata o ataque de Kelsey.

Estratexias básicas

Os seguintes ataques son sinxelos no sentido de que poden explicarse case por completo sen moitos detalles técnicos. Imos explicar cada tipo de ataque nos termos máis sinxelos, sen entrar en exemplos complexos ou casos de uso avanzados.

Algúns destes ataques quedaron en gran parte obsoletos e non se usaron durante moitos anos. Outros son vellos que aínda se colan regularmente sobre desenvolvedores de criptosistemas desprevenidos no século XXI. A era da criptografía moderna pódese considerar que comezou coa chegada de IBM DES, o primeiro cifrado que resistiu todos os ataques desta lista.

Forza bruta simple

O esquema de cifrado consta de dúas partes: 1) a función de cifrado, que toma unha mensaxe (texto plano) combinada cunha clave e, a continuación, crea unha mensaxe cifrada: texto cifrado; 2) unha función de descifrado que toma o texto cifrado e a clave e produce texto plano. Tanto o cifrado como o descifrado deben ser fáciles de calcular coa clave e difícil de calcular sen ela.

Supoñamos que vemos o texto cifrado e tentamos descifralo sen ningunha información adicional (isto chámase un ataque só con texto cifrado). Se dalgunha maneira atopamos de xeito máxico a chave correcta, podemos verificar facilmente que realmente é correcta se o resultado é unha mensaxe razoable.

Teña en conta que aquí hai dúas suposicións implícitas. En primeiro lugar, sabemos como realizar o descifrado, é dicir, como funciona o sistema criptográfico. Esta é unha suposición estándar cando se fala de criptografía. Ocultar os detalles de implementación do cifrado aos atacantes pode parecer unha medida de seguridade adicional, pero unha vez que o atacante descobre estes detalles, esta seguridade adicional pérdese de forma silenciosa e irreversible. Así é como Principio de Kerchhoff: O sistema que cae en mans do inimigo non debe causar inconvenientes.

En segundo lugar, asumimos que a clave correcta é a única que levará a un descifrado razoable. Esta é tamén unha suposición razoable; cómpre se o texto cifrado é moito máis longo que a clave e é lexible. Isto adoita ser o que ocorre no mundo real, excepto enormes claves pouco prácticas ou outras travesuras que é mellor deixar de lado (se non che gusta que saltamos a explicación, consulta o Teorema 3.8). aquí).

Tendo en conta o anterior, xorde unha estratexia: comprobar todas as claves posibles. Isto chámase forza bruta, e tal ataque está garantido para funcionar contra todos os cifrados prácticos, eventualmente. Por exemplo, a forza bruta é suficiente para piratear cifra César, un cifrado antigo onde a clave é unha letra do alfabeto, o que implica algo máis de 20 claves posibles.

Desafortunadamente para os criptoanalistas, aumentar o tamaño da chave é unha boa defensa contra a forza bruta. A medida que aumenta o tamaño da clave, o número de claves posibles aumenta exponencialmente. Cos tamaños de teclas modernos, a simple forza bruta é totalmente impracticable. Para entender o que queremos dicir, tomemos a supercomputadora máis rápida coñecida a mediados de 2019: Cumio de IBM, cun rendemento máximo dunhas 1017 operacións por segundo. Hoxe, a lonxitude típica da clave é de 128 bits, o que significa 2128 combinacións posibles. Para buscar a través de todas as claves, o supercomputador Summit necesitará un tempo que é aproximadamente 7800 veces a idade do Universo.

A forza bruta debería considerarse unha curiosidade histórica? En absoluto: é un ingrediente necesario no libro de receitas de criptoanálise. Poucas veces os cifrados son tan débiles que só se poden romper por un ataque intelixente, sen o uso da forza nun ou outro grao. Moitos pirateos exitosos usan un método algorítmico para debilitar primeiro o cifrado obxectivo e despois realizar un ataque de forza bruta.

Análise de frecuencia

A maioría dos textos non son galimatías. Por exemplo, nos textos en inglés hai moitas letras 'e' e artigos 'the'; nos ficheiros binarios, hai moitos cero bytes como recheo entre pezas de información. A análise de frecuencia é calquera ataque que aproveite este feito.

O exemplo canónico dun cifrado vulnerable a este ataque é o cifrado de substitución simple. Neste cifrado, a clave é unha táboa con todas as letras substituídas. Por exemplo, "g" substitúese por "h", "o" por j, polo que a palabra "ir" pasa a ser "hj". Este cifrado é difícil de aplicar a forza bruta porque hai moitas táboas de busca posibles. Se estás interesado nas matemáticas, a lonxitude efectiva da clave é duns 88 bits: iso é
. Pero a análise de frecuencia adoita facer o traballo rapidamente.

Considere o seguinte texto cifrado procesado cun cifrado de substitución simple:

XDYLY ALY UGLY XDWNKE WN DYAJYN ANF YALXD DGLAXWG XDAN ALY FLYAUX GR WN OGQL ZDWBGEGZDO

Desde Y ocorre con frecuencia, incluso ao final de moitas palabras, podemos supoñer provisionalmente que esta é a letra e:

XDeLe ALe UGLe XDWNKE WN DeAJeN ANF eALXD DGLAXWG XDAN ALe FLeAUX GR WN OGQL ZDWBGEGZDO

Casal XD repetido ao comezo de varias palabras. En particular, a combinación XDeLe suxire claramente a palabra these ou there, así que imos continuar:

theLE ALe UGLe THWNKE WN HEAJeN ANF EALTH DGLAtWG QUE ALe FLeAUt GR WN OGQL ZDWBGEGZDO

Supoñamos ademais que L corresponde a r, A - a etcétera. Probablemente fará falta algúns intentos, pero en comparación cun ataque de forza bruta completa, este ataque restaura o texto orixinal en pouco tempo:

hai máis cousas no ceo e na terra horatio das que se soña na túa filosofía

Para algúns, resolver tales "criptogramas" é un pasatempo emocionante.

A idea da análise de frecuencia é máis fundamental do que parece a primeira vista. E aplícase a cifras moito máis complexas. Ao longo da historia, varios deseños de cifrado intentaron contrarrestar tal ataque mediante a "substitución polialfabética". Aquí, durante o proceso de cifrado, a táboa de substitución de letras modifícase de xeito complexo pero previsible que depende da clave. Todos estes cifrados foron considerados difíciles de romper a un tempo; e aínda así, a modesta análise de frecuencia acabou por derrotalos a todos.

O cifrado polialfabético máis ambicioso da historia, e probablemente o máis famoso, foi o cifrado Enigma da Segunda Guerra Mundial. Era relativamente complexo en comparación cos seus predecesores, pero despois de moito traballo duro, os criptoanalistas británicos descifraron usando a análise de frecuencia. Por suposto, non poderían desenvolver un ataque elegante como o mostrado arriba; tiveron que comparar pares coñecidos de texto plano e cifrado (o chamado "ataque de texto claro"), provocando incluso que os usuarios de Enigma cifrasen determinadas mensaxes e analizasen o resultado (o "ataque de texto claro escollido"). Pero isto non facilitou o destino dos exércitos inimigos derrotados e dos submarinos afundidos.

Despois deste triunfo, a análise de frecuencias desapareceu da historia da criptoanálise. Os cifrados na era dixital moderna están deseñados para funcionar con bits, non con letras. Máis importante aínda, estes cifrados foron deseñados coa escura comprensión do que máis tarde se coñeceu como Lei de Schneier: Calquera persoa pode crear un algoritmo de cifrado que el mesmo non pode romper. Non é suficiente para o sistema de cifrado parecía difícil: para demostrar a súa valía, debe someterse a unha revisión de seguridade sen piedade por parte de moitos criptoanalistas que farán todo o posible para descifrar o cifrado.

Cálculos preliminares

Tomemos a hipotética cidade de Precom Heights, de 200 habitantes. Cada casa da cidade contén unha media de 000 dólares en obxectos de valor, pero non máis de 30 dólares. O mercado de seguridade en Precom está monopolizado por ACME Industries, que produce as lendarias pechaduras da clase Coyote™. Segundo a análise de expertos, un bloqueo da clase Coyote só pode romperse cunha máquina hipotética moi complexa, cuxa creación require uns cinco anos e un investimento de 000 dólares. A cidade é segura?

O máis probable é que non. Finalmente, aparecerá un criminal bastante ambicioso. Razoará así: “Si, vou incorrer en grandes custos iniciais. Cinco anos de espera paciente e 50 dólares, pero cando remate, terei acceso a toda a riqueza desta cidade. Se xogo ben as miñas cartas, este investimento pagarase por si mesmo moitas veces".

O mesmo ocorre na criptografía. Os ataques contra un cifrado en particular están suxeitos a unha desapiadada análise custo-beneficio. Se a proporción é favorable, o ataque non se producirá. Pero os ataques que funcionan contra moitas vítimas potenciais ao mesmo tempo case sempre pagan os seus froitos, nese caso a mellor práctica de deseño é asumir que comezaron desde o primeiro día. Temos esencialmente unha versión criptográfica da Lei de Murphy: "Calquera cousa que realmente poida romper o sistema romperá o sistema".

O exemplo máis sinxelo dun sistema criptográfico que é vulnerable a un ataque de precomputación é un cifrado sen chave constante. Este foi o caso de Cifrado de César, que simplemente move cada letra do alfabeto tres letras cara adiante (a táboa está en bucle, polo que a última letra do alfabeto está cifrada en terceiro lugar). Aquí de novo entra en xogo o principio de Kerchhoffs: unha vez que un sistema é pirateado, é pirateado para sempre.

O concepto é sinxelo. Incluso un desenvolvedor novato de sistemas criptográficos probablemente recoñecerá a ameaza e se preparará en consecuencia. Mirando a evolución da criptografía, tales ataques foron inadecuados para a maioría dos cifrados, desde as primeiras versións melloradas do cifrado César ata o declive dos cifrados polialfabéticos. Tales ataques só regresaron coa chegada da era moderna da criptografía.

Este retorno débese a dous factores. En primeiro lugar, por fin apareceron criptosistemas suficientemente complexos, onde a posibilidade de explotación despois do hackeo non era obvia. En segundo lugar, a criptografía xeneralizouse tanto que millóns de legos tomaron decisións todos os días sobre onde e que partes da criptografía reutilizar. Pasou algún tempo antes de que os expertos se decataran dos riscos e desen a alarma.

Lembra o ataque previo á computación: ao final do artigo veremos dous exemplos criptográficos reais nos que xogou un papel importante.

Interpolación

Aquí está o famoso detective Sherlock Holmes, realizando un ataque de interpolación contra o desafortunado doutor Watson:

Inmediatamente adivinei que viñeras de Afganistán... O meu pensamento foi o seguinte: “Este home é médico por tipo, pero ten porte militar. Entón, un médico militar. Acaba de chegar dos trópicos: o seu rostro é escuro, pero este non é o ton natural da súa pel, xa que os seus pulsos son moito máis brancos. A cara é demacrada, obviamente, sufriu moito e sufriu enfermidades. Estaba ferido na man esquerda: manténa inmóbil e un pouco antinatural. Onde dos trópicos podería un médico militar inglés soportar dificultades e resultar ferido? Por suposto, en Afganistán". Todo o tren do pensamento non levou nin un segundo. E por iso dixen que viñeches de Afganistán e quedou sorprendido.

Holmes podía extraer moi pouca información de cada proba individualmente. Só puido chegar á súa conclusión considerándoos todos xuntos. Un ataque de interpolación funciona de xeito similar ao examinar os pares coñecidos de texto claro e cifrado que resultan da mesma clave. De cada parella extráense observacións individuais que permiten extraer unha conclusión xeral sobre a clave. Todas estas conclusións son vagas e parecen inútiles ata que de súpeto alcanzan unha masa crítica e conducen á única conclusión posible: por incrible que sexa, debe ser verdade. Despois diso, ou a clave é revelada ou o proceso de descifrado faise tan refinado que pode ser replicado.

Imos ilustrar cun exemplo sinxelo como funciona a interpolación. Digamos que queremos ler o diario persoal do noso inimigo, Bob. Cifra todos os números do seu diario usando un sistema criptográfico sinxelo que coñeceu nun anuncio da revista "A Mock of Cryptography". O sistema funciona así: Bob escolle dous números que lle gustan: и . A partir de agora, para cifrar calquera número , calcula . Por exemplo, se Bob escolleu и , despois o número cifrarase como .

Digamos que o 28 de decembro notamos que Bob estaba rascando algo no seu diario. Cando remate, recollerémolo en silencio e miraremos a última entrada:

Data: 235/520

Querido diario,

Hoxe foi un bo día. A través 64 hoxe teño unha cita con Alisa, que vive nun piso 843. Realmente creo que ela podería ser 26!

Xa que nos tomamos en serio seguir a Bob na súa cita (os dous temos 15 anos neste escenario), é fundamental coñecer a data e o enderezo de Alice. Afortunadamente, notamos que o sistema criptográfico de Bob é vulnerable a un ataque de interpolación. Quizais non o saibamos и , pero sabemos a data de hoxe, polo que temos dous pares texto claro-texto cifrado. É dicir, sabemos que cifrado en E - dentro . Isto é o que imos anotar:

Dende que temos 15 anos xa coñecemos un sistema de dúas ecuacións con dúas incógnitas, que nesta situación é suficiente para atopar и sen ningún problema. Cada par de texto simple-texto cifrado coloca unha restrición na clave de Bob, e as dúas restricións xuntas son suficientes para recuperar completamente a clave. No noso exemplo a resposta é и (ás , así que 26 no diario correspóndese coa palabra 'o único', é dicir, "o mesmo" - aprox. carril).

Os ataques de interpolación, por suposto, non se limitan a exemplos tan sinxelos. Todo sistema criptográfico que se reduce a un obxecto matemático ben entendido e unha lista de parámetros corre o risco de sufrir un ataque de interpolación: canto máis comprensible sexa o obxecto, maior será o risco.

Os recén chegados adoitan queixarse ​​de que a criptografía é "a arte de deseñar cousas o máis feas posible". Os ataques de interpolación probablemente sexan en gran parte os culpables. Bob pode usar un deseño matemático elegante ou manter a súa cita con Alice en privado, pero, por desgraza, normalmente non podes facelo dos dous xeitos. Isto quedará moi claro cando cheguemos ao tema da criptografía de chave pública.

Protocolo cruzado/downgrade

En Now You See Me (2013), un grupo de ilusionistas intenta estafar ao corrupto magnate dos seguros Arthur Tressler de toda a súa fortuna. Para acceder á conta bancaria de Arthur, os ilusionistas deben proporcionar o seu nome de usuario e contrasinal ou obrigalo a aparecer persoalmente no banco e participar no esquema.

Ambas opcións son moi difíciles; Os mozos están afeitos a actuar no escenario, e non participar en operacións de intelixencia. Así que escollen a terceira opción posible: o seu cómplice chama ao banco e fai pasar por Arthur. O banco fai varias preguntas para verificar a identidade, como o nome do tío e o nome da primeira mascota; os nosos heroes con antelación extraen facilmente esta información de Arthur usando enxeñería social intelixente. A partir deste momento, a excelente seguridade do contrasinal xa non importa.

(Segundo unha lenda urbana que verificamos e verificamos persoalmente, o criptógrafo Eli Beaham atopouse unha vez cun caixeiro bancario que insistiu en poñer unha pregunta de seguridade. Cando o caixeiro lle preguntou o nome da súa avoa materna, Beaham comezou a ditar: "X mayúscula, pequeno y, tres... ").

O mesmo pasa en criptografía, se se usan dous protocolos criptográficos en paralelo para protexer o mesmo activo, e un é moito máis débil que o outro. O sistema resultante vólvese vulnerable a un ataque de protocolo cruzado, onde se ataca un protocolo máis débil para chegar ao premio sen tocar o máis forte.

Nalgúns casos complexos, non é suficiente simplemente contactar co servidor mediante un protocolo máis débil, senón que require a participación involuntaria dun cliente lexítimo. Isto pódese organizar mediante o chamado ataque de downgrade. Para entender este ataque, supoñamos que os nosos ilusionistas teñen unha tarefa máis difícil que na película. Supoñamos que un empregado do banco (caixeiro) e Arthur atoparon algunhas circunstancias imprevistas, que deron lugar ao seguinte diálogo:

Ladrón: Ola? Este é Arthur Tressler. Gustaríame restablecer o meu contrasinal.

Caixa: Genial. Bótalle un ollo ao teu libro de códigos secretos persoal, páxina 28, palabra 3. Todas as seguintes mensaxes cifraranse usando esta palabra específica como clave. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV…

Ladrón: Ei, ei, espera, espera. Isto é realmente necesario? Non podemos falar como xente normal?

Caixa: Non recomendo facer isto.

Ladrón: Eu só... mira, tiven un día pésimo, vale? Son un cliente VIP e non estou de humor para explorar estes estúpidos libros de códigos.

Caixa: Ben. Se insiste, señor Tressler. Que queres?

Ladrón: Por favor, gustaríame doar todo o meu diñeiro ao Arthur Tressler National Victims Fund.

(Pausa).

Caixa: Está claro agora. Introduce o teu PIN para transaccións grandes.

Ladrón: O meu que?

Caixa: A túa solicitude persoal, as transaccións deste tamaño requiren un PIN para transaccións grandes. Este código déronche cando abriches a túa conta.

Ladrón:... perdino. Isto é realmente necesario? Non podes simplemente aprobar o acordo?

Caixa: Non. Síntoo, señor Tressler. De novo, esta é a medida de seguridade que pediu. Se queres, podemos enviarlle un novo código PIN á túa caixa de correo.

Os nosos heroes aprazan a operación. Escoitan varias das grandes transaccións de Tressler, coa esperanza de escoitar o PIN; pero cada vez que a conversa se converte en galimatías codificadas antes de que se diga nada interesante. Finalmente, un bo día, o plan ponse en marcha. Agardan pacientemente o momento en que Tressler teña que facer unha gran transacción por teléfono, póñase en liña e despois...

Tressler: Ola. Gustaríame completar unha transacción remota, por favor.

Caixa: Genial. Bota un ollo ao teu libro de códigos secretos persoal, páxina...

(O ladrón preme o botón; a voz do caixeiro convértese en ruído inintelixible).

Caixa: - #@$#@$#*@$$@#* cifrarase con esta palabra como clave. AAAYRR PLRQRZ MMNJK LOJBAN...

Tressler: Perdón, non entendín moi ben. De novo? En que páxina? Que palabra?

Caixa: Esta é a páxina @#$@#*$)#*#@()#@$(#@*$(#@*.

Tressler: Que?

Caixa: Palabra número vinte @$#@$#%#$.

Tressler: En serio! Xa abonda! Ti e o teu protocolo de seguridade sodes unha especie de circo. Sei que podes falar comigo normalmente.

Caixa: Non recomendo…

Tressler: E non che aconsello que perdas o tempo. Non quero saber máis sobre isto ata que soluciones os problemas da túa liña telefónica. Podemos concretar este acordo ou non?

Caixa:… Si. Ben. Que queres?

Tressler: Gustaríame transferir 20 dólares a Lord Business Investments, número de conta...

Caixa: Un minuto, por favor. É unha gran cousa. Introduce o teu PIN para transaccións grandes.

Tressler: Que? Ah, exactamente. 1234.

Aquí hai un ataque á baixa. Imaxinouse o protocolo máis débil "só fala directamente". opción en caso de emerxencia. E aínda así, aquí estamos.

Poderíase preguntar quen no seu sano juicio deseñaría un sistema "seguro ata que se lle pregunte o contrario" como o descrito anteriormente. Pero do mesmo xeito que un banco ficticio corre riscos para reter clientes que non lles gusta a criptografía, os sistemas en xeral adoitan gravitar cara a requisitos que son indiferentes ou ata francamente hostís á seguridade.

Isto é exactamente o que pasou co protocolo SSLv2 en 1995. O goberno dos Estados Unidos comezou a ver a criptografía como unha arma que é mellor manter lonxe dos inimigos estranxeiros e domésticos. As pezas de código foron aprobadas individualmente para a súa exportación desde os Estados Unidos, a miúdo coa condición de que o algoritmo se debilitase deliberadamente. Netscape, o desenvolvedor do navegador máis popular, Netscape Navigator, recibiu permiso para SSLv2 só coa chave RSA de 512 bits inherentemente vulnerable (e 40 bits para RC4).

A finais do milenio, as regras relaxáronse e o acceso á encriptación moderna fíxose amplamente dispoñible. Non obstante, os clientes e servidores soportaron durante anos a criptografía de "exportación" debilitada debido á mesma inercia que mantén a compatibilidade con calquera sistema heredado. Os clientes crían que poderían atopar un servidor que non admitía outra cousa. Os servidores fixeron o mesmo. Por suposto, o protocolo SSL di que os clientes e servidores nunca deben usar un protocolo débil cando hai un mellor dispoñible. Pero a mesma premisa aplicábase a Tressler e ao seu banco.

Esta teoría atopou o seu camiño en dous ataques de alto perfil que sacudiron a seguridade do protocolo SSL en 2015, ambos descubertos por investigadores de Microsoft e INRIA. En primeiro lugar, os detalles do ataque FREAK foron revelados en febreiro, seguidos tres meses despois por outro ataque similar chamado Logjam, que trataremos con máis detalle cando pasemos aos ataques á criptografía de clave pública.

Vulnerabilidade ABERRACIÓN (tamén coñecido como "Smack TLS") saíu á luz cando os investigadores analizaron as implementacións de cliente/servidor de TLS e descubriron un erro curioso. Nestas implementacións, se o cliente nin sequera pide usar unha criptografía de exportación débil, pero o servidor aínda responde con tales claves, o cliente di "Oh ben" e cambia a unha suite de cifrado débil.

Nese momento, a criptografía de exportación considerábase moi obsoleta e fóra dos límites, polo que o ataque foi un choque completo e afectou a moitos dominios importantes, incluíndo a Casa Branca, o IRS e os sitios da NSA. Peor aínda, resulta que moitos servidores vulnerables estaban a optimizar o rendemento reutilizando as mesmas claves en lugar de xerar outras novas para cada sesión. Isto fixo posible, despois de degradar o protocolo, levar a cabo un ataque previo á computación: crackear unha clave seguía sendo relativamente caro (100 dólares e 12 horas no momento da publicación), pero o custo práctico de atacar a conexión reduciuse significativamente. É suficiente seleccionar a clave do servidor unha vez e romper o cifrado para todas as conexións posteriores a partir dese momento.

E antes de seguir adiante, hai un ataque avanzado que hai que mencionar...

Ataque Oracle

Moxie Marlinspike máis coñecido como o pai da aplicación de mensaxería criptográfica multiplataforma Signal; pero persoalmente gústanos unha das súas innovacións menos coñecidas - principio de condena criptográfica (Principio Criptográfico Doom). Parafraseando lixeiramente, podemos dicir isto: “Se o protocolo funciona calquera realiza unha operación criptográfica nunha mensaxe dunha fonte potencialmente maliciosa e compórtase de forma diferente dependendo do resultado, está condenado". Ou nunha forma máis nítida: "Non tome información do inimigo para procesala e, se é necesario, polo menos non mostre o resultado".

Deixemos de lado os desbordamentos de tampón, as inxeccións de comandos e similares; están fóra do alcance desta discusión. A violación do "principio doom" leva a serios ataques de criptografía debido ao feito de que o protocolo se comporta exactamente como se esperaba.

Como exemplo, tomemos un deseño ficticio cun cifrado de substitución vulnerable e, a continuación, demostremos un posible ataque. Aínda que xa vimos un ataque a un cifrado de substitución mediante a análise de frecuencia, non é só "outra forma de romper o mesmo cifrado". Pola contra, os ataques de oráculo son un invento moito máis moderno, aplicable a moitas situacións nas que a análise de frecuencia falla, e veremos unha demostración diso na seguinte sección. Aquí escóllese o cifrado simple só para facer o exemplo máis claro.

Entón, Alicia e Bob comunícanse mediante un simple cifrado de substitución mediante unha clave coñecida só por eles. Son moi estritos sobre a lonxitude das mensaxes: teñen exactamente 20 caracteres. Entón acordaron que se alguén quería enviar unha mensaxe máis curta, debería engadir un texto ficticio ao final da mensaxe para que teña exactamente 20 caracteres. Despois dunha discusión, decidiron que só aceptarían os seguintes textos ficticios: a, bb, ccc, dddd etc. Así, coñécese un texto ficticio de calquera lonxitude requirida.

Cando Alice ou Bob reciben unha mensaxe, primeiro comproban que a mensaxe ten a lonxitude correcta (20 caracteres) e que o sufixo é o texto ficticio correcto. Se non é o caso, responden cunha mensaxe de erro adecuada. Se a lonxitude do texto e o texto ficticio son correctos, o destinatario le a propia mensaxe e envía unha resposta cifrada.

Durante o ataque, o atacante fai pasar por Bob e envía mensaxes falsas a Alice. As mensaxes son unha tontería total: o atacante non ten a chave e, polo tanto, non pode forxar unha mensaxe significativa. Pero dado que o protocolo viola o principio de perdición, un atacante aínda pode atrapar a Alice para que revele a información clave, como se mostra a continuación.

Ladrón: PREWF ZHJKL MMMN. LA

Alicia: Texto ficticio non válido.

Ladrón: PREWF ZHJKL MMMN. LB

Alicia: Texto ficticio non válido.

Ladrón: PREWF ZHJKL MMMN. LC

Alicia: ILCT? TLCT RUWO PUT KCAW CPS OWPOW!

O ladrón non ten idea do que acaba de dicir Alicia, pero sinala que o símbolo C debe corresponder a, xa que Alice aceptou o texto ficticio.

Ladrón: REWF ZHJKL MMMN. LAA

Alicia: Texto ficticio non válido.

Ladrón: REWF ZHJKL MMMN. LBB

Alicia: Texto ficticio non válido.

Despois de varios intentos...

Ladrón: REWF ZHJKL MMMN. LGG

Alicia: Texto ficticio non válido.

Ladrón: REWF ZHJKL MMMN. LHH

Alicia: TLQO JWCRO FQAW SUY LCR C OWQXYJW. IW PWWR TU TCFA CHUYT TLQO JWFCTQUPOLQZ.

De novo, o atacante non ten nin idea do que Alice acaba de dicir, pero sinala que H debe coincidir con b xa que Alice aceptou o texto ficticio.

E así ata que o atacante coñeza o significado de cada personaxe.

A primeira vista, o método aseméllase a un ataque de texto plano elixido. Ao final, o atacante selecciona os textos cifrados e o servidor os procesa obedientemente. A principal diferenza que fai que estes ataques sexan viables no mundo real é que o atacante non necesita acceso á transcrición real; é suficiente unha resposta do servidor, incluso unha tan inocua como "Texto ficticio non válido".

Aínda que este ataque en particular é instrutivo, non te preocupes demasiado polos detalles do esquema de "texto ficticio", o sistema criptográfico específico utilizado ou a secuencia exacta de mensaxes enviadas polo atacante. A idea básica é como Alicia reacciona de forma diferente en función das propiedades do texto plano, e faino sen verificar que o texto cifrado correspondente proveña realmente dunha parte de confianza. Así, Alice permite ao atacante espremer información secreta das súas respostas.

Hai moito que se pode cambiar neste escenario. Os símbolos aos que reacciona Alicia, ou a propia diferenza no seu comportamento, ou mesmo o sistema criptográfico utilizado. Pero o principio seguirá sendo o mesmo e o ataque no seu conxunto seguirá sendo viable dunha forma ou doutra. A implementación básica deste ataque axudou a descubrir varios erros de seguridade, que veremos en breve; pero primeiro hai que aprender algunhas leccións teóricas. Como usar este "script Alice" ficticio nun ataque que pode funcionar nun cifrado moderno real? É isto posible, mesmo en teoría?

En 1998, o criptógrafo suízo Daniel Bleichenbacher respondeu afirmativamente a esta pregunta. Demostrou un ataque de oráculo ao sistema criptográfico de chave pública amplamente utilizado RSA, utilizando un esquema de mensaxe específico. Nalgunhas implementacións de RSA, o servidor responde con diferentes mensaxes de erro dependendo de se o texto sin formato coincide co esquema ou non; isto foi suficiente para levar a cabo o ataque.

Catro anos máis tarde, en 2002, o criptógrafo francés Serge Vaudenay demostrou un ataque de oráculo case idéntico ao descrito no escenario de Alicia anterior, excepto que en lugar dun cifrado ficticio, rompeu toda unha respectable clase de cifrados modernos que a xente realmente utiliza. En particular, o ataque de Vaudenay ten como obxectivo cifras de tamaño de entrada fixo ("cifrados de bloque") cando se usan no chamado "modo de cifrado CBC" e cun determinado esquema de recheo popular, basicamente equivalente ao do escenario de Alicia.

Tamén en 2002, o criptógrafo estadounidense John Kelsey - co-autor Dous peixes — propuxo varios ataques de oráculo a sistemas que comprimen as mensaxes e despois as cifran. O máis destacable entre estes foi un ataque que aproveitou o feito de que moitas veces é posible inferir a lonxitude orixinal do texto plano a partir da lonxitude do texto cifrado. En teoría, isto permite un ataque de oráculo que recupera partes do texto sinxelo orixinal.

A continuación ofrecemos unha descrición máis detallada dos ataques Vaudenay e Kelsey (daremos unha descrición máis detallada do ataque Bleichenbacher cando pasemos aos ataques á criptografía de clave pública). Malia o noso mellor esforzo, o texto vólvese algo técnico; polo que, se o anterior é suficiente para vostede, omita as dúas seguintes seccións.

O ataque de Vodene

Para comprender o ataque de Vaudenay, primeiro necesitamos falar un pouco máis sobre os cifrados de bloques e os modos de cifrado. Un "cifrado de bloque" é, como se mencionou, un cifrado que toma unha clave e unha entrada dunha determinada lonxitude fixa ("longitude de bloque") e produce un bloque cifrado da mesma lonxitude. Os cifrados de bloques son moi utilizados e considéranse relativamente seguros. O DES xa retirado, considerado o primeiro cifrado moderno, era un cifrado de bloques. Como se mencionou anteriormente, o mesmo ocorre con AES, que é amplamente utilizado hoxe en día.

Desafortunadamente, os cifrados en bloque teñen unha debilidade evidente. O tamaño típico do bloque é de 128 bits ou 16 caracteres. Obviamente, a criptografía moderna require traballar con datos de entrada máis grandes, e aquí é onde entran en xogo os modos de cifrado. O modo de cifrado é esencialmente un hackeo: é unha forma de aplicar dalgún xeito un cifrado de bloques que só acepta entradas dun determinado tamaño a entradas dunha lonxitude arbitraria.

O ataque de Vodene céntrase no popular modo de operación CBC (Cipher Block Chaining). O ataque trata o cifrado de bloques subxacente como unha caixa negra máxica e inexpugnable e evita por completo a súa seguridade.

Aquí tes un diagrama que mostra como funciona o modo CBC:

O signo máis rodeado dun círculo indica a operación XOR (OU exclusivo). Por exemplo, recíbese o segundo bloque de texto cifrado:

1. Realizando unha operación XOR no segundo bloque de texto plano co primeiro bloque de texto cifrado.
2. Cifrar o bloque resultante cun cifrado de bloque usando unha clave.

Dado que CBC fai un uso tan intenso da operación XOR binaria, dediquemos un momento a recordar algunhas das súas propiedades:

• Idempotencia:
• Conmutatividade:
• Asociatividade:
• Autorreversibilidade:
• Tamaño do byte: byte n de = (byte n de ) (byte n de )

Normalmente, estas propiedades implican que se temos unha ecuación que implique operacións XOR e unha incógnita, pódese resolver. Por exemplo, se o sabemos co descoñecido e famoso и , entón podemos confiar nas propiedades mencionadas anteriormente para resolver a ecuación . Aplicando XOR a ambos os dous lados da ecuación con , obtemos . Todo isto será moi relevante nun momento.

Hai dúas diferenzas menores e unha diferenza importante entre o noso escenario de Alicia e o ataque de Vaudenay. Dous menores:

• No guión, Alice esperaba que os textos planos terminasen cos personaxes a, bb, ccc etcétera. No ataque Wodene, a vítima espera que os textos planos rematen N veces co N byte (é dicir, hexadecimal 01 ou 02 02, ou 03 03 03, etc.). Esta é unha diferenza puramente cosmética.
• No escenario de Alicia, era fácil saber se Alicia aceptara a mensaxe coa resposta "Texto ficticio incorrecto". No ataque de Vodene requírese máis análise e é importante a implementación precisa por parte da vítima; pero por unha cuestión de brevidade, tomemos por feito que esta análise aínda é posible.

Diferenza principal:

• Dado que non estamos a usar o mesmo sistema criptográfico, a relación entre os bytes de texto cifrado controlado polo atacante e os segredos (chave e texto claro) obviamente será diferente. Polo tanto, o atacante terá que utilizar unha estratexia diferente á hora de crear textos cifrados e interpretar as respostas do servidor.

Esta gran diferenza é a peza final do quebracabezas para entender o ataque de Vaudenay, así que dediquemos un momento a pensar por que e como se pode montar un ataque oráculo a CBC en primeiro lugar.

Supoñamos que se nos dá un texto cifrado CBC de 247 bloques e queremos descifralo. Podemos enviar mensaxes falsas ao servidor, do mesmo xeito que antes podíamos enviar mensaxes falsas a Alice. O servidor descifrará as mensaxes por nós, pero non mostrará o descifrado; no seu lugar, de novo, como ocorre con Alice, o servidor só informará dun bit de información: se o texto plano ten un recheo válido ou non.

Considere que no escenario de Alicia tiñamos as seguintes relacións:

$$display$$text{SIMPLE_SUBSTITUTION}(texto{ciphertext},text{key}) = text{plaintext}$$display$$

Chamemos a isto "ecuación de Alicia". Nós controlamos o texto cifrado; o servidor (Alice) filtrou información vaga sobre o texto plano recibido; e isto permitiunos deducir información sobre o último factor: a clave. Por analoxía, se podemos atopar unha conexión deste tipo para o guión de CBC, tamén podemos extraer algunha información secreta alí.

Afortunadamente, realmente hai relacións que podemos usar. Considere a saída da chamada final para descifrar un cifrado de bloque e denote esta saída como . Tamén denotamos bloques de texto plano e bloques de texto cifrado . Bótalle un novo ollo ao diagrama CBC e observa o que ocorre:

Chamémoslle a isto "ecuación CBC".

No escenario de Alice, monitorizando o texto cifrado e observando a fuga de texto en plano correspondente, puidemos montar un ataque que recuperou o terceiro termo da ecuación: a clave. No escenario CBC, tamén supervisamos o texto cifrado e observamos fugas de información no texto plano correspondente. Se a analoxía é válida, podemos obter información sobre .

Supoñamos que realmente restauramos , que entón? Ben, entón podemos imprimir todo o último bloque de texto plano á vez (), simplemente ingresando (que temos) e
recibido na ecuación CBC.

Agora que somos optimistas sobre o plan xeral de ataque, é hora de resolver os detalles. Por favor, preste atención a como se filtra a información de texto claro no servidor. No script de Alice, a filtración ocorreu porque Alice só respondería coa mensaxe correcta se $inline$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key})$inline$ rematase coa liña a (Ou bb, etc., pero as posibilidades de que estas condicións se desencadeasen por casualidade eran moi pequenas). Do mesmo xeito que CBC, o servidor acepta o recheo se e só se remata en hexadecimal 01. Entón, imos probar o mesmo truco: enviar textos cifrados falsos cos nosos propios valores falsos ata que o servidor acepte o recheo.

Cando o servidor acepta un recheo para unha das nosas mensaxes falsas, isto significa que:

Agora usamos a propiedade XOR byte-byte:

Coñecemos o primeiro e o terceiro termo. E xa vimos que isto permítenos recuperar o termo restante: o último byte de :

Isto tamén nos dá o último byte do bloque de texto plano final mediante a ecuación CBC e a propiedade byte a byte.

Poderíamos deixalo así e estar satisfeitos de que fixemos un ataque a un cifrado teoricamente forte. Pero de feito podemos facer moito máis: podemos recuperar todo o texto. Isto require un truco que non estaba no guión orixinal de Alicia e que non é necesario para o ataque do oráculo, pero aínda vale a pena aprender.

Para entendelo, primeiro teña en conta que o resultado da saída do valor correcto do último byte é temos unha nova capacidade. Agora, ao falsificar textos cifrados, podemos manipular o último byte do texto plano correspondente. De novo, isto está relacionado coa ecuación CBC e a propiedade byte a byte:

Xa que agora coñecemos o segundo termo, podemos usar o noso control sobre o primeiro para controlar o terceiro. Simplemente calculamos:

Non podíamos facelo antes porque aínda non tiñamos o último byte .

Como nos vai axudar isto? Supoñamos que agora creamos todos os textos cifrados de tal xeito que nos textos planos correspondentes o último byte sexa igual a 02. O servidor agora só acepta o recheo se o texto claro remata con 02 02. Dado que corriximos o último byte, isto só ocorrerá se o penúltimo byte do texto plano tamén é 02. Seguimos enviando bloques de texto cifrado falsos, cambiando o penúltimo byte, ata que o servidor acepte o recheo dun deles. Neste punto temos:

E restauramos o penúltimo byte igual que o último foi restaurado. Seguimos co mesmo espírito: corriximos os dous últimos bytes do texto plano a 03 03, repetimos este ataque para o terceiro byte desde o final e así sucesivamente, finalmente restaurando completamente .

E o resto do texto? Teña en conta que o valor é en realidade $inline$text{BLOCK_DECRYPT}(texto{key},C_{247})$inline$. Podemos poñer calquera outro bloque no seu lugar , e o ataque aínda terá éxito. De feito, podemos pedirlle ao servidor que faga $inline$text{BLOCK_DECRYPT}$inline$ para calquera dato. Neste punto, o xogo rematou: podemos descifrar calquera texto cifrado (bota unha ollada ao diagrama de descifrado CBC para ver isto; e teña en conta que o IV é público).

Este método en particular xoga un papel crucial no ataque oráculo que atoparemos máis adiante.

O ataque de Kelsey

O noso amable John Kelsey expuxo os principios subxacentes a moitos posibles ataques, non só os detalles dun ataque específico a un cifrado específico. O seu 2002 artigo do ano é un estudo de posibles ataques a datos comprimidos cifrados. Pensaches que a información de que os datos foron comprimidos antes do cifrado non era suficiente para levar a cabo un ataque? Resulta que é suficiente.

Este sorprendente resultado débese a dous principios. En primeiro lugar, hai unha forte correlación entre a lonxitude do texto plano e a lonxitude do texto cifrado; para moitos cifrados a igualdade exacta. En segundo lugar, cando se realiza a compresión, tamén hai unha forte correlación entre a lonxitude da mensaxe comprimida e o grao de "ruído" do texto plano, é dicir, a proporción de caracteres que non se repiten (o termo técnico é "alta entropía" ).

Para ver o principio en acción, considere dous textos sinxelos:

Texto simple 1: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Texto simple 2: ATVXCAGTRSVPTVVULSJQHGEYCMQPCRQBGCYIXCFJGJ

Supoñamos que ambos os dous textos están comprimidos e despois cifrados. Obtén dous textos cifrados resultantes e tes que adiviñar cal é o texto cifrado que coincide con cal:

Texto cifrado 1: PVOVEYBPJDPVANEAWVGCIUWAABCIYIKOOURMYDTA

Texto cifrado 2: DWKJZXYU

A resposta é clara. Entre os textos sinxelos, só o texto simple 1 podería comprimirse na escasa lonxitude do segundo texto cifrado. Descubrimos isto sen saber nada sobre o algoritmo de compresión, a clave de cifrado ou mesmo o propio cifrado. En comparación coa xerarquía de posibles ataques criptográficos, isto é unha especie de tolo.

Kelsey sinala ademais que, baixo certas circunstancias pouco habituais, este principio tamén se pode usar para levar a cabo un ataque de oráculo. En particular, describe como un atacante pode recuperar o texto claro secreto se pode forzar ao servidor a cifrar os datos do formulario (o texto claro seguido de mentres el ten o control e pode comprobar dalgún xeito a lonxitude do resultado cifrado.

De novo, como outros ataques de oráculo, temos a relación:

De novo, controlamos un termo (), vemos unha pequena fuga de información sobre outro membro (texto cifrado) e tentamos recuperar o último (texto plano). A pesar da analoxía, esta é unha situación un tanto inusual en comparación con outros ataques de oráculo que vimos.

Para ilustrar como pode funcionar un ataque deste tipo, usemos un esquema de compresión ficticio que acabamos de crear: TOYZIP. Busca liñas de texto que apareceron anteriormente no texto e substitúeas por tres bytes de marcador de posición que indican onde atopar unha instancia anterior da liña e cantas veces aparece alí. Por exemplo, a liña helloworldhello pódese comprimir en helloworld[00][00][05] 13 bytes de longo en comparación cos 15 bytes orixinais.

Supoñamos que un atacante tenta recuperar o texto sinxelo dun formulario password=..., onde o propio contrasinal é descoñecido. Segundo o modelo de ataque de Kelsey, un atacante podería pedirlle ao servidor que comprima e despois cifra as mensaxes do formulario (texto simple seguido de ), onde  - texto libre. Cando o servidor rematou de funcionar, informa da lonxitude do resultado. O ataque é así:

Ladrón: Comprime e cifra o texto sen recheo.

Servidor: Duración do resultado 14.

Ladrón: Comprime e cifra o texto plano ao que se anexa password=a.

Servidor: Duración do resultado 18.

O cracker observa: [orixinal 14] + [tres bytes que substituíron password=] + a

Ladrón: Comprime e cifra o texto plano ao que se engade password=b.

Servidor: Duración do resultado 18.

Ladrón: Comprime e cifra o texto plano ao que se engade password=с.

Servidor: Duración do resultado 17.

O cracker observa: [orixinal 14] + [tres bytes que substituíron password=c]. Isto supón que o texto sinxelo orixinal contén a cadea password=c. É dicir, o contrasinal comeza cunha letra c

Ladrón: Comprime e cifra o texto plano ao que se engade password=сa.

Servidor: Duración do resultado 18.

O cracker observa: [orixinal 14] + [tres bytes que substituíron password=с] + a

Ladrón: Comprime e cifra o texto plano ao que se engade password=сb.

Servidor: Duración do resultado 18.

(… Algún tempo despois…)

Ladrón: Comprime e cifra o texto plano ao que se engade password=со.

Servidor: Duración do resultado 17.

O cracker observa: [orixinal 14] + [tres bytes que substituíron password=co]. Usando a mesma lóxica, o atacante conclúe que o contrasinal comeza polas letras co

E así sucesivamente ata que se restaure o contrasinal completo.

Perdoaríase ao lector que pensase que este é un exercicio puramente académico e que un escenario de ataque deste tipo nunca se presentaría no mundo real. Por desgraza, como veremos pronto, é mellor non renunciar á criptografía.

Vulnerabilidades da marca: CRIME, POODLE, DROWN

Finalmente, despois de estudar a teoría en detalle, podemos ver como se aplican estas técnicas en ataques criptográficos da vida real.

CRIME

Se o ataque está dirixido ao navegador e á rede da vítima, algúns serán máis fáciles e outros máis difíciles. Por exemplo, é fácil ver o tráfico da vítima: só tes que sentarte con el no mesmo café con wifi. Por este motivo, recoméndase xeralmente ás vítimas potenciais (é dicir, a todos) que utilicen unha conexión cifrada. Será máis difícil, pero aínda é posible, facer solicitudes HTTP en nome da vítima a algún sitio de terceiros (por exemplo, Google). O atacante debe atraer á vítima a unha páxina web maliciosa cun script que faga a solicitude. O navegador web proporcionará automaticamente a cookie de sesión adecuada.

Isto parece incrible. Se Bob fose evil.com, podería o script deste sitio só pedirlle a Google que envíe o contrasinal de Bob por correo electrónico [email protected]? Pois en teoría si, pero en realidade non. Este escenario denomínase ataque de falsificación de solicitudes entre sitios (Falsificación de solicitudes entre sitios, CSRF), e foi popular a mediados dos anos 90. Hoxe se evil.com proba este truco, Google (ou calquera sitio web que se precie) responderá normalmente con: "Xenial, pero o teu token CSRF para esta transacción será... um... три триллиона и семь. Por favor repita este número". Os navegadores modernos teñen algo chamado "política da mesma orixe" pola cal os scripts do sitio A non teñen acceso á información enviada polo sitio web B. Así que o script do sitio A evil.com pode enviar solicitudes a google.com, pero non pode ler as respostas nin completar a transacción.

Debemos subliñar que a non ser que Bob estea a usar unha conexión cifrada, todas estas proteccións carecen de sentido. Un atacante pode simplemente ler o tráfico de Bob e recuperar a cookie de sesión de Google. Con esta cookie, simplemente abrirá unha nova pestana de Google sen saír do seu propio navegador e suplantarase a Bob sen atopar políticas molestas da mesma orixe. Pero, por desgraza para un ladrón, isto é cada vez menos común. Internet no seu conxunto declarou hai tempo a guerra ás conexións sen cifrar, e o tráfico de saída de Bob probablemente estea cifrado, queira ou non. Ademais, dende o primeiro momento da implantación do protocolo, tamén o tráfico encolleu antes do cifrado; esta era unha práctica común para reducir a latencia.

Aquí é onde entra en xogo CRIME (Compression Ratio Infoleak Made Easy, fuga simple a través da relación de compresión). A vulnerabilidade foi revelada en setembro de 2012 polos investigadores de seguridade Juliano Rizzo e Thai Duong. Xa examinamos toda a base teórica, o que nos permite comprender o que fixeron e como. Un atacante podería forzar o navegador de Bob a enviar solicitudes a Google e logo escoitar as respostas na rede local nun formulario comprimido e cifrado. Polo tanto temos:

Aquí o atacante controla a solicitude e ten acceso ao rastreador de tráfico, incluído o tamaño do paquete. O escenario ficticio de Kelsey cobrou vida.

Entendendo a teoría, os autores de CRIME crearon un exploit que pode roubar cookies de sesión para unha ampla gama de sitios, incluíndo Gmail, Twitter, Dropbox e Github. A vulnerabilidade afectou á maioría dos navegadores web modernos, polo que se lanzaron parches que enterraban silenciosamente a función de compresión en SSL para que non se utilizase en absoluto. O único protexido da vulnerabilidade foi o venerable Internet Explorer, que nunca utilizou a compresión SSL.

CANICHE

En outubro de 2014, o equipo de seguridade de Google fixo ondas na comunidade de seguridade. Puideron explotar unha vulnerabilidade do protocolo SSL que fora parcheada hai máis de dez anos.

Acontece que mentres os servidores están a executar o novo e brillante TLSv1.2, moitos deixaron soporte para o SSLv3 legado para compatibilidade con Internet Explorer 6. Xa falamos dos ataques de downgrade, así que podes imaxinar o que está a suceder. Unha sabotaxe ben orquestrada do protocolo de apretón de mans e os servidores están preparados para volver ao bo antigo SSLv3, desfacendo esencialmente os últimos 15 anos de investigación de seguridade.

Para o contexto histórico, Aquí tes un breve resumo da historia de SSL ata a versión 2 de Matthew Green:

Transport Layer Security (TLS) é o protocolo de seguridade máis importante de Internet. [..] case todas as transaccións que realizas en Internet dependen de TLS. [..] Pero TLS non sempre foi TLS. O protocolo comezou a súa vida en Comunicacións Netscape chamado "Secure Sockets Layer" ou SSL. Os rumores di que a primeira versión de SSL foi tan terrible que os desenvolvedores recolleron todas as copias impresas do código e enterraron nun vertedoiro secreto en Novo México. Como consecuencia, a primeira versión de SSL dispoñible publicamente é en realidade versión SSL 2. Dá bastante medo, e [..] foi un produto de mediados dos 90, que os criptógrafos modernos consideran "épocas escuras da criptografía" Moitos dos ataques criptográficos máis atroces que coñecemos hoxe aínda non foron descubertos. Como resultado, os desenvolvedores do protocolo SSLv2 deixáronse esencialmente a buscar o seu camiño na escuridade e enfrontáronse moitos monstros terribles - para o seu pesar e o noso beneficio, xa que os ataques a SSLv2 deixaron leccións inestimables para a próxima xeración de protocolos.

Tras estes acontecementos, en 1996, un frustrado Netscape redeseñou o protocolo SSL desde cero. O resultado foi a versión 3 de SSL, que solucionou varios problemas de seguridade coñecidos do seu predecesor.

Afortunadamente para os ladróns, "uns poucos" non significa "todos". En xeral, SSLv3 proporcionou todos os bloques de construción necesarios para lanzar un ataque Vodene. O protocolo utilizaba un cifrado de bloques en modo CBC e un esquema de recheo inseguro (isto foi corrixido en TLS; de aí a necesidade dun ataque de downgrade). Se lembras o esquema de recheo na nosa descrición orixinal do ataque Vaudenay, o esquema SSLv3 é moi semellante.

Pero, por desgraza para os ladróns, "semellante" non significa "idéntico". O esquema de recheo SSLv3 é "N bytes aleatorios seguidos do número N". Tenta, nestas condicións, seleccionar un bloque imaxinario de texto cifrado e percorrer todos os pasos do esquema orixinal de Vaudene: descubrirás que o ataque extrae con éxito o último byte do bloque correspondente de texto plano, pero non vai máis aló. Descifrar cada 16 byte do texto cifrado é un gran truco, pero non é unha vitoria.

Ante o fracaso, o equipo de Google recorreu a un último recurso: cambiaron a un modelo de ameazas máis potente: o usado en CRIME. Asumindo que o atacante é un script que se executa na pestana do navegador da vítima e pode extraer cookies de sesión, o ataque segue sendo impresionante. Aínda que o modelo de ameazas máis amplo é menos realista, vimos na sección anterior que este modelo en particular é viable.

Dadas estas capacidades atacantes máis poderosas, o ataque agora pode continuar. Teña en conta que o atacante sabe onde aparece a cookie de sesión cifrada na cabeceira e controla a lonxitude da solicitude HTTP que a precede. Polo tanto, é capaz de manipular a solicitude HTTP para que o último byte da cookie estea aliñado co final do bloque. Agora este byte é axeitado para o descifrado. Podes simplemente engadir un carácter á solicitude e o penúltimo byte da cookie permanecerá no mesmo lugar e é adecuado para a selección mediante o mesmo método. O ataque continúa deste xeito ata que se restaure completamente o ficheiro de cookie. Chámase POODLE: Padding Oracle on Downgraded Legacy Encryption.

AFOGAR

Como mencionamos, SSLv3 tiña os seus defectos, pero era fundamentalmente diferente do seu predecesor, xa que o SSLv2 con fugas era produto dunha época diferente. Alí podes interromper a mensaxe no medio: соглашусь на это только через мой труп convertido en соглашусь на это; o cliente e o servidor poderían reunirse en liña, establecer confianza e intercambiar segredos diante do atacante, quen podería suplantar facilmente a ambos. Tamén está o problema coa criptografía de exportación, que mencionamos ao considerar FREAK. Estes eran Sodoma e Gomorra criptográficas.

En marzo de 2016, un equipo de investigadores de diferentes campos técnicos reuniuse e fixo un descubrimento sorprendente: SSLv2 aínda se usa nos sistemas de seguridade. Si, os atacantes xa non podían degradar as sesións TLS modernas a SSLv2 xa que ese buraco se pechou despois de FREAK e POODLE, pero aínda poden conectarse aos servidores e iniciar sesións SSLv2 eles mesmos.

Podes preguntar, por que nos importa o que fan alí? Teñen unha sesión vulnerable, pero non debería afectar a outras sesións nin á seguridade do servidor, non? Ben, non do todo. Si, así debería ser en teoría. Pero non, porque xerar certificados SSL impón unha certa carga, polo que moitos servidores utilizan os mesmos certificados e, como resultado, as mesmas claves RSA para conexións TLS e SSLv2. Para empeorar as cousas, debido a un erro de OpenSSL, a opción "Desactivar SSLv2" nesta popular implementación de SSL non funcionou realmente.

Isto fixo posible un ataque de protocolo cruzado a TLS, chamado AFOGAR (Descifrando RSA con cifrado obsoleto e debilitado, descifrando RSA con cifrado obsoleto e debilitado). Recordemos que isto non é o mesmo que un ataque curto; o atacante non necesita actuar como un "home no medio" e non necesita involucrar ao cliente para participar nunha sesión insegura. Os atacantes simplemente inician unha sesión SSLv2 insegura co propio servidor, atacan o protocolo débil e recuperan a clave privada RSA do servidor. Esta chave tamén é válida para conexións TLS e, a partir deste momento, ningunha cantidade de seguridade TLS evitará que se vexa comprometida.

Pero para descifralo, necesitas un ataque de traballo contra SSLv2, que che permita recuperar non só o tráfico específico, senón tamén a clave secreta do servidor RSA. Aínda que esta é unha configuración complexa, os investigadores poderían elixir calquera vulnerabilidade que fose completamente pechada despois de SSLv2. Finalmente atoparon unha opción axeitada: o ataque de Bleichenbacher, que mencionamos anteriormente e que explicaremos en detalle no seguinte artigo. SSL e TLS están protexidos deste ataque, pero algunhas funcións aleatorias de SSL, combinadas con claves curtas na criptografía de exportación, fixeron posible unha implementación específica de DROWN.

No momento da publicación, o 25% dos principais sitios de Internet víronse afectados pola vulnerabilidade DROWN, e o ataque podería levarse a cabo con recursos modestos dispoñibles incluso para piratas informáticos solitarios. A recuperación da clave RSA do servidor requiriu oito horas de cálculo e 440 dólares, e SSLv2 pasou de obsoleto a radioactivo.

Espera, que hai de Heartbleed?

Este non é un ataque criptográfico no sentido descrito anteriormente; Este é un desbordamento do búfer.

Imos facer un descanso

Comezamos con algunhas técnicas básicas: forza bruta, interpolación, degradación, protocolo cruzado e precómputo. Despois analizamos unha técnica avanzada, quizais o principal compoñente dos ataques criptográficos modernos: o ataque oráculo. Pasamos bastante tempo descubrilo e non só entendemos o principio subxacente, senón tamén os detalles técnicos de dúas implementacións específicas: o ataque de Vaudenay ao modo de cifrado CBC e o ataque de Kelsey aos protocolos de cifrado previos á compresión.

Ao revisar os ataques de degradación e precomputación, describimos brevemente o ataque FREAK, que utiliza ambos métodos ao facer que os sitios de destino reduzan a versión de chaves débiles e despois reutilicen as mesmas claves. Para o seguinte artigo, gardaremos o ataque Logjam (moi semellante), que se dirixe aos algoritmos de chave pública.

Despois observamos tres exemplos máis da aplicación destes principios. En primeiro lugar, CRIME e POODLE: dous ataques que dependían da capacidade do atacante para inxectar texto claro arbitrario xunto ao texto claro de destino, despois examinar as respostas do servidor e entón,usando a metodoloxía de ataque Oracle, explote esta información escasa para recuperar parcialmente o texto plano. CRIME foi o camiño do ataque de Kelsey á compresión SSL, mentres que POODLE utilizou unha variante do ataque de Vaudenay á CBC co mesmo efecto.

A continuación, centramos a nosa atención no ataque DROWN entre protocolos, que establece unha conexión co servidor mediante o protocolo SSLv2 herdado e despois recupera as claves secretas do servidor mediante o ataque Bleichenbacher. Omitimos os detalles técnicos deste ataque polo momento; como Logjam, terá que esperar ata que teñamos unha boa comprensión dos sistemas criptográficos de chave pública e as súas vulnerabilidades.

No seguinte artigo falaremos de ataques avanzados como o meet-in-the-middle, a criptoanálise diferencial e os ataques de aniversario. Imos facer unha rápida incursión nos ataques de canles laterais e, a continuación, pasemos á parte divertida: os criptosistemas de chave pública.

Fonte: www.habr.com