Читать книгу Manual de informática forense III - Luis Enrique Arellano González - Страница 25

CAPÍTULO 4

LAS MEDIDAS PREVIAS, PRELIMINARES O PRUEBA ANTICIPADA EN INFORMÁTICA FORENSE

Dado que este tema ha sido desarrollado en detalle en el Manual de Informática Forense II (Errepar, 2012, página 24 y subsiguientes), solo agregaremos algunos elementos complementarios referidos al avance tecnológico y jurisprudencial que, pese a su brevedad, conforman auténticas modificaciones respecto de lo afirmado en dicha obra; sobre todo, el cambio instrumental físico y lógico cada día aporta elementos nuevos a la solución de esta problemática en particular:

1. Antes de presentar una demanda, sin intervención judicial. En este sentido, basta con que se conserven los recaudos que dicha tarea requiere:

a. Solamente se puede recolectar información propietaria (es decir, de propiedad de quien solicita la recolección) y/o pública.

b. Certificada ante escribano público.

i. Realidad argentina: al no poseer el país ninguna autoridad certificante, no es posible utilizar la firma electrónica como elemento legalmente válido de validación de datos. Por tal razón, es necesario recurrir a un escribano, al momento de certificar información privada.

ii. A tales fines, hace falta un mecanismo de seguridad que asegure la confidencialidad del hash, relacionado con la prueba recolectada. Por eso, es preciso integrar en la aplicación el hash con su correspondiente clave secreta. De ahí el empleo de rutinas de HMAC.

iii. Considerando que el escribano lo único que certifica son los dichos del perito, quien afirma que el archivo de recolección que le entrega se corresponde con el digesto matemático obtenido mediante HMAC.

iv. La clave secreta del HMAC (en dos copias) la guarda el perito en dos sobres cerrados y lacrados (uno acompaña al acta y el otro se adjunta a la recolección), asegurando la confidencialidad con el Juez; no debería ser abierto salvo por S. S.a, en caso de necesitar convalidar la integridad de la prueba.

c. Autenticada mediante el correspondiente digesto matemático (hash, de preferencia CBCMac, UMAC o HMAC, en lo posible con concatenación del archivo autenticado (15)).

d. Con su correspondiente cadena de custodia.

2. El paso anterior suele efectuarse para alcanzar alguna negociación previa a la acción judicial (métodos alternativos de resolución de conflictos) o como fundamento para justificar la solicitud de una medida previa, preliminar o prueba anticipada (acorde al fuero en que estemos operando). Este es el caso que nos interesa analizar.

En cuanto a la solicitud de la medida preliminar, implica en el caso de la Informática forense, una estricta observación del principio inaudita altera pars. Esta característica se funda en la especial volatilidad y volubilidad de la prueba documental informática, la cual puede ser modificada, alterada o eliminada, no solo por medios locales, sino también por medios remotos (acciones directas o virtuales, que incluyen la denegación de servicio).

Lleva implícita en su naturaleza una profunda relación con las medidas cautelares y es así que conserva al menos dos de sus tres requisitos clásicos: fumus bonis iuris: verosimilitud del derecho invocado. Periculum in mora: peligro en la demora. Y, difiere relativamente en el tercero, la contracautela, ya que este se reemplaza por el aseguramiento de la privacidad de los datos hallados durante la actividad y que no sean estrictamente conducentes y pertinentes a la requisitoria ordenada por el tribunal interventor que autoriza y convalida la medida Servare secreto private: preservar la privacidad.

El fundamento de esta medida es mantener la igualdad de las partes en el litigio, preservando la prueba existente al momento de presentar la demanda, evitando que la pretensión se vuelva ilusoria.

Características: instrumentalidad, sumariedad, provisionalidad, perennis in iudicium, reserva.

Se trata, entonces, de una acción jurisdiccional con características propias (cautelares en el sentido de preservar la prueba y asegurar su sobrevida durante el proceso). Aunque carece de autonomía respecto del proceso principal cuya eficacia garantiza, parece mantenerla al menos en el ámbito conceptual, anticipando la tutela del derecho invocado y la pretensión que funda al proceso en ciernes.

Requisitos doctrinarios

1. Verosimilitud del derecho (fumus bonis iuris). Para que se conceda, no es necesario un estudio exhaustivo y profundo de la materia controvertida en el proceso principal, sino de un conocimiento superficial; la certeza aparecerá a posteriori en la sentencia. No se requiere prueba plena y concluyente, sino un acreditamento convincente para que se ordene la providencia solicitada. Es necesario destacar que cuando la contraparte es la Administración Pública, como esta goza del principio de presunción de legalidad de sus actos, la verosimilitud del derecho invocado debe comprender la acreditación de las arbitrariedades o irregularidades manifiestas de esta.

2. Peligro en la demora (periculum in mora). Aunque en el caso de la prueba documental informática, el riesgo de su modificación, adulteración o eliminación es prácticamente evidente, en razón de su debilidad manifiesta frente a las acciones dolosas o culposas de los actores físicos, lógicos o humanos con los que se relaciona, siempre es necesario fundar con claridad este riesgo. Quien debe decidir tendrá siempre sobre su cabeza la espada de Damocles del derecho a la privacidad (de raigambre constitucional). En este sentido, es menester destacar en la fundamentación que en caso de pérdida, adulteración o modificación de la prueba, se torna prácticamente imposible realizar tareas que permitan reconstituirla. Suele afirmarse que los archivos borrados siempre pueden ser recuperados a posteriori; esta afirmación se ha llegado a utilizar en jurisprudencia, afirmando que si la información es borrada, entonces el requirente de la medida previa negada siempre podrá demostrar que fue borrada, aunque no queda muy claro. ¿De qué sirve probar que algo fue borrado si no puedo recuperar el contenido borrado?

3. Preservar la privacidad (servare secreto private). Cuanto menor sea la verosimilitud del derecho invocado, tanto mayor es la necesidad de asegurar este requisito. En el Derecho penal, se justifica claramente por la doctrina del árbol envenenado. En el resto de los fueros, siempre es posible que como resultado de esta medida se produzcan violaciones al derecho a la privacidad del futuro demandado. En este sentido, es preciso considerar que la norma debe ser la restricción: todo archivo cuyo acceso no ha sido liberado por su propietario es privado. Si para acceder a un archivo se debe utilizar un nombre de usuario y/o una contraseña, entonces su propietario lo está declarando bajo su dominio, de la misma forma en que se respeta la propiedad de un predio (incluyendo la exclusión de otras personas) si tiene una muralla que la rodea o si solo está demarcada por un seto vivo o no. Si el archivo es privado, para ser accedido contra la voluntad de su dueño es necesaria una autorización judicial expresa, detallada, precisa, limitada y legalmente fundada (orden de allanamiento y recolección local o remota).

15. En criptografía, un Message authentication code, a menudo llamado por sus siglas MAC o por su traducción al español Código de Autenticación de Mensaje, es una porción de información utilizada para autenticar un mensaje.

Los valores MAC se calculan mediante la aplicación de una función hash criptográfica con clave secreta K, que solo conocen el remitente y el destinatario, pero no los atacantes. Se dice que la función hash tiene que ser criptográfica porque tiene que cumplir ciertas propiedades de seguridad que las hacen resistentes frente a los ataques de adversarios. Matemáticamente, la función hash criptográfica toma dos argumentos: una clave K de tamaño fijo y un mensaje M de longitud arbitraria. El resultado es un código MAC de longitud fija:

MAC = CK(M)

donde:

 M es un mensaje de longitud arbitraria.

 CK es la función que transforma el mensaje en un valor MAC y que utiliza una clave secreta K como parámetro.

 MAC es el valor MAC calculado de longitud fija.

Si el valor MAC enviado coincide con el valor que el destinatario calcula, este puede garantizar que:

 El mensaje no fue alterado.

 El mensaje proviene del remitente indicado en el mensaje.

 Si el mensaje incluye un número de secuencia, que el mensaje sigue la secuencia correcta.

Seguridad

Función MAC ideal

Se define la función MAC ideal como un mapeo aleatorio de todos los posibles valores del mensaje de entrada M en salidas de tamaño de n bits.

Propiedad de seguridad

Para que una función MAC pueda ser usada, es necesario que sea resistente a la computación de nuevos valores hash.

Tipos de funciones MAC

Actualmente, existen 3 grandes grupos de funciones MAC:

 CBC-MAC: la idea detrás de este algoritmo es la de convertir un algoritmo de cifrado simétrico en una función MAC. El funcionamiento básico consiste en cifrar el mensaje usando un algoritmo en modo CBC y tirar todo el resultado de texto cifrado a excepción del último bloque.

 HMAC: dado que una función MAC es un mapeo aleatorio, y que las funciones hash se comportan como tales, podemos explotar la idea de utilizar una función hash para implementar una función MAC. La opción más popular hoy en día es la de usar HMAC-SHA-256.

 UMAC: las funciones UMAC parten de la premisa de que el atacante necesita interactuar con el sistema para comprobar si el resultado MAC que ha generado es válido o no. Es decir, no existe nada parecido a un ataque exhaustivo off-line contra las funciones MAC. Así, argumentan que se puede reducir el resultado a tan solo 64 bits. Sin embargo, no existe un estándar bien definido de funciones MAC como ocurre con las funciones hash, lo que tiene efectos contraproducentes a largo plazo desde el punto de vista de la implementación.

Debilidad. Aplicación del principio de Horton

El uso de valores MAC para autenticar provee cierta seguridad, pero no es la panacea. Por ejemplo, podría haber un ataque que consistiera en interceptar el mensaje y el valor MAC para poder reutilizarlo a fin de autenticarse.

En general, el principio de Horton establece que se debe autenticar el significado del mensaje y no el código del mensaje. Aplicando el principio a la autenticación de mensaje con MAC, deberíamos autenticar no solo el valor MAC, sino también cierta información que sea usada para formar un valor MAC que no sea ambiguo. Por ejemplo, puede ser buena idea incorporar algún tipo de sello de tiempo cuando calculo el valor MAC (v. gr., concatenándolo al mensaje). Este sello de tiempo se enviaría al verificador. Si el verificador recibe un sello de tiempo antiguo, entonces decide que es falso (ha caducado). Si el adversario decide actualizar el sello de tiempo, entonces el valor MAC interceptado ya no sería válido para mandárselo al verificador.

Otros sistemas proponen concatenar al mensaje (para calcular el valor MAC) ciertos datos relativos al contexto en el que se está (número de mensaje, tamaños de campos negociados, número de versión del protocolo...). Estos datos no habría que enviárselos al verificador porque ya están en el contexto y los conoce.

Aplicaciones

Las MAC se suelen usar para autenticación (de ahí su nombre). El que se quiere autenticar y el verificador comparten la clave de la función MAC y la mantienen en secreto. De esta forma, cuando el verificador recibe el valor MAC, puede verificar si ese valor MAC se corresponde con el que se tiene que generar a partir de un mensaje dado.

Hay dos formas principales de funcionar, según donde se genere el mensaje:

 El mensaje es generado por el que se quiere autenticar y después este manda al verificador el mensaje y el valor MAC asociado. En el paso siguiente, el verificador comprueba la validez del valor MAC y, a la vez, se asegura de la integridad del mensaje recibido.

 El mensaje es generado por el verificador y se le manda al que se quiere autenticar para que este genere el valor MAC y lo mande al verificador. Este tipo de protocolo se encuadraría en los llamados protocolos desafío-respuesta. Fuente: http://es.wikipedia.org/wiki/Message_authentication_code