En Cryptography is not Magic hablan sobre el tema de diseñar sistemas criptográficos y programarlos.

Trata de atraer a más desarrolladores a la materia porque, afirma, los consejos habituales hacen que alguna gente se eche para atrás.

Sin embargo, nos dice, la realidad es que programar primitivas criptográficas requiere poco conocimiento sobre criptografía. Lo más delicado sería la elección de cuales (por aquello de no elegir algún método obsoleto).

Perhaps surprisingly, implementing cryptographic primitives & protocols requires little cryptographic knowledge. Choosing what to implement is more delicate (you need to know the state of the art), but once you’ve made your choice, your only worries are side channels and correctness.

Nos habla sobre los canales laterales y remarca que la idea fundamental es no permitir el flujo de datos hacia ellos. La mayoría pueden ser ignorados sin demasiados problemas (energía, emisiones electromagnéticas, …) pero que nunca hay que olvidar los relacionados con el tiempo.

Side channels have one rule: don’t let any data flow from secrets to that channel. Interesting side channels include timings, energy consumption, electromagnetic emissions… Most can be ignored most of the time (energy consumption for instance requires physical access), except timings. Never ignore timings, they’re part of most threat models.

Sobre la corrección, nos avisa de su importancia: cualquier error hará que nuestro sistema sea inadecuado.

Then we have correctness. The slightest error may throw cryptographic guarantees out the window, so we cannot tolerate errors. Your code must be bug free, period. It’s not easy, but it is simple: it’s all about tests and proofs.

Sobre el diseño de protocolos dice que si el desarrollo criptográfico es tedioso, el diseño de protocolos es delicado.

That’s where things become interesting. Where implementing crypto was mostly tedious, designing protocols is delicate. One is not necessarily harder than the other, but they’re very different.

Habla de las amenazas para recordarnos que una vez que conocemos a las que se enfrentan nuestros casos de uso (threat model) es necesario demostrar que el protocolo las maneja adecuadamente.

Once you know your threat model, you need to demonstrate that your protocol addresses it.

Termina diciendo que desarrollar nuestra propia criptografía no es sencillo. Es fácil equivocarse, pero eso no significa que no pueda hacerse

I won’t sugar coat it, rolling your own crypto is not easy. Mistakes are easy to make, and the stakes are often high — getting it wrong can even get people killed. Don’t rush it, and if you can, seek guidance and feedback. Some communities are very welcoming.

En mi opinión, no es un campo donde yo me desenvolvería a gusto. Pero, tal vez, una aproximación más activa nos ayudaría a aprender y a mejorar.

Solemos decir que tomamos decisiones basadas en los datos. El problema que surje con esto es cuando nuestros datos no reflejan adecuadamente la realidad. En el mundo de la inteligencia artificial esto podría ser un problema, tal y como nos cuentan en Data poisoning in action.

Si podemos introducir errores en los modelos que se utilizan para entrenar las inteligencias artificiales, podremos causar problemas:

Data poisoning attacks compromise the integrity of machine learning models by injecting incorrect data in their training set.

Se trata de modificar un conjunto de datos de los que se emplean en el entrenamiento, para lograr que el resultado sean predicciones incorrectas.

A data poisoning attack aims to modify a training set such that the model trained using this dataset will make incorrect prediction

El objetivo es degradar el modelo obtenido (en el entrenamiento o cuando se le alimentan nuevos datos para volver a entrenarlo). Estos ataques podrían tener un efecto duradero, porque comprometen la integridad del modelo y le hacen cometer errores de manera consistente. Una vez comprometido, recuperar el sistema es un problema de solución no trivial.

Poisoning attacks have a long-lasting effect because they compromise the integrity of the model and cause it to make consistent errors at runtime when making predictions. Once a model has been poisoned, recovering from the attack at a later date is a non-trivial procedure.

Como ejemplo, nos habla de lo que sucedería si en un modelo orientado a detectar pedidos fraudulentos (y que, lógicamente, se entrenará con pedidos reales anteriores). Podría contaminarlo realizando una serie de pedidos y luego pagando algunos y otros no, con lo que podría conseguir degradar la capacidad de predicción.

The model should be able to predict whether a placed order will be paid for ( legitimate ) or not ( fraudulent ) based on information about the given order. The training set for this model consists of details contained in historical orders placed on the website. In order to poison this training set, an attacker would pose as a user or users of the site and place orders. The attacker pays for some orders and doesn’t pay for others such that the predictive accuracy of the model is degraded when it is next trained.

Hay dos formas de contaminar estos datos:

• Inyección de datos, tal y como decíamos arriba.

Data injection: by injecting new data in the training set, as illustrated above with the attacker creating new orders. This new data can be synthetic in nature.

• Cambio de etiquetas. Esto es, se trata de cambiar los valores que asigna el modelo a algunos datos.

Label flipping: by changing labels of existing real data in the training set.

Si conocemos el modelo utilizado y los datos que se utilizan para entrenarlo, se podría ir más allá, sintentizando (generando) datos que podrían optimizar el proceso de contaminación.

Given some knowledge about the model and its training data, an attacker can generate synthetic training data points that will optimally degrade the accuracy of the model.

Como defensa, se pueden utilizar modelos lo más complejos posibles, que serán más resistentes y robustos frente a los ataques.

In general, this means that complex models (models having a high capacity) are more resilient than simple models to DoS poisoning attacks, they require more poisoning data points to be compromised, and it is difficult to decrease their accuracy as a whole.

Muy interesante. Cada vez que hagamos un sistema automático, alguien intentará hacer que se comporte de manera diferente a la prevista.

En [RFC PATCH 00/16] The Runtime Verification (RV) interface un texto sobre la interfaz de verificación en tiempo de ejecución del Kernel de Linux.

Se trata de un método ligero que complementa las técnicas tradicionales de verificación exhaustiva mediante el análisis de la traza de la ejecución del sistema.

Runtime Verification (RV) is a lightweight (yet rigorous) method that complements classical exhaustive verification techniques (such as model checking and theorem proving) with a more practical approach for complex systems.

Instead of relying on a fine-grained model of a system (e.g., a re-implementation a instruction level), RV works by analyzing the trace of the system’s actual execution, comparing it against a formal specification of the system behavior.

Existe un documento de referencia, que es:

DE OLIVEIRA, Daniel Bristot; CUCINOTTA, Tommaso; DE OLIVEIRA, Rômulo Silva. Efficient formal verification for the Linux kernel. In: International Conference on Software Engineering and Formal Methods. Springer, Cham, 2019. p. 315-332.

En el RFC se presenta un sistema basado en monitores que ayudan a observar el uso y cómo se genera código automáticamente. Esto ha venido motivado por el uso de Linux en sistemas críticos.

In this RFC I am still not proposing any complex model. Instead, I am presenting only simple monitors that help to illustrate the usage of the automatic code generation and the RV interface. This is important to enable other researchers and developers to start using/extending this method.

It is also worth mentioning that this work has been heavily motivated by the usage of Linux on safety critical systems, mainly by the people involved in the Elisa Project.

De vez en cuando volvemos a hablar de los generadores de números aleatorios. Aunque sólo sea porque alguien la próxima vez lo haga un poco mejor. Siempre decimos que los sistemas informáticos son muy malos generando aleatoriedad y que utilizan algunos trucos para ello. En este caso John D. Cook entra en detalle en diversas implementaciones y propuestas en Evolution of random number generators.

Habla de los generadores basados en congruencias

x(n+1) = a.x(n) mod m

Y luego hace algunos análisis estadísticos con algunos valores para los parámetros del generador (los valores de a, n y m). No se asusten, es cortito y muy visual.

Imaginemos que pasas por delante de una puerta que está abierta y dentro ves la puerta de una habitación y dentro un montón de billetes. Sabemos que no lo robarrías pero…. ¿Volverías la puerta de la habitación o la cerrarías para que alguien que pase no tenga malas tentaciones? Tiene su peligro, porque si alguie te ve entrar y luego faltara dinero, podrían pensar que has sido tú. Podrías llamar a la policía y que se ocupen ellos, que seguramente nadie les acusaría con la misma facilidad de robar. Algo así ha estado pasando con el FBI (aunque sin que nadie les avise). En FBI cleans web shells from hacked Exchange servers in rare active defense move nos cuentan como el FBI obtuvo permiso del juez para eliminar puertas traseras de sistemas infectados.

Es un movimiento interesante porque esto supone que detectan un sistema infectado, son capaces de entrar en el mismo (la puerta no está exactamente abierta, hace falta ciertas herramientas y conocimiento para poder acceder), eliminan el problema y se van.

In a move that has been described as unprecedented, the FBI obtained a court order that allowed it to remove a backdoor program from hundreds of private Microsoft Exchange servers that were hacked through zero-day vulnerabilities earlier this year.

La cosa tiene su miga, porque muchas veces esos servidores están medio abandonados o mal gestionados y pueden ser utilizados para atacar y provocar problemas en otros sistemas. En este caso, una web shell es un programa que instalan los malos para poder acceder al sistema y ‘gestionarlo’ desde su navegador.

A web shell is a type of program that hackers install on hacked web servers to grant them backdoor access and remote command execution capabilities on those servers through a web-based interface.

En la solicitud del FBI explicaban que, a pesar de haber avisado tanto el fabricante, como otras organizaciones y ellos mismos, muchos servidores seguían infectados. Existiendo una solución para remediarlo.

In its warrant application, dated April 13, the FBI argues that despite the public awareness campaigns by Microsoft, CISA and the FBI itself, many servers remained infected with the web shell …

No sólo recibieron permiso para entrar en los sistemas con las credenciales que consiguieron para ello, sino que también recibieron autorización para conservar estos programas maliciosos, como evidencias para posibles acciones posteriores.

The FBI was also allowed to make a copy of the web shells first because they could constitute evidence.

Sin embargo, no recibieron autorización para parchear (esto es, aplicar las soluciones necesarias para proteger los sistemas de ataques posteriores) o para eliminar otros programas maliciosos que pudieran encontrar.

This means the FBI was not granted permission to patch the vulnerabilities to protect the servers from future exploitation or to remove any additional malware or tools that hackers might have already deployed.

Tiene sentido porque modificar el sistema puede tener consecuencias que serían difíciles de evaluar para un visitante casual, que no conoce toda la configuración y las actividades del sitio en cuestión.

Según la nota, no sería la primera vez que habían obtenido permiso (ellos u otras fuerzas del orden) para enviar instrucciones a programas maliciosos en sistemas infectados.

This is not the first time when the FBI or law enforcement authorities from other countries have sent commands to malware running on infected computers.

Nos cuenta el caso de la Gendarmería francesa, que habría sido autorizada para inhabilitar un servidor de ‘comando y control’ que se utilizaba para desplegar un programa malicioso de minado de criptomonedas, reemplazándolo con un servidor de desinfección.

In 2019, the French National Gendarmerie, working with antivirus vendor Avast, disabled the command-and-control server used by the Retadup worm that deployed cryptocurrency mining malware and replaced it with a “disinfection server.”

Pero se trataba más bien, nos dicen, de aproximaciones pasivas. Desactivaban el sistema de control de una red de programas amliciosos que contactaban con este sistema para recibir instrucciones.

Placing a specific command on a seized server knowing that malware programs are programmed to contact that server and execute that command is a somewhat passive approach.

Elogian también la transparencia del FBI y el Departamento de Justicia, así como la limitación en el ámbito de actividades desarrolladas.

It seems that the FBI and the DOJ tried to be transparent and were careful to limit the scope of their actions in this case.

Muy interesante.