Tesis de Ingeniería en Informática - Facultad de ...materias.fi.uba.ar/7500/TesisDeymonnaz.pdf ·...

Tesis de Ingenierıa en Informatica

Analisis de vulnerabilidades esteganograficasen protocolos de comunicacion

IP y HTTP

Autor: Pablo Andres Deymonnaz (81.755)[email protected]

Directora: Lic. Adriana Echeverrıa

Marzo 2012

Indice general

Indice general 1Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1. Conceptos generales 61.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2. Notacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.3. Caracterısticas y clasificacion de la esteganografıa . . . . . . . . . . . . . . . . . 151.4. Aplicaciones de las tecnicas esteganograficas modernas . . . . . . . . . . . . . . 181.5. Orıgenes y evolucion historica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.6. Relacion de la esteganografıa con otras tecnicas de comunicacion seguras . . . . 22

1.6.1. Relacion entre la Esteganografıa y la Criptografıa . . . . . . . . . . . . . 231.6.2. Caso de ejemplo: Caballos de Troya . . . . . . . . . . . . . . . . . . . . 26

2. Analisis de Protocolos de Comunicacion 282.1. Introduccion a la arquitectura de protocolos . . . . . . . . . . . . . . . . . . . . 292.2. Analisis de vulnerabilidades esteganograficas en el Protocolo IP . . . . . . . . . 33

2.2.1. Generalidades del protocolo IP . . . . . . . . . . . . . . . . . . . . . . . 332.2.2. Analisis esteganografico de la estructura del mensaje IP . . . . . . . . . 36

2.3. Analisis de vulnerabilidades esteganograficas en el Protocolo HTTP/1.1 . . . . 602.3.1. Generalidades del protocolo HTTP . . . . . . . . . . . . . . . . . . . . . 602.3.2. Formato y tipo de mensajes . . . . . . . . . . . . . . . . . . . . . . . . . 632.3.3. Parametros del Protocolo . . . . . . . . . . . . . . . . . . . . . . . . . . 682.3.4. Metodos de pedido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772.3.5. Codigos de respuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 792.3.6. Campos del encabezado . . . . . . . . . . . . . . . . . . . . . . . . . . . 862.3.7. Otras consideraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

2.4. Comparacion entre IP y HTTP en funcion del estudio realizado . . . . . . . . . 105

3. Implementacion de un artefacto 1083.1. Descripcion del escenario de aplicacion . . . . . . . . . . . . . . . . . . . . . . . 1083.2. Diseno del artefacto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

3.2.1. Consideraciones generales del artefacto . . . . . . . . . . . . . . . . . . . 1093.2.2. Artefacto sobre el protocolo IP . . . . . . . . . . . . . . . . . . . . . . . 111

3.2.2.1. Detalle de la implementacion . . . . . . . . . . . . . . . . . . . 1123.2.2.2. Pruebas realizadas . . . . . . . . . . . . . . . . . . . . . . . . . 116

3.2.3. Artefacto sobre el protocolo HTTP . . . . . . . . . . . . . . . . . . . . . 1243.2.3.1. Detalle de la implementacion . . . . . . . . . . . . . . . . . . . 1243.2.3.2. Pruebas realizadas . . . . . . . . . . . . . . . . . . . . . . . . . 129

1


4. Conclusiones y futuras lıneas de investigacion 1384.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1384.2. Futuras lıneas de investigacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Apendice 145A. Etimologıa del vocablo esteganografıa . . . . . . . . . . . . . . . . . . . . . . . 145B. Protocolo IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

B.1. Primitivas del modulo IP sugeridas por la RFC . . . . . . . . . . . . . . 145C. Protocolo esteganografico propuesto . . . . . . . . . . . . . . . . . . . . . . . . 147D. Prototipos de metodos del artefacto . . . . . . . . . . . . . . . . . . . . . . . . 148

D.1. Archivos del manejo del protocolo esteganografico (StegProtocol/) . . . 148D.1.1. StegProtocol.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . 148D.1.2. SingleStegProtocol.cpp . . . . . . . . . . . . . . . . . . . . . . 150D.1.3. SharedStegProtocol.cpp . . . . . . . . . . . . . . . . . . . . . . 150

D.2. Archivos del artefacto IP (IP/) . . . . . . . . . . . . . . . . . . . . . . . 151D.2.1. IPDatagram.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . 151D.2.2. IPHeader.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151D.2.3. IPSession.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152D.2.4. IPStegDatagram.cpp . . . . . . . . . . . . . . . . . . . . . . . 153D.2.5. IPStegSession.cpp . . . . . . . . . . . . . . . . . . . . . . . . . 153

D.3. Archivos del artefacto HTTP (HTTP/) . . . . . . . . . . . . . . . . . . 154D.3.1. HTTPConnection.cpp . . . . . . . . . . . . . . . . . . . . . . . 154D.3.2. HTTPHeader.cpp . . . . . . . . . . . . . . . . . . . . . . . . . 154D.3.3. HTTPHeaderField.cpp . . . . . . . . . . . . . . . . . . . . . . 158D.3.4. HTTPMessage.cpp . . . . . . . . . . . . . . . . . . . . . . . . . 159D.3.5. HTTPProxy.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . 165D.3.6. HTTPSemaphore.cpp . . . . . . . . . . . . . . . . . . . . . . . 166

D.4. Archivos auxiliares (utils/) . . . . . . . . . . . . . . . . . . . . . . . . . 166D.4.1. ConfigFile.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . 166D.4.2. random.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166D.4.3. Semaphore.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . 167D.4.4. shmem.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167D.4.5. StringInc.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167D.4.6. TCPSocket.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . 169

E. Script PHP para mostrar encabezados HTTP . . . . . . . . . . . . . . . . . . . 170

Bibliografıa 171

Pablo Andres Deymonnaz (81.755) 2

Agradecimientos

A mis padres,a Adriana, mi directora de tesis,

a mis companeros y amigos, con quienes compartı las horas en la Facultad:Patricio, Federico, Pablo y demas integrantes del grupo somos 6,

a Leonel, Maru y el grupo fellowmugsy a todos los que me apoyaron en los anos de estudio.

Introduccion

Era el mes de julio de 1916, en epoca de la Primera Guerra Mundial, el doctor y espıa YuTsun debıa cumplir la mision de comunicar un secreto a los oficiales del ejercito aleman. Trassus pasos, corrıa el capitan Richard Madden, bajo las ordenes de Inglaterra. Yu Tsun creıa quesu asesinato era inminente, pero aun ası debıa esforzarse para cumplir su mision. Encontro enla guıa telefonica el nombre y la direccion de la persona que lo podrıa ayudar. Esta personavivıa en un suburbio al que llego luego de treinta minutos de tren y con la amenaza del acosode Madden. Descendio en medio del campo y camino por senderos oscuros y solitarios hastaarribar al portal herrumbrado de la casa del sabio sinologo1 Stephen Albert. Inmediatamenteentraron en conversacion. Albert, lo recibio con una sonrisa, con sus cien anos de vida conocıay recordaba perfectamente a su bisabuelo, un notable gobernador y escritor. Compartieron lainterpretacion de una novela de autorıa de este cuando, en un momento de descuido, Yu Tsunempuno un revolver y disparo con sumo cuidado contra Albert, que fallecio en el acto. Luego,aparecio Madden y lo tomo arrestado. Al dıa siguiente, los periodicos publicaron la noticia delasesinato, que llego a manos de los oficiales del ejercito aleman en Berlın. Yu Tsun, aunqueprisionero y luego condenado a la horca, habıa cumplido su mision: Albert era el nombre dela ciudad, al norte de Francia, que debıa atacar el ejercito aleman. Segun sus palabras, paracomunicar el nombre de la ciudad, no habıa encontrado otro metodo que asesinar a una personareconocida, con ese nombre.

El argumento pertenece al cuento “El jardın de senderos que se bifurcan” de Jorge LuisBorges[Bor41].

Desde el comienzo de la civilizacion, el hombre vivio en sociedad y tuvo necesidad de comu-nicarse y, en muchas ocasiones, que esas comunicaciones fueran secretas para terceras personasque intentaran interceptarlas[AB]. El interrogante que se plantea es como transmitir un men-saje entre dos partes de modo que no solamente el mensaje, sino tambien la comunicacionmisma entre el emisor y el receptor pase inadvertida para personas que no participan en lacomunicacion. Ciertamente, asesinar a una persona para lograr este objetivo es solo admisibleen historias de ficcion.

En el presente trabajo se estudia la esteganografıa, entendida esta como la tecnica de comu-nicar mensajes entre dos partes de modo que el propio acto de comunicacion pase inadvertidopor quienes puedan tener acceso al canal de comunicacion (en el cuento citado, los periodicosdesconocıan que al publicar la noticia del asesinato daban a conocer el nombre de una ciudad,y sus lectores corrientes muy probablemente, al leer esa noticia, no lo habrıan sospechado).

El objetivo principal del trabajo consiste en el estudio pormenorizado de los protocolos decomunicacion IP y HTTP para encontrar aplicaciones de tecnicas esteganograficas sobre losmismos. Se entiende por tecnica esteganografica sobre un protocolo a cada una de las interpre-taciones o modificaciones que se aplica a un mensaje del protocolo que permita comunicar unmensaje de manera inadvertida, fuera de las reglas del protocolo. A la posibilidad de aplicacionde esas tecnicas sobre los protocolos se las denominara “vulnerabilidades esteganograficas” de

1estudioso de la cultura china que no pertenece a ella

4


los protocolos.En el primer capıtulo, se presenta una introduccion al tema a tratar y su evolucion historica,

se definen los conceptos que se utilizan a lo largo del trabajo, de manera de establecer una con-vencion de nomenclatura. Se presenta un paralelismo entre la esteganografıa y la criptografıa, yse resaltan las diferencias entre ambas. Mientras que con la primera tecnica se pretende ocultarla existencia de un mensaje, con la criptografıa se le aplica una transformacion para obtener unmensaje cifrado que solo es posible interpretar a partir de la aplicacion de una transformacioninversa (que comprende una clave secreta).

En el segundo capıtulo se trata el analisis de los protocolos IPv4 (Internet Protocol version4 )[Def81] y HTTP version 1.1 (Hypertext Transfer Protocol)[R. 99]. Se toma como base lasRFCs (Request For Comments) respectivas. El estudio de estos dos protocolos se continua conuna comparacion de las conclusiones de la aplicacion de tecnicas esteganograficas en cada unode ellos. Se resaltan las diferencias, surgidas a raız del campo de accion, objetivo y estructurainterna de cada uno.

En el tercer capıtulo se toman como base los puntos analizados en el capıtulo 2, paradisenar un artefacto de software que sera situado en un nodo en la ruta entre aquellos querealizan la comunicacion. El objetivo es mostrar como evitar o disminuir las vulnerabilidadesesteganograficas de los protocolos de comunicacion a partir de la construccion de un guardianesteganografico.

En los ultimos dos capıtulos se presentan las conclusiones sobre la posibilidad de disminu-cion de la aplicacion de las tecnicas esteganograficas analizadas, las lıneas de estudio futurasy se presentan las referencias bibliograficas.

Se entrega, como parte del presente trabajo, una implementacion del artefacto y una simu-lacion en condiciones reales de trabajo, para comprobar su funcionamiento.


Capıtulo 1

Conceptos generales

1.1. Introduccion

En este capıtulo se desarrolla la introduccion teorica a la esteganografıa, se plantean losconceptos generales que se utilizaran, se formaliza una notacion simbolica, se resume la evolu-cion historica a traves de hitos y avances destacados, y se compara con la criptografıa y otrasformas de ocultamiento de informacion.

Se denomina esteganografıa a la tecnica y el proceso de incorporar mensajes que se deseamantener secretos dentro de otros datos, llamados portadores (del ingles carriers)[CMB+08]1.

El objetivo de la esteganografıa consiste en la comunicacion de mensajes entre dos pares(en el sentido de iguales), a traves de un canal de comunicacion, de modo que el propio acto dela comunicacion pase inadvertido por quienes puedan tener acceso a ese canal. Este conceptoradica en la teorıa de seguridad por oscuridad2[PAK99], que supone que si nadie conoce queexiste un mensaje oculto, nadie tratara de obtenerlo. El canal es simplemente el medio utilizadopara transmitir el mensaje desde el emisor hacia el receptor.

Esta practica es posible gracias a la existencia de canales encubiertos3, este concepto fueintroducido por primera vez en 1973 por Butler W. Lampson[Lam73]. Se define canal encu-bierto a aquel que no esta destinado a la transmision de informacion, pero que de algun modopuede utilizarse para una comunicacion. En oposicion a los canales encubiertos, se encuen-tran los canales legıtimos que comprenden a las vıas de comunicacion disenadas a tal fin (e.g.la comunicacion de informacion en el marco de lo establecido por el protocolo IP[Def81] oel almacenamiento de informacion en un archivo en formato XML, conforme a su especifica-cion[Rec08]).

El emisor o transmisor es quien opera con el mensaje para transmitirlo por el canal atraves de los procedimientos predefinidos. El receptor realiza la operacion inversa al emisor,para reconstruir el mensaje. Adicionalmente, se define al destinatario como la persona o cosaa la que esta dirigida el mensaje[Sha48].

La comunicacion esteganografica se sustenta en el establecimiento de un canal subliminalentre el emisor y receptor. Esto es, un canal de comunicacion que explota la existencia de uncanal encubierto para comunicar informacion de manera disimulada, tal que a la vista de untercero simule que la comunicacion real consiste en los mensajes que actuan como portadores.

El concepto de canal subliminal se explica a partir del “Problema de los prisioneros”, for-mulado por Simmons en 1983[Sim83]: Dos prisioneros complices de un crimen fueron arrestados

1En el Apendice A se consigna la etimologıa del vocablo esteganografıa, los vocablos griegos relacionados ysus respectivos significados.

2En ingles se utiliza el termino Security through obscurity3Si bien en la bibliografıa en ingles se utiliza el termino covert channels, en el presente trabajo se utilizara el

termino en espanol.

6


y colocados en celdas separadas. El guardian de la carcel les permite comunicarse mensajesentre sı solo si el transporta el mensaje de uno hacia el otro y comprueba que las comunica-ciones son genuinas (i.e. se debe evitar que coordinen un escape conjunto). En este escenario,los prisioneros deben establecer un canal subliminal en los mensajes a la vista del guardian ydeben evitar ser enganados por mensajes generados o modificados por el.

La analogıa con los prisioneros enfatiza, ademas, que la comunicacion esteganografica serealiza debido a la existencia de un enemigo o adversario. Es decir, un participante, que tie-ne acceso a los mensajes transmitidos a traves del canal de comunicacion, con la intencionde conocer si el emisor y receptor comunican mensajes que desean mantener secretos. Si noexistiera el enemigo (en el caso de los prisioneros, el guardian4), el emisor y receptor podrıancomunicarse de forma abierta, sin aplicar esteganografıa.

Adicionalmente, modelizar la comunicacion esteganografica a traves del problema de losprisioneros permite estudiar que requerimiento de un intercambio previo de informacion existeentre los prisioneros, es decir, cual es el acuerdo previo al momento de ser colocados en lasceldas separadas.

Los canales encubiertos pueden clasificarse en:

Canales encubiertos de almacenamiento: son aquellos en los que la aplicacion de estega-nografıa se desarrolla mediante la alteracion misma de datos almacenados o transmitidos.Como ejemplo de ellos se puede mencionar: la alteracion de campos no utilizados o sinsignificado particular en un protocolo de comunicacion, o la modificacion de los coloresque componen a cada uno de los pıxeles de una imagen en un archivo5.

Canales encubiertos temporales: son aquellos en los que aplicacion de esteganografıa sedesarrolla a partir de la interpretacion del desarrollo temporal de un evento sobre elportador[ABS08]. Como ejemplo, si se recibe antes un mensaje A y luego el B, se puedeasignar un significado diferente a si se reciben en el orden inverso.

Otros tipos de canales encubiertos, derivados de los anteriores: A partir de canales encu-biertos de almacenamiento y temporales puede construirse otros que hagan uso de algunapropiedad derivada. Por ejemplo, se puede realizar un analisis de la variacion de un ca-nal encubierto temporal y obtener una variable estadıstica que constituya una forma decomunicacion (e.g. la varianza). Como ejemplo, se puede mencionar el analisis de tiem-pos de respuesta en un protocolo de comunicacion de tipo pedido/respuesta (del inglesrequest/reply), como lo es el protocolo Internet Control Message Protocol (ICMP)[Pos81].

El portador es todo aquel conjunto de datos que sea susceptible de ser alterado para in-corporarle un mensaje que se mantiene secreto, a partir de la aplicacion de un algoritmoesteganografico (denominado estego-algoritmo) que indica como realizar el procedimiento deincorporacion. Este algoritmo puede estar parametrizado por una clave esteganografica (deno-minada estego-clave) que define como aplicar el algoritmo (por ejemplo, la estego-clave podrıarepresentar el lugar dentro del portador a partir del cual se comienza a realizar la incorpora-cion del mensaje). Tanto el estego-algoritmo cuanto la estego-clave deben estar previamenteacordados entre el emisor y el receptor.

La capacidad de alterar el portador de manera imperceptible es posible a partir de laexistencia de redundancia en el mismo. Las alteraciones pueden realizarse tanto en el contenido,cuanto en otros parametros, como ser, el tiempo de respuesta en la emision del portador.

4Se utiliza la palabra “enemigo” con respecto a quienes desean comunicarse. Son los prisioneros los quedesean comunicarse y el guardian es quien debe conocerlo e impedirlo.

5Se utilizara el termino archivo de manera general para referirse a un conjunto de bits que conforman unaentidad, almacenado en algun dispositivo.



El portador puede ser de varios tipos de datos o formatos: una imagen (e.g. en formatoJPEG[Com]), audio (e.g. en formato OGG6), una porcion de texto plano, un archivo binario,un mensaje de un protocolo de comunicacion (e.g. IP), etc.

La accion de ocultar el mensaje dentro del portador se denomina embeber, mientras que laaccion de la recuperacion posterior del mensaje oculto se denomina extraer [Pft96].

Asimismo, el mensaje a embeber (i.e. mensaje esteganografico) puede ser de diferentesformatos. Por razones de claridad en los ejemplos, en el presente trabajo se utilizaran mensajesde tipo texto. Las tecnicas aplicadas pueden ser extendidas a otros formatos de mensajes (e.g.imagenes, audio, etc.).

Las practicas esteganograficas se emplean con el fin de realizar una comunicacion entredos partes, en este sentido, para que pueda hablarse de esteganografıa, debe haber voluntadde comunicacion por parte del emisor y del receptor. En la figura 1.1 se ilustra cuales son loscomponentes de una comunicacion esteganografica.

Se define como esquema esteganografico al conjunto de componentes que permite llevar acabo la comunicacion esteganografica [CMB+08]:

la seleccion del tipo de portadores: esto es, sobre que tipo de medios se aplicara estegano-grafıa. Esta decision esta condicionada por los portadores a los que puedan tener accesoel emisor y receptor, a transmitir sobre el canal de comunicacion que los vincula.

los algoritmos para embeber y extraer el mensaje en el portador, los cuales contemplanlas modificaciones que se permite realizar al tipo de portador, la forma de interpretarlas modificaciones realizadas y una posible clave esteganografica para parametrizar losalgoritmos.

la manera de transmitir el portador (e.g. a traves de una red, de un archivo enviadoadjunto en un correo electronico, de un texto impreso, etc.).

estego-clave

mensaje a embeber

estego-clave

mensaje extraído

estego-mensaje

Transmisiónembeber extraerportador

Figura 1.1: Esquema de comunicacion esteganografica

La parte izquierda del diagrama corresponde al proceso de incorporacion del mensaje, rea-lizado por el emisor. En este proceso se utiliza un portador, el mensaje esteganografico que sedesea transmitir y aplica un estego-algoritmo parametrizado por una estego-clave. El resulta-do de este proceso se denomina estego-mensaje7 y es transmitido al receptor. El proceso deextraccion consiste en aplicar los estego-algoritmo y estego-clave necesarios al estego-mensajerecibido para obtener el mensaje original. Segun el rol dentro del proceso esteganografico, elemisor es tambien denominado embebedor y el receptor extractor. Al igual que en todo actode comunicacion convencional, es comun que los roles de emisor y receptor se intercambiensucesivamente entre dos partes que se comunican.

Como convencion, se empleara el termino mensaje legıtimo para referir a la informaciono al mensaje transportado por el portador, y el termino mensaje esteganografico para el quese embebe en el portador a partir de tecnicas esteganograficas. En este contexto, la palabra

6S. Pfeiffer. The Ogg Encapsulation Format Version 0 - Request for Comments: 3533, May 2003.7En la bibliografıa se utiliza tambien el termino estego-trabajo.



legıtimo se utiliza para denotar que la comunicacion que se efectua para transmitir ese mensajees conocida, es decir, alguien con acceso al canal de comunicacion puede tomar conocimien-to de la realizacion del acto de comunicacion, a diferencia de lo que ocurre con el mensajeesteganografico.

Cabe destacar que en la practica de esteganografıa, el mensaje a embeber no guarda nece-sariamente relacion con el portador. En el esquema descripto se muestra que en el proceso deextraccion el resultado final es el mensaje embebido, mientras que a los fines de la comunicacionesteganografica, el portador es ignorado o descartado (su objetivo es el mero transporte delmensaje esteganografico), aunque este podrıa tener valor para otros componentes del sistemainformatico (e.g. una foto utilizada como portador podrıa formar parte de una pagina weblegıtima).

Se denomina esteganalista, en sentido amplio, a la persona que intenta determinar la exis-tencia de un mensaje embebido, probar frente a un tercero la existencia del mensaje o queintenta eliminar el mensaje esteganografico de un portador[Pft96]. Se denomina esteganalisisa las acciones tendientes a determinar la existencia o ausencia de un mensaje embebido dentrode un portador. Cabe destacar que la tarea de esteganalisis no intenta determinar el contenidodel mensaje, sino solamente su existencia. Es decir, una comunicacion esteganografica se con-sidera rota si un esteganalista pudo determinar la presencia de un mensaje embebido[PK00].En un sentido estricto, se denomina esteganalista a la persona que intenta aplicar tecnicas deesteganalisis sobre un estego-mensaje. Se denomina estegologıa al compendio de esteganografıay esteganalisis.8

Se denomina cleptografıa (del ingles kleptography) al estudio del robo o filtracion de in-formacion de manera subliminal[AY05], en la que un tercero compromete la seguridad de unsistema informatico a partir de la instalacion de una puerta trasera, que permite la comunica-cion de informacion hacia el exterior[AY07]. El usuario del sistema comprometido desconocela existencia de la puerta trasera. Como extension de los conceptos definidos anteriormente,puede relacionarse a la cleptografıa como la aplicacion de esteganografıa con fines malintencio-nados hacia un damnificado que desconoce de su condicion (i.e. el robo de informacion), dondeel emisor y receptor son la misma persona (i.e. el que perpetra el robo).

Se denomina protocolo de comunicacion al conjunto de reglas o convenciones que rige elintercambio de bloques de datos entre dos pares[Sta04]. Se denomina mensaje de protocoloa cada una de las unidades que se transmite independientemente a traves de un canal decomunicacion y que esta construida sobre la base de las reglas del protocolo de comunicacion.

Se utiliza la definicion de esteganografıa digital como aquella aplicada sobre un canal di-gital, siendo este un canal donde es posible transmitir solo senales digitales. En particular, serestringe la aplicacion a elementos binarios, que pueden ser operados por una computadora.Formalmente, un canal digital se define como una distribucion en secuencias de bits, donde ca-da bit esta etiquetado con un valor de tiempo monotono creciente[NJH02], es decir, preservanun orden.

Se denomina esteganografıa de protocolo a la aplicacion de tecnicas esteganograficas so-bre mensajes de protocolos de comunicacion utilizados como portadores[NBL]. El protocolosubyacente utilizado, sobre el cual se sustenta el esquema esteganografico, puede correspondera cualquiera de las capas de una arquitectura de protocolos (e.g. la arquitectura OSI: OpenSystems Interconnection[Sta04]).

Un algoritmo de esteganografıa de protocolo preserva la sintaxis si, para cualquier mensajedel protocolo que actua como portador y cualquier mensaje que se desee comunicar entre elemisor y el receptor embebido en el portador, se cumple que el estego-mensaje (i.e. el portadormodificado con el mensaje embebido) es un mensaje de protocolo valido de acuerdo con las

8En la bibliografıa suele utilizarse el termino esteganografıa en sentido amplio, en lugar de estegologıa.



reglas de este. Por ejemplo, supongase un protocolo de comunicacion orientado a las cadenasde bits. Si un algoritmo que preserva la sintaxis embebe un mensaje esteganografico, este deberecalcular los posibles bits de paridad de modo que el estego-mensaje resultante sea validoconforme al protocolo. Se puede notar que si un algoritmo preserva la sintaxis, el estego-mensajegenerado no necesariamente tiene el mismo contenido semantico que el portador utilizado,bajo la interpretacion del protocolo de comunicacion del portador. Se dice que un algoritmo deesteganografıa de protocolo preserva la semantica si el estego-mensaje generado posee el mismosignificado que el portador, interpretado a partir del protocolo de comunicacion del mismo. Lapreservacion de la semantica implica, ademas, la preservacion de la sintaxis y, constituye deeste modo una restriccion mas fuerte en el diseno de un algoritmo esteganografico[NBL].

La deteccion de la falta de preservacion sintactica de un mensaje de protocolo en algun pun-to de su recorrido a traves del canal, puede analizarse a partir de la evaluacion de cada mensajeen particular, respecto de su protocolo correspondiente. Este analisis puede ser realizado porun nodo o un enrutador[Tan97] (i.e. un punto de conexion de la red, entre el emisor y receptor,cuya tarea es el reenvıo de los mensajes hacia el nodo siguiente o destino final). Si algun nododetecta un mensaje de protocolo que no cumple con las reglas del mismo, puede descartarlo,es decir, no reenviarlo, puesto que se basa en que la presencia de un mensaje de protocolo novalido responde a problemas en el canal de comunicacion (e.g. errores en la transmision) y queel mensaje no podra ser interpretado por el destinatario final. De este modo, no se cumple elobjetivo principal de la esteganografıa (comunicar un mensaje entre emisor y receptor). Poresta razon, en este trabajo se considera que la preservacion sintactica es una cualidad esencialen un esquema esteganografico de protocolo.

En el esquema esteganografico de protocolo, la ejecucion del algoritmo que embebe el men-saje por comunicar, puede realizarse tanto en el emisor que genera el portador (el mensajedel protocolo), cuanto en un nodo de la red en el camino hacia el receptor (denominado deforma general: host). En el primer caso, el algoritmo esteganografico podrıa formar parte de lacapa correspondiente al protocolo de comunicacion del emisor[Tan97] (seccion 2.1), mientrasque en el segundo caso, podrıa tratarse de un nodo retransmisor de los mensajes de ese proto-colo. La misma consideracion cabe para la ubicacion del algoritmo de extraccion del mensajeesteganografico.

En la figura 1.2 se muestra un esquema de los posibles puntos en donde es posible aplicarlos algoritmos para embeber y extraer el mensaje esteganografico, en el camino que recorre unmensaje entre el emisor y el receptor.

A continuacion se explican los diferentes casos presentados en la figura:

Caso 1 Tanto el emisor cuanto el receptor del protocolo de comunicacion portadorrealizan las acciones de embeber y extraer. El estego-mensaje transita por la red entreambos.

Caso 2 El emisor del protocolo de comunicacion no efectua la incorporacion estega-nografica, el portador transita hasta un nodo donde se efectua el algoritmo de incorpora-cion que lo altera, el estego-mensaje continua hasta el receptor del protocolo que realizatambien la extraccion esteganografica.

Caso 3 Los algoritmos esteganograficos se aplican en nodos de la red. Tanto el emisordel protocolo de comunicacion portador cuanto el correspondiente receptor, generan yreciben el mismo mensaje de protocolo inalterado.

Caso 4 Es similar al Caso 3, con la diferencia que en este el algoritmo de extraccion noreconstruye el portador original (i.e. no modifica al estego-mensaje para que coincida conel portador inicial), sino que retransmite el estego-mensaje hacia el receptor del protocolo.



Emisor

Emisor

Emisor

Emisor

Emisor

Emisor

Receptor

Receptor

Receptor

Receptor

Receptor

Receptor

c

cEmb

mExt

m

s

s

Embm

Ext

m c

c

c

c

c

c

c

c

c

c

Embm

Ext

m

Embm

Ext

m

Ext

m

Embm

Embm

Ext

m

sc

c cs

s

s

s s

c

c

Caso 1:

Caso 2:

Caso 3:

Caso 4:

Caso 5:

Caso 6:

Figura 1.2: Caminos del mensaje en la comunicacion esteganografica

Esto puede ser debido a que no sea posible en todos los casos reconstruir el mensaje deprotocolo original.

Caso 5 El emisor del protocolo de comunicacion portador realiza tambien la incorpo-racion esteganografica, la extraccion se realiza en un nodo en el camino de dicho mensaje,que reconstruye el portador original.

Caso 6 Es similar al Caso 5, con la diferencia que el nodo que realiza la extraccion es-teganografica retransmite el estego-mensaje, sin alterarlo, hacia el receptor del protocoloportador.

Cabe destacar que no es posible implementar todos los casos en algunos ambientes de red,de acuerdo con su configuracion o topologıa. Por ejemplo, los casos 2, 3 y 4, donde se embebe elmensaje esteganografico en un host diferente al que origino el mensaje de protocolo, pueden serimplementados en un esquema de red privada donde uno de los equipos tiene conexion a la redpublica (e.g. Internet)[Tan97]. Por otra parte, la ventaja del caso 3 respecto del caso 1 radicaen que el estego-mensaje s permanece menos tiempo en transito en el canal de comunicacion.

Para los canales encubiertos se puede realizar una subclasificacion entre canales de selecciony clases de equivalencia[Ros]. Los canales de seleccion consisten en canales adicionales al por-tador utilizado para embeber, donde se comunica que posiciones del portador se utilizan parala comunicacion esteganografica. Como ejemplo, se puede suponer como portador a un librode texto. Un canal de seleccion podrıa estar definido por una sucesion de numeros naturalesque representan la posicion de cada una de las palabras dentro del libro de texto que se debeconsiderar para construir el mensaje esteganografico. Las clases de equivalencia corresponden apares de elementos del portador utilizado que tienen una interpretacion semantica equivalenteen la comunicacion legıtima, pero el uso de un elemento u otro tiene un significado acordado



en la comunicacion esteganografica. Por ejemplo, las palabras lindo y bonito son sinonimos enespanol y podrıan utilizarse indistintamente en un texto. Un lector no notarıa diferencia en lasemantica del texto.

Para que una comunicacion esteganografica permanezca indetectable, es importante mante-ner en secreto los portadores originales, es decir, los portadores que se utilizaron para embeberun mensaje[Pro]. En este sentido, los escenarios donde se embebe el mensaje en el mismo emi-sor que genera el mensaje del protocolo (casos 1, 5 y 6 del diagrama) tienen un mayor nivel deindetectabilidad.

La deteccion de la ausencia de preservacion semantica de mensajes de protocolos de co-municacion, por parte de un observador esteganalista podrıa despertar sospechas acerca de laexistencia de comunicaciones esteganograficas en el canal observado, y malograr el objetivode las mismas (i.e. ocultar el acto mismo de la comunicacion). Por un lado, si el algoritmoque embebe el mensaje esteganografico en el portador forma parte del mismo procedimientode construccion del mensaje de protocolo usado como portador (esta situacion se ilustra enlos casos 1, 5 y 6 de la figura), no sera posible detectar si luego de la modificacion produ-cida el embeber el mensaje esteganografico se altero la semantica de protocolo del portador.Por otra parte, podrıa parecer sencillo detectar la ausencia de preservacion semantica cuandola accion de embeber se realiza en un nodo del canal de comunicacion (casos 2, 3 y 4 de lafigura). Pero cabe destacar que esto obligarıa a analizar la totalidad de trafico del canal decomunicacion y comparar los datos transmitidos en diferentes puntos del canal. Lo cual, esuna tarea que consumirıa excesivos recursos de procesamiento y almacenamiento, por lo queresulta generalmente impracticable. Para ilustrar esta situacion se puede mencionar el Decre-to 1563/2004[Kir04] de la Republica Argentina, que impuso a los proveedores del servicio deconexion a Internet la obligatoriedad de almacenar la totalidad del trafico que circulaba porsus redes por el plazo de 10 (diez) anos con fines de “monitoreo de comunicaciones de las re-des publicas y/o privadas de telecomunicaciones”. Debido a la impracticabilidad tecnica, estamedida fue suspendida[Kir05]9.

Se considerara en este trabajo, por tanto, que la preservacion semantica es una cualidad noesencial, aunque deseable, en un esquema esteganografico de protocolo.

La comunicacion esteganografica intenta pasar inadvertida para un tercero que tiene accesoal canal de comunicacion. En el modelo del problema de los prisioneros, este es el guardian dela carcel. Segun su poder de accion sobre el canal de comunicacion, los guardianes se clasificanen:

Guardian pasivo: Tiene acceso a observar los mensajes que transitan por el canal de co-municacion, pero no tiene la capacidad de alterarlos, es decir, tiene acceso de solo-lecturasobre el canal de comunicacion[Cac04]. Cuando detecta la presencia de trafico oculto noautorizado envıa una senal a un sistema externo[RJA97]. Un ejemplo de guardian pasi-vo lo constituirıan las empresas prestadoras de servicio de conexion a Internet bajo lodispuesto por el decreto de almacenamiento de datos citado.

Guardian activo: Tiene acceso al canal de comunicacion y la capacidad de modificaro quitar del canal el contenido que pasa por el cuando detecta trafico no autorizado.Un ejemplo de guardian activo lo constituye el estado de China a traves de la empresade comunicaciones China Mobile en su censura a los mensajes de texto entre telefonoscelulares con contenido sexual o polıticamente no autorizados, mediante la deteccion depalabras pertenecientes a un listado escrito por la policıa[Laf10][Crı10].

9Ademas de cuestiones tecnicas, se presentaron pedidos de declaracion de la inconstitucionalidad de la medida(Camara Argentina de Bases de Datos y Servicios en Lınea c/ EN Cley 25.873C dto. 1563/04 s/ amparo ley16.986.).



Guardian malicioso: Tiene el poder de alterar a su voluntad los mensajes que transitanpor el canal al que tiene acceso, puede componer mensajes nuevos a modo de enganar auno de los prisioneros. Este tipo de guardianes no es comun en los casos reales[Cra]. Sibien, no tiene como objetivo ser guardian frente a una comunicacion entre dos partes,un ejemplo de guardian malicioso podrıa constituirlo una falla en algun nodo de unared de comunicacion. La falla podrıa ser accidental o intencional, maliciosa o no[PV01].A los fines de la comunicacion, la falla puede introducir errores no solo en la comuni-cacion legıtima (del portador), sino tambien en la esteganografica, y en esos casos, losparticipantes deberıan tener un mecanismo de deteccion.

Si el emisor y el receptor se comunican a traves de un canal supervisado o posiblementeafectado por un guardian malicioso, deben asegurarse que cada mensaje esteganografico fueconstruido por la otra parte y no por el guardian. En este caso, se debe aplicar un metodo deautenticacion en cada mensaje[Sim83].

Para el analisis de las comunicaciones, se asume que el canal de comunicacion es librede ruido, en la practica, esto puede asegurarse con protocolos de correccion de errores o, atraves del sustento en el envıo confiable de protocolos de capas inferiores, como puede ser elcaso de comunicaciones entre capas de aplicacion sobre capas de transporte TCP[Tan97]. Lasunicas modificaciones al mensaje que se supondra en el trayecto del emisor al receptor son lasefectuadas por los guardianes (activos o maliciosos).

Cabe mencionar que la sola transmision de un portador en particular puede representar unmensaje esteganografico en sı mismo, sin necesidad de alteraciones sobre el. Por ejemplo, latransmision de una foto cuyo motivo principal es una persona con un sombrero verde podrıaindicarle al capitan de un ejercito la decision de atacar, mientras que la foto con sombrerorojo, la de retirarse. En estos ejemplos, las imagenes serıan copias inalteradas respecto de lascapturadas por un equipo fotografico y el estego-algoritmo consiste en la forma de interpretarlos colores de la imagen. Estas comunicaciones, realizadas en un ambiente en donde es comunel envıo de imagenes, cumplen con el objetivo de comunicar, de forma inadvertida, la decisiondel ejercito de atacar.

Se define como canal supraliminal a las porciones del portador que transmiten informacionque el guardian no puede modificar sin alterar la semantica completa del mensaje legıtimo[Cra].Por ejemplo, en una fotografıa de un arbol, no es posible transformarlo en un monumentosin alterar la esencia de la imagen, o eventualmente destruirla. El arbol en sı constituye uncanal supraliminal. En un portador de protocolo de comunicacion, la identificacion del tipo deprotocolo no puede ser alterada sin destruir el portador. Se desprende que para poder realizaruna comunicacion esteganografica a traves de un canal supraliminal, el contenido del estego-mensaje por sı mismo debe ser una funcion de la informacion embebida dentro del mismo (e.g.si se transmite una fotografıa con un sombrero verde, se debe atacar). Es de notar que la tasaesteganografica de un canal supraliminal es mucho menor a la de un canal subliminal.

La utilizacion de un canal encubierto para transmitir informacion viola una polıtica deseguridad sobre el uso del canal portador. En el marco de este trabajo, se define vulnerabilidadesteganografica de un protocolo de comunicacion a la capacidad de transmision de informacionmediante mecanismos por los cuales el protocolo no fue disenado y, por lo tanto, de manerade violar las polıticas de seguridad del ambiente donde se realiza la comunicacion[Kip04].Un protocolo que posee vulnerabilidades esteganograficas posibilita comunicar informacion deforma subliminal, es decir, realizar esteganografıa.

Se define tasa de un esquema esteganografico digital al numero de bits del mensaje estega-nografico divido el numero total de bits en el portador[NJH02].

Se utiliza la palabra dato para denotar a los elementos componentes de un mensaje. En unmensaje binario, se refiere como datos a los bits que lo componen.



1.2. Notacion

Se utilizara el sımbolo ∈ como en c ∈ C para indicar que el elemento c pertenece al conjuntode elementos C, los sımbolos d y e para denotar el redondeo decimal hacia arriba. Es decir, dxees el menor numero entero que no es menor que x (si x es un numero entero: dxe = x).

Se adopta la nomenclatura Alicia y Boby para el emisor y receptor de la comunicacionesteganografica, de modo que en forma compacta se utilizan sus inicialesA yB respectivamente.Si hubiera mas participantes se utilizarıa las letras C, D. . . (y los nombres asociados: Carlos,Daniel . . . ). Para el guardian (i.e. el esteganalista que tiene acceso al canal que conecta a Aliciay Boby) se utiliza el nombre Walter y cuando se requiera la inicial, la W (en la bibliografıa eningles se utilizan los nombres: Alice, Bob y Warden, este ultimo significa “guardian” en espanol,o Wendy). Tambien se suele utilizar un nombre diferente conforme el guardian es pasivo omalicioso. Si es pasivo, se utiliza el nombre de mujer Eve (por abreviacion de Eavesdropper, quesignifica escuchar secretamente una conversacion sin el consentimiento del emisor y receptor),si es malicioso el nombre utilizado es Mallory (que hace referencia a malvado)[Cac04]. Parasimplificar la notacion, en esta tesis se utiliza el nombre Walter.

A continuacion, se define la notacion simbolica que se utiliza en la tesis.

m: Mensaje que se desea comunicar a traves del esquema esteganografico (i.e. embebidoen un portador).

M: Conjunto de todos los posibles mensajes a comunicar embebidos en un portador(m ∈ M). Este concepto se corresponde con el de fuente de informacion desarrolladopor Shannon en el campo de la Teorıa de la Informacion[Sha48].

c: Portador donde se embebe el mensaje.

C: Conjunto de todos los portadores que se pueden utilizar para embeber un mensaje enun esquema esteganografico determinado (e.g. si se aplica esteganografıa sobre archivosde imagenes en formato JPEG[Com], C estara compuesto por todos los posibles archivosde formato JPEG valido), de este modo c ∈ C.

ks: Estego-clave opcionalmente necesaria para embeber el mensaje. Si la clave necesariapara extraer el mensaje es la misma, se dice que el esquema esteganografico es de clavesimetrica[Pft96].

K: Conjunto de estego-claves posibles (ks ∈ K).

Emb: Estego-algoritmo, que realiza la incorporacion del mensaje m en el portador c. Enterminos generales, Emb debe aplicarse a cualquier elemento de C (conjunto de portado-res), para embeber un elemento deM (conjunto de mensajes posibles) y, opcionalmente,ser parametrizado con un elemento de K (conjunto de claves esteganograficas)[CMB+08].El resultado de Emb sera s (ver figura 1.1).

Si Emb preserva la sintaxis entonces s ∈ C10. Simbolicamente:

Emb : C ×M×K → C

Si, ademas, Emb preserva la semantica, se dice que la interpretacion del portador esequivalente a la misma con el mensaje embebido (necesariamente s ∈ C). Simbolicamente:

s ≡sem c

10Se puede notar que es posible disenar un algoritmo Emb cuyo resultado s /∈ C. En este caso, disminuirıa elnivel de invisibilidad del esquema esteganografico.



s: Estego-mensaje que se comunica entre las partes. De modo que:

s = Emb (c,m, ks)

Ext: Algoritmo de extraccion. El algoritmo de extraccion toma el estego-mensaje s ∈ C(y opcionalmente la estego-clave ks) para producir el mensaje m ∈M. Simbolicamente:

Ext : C →M

Los algoritmos para embeber (Emb) y extraer (Ext) deben ser inversos entre sı con respectoal mensaje m, es decir, el segundo debe permitir recuperar el mensaje embebido por el primero.Simbolicamente:

m = Ext (Emb (m, c, ks) , ks)

Dado un algoritmo Emb y un portador c ∈ C, se define |M|, cardinalidad de M a lacantidad de mensajes m ∈M que es posible embeber en c[CMB+08].

La capacidad para embeber de c, expresada en bits, resulta Sc = log2 |M|. Esto es, si enel portador c es posible embeber l bits, entonces, se podra embeber 2l mensajes diferentes(denominado |M|). En consecuencia, si un mensaje m0 tiene un tamano en bits smo > l, elmensaje m debera ser transmitido fragmentado en d smo

l e partes (denominadas cada una deellas m1, m2, . . . ,mi). Si en cambio, smo < l, se dice que el mensaje m0 tiene una longitudrelativa smo

|M| [CMB+08].El impacto de la esteganografıa sobre el portador c tiene consecuencias en la invisibilidad

del esquema empleado. Para medir este impacto, se define el concepto de distorsion estega-nografica: D (c, s) como la distancia entre c y s. Esta distancia puede ser calculada a partirde algun algoritmo de distancia d para elementos pertenecientes a C (e.g. la cantidad de bitsmodificados).

1.3. Caracterısticas y clasificacion de la esteganografıa

Las caracterısticas de un esquema esteganografico se pueden resumir en:

Invisibilidad : La invisibilidad corresponde al objetivo principal de la esteganografıa: ocul-tar la existencia del acto de comunicacion. Esta condicionada por la medida de la dis-torsion que se le produce al portador debido a la aplicacion del algoritmo que embebeel mensaje. Para hablar de invisibilidad, solo debe tener conocimiento de la existenciade un mensaje embebido el que conoce el algoritmo para extraer (Ext). Ningun otroparticipante debe tener evidencias de su existencia[Aur95].

Confiabilidad : Se denomina confiabilidad a la probabilidad de que el algoritmo de extrac-cion (Ext) emita como salida el mensaje esteganografico m correcto (i.e. el mismo quecoloco el algoritmo Emb)[Cac05].

Robustez : se denomina robustez o Resistencia a la manipulacion[Pap05] al grado deinmunidad del estego-mensaje frente a alteraciones posteriores realizadas por un guardianactivo. Esto es, la probabilidad de que el algoritmo de extraccion (Ext) emita como salidael mensaje esteganografico m cuando el estego-mensaje fue modificado por el guardian.

Capacidad para embeber : corresponde al maximo numero de bits que pueden ser embe-bidos en un portador dado[CMB+08].



Capacidad esteganografica: corresponde al maximo numero de bits que pueden ser em-bebidos en un portador dado de modo que la probabilidad de deteccion por parte de unesteganalista sea despreciable[CMB+08]. La capacidad esteganografica depende del tipode portador y, en general, es mucho menor a la capacidad para embeber. Estos valores decapacidad se conocen, habitualmente, con el nombre de ancho de banda y pueden estarexpresados en bits del mensaje

unidades del portador (e.g. bits del mensaje esteganografico por cada unidaddel mensaje de protocolo: 3 bits/datagrama IP).

En general, es de esperar que el ancho de banda de un esquema esteganografico queexplota una vulnerabilidad (i.e. una redundancia) de un portador, no sea elevado. Encaso que hubiera redundancia, esta serıa eliminada en el portador por cuestiones de eco-nomıa de recursos (menor tiempo de procesamiento, menor espacio de almacenamiento,etc.)[RJA97].

Dependencia del portador : Los metodos esteganograficos estan basados en el analisis delas caracterısticas del portador utilizado y la posibilidad de explotar el uso del mismopara aplicar estas tecnicas[Ros]. Es decir, existe una fuerte dependencia del portadorutilizado.

Segun la naturaleza de los datos portadores utilizados para embeber, la esteganografıapuede ser clasificada en dos categorıas: estructurada y no estructurada (o subjetiva). A conti-nuacion se describe las caracterısticas de los portadores[FFPN]:

Estructurada: se dice que un portador es estructurado cuando su semantica y sintaxisestan previamente definidas y esta destinado a la interpretacion por parte de un sistemainformatico. Esto permite que un nodo, en el camino de la comunicacion, pueda aplicarlas reglas sintacticas que definen la estructura y formato del portador para determinarsi el mismo es valido respecto de su especificacion.

Como ejemplo de portador estructurado se puede mencionar los protocolos de comuni-cacion de redes, como IP[Def81], o el lenguaje XML[Rec08], etc.

No estructurada o Subjetiva: un portador es subjetivo cuando su interpretacion esta de-terminada por parametros difusos, como la percepcion del receptor y carece de una sin-taxis y semantica objetivamente definida. Estos portadores lo constituyen las imagenes,el sonido y el lenguaje natural. En el caso de portadores no estructurados, a diferenciade los estructurados, el receptor final del mensaje es generalmente un ser humano queinterpreta el portador a traves de alguno de sus sentidos. En estos portadores no existe unnivel universal de cuanta informacion puede ser embebida, puesto que se debe analizar elnivel de alteracion de la percepcion para cada contenido del portador en particular (e.g.las alteraciones que se realicen sobre una imagen pueden ser imperceptibles, mientras quelas mismas alteraciones sobre otra imagen pueden degradar notablemente su calidad).

Ejemplos de los mismos lo constituyen un archivo de musica (e.g. en formato MP3 11), unarchivo en algun formato grafico correspondiente a una imagen (e.g. en formato de mapade bits, BMP) o un texto almacenado en un formato de archivo de tipo texto plano.

Si bien la composicion interna de un portador subjetivo en una computadora debe sernecesariamente estructurada, como es el ejemplo de un archivo de audio, y su interpreta-cion esta destinada a un software de reproduccion de musica, la interpretacion final delcontenido es subjetiva, puesto que esta regida por los sentidos de la persona que percibeel sonido ejecutado.

11http://tools.ietf.org/html/rfc3003



Las tecnicas esteganograficas sobre portadores estructurados consisten en asignarle unasegunda interpretacion a los campos y componentes del portador, diferente de la interpretacionasignada por la especificacion del portador, o de aprovechar ambiguedades y vaguedades de laespecificacion (por ejemplo, casos en los que la especificacion no aclare que accion tomar si doscampos diferentes tienen valor 0 al mismo tiempo).

Mientas que la aplicacion de esteganografıa sobre portadores subjetivos consiste en la mo-dificacion del contenido del mismo, que permita construir un mensaje esteganografico a partirde las modificaciones y, a la vez, pase inadvertido por quien percibe el portador. Por ejemplo,al aplicarla sobre imagenes, se puede alterar el nivel de color de ciertos pıxeles de la imagen. Laimagen resultante presentara diferencias respecto de la original, pero tanto el receptor comoun enemigo con acceso al canal de comunicacion, desconocen la existencia del original, incluso,estas modificaciones pueden ser imperceptibles para el ojo humano. En el caso del lenguajenatural, se puede, por ejemplo, aplicar el uso de sinonimos para construir un canal encubiertode seleccion.

La diferencia principal entre un guardian esteganografico de portadores estructurados y otrode subjetivos, radica en que el primero puede actuar sobre el portador con reglas determinadasbasadas en la definicion de la estructura del portador.

En una comunicacion esteganografica, dado que no existe relacion entre el portador y elmensaje esteganografico, el emisor tiene la libertad de elegir cualquier mensaje legıtimo deltipo y canal de comunicacion que actue como portador. Esto implica que el emisor puedeelaborar una regla de seleccion de mensajes legıtimos para decidir cuales modificar, con el finde embeber la comunicacion esteganografica. Segun la forma de seleccion del mensaje legıtimoutilizado como portador, las comunicaciones esteganograficas se pueden clasificar en[CMB+08]:

Busqueda12 de portadores: El emisor cuenta con un conjunto de portadores preexisten-tes y elige uno de ellos para enviar por el canal de comunicacion, sin modificarlo. Lainterpretacion esteganografica se realiza a partir de una propiedad o caracterıstica delportador elegido para la comunicacion. Este tipo de seleccion podrıa utilizarse en el ejem-plo mencionado de la foto del sombrero. La desventaja de este metodo es que la cantidadde portadores requerida para enviar un mensaje esteganografico complejo (i.e. un texto,bastante mayor a un mensaje compuesto por un solo bit), es muy grande.

Sıntesis de portadores: A partir de la necesidad de comunicar un mensaje esteganografico,el emisor construye un portador que no tiene un objetivo ni necesidad real dentro de lacomunicacion genuina. En una comunicacion a traves de Internet, se podrıa generartrafico de mensajes que simulen tener un objetivo legıtimo, por ejemplo, descargar grancantidad de archivos de una pagina web pero realmente ignorar los archivos descargados(los mensajes generados para intercambiar el contenido se podrıan utilizar exclusivamentepara efectuarles alteraciones disimuladas). Por ejemplo, en la seccion 1.5 se mencionaque durante la Primera Guerra Mundial se encontro a espıas alemanes que generabanconversaciones falsas sobre ordenes de pedidos de cigarros.

Modificacion de portadores: Consiste en la alteracion del mensaje genuino para embeberel mensaje esteganografico, de manera que las modificaciones permanezcan inadvertidasa la vista del enemigo. Estas modificaciones estan regidas por el estego-algoritmo (im-plementado en las funciones Emb y Ext), el cual, por una parte le asigna la semanticapropia a las mismas y por otra, decide que porciones del portador son las modificadas.Es el metodo mas comun de aplicacion de esteganografıa y es el representado en la figura1.1. Es el unico metodo que se puede aplicar en los casos 2, 3 y 4 de la figura 1.2.

12del ingles lookup



Del conjunto de porciones del portador que son susceptibles a ser modificadas, la formade eleccion de cuales modificar puede estar regida bajo alguna de las polıticas, deno-minada regla de seleccion[CMB+08]: secuencial cuando el estego-algoritmo realiza lasmodificaciones en todas las posiciones acordadas, pseudo-aleatoria cuando la decision deque posiciones del portador modificar esta determinada por una secuencia de numerosaleatorios (esta secuencia debe estar acordada entre las funciones Emb y Ext, para eseefecto, puede estar determinada por la estego-clave ks) y adaptativa cuando las posicionesmodificadas del portador son determinadas por alguna caracterıstica del mismo (e.g. lapresencia de algun valor determinado en alguna posicion particular).

Si el emisor tiene la posibilidad de seleccionar un mensaje genuino entre varios, para al-terarlo, podrıa elegir modificar aquel que mas se ajuste al mensaje que se desea transmitir.Esto es, el portador que sufra menos modificaciones con la accion de embeber el mensajeesteganografico que se desea comunicar (i.e. el que presente menor distorsion esteganografica).

1.4. Aplicaciones de las tecnicas esteganograficas modernas

Dada la naturaleza de la actividad esteganografica, se presenta difusa la frontera entrelas aplicaciones bien intencionadas[PAK99] (i.e. etica y moralmente correctas) y las que sonmalintencionadas. Es por esto que el diseno de esquemas esteganograficos con fines bien in-tencionados puede devenir en un posterior uso malintencionado y danino de los mismos. Engeneral, esta distincion no se presenta con la aplicacion de tecnicas criptograficas para asegurarel secreto del mensaje, donde lo que se pretende es ocultar solamente el contenido del mensajey no su existencia (seccion 1.6.1).

Las tecnicas esteganograficas pueden ser de especial importancia para las comunicacio-nes de organismos militares o agencias de inteligencia, donde la deteccion de la existenciade la comunicacion puede constituir una informacion util para el enemigo en un escenariobelico[PK00]. Por otra parte, regımenes opresivos de gobierno, o aquellos que limitan la liber-tad de expresion y prensa con mecanismos como el lımite al uso civil de criptografıa, alientanel desarrollo de tecnicas de anonimizacion y esteganografıa en las comunicaciones entre losdisidentes polıticos[PAK99]. Lo mismo puede suceder con el envıo de e-mails secretos desdeempresas que no permiten el uso de criptografıa (o, incluso, el uso de la misma alentarıa elindagar al emisor acerca del contenido de su correspondencia).

Los criminales y distribuidores de drogas ilegales pueden hacer uso de estas tecnicas paracoordinar movimientos, y la eventual negacion (i.e. repudio) ante acusaciones de comunicacio-nes delictivas. En general, usurpan el servicio de comunicacion de telefonıa celular[RJA97].

En general las aplicaciones bien intencionadas se enfocan en asegurar la privacidad dela informacion en computadoras, para protegerla de robo, sabotaje, o el acceso a la mismaa personas no autorizadas. Entre ellas, una aplicacion consiste en ocultar la existencia dearchivos en la computadora, para que los mismos no lleguen a manos de terceras personasmal intencionadas, en caso de robo del equipo informatico. Entre los que permiten efectuarestas operaciones se puede citar el software Steganos Privacy Suite13. El mismo consiste enun paquete de seguridad para uso personal y hogareno que permite aplicar esteganografıa enarchivos de imagenes y musica para ocultar textos14.

Algunos esquemas de voto electronico y dinero electronico hacen uso de este tipo detecnicas[PAK99].

La industria medica y los sistemas de imagenes medicos se benefician de estas tecnicas.En las imagenes de pacientes se adjunta informacion adicional que las describe, denominada

13http://www.steganos.com/14https://www.steganos.com/en/products/data-security/privacy-suite/features/



metadata: nombre del paciente, fecha de la imagen, tipo de imagen, diagnostico. La posibi-lidad de incorporar esa informacion dentro de la imagen evita la perdida de la vinculacionentre la metadata y la imagen relacionada[PK00]. Existen aplicaciones de proposito generalpara agregar etiquetas (tags) a imagenes online para permitir indexacion de las etiquetas ybusquedas[Wes03].

Con respecto a las imagenes y a archivos multimedia en general, uno de los principales usosde las tecnicas esteganograficas consiste en ocultar marcas de copyright en las mismas, quepermitan identificar al autor. Estas marcas pueden ser ocultas o visibles en los archivos multi-media. Estas practicas se conocen con el nombre de Watermarking (marcas de agua). Ademasde las marcas de identificacion del autor, se puede agregar marcas de identificacion del des-tinatario (i.e. numeros de serie). Esto permite determinar quien fue el usuario que violo losderechos de copyright del archivo multimedia. Estas tecnicas se conocen con el nombre de Fin-gerprinting (huellas dactilares)[PAK99]. Una aplicacion consiste en el monitoreo automaticodel material con copyright en Internet: un software robot descarga automaticamente imagenesde sitios web en busca de las marcas ocultas de copyright para identificar a quienes hayanviolado la licencia de uso[PK00]. Ambas tecnicas, watermarking y fingerprinting, no son estric-tamente consideradas esteganograficas puesto que su resultado puede causar una modificacionperceptible. El objetivo principal de las mismas es identificar los derechos de uso del portadory que los mismos no puedan ser quitados del portador sin danarlo perceptiblemente. Aunqueno es indispensable el disimulo de las marcas de copyright para este objetivo, bien se puedellevar a cabo a partir de tecnicas esteganograficas.

Existen tambien impresoras que dejan una marca de puntos imperceptibles a simple vista,que pueden ser usados con fines de investigacion forense15.

Otras aplicaciones en protocolos de transferencia de archivos o el protocolo HTTP, consis-ten en permitir la autenticacion de usuarios sobre la base de mecanismos disimulados. De estemodo, se envıa un contenido a un usuario de acuerdo a su rol, y se diferencia del contenidoenviado a otro usuario. Finalmente, otras aplicaciones sobre protocolos de comunicacion con-sisten en agregar informacion sobre el enrutamiento de mensajes en una red, con el objetivode ganar eficiencia[DK]. Estos ejemplos muestran el uso de canales encubiertos para diferentesfines.

Es evidente la posibilidad de existencia de otras muchas aplicaciones de esteganografıa queno sean publicas, que permanezcan secretas para cumplir con su objetivo de ocultamiento.

1.5. Orıgenes y evolucion historica

A continuacion se presenta una sıntesis de los orıgenes y evolucion historica de la practica deesteganografıa. Se comienza con la mencion de algunos metodos tradicionales (i.e. no aplicadoscon computadoras) y luego se continua con los metodos computacionales mas destacados. Elanalisis de los metodos tradicionales permite transportar algunos conceptos y tecnicas al disenode algoritmos computacionales.

Grecia Clasica Las primeras tecnicas esteganograficas fueron desarrolladas en la antiguaGrecia, en el siglo V antes de Cristo. El primer registro escrito proviene de Herodoto, quienrelato el procedimiento utilizado por el general Histiæus para enviar mensajes desde la ciudadde Mileto: consistıan en rasurar la cabeza de un esclavo (que actuaba de portador) para tatuarel mensaje que se ocultaba, luego, se dejaba crecer suficientemente el pelo y se enviaba alesclavo a la ciudad de destino. El receptor, rasuraba nuevamente la cabeza del esclavo y leıa elmensaje. A traves de estos mensajes se indico a Aristagoras que iniciara una revuelta contra

15http://www.eff.org/pages/list-printers-which-do-or-do-not-display-tracking-dots



el rey de Persia[CMB+08]. A la vista de un enemigo, la presencia del esclavo mensajero nodespertaba sospecha de la existencia del mensaje.

Otros metodos incluıan ocultar la escritura en tablas que se cubrıan con cera. A la vista,esas tablas parecıan blancas, sin escritura. Para leer el mensaje se debıa quitar la cera con calor.Æneas Tacticus propuso varios metodos: ocultar mensajes en aros que vestıan las mujeres, enpalomas mensajeras y en la variacion del grosor de letra en la escritura.

Edad Moderna El aleman Johannes Trithemius es considerado el fundador de la estegano-grafıa moderna. En su libro “Steganographia”, escrito en el ano 1499, describe metodos paraocultar mensajes de texto dentro de otros textos (en particular en los nombres de angeles).Uno de sus inventos es el cifrador “Ave Marıa”: es un cifrador por sustitucion. Para codifi-car un mensaje se reemplazan las letras del mismo por palabras correspondientes, definidasen tablas. El texto resultante simula ser inocente (por esta razon el metodo es consideradoesteganografico en lugar de criptografico)[Bry01].

El italiano Girolamo Cardano realizo su aporte a la esteganografıa en el siglo XVI conla invencion de la Grilla de Cardano. Esta consiste en una pieza de papel con agujeros enposiciones determinadas, que son acordadas entre el emisor y receptor previo a la comunicacionesteganografica. Al colocarse esta pieza de papel encima de un texto escrito (que actua deportador), se puede observar letras que conforman el mensaje esteganografico. Un tercero queintercepte el texto no sospechara de la existencia de un mensaje incorporado en el[Kip04].

El cientıfico aleman Gaspar Schott propuso en el siglo XVII un metodo para ocultar men-sajes en pentagramas musicales que simulen ser musica legıtima. Si bien, al ser ejecutada esapieza musical no serıa agradable, el pentagrama escrito tenıa el aspecto de haber sido elaboradopor un musico[Kip04]. Este es un ejemplo de esteganografıa por sıntesis de portadores.

Las primeras tecnicas de alteracion de estilos tipograficos fueron descriptas por el inglesFrancis Bacon en el siglo XVII. Propuso la utilizacion de estilos tipografico italica y normal ensu escritura para representar un dıgito binario del mensaje esteganografico. Con cinco dıgitosbinarios se conforma una letra del alfabeto (se utiliza menos de 25 = 32 caracteres). Estemetodo sustentaba la indetectabilidad en la existencia de grandes variaciones en la tipografıade su epoca[CMB+08].

Edad Contemporanea En este perıodo historico, iniciado con la Revolucion francesa en1789, las diferentes guerras internacionales llevaron al desarrollo de diversos metodos estega-nograficos que fueron aplicados con resultados mixtos.

Durante la Guerra Franco-Prusiana (1870 - 1871), la ciudad de Parıs se encontraba sitiadae incomunicada con el resto de Francia. Los carteros que transportaban mensajes eran captu-rados por los prusianos. El ejercito parisino encontro la forma de enviar mensajes secretos atraves de palomas mensajeras. Se estima que se enviaron casi cien mil mensajes de esta forma.Al finalizar la guerra, varias fuerzas militares europeas contaban, como parte de su equipoarmado, con palomas mensajeras. Esta forma de comunicacion perduro hasta la utilizacion decomunicaciones inalambricas[Kip04].

Durante la Primera Guerra Mundial se emplearon varios metodos de ocultamiento con ob-jetos, como las Grillas rotantes, que consistıan en una evolucion de las Grillas de Cardano,donde en estas se escribıa un texto en forma de cuadrıcula que se hacıa rotar en la hoja utiliza-da16. Ademas, se desarrollaron tecnicas de microfotografıa para reducir imagenes del tamanode una pagina de papel al de una moneda (la utilizacion de esta tecnica fue descubierta duran-te la Guerra)[CMB+08]. Se utilizo tambien el envıo de mensajes con personas que ocultabanpapeles con tinta invisible en sus zapatos o prendas de vestir[Kip04].

16esta tecnica es denominada acrostico y suele emplearse en juegos de ingenio del tipo “sopa de letras”



Un caso trascendido durante la Guerra lo constituye el de un correo postal que al enviar unacarta modifico el texto “Father is dead” (El padre esta muerto) por “Father is deceased” (Elpadre esta fallecido). Al poco tiempo se recibio la respuesta “Is father dead or deceased?” (¿Elpadre esta muerto o fallecido? )[RJA97]. En este caso, el correo actuo como guardian activo yevito la transmision de un mensaje esteganografico.

Por otra parte, espıas alemanes fueron descubiertos en conversaciones al comunicarse en-tre sı ordenes de pedido de cigarros. La cantidad y tipo de cigarros tenıan un significadooculto. Estas comunicaciones despertaron sospecha debido al elevado numero de cigarros enlos pedidos[Kip04]. Este ejemplo constituye un caso en donde el algoritmo para embeber elmensaje esteganografico en el portador o generar un portador con el mensaje embebido nocumplio con el requisito de invisibilidad. Por lo tanto, no se cumple el objetivo de la estegano-grafıa. Esta tecnicas se conocen con el nombre de codigos de jergas17.

Durante la Segunda Guerra Mundial, se creıa mas eficaz el envıo de mensajes secretos atraves de tecnicas esteganograficas que criptograficas. Estados Unidos creo una organizacionde censura para pensar en formas creativas de modificar elementos que pudieran transportarmensajes (i.e. que actuaran como portadores). Entre los elementos puestos bajo vigilancia seencuentran: estampillas postales que fueron reemplazadas por otras de igual valor pero diferenteimagen, hojas en blanco en busca de tinta invisible, la modificacion del texto de cartas de amor,los textos confusos o en idioma diferente al de los participantes de la Guerra, cartas de Navidad,entre otros[Kip04].

Durante la guerra de Vietnam, el Comandante Jeremiah Denton, piloto de la fuerza naval deEstados Unidos, fue capturado y puesto en prision. En un momento, sus captores le permitieronbrindar una conferencia de prensa. Denton sabıa que si revelaba detalles de sus captores frentea las camaras podrıa ser asesinado. Mientras hablaba frente a los medios, Denton pestaneo susojos con la palabra T-O-R-T-U-R-E en codigo Morse[Kip04].

Un hecho de reciente trascendencia lo constituye un mensaje insultante descubierto ocultodentro de una carta escrita a fines de 2009 por Arnold Schwarzenegger, alcalde de California,Estados Unidos. El mensaje esteganografico estaba formado por la primera letra de cada unade las lıneas de la carta. El hecho fue posteriormente desmentido por las autoridades18.

Actualmente, las fuerzas de seguridad de diversos organismos y paıses emplean mensajesesteganograficos incorporados en comunicaciones, con el objetivo de evitar el conocimiento delas mismas por parte de algun enemigo que constituya una amenaza de peligro.

Otro ejemplo actual y difundido de uso de comunicaciones esteganograficas lo constituyenlos radio-taxis de la Ciudad de Buenos Aires. Los choferes de taxi emplean ciertas palabrasacordadas previamente durante una conversacion por radio con la agencia que actua comobase de operaciones. A la vista del pasajero que viaja dentro del taxi, la conversacion puedeparece normal, incluso, sobre un tema intrascendente, pero la interpretacion que realiza elinterlocutor sobre la comunicacion constituye un mensaje esteganografico. Estas tecnicas se

17 Como ejemplo de codigos de jergas puede mencionarse una leyenda familiar: muchos anos atras un familiarviajo de Argentina a Italia a visitar a sus parientes. A los pocos dıas, envıa un telegrama con el texto: “Mortadela,mandarina”. La interpretacion del mensaje era la siguiente, se comunicaba el fallecimiento de Adela, y el mensajelo remitıa Rina. Cabe destacar que la empresa de telegramas cobra sus envıos por cantidad de palabras (y enun mensaje internacional los valores son mayores). Expresar ese mensaje con la semantica explıcita hubieranecesitado varias palabras mas que las dos utilizadas. La empresa de comunicacion desconocıa que transmitıa elfallecimiento de una persona (a la vista de un tercero, el mensaje podrıa remitir a un listado de ingredientes ocomidas). En este caso, el empleo de la esteganografıa permitio reducir el costo del envıo del mensaje. Ademas,constituye un caso de aplicacion de esteganografıa pura, esto es, no se necesito una explicacion previa (anterioral viaje) de la jerga entre el emisor y receptor[PK00]. Con creatividad suficiente, el receptor pudo interpretar elmensaje esteganografico.

18http://www.nytimes.com/2009/10/29/us/29arnold.html. El texto de la carta puede leerse en el sitio oficialdel gobierno de California: http://gov.ca.gov/pdf/press/2009bills/AB1176 Ammiano Veto Message.pdf



emplean para comunicar disimuladamente diversas situaciones: peligros, disconformidad con elpasajero, numeros de telefono, etc.19

Etapa computacional Este perıodo da el nombre de lo que se conoce como Esteganografıamoderna[PAK99].

Como se ha mencionado, la definicion de canales encubiertos de comunicacion en transmi-siones por computadora fue realizada por primera vez por Lampson en 1973, y el estudio formalde la esteganografıa en computadoras continuo con la investigacion de Simmons publicada en1983.

La mayor investigacion y desarrollo en este area se centra en torno a la aplicacion de latecnicas en archivos de computadora de formato multimedia (audio, imagen, video)[CMB+08].Con respecto a la aplicacion en archivos de audio, la investigacion se centra en el modelopsicoacustico humano para determinar posibilidades de enmascaramiento de sonidos de formaimperceptible. Entre las tecnicas con aplicacion en archivos de imagenes, los metodos se centranen la modificacion de las imagenes de forma imperceptible para la vista. El mas simple ydivulgado de estos metodos es el de la sustitucion del bit menos significativo (o LSB por lassiglas en ingles de Least Significant Bit)[PK00]. En una imagen donde cada pıxel tiene un valorasociado que corresponde al color del mismo, el bit menos significativo de ese valor se modificapor un bit del mensaje esteganografico. Esto se realiza para cada pıxel de la imagen, o paraun conjunto seleccionado a traves de un mecanismo de seleccion (e.g. un mecanismo aleatoriosincronizado entre el emisor y el receptor). Este metodo tiene una probabilidad de modificaciondel portador de 0,5 para cada bit de cada pıxel empleado: si el bit del mensaje esteganograficocoincide con el bit menos significativo del pıxel de la posicion correspondiente, dicho bit no semodificara (y, en consecuencia, la imagen permanecera inalterada en ese punto).

En la actualidad, existen cientos de productos de software20, distribuidos a traves de In-ternet que permiten realizar comunicacion o la aplicacion de diversas tecnicas esteganograficasen archivos multimedia[CMB+08].

La Industria Discografica tiene especial interes en el desarrollo de tecnicas esteganograficasque permiten ocultan marcas de copyright y numeros de serie en archivos de pelıculas, audio,libros y archivos multimedia para intentar disminuir la distribucion de copias ilegales[RJA97].

Con el avance reciente de las comunicaciones e Internet, la evolucion de la esteganografıa hatenido especial atencion como metodo para mantener el secreto de las comunicaciones[NBL].

Se sospecha que grupos terroristas que planificaron los ataques del 11 de septiembre de2001 en Estados Unidos transmitieron mensajes a traves de Internet ocultos en archivos deimagenes o audio[CK01][McC01][Roo]. Entre ellos, se cree que se utilizo el canal de ventaseBay21 para la comunicacion de las imagenes con mensajes esteganograficos.

1.6. Relacion de la esteganografıa con otras tecnicas de comu-nicacion seguras

En el presente trabajo se centrara el estudio en el uso de tecnicas esteganograficas conrespecto a la confidencialidad: se estudian formas de utilizar los protocolos de comunicacioncomo portadores de una comunicacion esteganografica. La confidencialidad radica tanto en elcontenido de los mensajes esteganograficos, cuanto en la realizacion de la comunicacion misma.Por otra parte, se analiza y construye un prototipo de guardian activo que intenta evitar larealizacion de dicha comunicacion.

19Esta informacion fue provista por el testimonio en persona de un chofer de taxi anonimo.20Se puede ver a una recopilacion de productos de software en: http://www.jjtc.com/Security/stegtools.htm21http://www.ebay.com/



Se deja fuera del alcance del trabajo el resto de los usos que puede realizarse de las tecnicasesteganograficas.

La comunicacion se compone de varios elementos: el emisor, receptor, mensaje, canal.La esteganografıa se puede relacionar con otras tecnicas que pueden ser usadas para man-

tener la confidencialidad o secreto de alguno de los elementos mencionados. La esteganografıaintenta mantener el secreto del acto de comunicacion y, en consecuencia, el mensaje que secomunica y el canal utilizado. Otra forma de ocultar la existencia de una comunicacion es apartir de la generacion de comunicaciones aleatorias, sin un significado legıtimo, de modo quepara una tercera persona con acceso al canal, se dificulte la tarea de detectar la existencia dela comunicacion legıtima, dada la existencia de las aleatorias.

Por otra parte, para mantener el secreto del mensaje, se aplican tecnicas de Criptografıa.La aplicacion de criptografıa consiste en transformar el mensaje a partir de un algoritmo deencriptacion y una clave criptografica para obtener un mensaje resultante que solo puede serinterpretado a partir de la aplicacion del algoritmo de desencriptacion y la clave correspon-diente. Un algoritmo criptografico puede ser de clave simetrica, cuando se utiliza la mismaclave para los algoritmos de encriptacion y desencriptacion, o puede ser de clave asimetricao clave publica, cuando se utiliza una clave para el algoritmo de encriptacion y otra para ladesencriptacion[Sta06].

Una tercera persona con acceso al canal de comunicacion, puede observar que el contenidotransmitido consiste en un mensaje que no puede interpretar y, en general, podrıa observarquienes son el emisor y el receptor. Puede intentar descubrir el contenido del mensaje originala partir de realizar Criptoanalisis.

Para asegurar el secreto del emisor y el receptor en la comunicacion, se utilizan tecnicasde Anonimizacion o Prevencion de la identificacion. La aplicacion de estas tecnicas en redesde computadoras comenzo con el concepto de Chaum Mixes publicado por David Chaum en1981 para la distribucion anonima de mensajes de correo electronico[Dav81]. Los Chaum Mixesconsisten en nodos intermedios de la red, en el camino entre el emisor y el receptor del mensaje,que reciben los mensajes del emisor, los cuales a la vista de un tercero estan dirigidos al ChaumMix, y luego los retransmiten al destinatario o a otro Chaum Mix en forma desordenada, demodo que se dificulte conocer quien fue el emisor del mensaje y el orden en el que se recibieronlos mensajes o los fragmentos de los mismos. En ciertas ocasiones, el conocer el emisor yreceptor de una comunicacion provee informacion suficiente para un enemigo.

Estas tecnicas pueden ser aplicadas en conjunto, para asegurar un mayor nivel de privaci-dad, o por ejemplo, para comunicar de forma esteganografica una clave que deba ser empleadapor un algoritmo criptografico.

Por otra parte, actualmente, hay una creciente atencion puesta en la privacidad de lainformacion, debido principalmente al auge de las redes sociales en Internet[Ali10], donde losmensajes quedan almacenados y, generalmente, pueden ser accedidos por tiempo indefinido.Existen investigaciones respecto de asignar una fecha de caducidad a los mensajes. Tal es elcaso del protocolo Vanish22 que integra tecnicas criptograficas y la distribucion de las claves decifrado, con el objetivo de asegurar que luego de la fecha de expiracion fijada para el mensajese destruya la clave que permite obtener el mensaje original.

1.6.1. Relacion entre la Esteganografıa y la Criptografıa

A continuacion, se realiza una comparacion de la aplicacion de esteganografıa con respectoa criptografıa segun los siguientes objetivos referidos a la seguridad de las comunicaciones23:

22http://vanish.cs.washington.edu/23Se deja fuera de la enumeracion otros aspectos de la seguridad de las comunicaciones, como la defensa ante

la replicacion de mensajes (i.e. el envıo del mismo mensaje repetidas veces por parte de un enemigo).



Confidencialidad : Entendida como mantener el secreto. En un esquema criptografico, laconfidencialidad implica que una tercera persona no pueda conocer el contenido del men-saje que se transmite a traves de un canal. Al aplicar esteganografıa, la confidencialidadimplica el disimulo del acto mismo de comunicacion entre dos pares, ademas del conteni-do comunicado. Mientras que al aplicar criptografıa, la confidencialidad implica asegurarel secreto del mensaje. En este sentido, la esteganografıa implica un mayor grado deconfidencialidad respecto del uso de criptografıa.

No Repudio: Entendido como la prevencion, por parte del emisor o receptor, del negarla transmision del mensaje. En un esquema criptografico, el no repudio implica aplicarun proceso de firma digital : encriptar un mensaje con una clave que es solo conocidapor el usuario firmante (i.e. su clave privada). El resultado de este proceso, es una firmaque puede ser verificada con la aplicacion del algoritmo de desencriptacion con la clavepublica del firmante. En un esquema esteganografico, no se puede aplicar el concepto deNo Repudio mencionado, sino que el autor de un mensaje puede utilizar tecnicas este-ganograficas para mostrar que un estego-mensaje es de su autorıa, dado que el portadorpuede estar alterado con reglas que solo el conoce, estas tecnicas son las descriptas bajo elnombre de Watermarking y algunas son utilizadas en los mecanismos de aseguramientode derechos digitales sobre documentos multimedia[CMB+08].

Integridad : Se refiere a la prevencion de la modificacion de los datos transmitidos, duranteel curso de la comunicacion. Las tecnicas criptograficas utilizan funciones de hashing24

y firmas digitales para construir un codigo que permita verificar que el mensaje no fuealterado[Sta06]. En el caso de la aplicacion de esteganografıa, se podrıa aplicar unafuncion de hashing sin alterar el mensaje legıtimo. De este modo, el receptor podrıaverificar, de una forma secreta, que el mensaje legıtimo no fue alterado por una tercerapersona con acceso al canal. A diferencia de la aplicacion de criptografıa, en el caso deesteganografıa, una tercera persona desconocerıa que se aplican estas tecnicas.

Autenticacion: Se refiere a asegurar que un mensaje es autentico, es decir, que fue genera-do por quien dice ser su emisor (i.e. no existe una tercera persona que genere mensajes anombre del emisor). Con criptografıa, se aplica una firma digital sobre el mensaje legıti-mo. El receptor puede comprobar la firma con la clave publica del emisor. Al aplicartecnicas de esteganografıa, se puede ocultar la identificacion del emisor, embebido en elportador, y el receptor podrıa ser capaz de verificar la autenticidad del emisor a partirde un estego-algoritmo sobre el portador. Para un atacante que desee emitir mensajes anombre de otro, en el caso criptografico, la seguridad radica en la fortaleza de la claveprivada del emisor atacado, mientras que en el caso esteganografico, la seguridad radicaen el secreto de la aplicacion de esteganografıa para transmitir el generador del mensaje.Romper el esquema de autenticacion implica vulnerar cada uno de estos aspectos.

En lıneas generales, la criptografıa intenta proteger el mensaje de un enemigo, pero sinesconder que se realiza una comunicacion y una proteccion a la misma. Mientras que conesteganografıa, se intenta ocultar que se protege la comunicacion[NBL]. En este sentido, sepueden enumerar las consecuencias de esta diferencia como las siguientes:

La existencia de un mensaje cifrado, i.e. con aplicacion de criptografıa, levanta sospechaal enemigo que lo observa: Incluso, acorde a las circunstancias de la comunicacion y el

24Las funciones de hashing transforman un valor de entrada, de longitud variable, en una salida de longitudfija. Esta transformacion es, evidentemente, irreversible. La robustez de una funcion de hashing radica en ladificultad de construir un nuevo valor de entrada que produzca el mismo resultado, o hash, que otro valor deentrada[Sta06].



enemigo, este podrıa amenazar o torturar a los participantes de la comunicacion legıtimapara que revelen el contenido del mensaje. Con la aplicacion de esteganografıa no selevanta sospecha de una proteccion a la comunicacion. Por ejemplo, si una empresadetecta que un empleado envıa mensajes cifrados al exterior de la misma, sin causajustificada, constituirıa un indicio de un comportamiento inadecuado hacia la empresa.

Encriptar mensajes alienta desarrollar mecanismos de extorsion para conseguir el mensajeplano (i.e. el contenido original). En contraposicion, en el caso comentado de los esclavosmensajeros, en la Grecia Clasica, ellos podrıan desconocer el contenido del mensaje escritoen sus cabezas, incluso desconocer que se les habıa escrito un mensaje (por ejemplo,creer que el tatuaje podrıa referir al dueno del esclavo). Si un enemigo los interceptaen el trayecto hacia el destino, por mas que les apliquen torturas, no podrıan revelar elmensaje.

El hecho de encontrar un mensaje encriptado, suele alentar el desafıo de quebrarlo: Porejemplo, en un escenario belico, si uno de los contendientes intercepta un mensaje encrip-tado del adversario, se vera motivado a encontrar mecanismos para quebrar la seguridady obtener el mensaje original.

La deteccion de un mensaje encriptado puede ser suficiente para un enemigo: en ocasionesno es necesario conocer el contenido del mensaje. El solo hecho de conocer que se efectuauna comunicacion puede ser suficiente informacion. En el escenario belico, si una basemilitar le envıa un mensaje encriptado a otra base, y este es interceptado por un enemigo,podrıa decidir atacar la base militar que recibe el mensaje[PAK99].

El poder de computo de las computadoras aumenta y atenta permanentemente contrala robustez de los algoritmos criptograficos: un algoritmo seguro hoy en dıa puede noserlo en un futuro[LaR08]. Si la seguridad radica en la clave criptografica, un ataque porfuerza bruta (i.e. probar desencriptar con todas las claves posibles) sera mas rapido dedesarrollar con equipos computacionales con mayor capacidad de procesamiento.

Suele ser difıcil demostrar la confiabilidad de algoritmos criptograficos y, en ocasiones, lavulnerabilidad de la seguridad criptografica puede radicar en el algoritmo utilizado. Comoejemplo, en el ano 2004, se encontraron formas de quebrar el algoritmo de hashing MD5,usado en ciertos protocolos criptograficos. Esto es, para un mensaje de entrada y su hashgenerado segun el algoritmo MD5, se quiebra el algoritmo de hash con un procedimientoque genera otro mensaje, diferente al primero, que posee el mismo hash MD5 que elprimero[Vla05]. De forma similar, puede ser difıcil demostrar la confiabilidad de unacomunicacion esteganografica, es decir, la invisibilidad de un mensaje esteganograficoembebido en un portador.

Con respecto a los aspectos legales de la criptografıa: en algunos paıses, la aplicacion ydistribucion de algoritmos criptograficos esta legislada. Como ejemplo, puede citarse elalgoritmo de clave publica PGP (Pretty Good Privacy). Las leyes federales de EstadosUnidos prohibıan la exportacion de algoritmos criptograficos que utilicen claves de masde 40 bits y, PGP las utilizaba. Cuando su autor, Philip Zimmermann puso a disposicionel software en febrero de 1993, fue investigado y acusado criminalmente por el gobiernode Estados Unidos. Finalmente, en 1996, el juicio fue declarado nulo[75.]. Con respectoa la aplicacion de esteganografıa, se plantea una dificultad en la naturaleza de dichaactividad para su legislacion, puesto que no es sencillo legislar comunicaciones secretasque no levantan sospecha de su existencia y, mas aun, demostrar la existencia de las



mismas en una instancia judicial puede ser mas complejo (o incluso impracticable) quedemostrar comunicaciones criptograficas.

Por ultimo, puede mencionarse una popularidad ampliamente mayor de la Criptografıarespecto de la Esteganografıa25 entre personas no especializadas en el area de seguridadinformatica. Esto puede deberse a que la aplicacion de tecnicas criptograficas es en lapractica mas facil que las tecnicas esteganograficas. En particular las tecnicas estega-nograficas requieren una alta sincronizacion entre el emisor y el receptor para mantenerla comunicacion. Adicionalmente, la esteganografıa tiene una capacidad de embeber unmensaje que es limitada y fuertemente condicionada por el portador.

1.6.2. Caso de ejemplo: Caballos de Troya

Los Caballos de Troya son piezas de software construidas por atacantes (i.e. con finesmaliciosos) para instalar un virus informatico dentro de una organizacion. El Caballo de Troyaconsiste en un software oculto dentro de otro software que actua como portador. A la vista delusuario final, el software hace lo que hace el portador (e.g. un videojuego, un saludo navideno,etc.) y, al mismo tiempo, instala de forma oculta el otro software, que el usuario no puedever. El software oculto consiste, generalmente, en una puerta trasera que permite al atacantetomar control remoto del equipo atacado, o un virus que dane informacion del usuario.

El termino Caballo de Troya proviene de la Grecia Clasica. Los griegos proveyeron uncaballo gigante de madera a los troyanos a modo de ofrenda. Dentro suyo habıa soldadosgriegos que al salir del caballo capturaron a troyanos[Cor].

Los Caballos de Troya se asemejan a las actividades esteganograficas, dado que consistenen una parte oculta dentro de un portador, pero su principal diferencia radica en el objetivode la actividad: como se menciono anteriormente, con las tecnicas esteganograficas se requierevoluntad de ambas partes para realizar la comunicacion y la necesidad de proteccion frente aun enemigo, mientras que el Caballo de Troya no tiene el consentimiento del usuario que lorecibe, sino que es afectado por su actividad y no constituye una proteccion contra un tercerocon acceso al canal de comunicacion. Ademas, los mensajes esteganograficos son consideradospasivos, esto es, no contienen instrucciones, sino que constituyen un acto de comunicacion,mientras que el Caballo de Troya representa software activo para el receptor[Col03].

Por otra parte, los Caballos de Troya, pueden realizar actividades esteganograficas. Unavez que han instalado una puerta trasera en el equipo vıctima, pueden enviar informacion quese encuentre en esa computadora hacia otra computadora a traves de una red con tecnicasesteganograficas que disminuyan la probabilidad de levantar sospecha de su actividad (comopueden ser las tecnicas sobre los protocolos estudiados en el presente trabajo). Como ejemplo deCaballo de Troya, puede mencionarse la propagacion de Daprosy en Julio de 200926, destinadoa obtener contrasenas de redes de juegos ingresadas por el usuario de la computadora atacada.

Actualmente, hay un incremento creciente en la diseminacion y ataque con este tipo detecnicas[Cor]. Existen mecanismos tendientes a minimizar la posibilidad de intrusion de estasamenazas, como los software antivirus, o las tecnicas de hardening, que tienen como objetivodisminuir las vulnerabilidades de seguridad de los sistemas computacionales, a partir de laaplicacion de configuraciones restrictivas. Entre ellas, se puede mencionar las recomendacionesde CIS (Center for Internet Security)27, que elabora metricas, propuestas de configuraciones

25Una consulta en el buscador de Internet Google (http://www.google.com/ ) muestra mas de nueve millonesde resultados para la palabra “cryptography”, mientras que para la palabra “steganography” devuelve alrededorde cuatrocientos mil. Se decidio utilizar las palabras en ingles porque tienen mayor aparicion que las mismas enespanol.

26http://www.symantec.com/en/sg/security response/writeup.jsp?docid=2009-071521-4358-9927http://cisecurity.org/



y benchmarks (analisis de la implementacion de las medidas de seguridad).


Capıtulo 2

Analisis de Protocolos deComunicacion

En el presente capıtulo se analiza las vulnerabilidades esteganograficas de los protocolosde comunicacion IP (Internet Protocol) y HTTP (Hypertext Transfer Protocol) entre redes decomputadoras. En el caso de IP, se analiza la version 4, que es la que sustenta actualmentelas comunicaciones en Internet, basado en la RFC (Request for Comments) numero 791 Inter-net Protocol, DARPA Internet Program, Protocol specification, prepared for Defense AdvancedResearch Projects Agency [Def81]. En el caso de HTTP, la version analizada es la 1.1, que cons-tituye la version vigente, definida en la RFC 2616 Network Working Group, Hypertext TransferProtocol – HTTP/1.1 [R. 99]. Cabe mencionar que ambas RFCs figuran entre las cincuenta maspopulares segun el sitio Internet FAQ Archives1.

En lo sucesivo, cuando se requiera hacer mencion a cada RFC respectiva se usara la expre-sion la especificacion del protocolo o, simplemente, la especificacion.

El analisis de las vulnerabilidades esteganograficas estara centrado en descubrir canales en-cubiertos en los mensajes de los protocolos de comunicacion. Estos actuaran como portadoresde la comunicacion esteganografica. Es decir, se analizara la posibilidad de realizar segundasinterpretaciones (i.e. diferentes a las dadas en la especificacion) a las estructuras y campos delos mensajes de protocolo que permitan llevar a cabo una comunicacion. Esta comunicacionno estara regida bajo las reglas de la especificacion del protocolo y el objetivo es que la mismapase inadvertida ante la vista de un tercero que tenga la posibilidad de observar los men-sajes del protocolo. En consecuencia, se habla de comunicacion a partir de vulnerabilidadesesteganograficas del protocolo.

El analisis de dichas vulnerabilidades permitira aplicar esteganografıa por modificacion deportadores, para desarrollar la comunicacion. Este tipo de tecnicas es la mas comun (puede seraplicada en todos los casos de la figura 1.2 del capıtulo 1), y permite, sin perdida de generalidad,extender las conclusiones del analisis de los protocolos a las practicas de esteganografıa porbusqueda o por sıntesis de portadores.

En concreto, se buscara determinar la posibilidad de realizar comunicaciones de estegano-grafıa de protocolo y se dejara fuera del alcance del presente trabajo el analisis de aplicacionde esteganografıa sobre el contenido, es decir, sobre los datos que transporta el mensaje deprotocolo. El contenido transportado por el mensaje de protocolo puede ser, a su vez, portadorpara otros tipos de tecnicas esteganograficas, que deben ser analizadas en relacion al tipo decontenido particular, dada la fuerte dependencia del portador en estas tecnicas (e.g. puedetratarse de texto, de una imagen, de un mensaje de otro protocolo de comunicacion, etc.).En ciertas ocasiones la frontera entre lo que constituye esteganografıa de protocolo y de su

1http://www.faqs.org/rfc-pop1.html

28


contenido puede parecer difusa.La identificacion de vulnerabilidades en protocolos de comunicacion, surgidas a partir de

canales encubiertos explotables en el marco de una comunicacion esteganografica, es vital enel desarrollo de sistemas de seguridad con polıticas obligatorias de control de acceso[ABS08].

Para los fines del presente trabajo, i.e. descubrir los canales encubiertos en los protocolosde comunicacion, se asumira que para satisfacer el requerimiento de invisibilidad (i.e. ocultarla existencia del acto de comunicacion) se tomara por suficiente que los mensajes de proto-colo intercambiados entre emisor y receptor, por un lado preserven la sintaxis: los portadoresmodificados sobre la base de las reglas propuestas seran validos segun la especificacion delprotocolo y, por otra parte, preserven la semantica: el portador modificado debera cumplir elmismo objetivo de la comunicacion genuina que el portador no modificado (el acto de modificarel portador no interfiere con la comunicacion genuina). Esto permite concentrar el analisis enel protocolo propiamente dicho, y las posibilidades de aplicacion de tecnicas esteganograficassobre el mismo.

Si se quisiera realizar esteganografıa por sıntesis de portadores, los mensajes de protocoloconstruidos al efecto deberıan ser validos de acuerdo al protocolo (no se habla estrictamentede preservacion sintactica porque el mensaje no existe previo a su construccion) y el contenidodel mismo puede ser inutil (puede generarse contenido que simule ser real y que sea descartadosin ser interpretado por el receptor, como tambien, puede generarse contenido que ni siquierasimule ser real, conforme a las necesidades y escenario de la comunicacion, como eran laspartituras musicales mencionadas en la seccion 1.5).

Los mensajes de protocolo de los dos protocolos estudiados consisten en estructuras de-finidas en una especificacion, destinadas a ser interpretadas por computadoras, es decir, nohay interpretaciones subjetivas de los mismos. En consecuencia, el analisis correspondera aesteganografıa aplicada a portadores estructurados (seccion 1.3).

En las situaciones en las que el analisis teorico de la especificacion se complemente con unexperimento empırico, se utilizara el software Wireshark2, que realiza la captura del trafico dedatos a traves de la interfaz de red de la computadora (en ingles se conoce esta actividad comosniffing) y permite la interpretacion de las estructuras de gran cantidad de protocolos3, entrelos que se encuentran los analizados en el presente trabajo.

2.1. Introduccion a la arquitectura de protocolos

Con el objeto de reducir la complejidad en su diseno, el software de red que implementalos protocolos de comunicacion se jerarquiza en capas. Cada capa ofrece servicios a la capasuperior, de modo que la capa superior no tiene que ocuparse por la implementacion real deesos servicios. Cada capa de una computadora se comunica con la capa par (i.e. del mismonivel) en la computadora de destino (la capa n de una computadora se comunica con la capa nde la otra). Esta comunicacion esta regida por el protocolo, que se denomina protocolo de capan[Tan97]. La lista de protocolos de un sistema, con un protocolo por capa se denomina pila deprotocolos. Se denomina arquitectura de red al conjunto de capas y protocolos que se utilizanen la comunicacion en la red. La separacion entre capas se denomina interfaz. La interfazdetermina los servicios que una capa expone a la capa superior. Para realizar la comunicacion,cada capa transmite sus datos y la informacion de control a su capa inmediata inferior a travesde la interfaz en lo que se denomina unidad de datos de la interfaz. Esto se repite hasta llegar ala capa 1 que corresponde a la capa fısica. Esta ultima es la que efectua la comunicacion fısica.

2http://www.wireshark.org/. Anteriormente, este software era popularmente conocido con el nombre Ethereal(http://www.wireshark.org/news/20060607.html).

3http://wiki.wireshark.org/ProtocolReference



En la computadora receptora, el mensaje fluye de abajo hacia arriba a traves de las interfacesde las capas. Cada computadora conectada a la red se denomina host.

Un servicio se especifica con un conjunto de operaciones, denominadas primitivas, que tienedisponible para ser usadas por parte de la entidad que accede al servicio. Las primitivas sonlas funciones conocidas que la capa inferior le ofrece a la capa superior y que generalmentetienen parametros.

Los servicios que ofrece una capa pueden ser orientados a la conexion o sin conexion. Losservicios orientados a la conexion requieren de una etapa de establecimiento de la conexionprevio al uso, y al finalizar, una etapa de liberacion de la conexion. Los servicios sin conexion norequieren de estas etapas y, por lo tanto, no mantienen informacion de estado entre diferentesmensajes de protocolo enviados en una misma sesion. Con respecto a la calidad del servicio, elmismo puede ser un servicio confiable (cuando la comunicacion entre las capas pares no pierdedatos) o un servicio no confiable. Un servicio sin conexion y no confiable se suele denominarservicio de datagramas[Tan97]. En un escenario de comunicacion de tipo cliente/servidor, elmodelo de comunicacion clasico consiste en el envıo de una peticion por parte del cliente y larespuesta por parte del servidor. Se dice que este servicio es un servicio de peticion y respuesta(en ingles se utilizan los terminos request y reply respectivamente).

M

M

M

M

H 4

H 4

H 4

H 3

H 3H 2

M

M

M

M

H 4

H 4

H 4

H 3

H 3H 2

Capa 5

Capa 4

Capa 3

Capa 2

Capa 1 Protocolo de la capa 1

Protocolo de la capa 2




Host de origen Host de destino

Figura 2.1: Esquema de comunicacion de una arquitectura de protocolo de cinco capas

La figura 2.1 muestra un esquema de comunicacion entre dos hosts en una arquitecturade cinco capas. El mensaje (representado con la letra M en el diagrama) es generado por lacapa superior del host emisor. Cada capa en ese host agrega un encabezado con informacionde control para identificar su mensaje de protocolo (identificado con las letras H5, H4, H3 yH2 en el diagrama). El mensaje y su encabezado se denomina unidad de datos de protocoloy es enviado a la capa inferior. La capa 1 corresponde a la capa fısica y es la que realiza lacomunicacion hacia el host de destino a traves de un medio fısico (se supone en el diagramaque ambas computadoras residen en la misma red, con conexion fısica entre ellas). En el hostde destino se realiza el proceso inverso al recibir la unidad de protocolo: cada capa extrae suencabezado y le envıa el contenido a su capa superior. Virtualmente es como si cada capa secomunicara con su capa par, a traves del protocolo que ellas dos interpretan (lıneas punteadasen el diagrama).

Entre las arquitecturas de red mas difundidas se encuentran: el modelo OSI y el modeloTCP/IP.

El modelo OSI (sigla de Open Systems Interconnection, en espanol: Interconexion de Sis-temas Abiertos) fue desarrollado por la Organizacion Internacional de Normas (ISO, por sussiglas en ingles) en el ano 1983 para estandarizar los protocolos de las distintas capas con elobjetivo de promover la interoperabilidad entre los equipos de diferentes fabricantes[Sta04].Consta de siete capas.

A continuacion se sintetiza las caracterısticas de cada una de ellas, desde la capa inferior



(la capa 1) hacia la capa superior:

Capa fısica: Se encarga de la transmision de las cadenas de bits sobre el medio fısi-co. Esta caracterizada por aspectos mecanicos (propiedades fısicas de la interfaz, e.g.forma de los conectores), electricos (representacion electrica de los bits, velocidad detransmision), funcionales (las funciones de cada uno de los circuitos de la interfaz) y deprocedimiento (la secuencia de eventos que lleva a cabo la transmision de bits a travesdel medio fısico).

Capa de enlace de datos: Se encarga de que el enlace fısico sea confiable. Proporcionamecanismos para activar, mantener y desactivar el enlace fısico. Provee el servicio dedeteccion y control de errores (dentro de la comunicacion con enlace fısico).

Capa de red : Realiza la comunicacion de mensajes entre dos sistemas finales conectados atraves de una red de comunicacion. El mensaje se transmite a traves de modulos de capade red de nodos que interconectan diferentes redes, estos nodos actuan como retransmiso-res. Esta capa proporciona el servicio de direccionamiento y otros servicios como gestionde prioridades de mensajes, y fragmentacion de mensajes (para la comunicacion a travesde redes que no permiten mensajes grandes).

Capa de transporte: Se encarga de los mecanismos para el intercambio de mensajes entrelos sistemas finales. Proporciona servicios de comunicacion confiable entre los sistemasfinales (en el caso se ser un protocolo con conexion), es decir, asegura la entrega demensajes sin errores, duplicaciones, ni perdidas. Proporciona otros servicios como calidaddel servicio (e.g. retardo maximo del envıo del mensaje).

Capa de sesion: Permite manejar sesiones entre las aplicaciones de usuario finales. Lassesiones permiten controlar el dialogo entre las aplicaciones (simultaneo, full-duplex, ohalf-duplex, alternado en ambos sentidos), sincronizacion o recuperacion del estado de lacomunicacion entre aplicaciones, agrupamiento de mensajes intercambiados, etc.

Capa de presentacion: Se encarga de normalizar el formato y representacion de los datosque se comunican entre aplicaciones. Ofrece el servicio de transformacion de los datos.Por ejemplo, puede realizar transformaciones de codificacion de caracteres y de la formaen la que se representan los numeros enteros en la arquitectura de la computadora.

Capa de aplicacion: Proporciona las reglas de comunicacion entre aplicaciones (i.e. soft-ware) distribuidas y de usuarios finales.

El modelo TCP/IP define una arquitectura de cinco capas.

Capa fısica: Analoga a la capa fısica definida por el modelo OSI.

Capa de acceso a la red : Se encarga de la conexion de la computadora a la red decomunicacion a la cual esta conectada, encapsula las particularidades del tipo de redsobre el cual se realice la comunicacion.

Capa interred : Se encarga de entregar mensajes, denominados paquetes de red o datagra-mas, entre los sistemas finales que pueden estar conectados entre sı a traves de distintasredes intermedias vinculadas por nodos. Esta capa realiza el encaminamiento del men-saje a traves de las distintas redes, por lo cual, esta capa se implementa tanto en lossistemas finales cuanto en los nodos intermedios de las redes. Es similar a la capa de reddel modelo OSI. El protocolo de comunicacion que se emplea en esta capa es el protocoloIP.



Capa de transporte: Provee a las aplicaciones de la capa superior el intercambio con-fiable de mensajes: asegura que no se pierdan mensajes y que lleguen a destino en elmismo orden en que fueron enviados. Esta capa es implementada por los sistemas finalesque se comunican. El protocolo de transporte mas utilizado para este objetivo es TCP(Transmission Control Protocol4).

Capa de aplicacion: Contiene la logica de la comunicacion necesaria para las aplicacionesdel usuario. Por ejemplo, la transferencia de archivos, e.g. FTP (File Transfer Protocol5)o HTTP.

4RFC 793. Transmission Control Protocol, DARPA Internet Program, Protocol Specification. September1981. http://tools.ietf.org/html/rfc793

5RFC 765, File Transfer Protocol. June 1980. http://tools.ietf.org/html/rfc765



2.2. Analisis de vulnerabilidades esteganograficas en el Proto-colo IP

En la presente seccion se realiza el analisis de las estructuras (i.e. campos de datos) quedefine la especificacion del protocolo IP para la transmision de mensajes, con el objetivo deencontrar canales encubiertos que puedan ser utilizados para una comunicacion esteganografica.Se analiza el protocolo IP version 4, que actualmente corresponde a la version ampliamenteutilizada en Internet (si bien existe la version 6, denominada generalmente IPv6 6, que esimplementada por la mayorıa de los sistemas operativos actuales7 y reemplazara en el uso a laversion 4).

2.2.1. Generalidades del protocolo IP

IP es un protocolo de capa de red disenado para ser utilizado en redes interconectadas, suobjetivo es la transmision de bloques de bits, denominados datagramas. El origen y el destinofinales de la transmision pueden estar ubicados en redes diferentes. Este servicio se conoce conel nombre de direccionamiento.

La capa IP envıa mensajes de la capa superior encapsulados dentro de un encabezado queposee la informacion de control necesaria para el envıo del mismo. Provee tambien la funcionde fragmentacion y posterior reensamblado en destino de los datagramas, cuando estos debenatravesar redes que permiten el envıo de paquetes de datos mas pequenos que la longitud deldatagrama que se envıa. El origen y destino estan identificados por direcciones de longitud fija.

Cada host involucrado en la red de comunicacion posee una implementacion del modulo IP.Los hosts que interconectan mas de una red se denominan gateways. El modulo IP selecciona elcamino, entre varios caminos posibles, para enviar el datagrama al destino final, esta operacionse denomina enrutamiento (o ruteo, en ingles: routing). Cada gateway posee reglas que lepermiten decidir el enrutamiento y realizar la fragmentacion en caso de que la red seleccionadalo requiera. Para decidir sobre el enrutamiento del datagrama IP se considera la direccion IPde destino, ademas de, eventualmente, otros parametros del datagrama.

Las direcciones IP consisten en cuatro octetos (32 bits) y estan compuestas por una direc-cion de red seguida de una direccion local dentro de la red. Un mismo host puede actuar comosi fueran varios hosts a partir del uso de varias direcciones IP. Una misma interfaz fısica deacceso a la red puede ser utilizada por la capa IP superior para proveer diferentes direccionesIP logicas. Ademas, un host puede tener mas de una interfaz fısica de red conectada a la redlocal (esto se denomina multi-homing).

El protocolo IP no provee confiabilidad (i.e. no se asegura la recepcion de los mensajesenviados, no se envıa confirmacion de recepcion del destino ni de los enrutadores intermedios),control del flujo de mensajes, retransmisiones, ni secuenciamiento (no se asegura la entregaordenada de los datagramas en destino, respecto del orden en el cual fueron entregados a lacapa inferior en la computadora de origen). No se provee un mecanismo de control de erroressobre los bits transportados, solo hay una suma de verificacion (en ingles checksum) sobre loscampos del encabezado del datagrama IP.

Cada datagrama es tratado como una unidad independiente, es decir, no se almacena in-formacion de estado entre diferentes datagramas. En consecuencia, la comunicacion a travesdel protocolo IP no requiere de fases de conexion ni liberacion.

6RFC 2460, Internet Protocol, Version 6 (IPv6), Network Working Group, Diciembre 1998.http://tools.ietf.org/html/rfc2460

7Por ejemplo, en 2005 el kernel de Linux le quito el estado experimental al modulo de IPv6:http://kernelnewbies.org/Linux 2 6 12.



El protocolo IP ofrece cuatro mecanismos para proveer su servicio: tipo de servicio, tiempode vida, opciones y suma de verificacion del encabezado. El tipo de servicio se utiliza paraindicar la calidad deseada del servicio. Esta informacion es utilizada por los gateways paraseleccionar parametros para la transmision y la seleccion de la red utilizada. El tiempo de vida(en ingles time to live, o TTL, por sus iniciales) es un indicador del lımite superior de la vidadel datagrama en las redes. Este valor es inicialmente asignado por el emisor del datagramay es decrementado por cada gateway. Si el valor llega a 0, se descarta el datagrama. Lasopciones proveen funciones adicionales de control para la comunicacion (e.g. hora del mensaje,parametros de seguridad, enrutamiento especial). La suma de verificacion (checksum) proveeun mecanismo para asegurar que la informacion contenida en el encabezado del datagrama escorrecta y no fue alterada en el trayecto (e.g. a causa de errores en la comunicacion). Si fallala suma de verificacion, se descarta el datagrama. No se realiza verificacion sobre el contenidodel datagrama.

modulo IP

accesoa red 1

modulo IP

accesoa red 2

modulo IP

accesoa red 2

accesoa red 1

gateway G1origen destino

capa n + 1capa n + 1

Red local 1 Red local 2

Figura 2.2: Modelo de operacion para el envıo de un datagrama con un gateway intermedio

El modelo de operacion del protocolo IP para la transmision de un datagrama entre doscomputadoras conectadas a dos redes diferentes, que se encuentran vinculadas a traves de ungateway (se ilustra este escenario en la figura 2.2), consta de los siguientes pasos8:

1. La aplicacion de origen prepara su mensaje a enviar. Invoca la funcion de acceso de envıode mensajes del modulo IP y le pasa como argumentos la direccion de destino y otrosparametros necesarios para el envıo.

2. El modulo IP construye el encabezado de un datagrama y le adjunta el contenido delmensaje de su capa superior. Determina la direccion dentro de la red local a la cual sedebe enviar el mensaje. En el ejemplo, dado que el destino del datagrama no se encuentraen la misma red que el origen, el datagrama debe ser remitido a la direccion del gateway,que se encuentra en su red local (podrıa haber mas de un gateway en la misma red, eneste caso, corresponde al modulo IP decidir a cual enviarselo).

3. El modulo IP envıa el datagrama confeccionado a su interfaz de red local (su capa infe-rior).

4. La interfaz de red local adjunta un encabezado de red local al datagrama recibido (i.e.encapsula el datagrama en un mensaje de su protocolo, denominado trama) y lo envıa asu red local (marcada con color negro en la figura).

5. La trama de red llega al gateway, el modulo de acceso a la red desempaqueta la trama(le extrae su encabezado) y entrega el datagrama contenido al modulo IP (i.e. su capa

8En el escenario propuesto en el ejemplo no se considera la necesidad de fragmentacion del datagrama, estopuede deberse a que la red local 2 permita un largo de datagrama igual o mayor al permitido por la red local 1.



superior). El modulo IP, determina que la direccion de destino IP se encuentra en la red2 y que el mensaje debe enviarse a traves de su interfaz de red 2. Entrega el datagramaa su interfaz de red local 2. Esta le adjunta su encabezado y envıa la nueva trama de redal destino a traves de la red.

6. En el host de destino, el modulo de acceso a la red recibe la trama, le extrae su encabezadoy entrega el datagrama contenido al modulo IP de su capa superior.

7. El modulo IP recibe el datagrama, determina que el mismo corresponde a una aplicacionen la propia computadora. Entrega el contenido del datagrama a su capa superior juntocon otros parametros (direccion IP de origen).

Con respecto a la seleccion entre multiples rutas, en la figura 2.3 se muestra un esquemade una comunicacion entre un origen y un destino con dos rutas posibles para el envıo deldatagrama: la Ruta A y la Ruta B. El gateway G1 decide para cada datagrama la ruta por laque se enviara. En tono sombreado se han marcado las interfaces de acceso de la capa IP consu capa inferior.

origen destino

Ruta A

Ruta B

G1 G2

Figura 2.3: Esquema de una comunicacion entre un origen y un destino con varias rutas posibles

En el capıtulo 1 se ha mostrado que es posible aplicar la incorporacion y extraccion estega-nografica en nodos intermedios del camino del mensaje. Esto se ha ilustrado y comentado en lafigura 1.2. Del analisis de la figura 2.3 resulta que es importante conocer los diferentes caminosque puede tomar un datagrama hasta arribar al destino. Supongase que se desea implemen-tar la funcion de extraccion esteganografica (Ext) en un nodo ubicado sobre la ruta B. Si elgateway G1 decide enviar los datagramas generados por el origen esteganografico (marcadocomo origen en la figura) a traves de la ruta A, no se lograra el objetivo de la comunicacionesteganografica propuesta.

Dado que el protocolo IP no asegura la entrega confiable de los mensajes, se implementala entrega confiable en una capa superior (en el modelo TCP/IP, este objetivo lo cumple elprotocolo TCP). Para la aplicacion de esteganografıa sobre los campos de control de IP sedebe tomar las mismas consideraciones: si el emisor de la comunicacion esteganografica debetener certeza de la recepcion de su mensaje por parte del receptor, se debe disenar un proto-colo esteganografico que permita enviar confirmaciones de recepcion9. La misma consideracionvale para el envıo ordenado de los datagramas IP. Si los datagramas arriban al destino querealizara la interpretacion esteganografica en un orden diferente al que el emisor los genero,es necesario asegurar una forma de secuenciamiento que permita reconstruir el mensaje es-teganografico original. Estas son consideraciones que tienen impacto directo en el diseno deun protocolo de comunicacion esteganografica que actua sobre un protocolo de comunicacionsubyacente. Es decir, el portador utilizado y sus caracterısticas operacionales, determinan laforma y posibilidad de realizar esteganografıa sobre el.

Para los fines del presente analisis, resulta transparente la utilizacion que se haga delprotocolo IP por parte de una capa superior. Es decir, en el modelo TCP/IP el protocolo IP

9mensajes denominados ACK, por la abreviatura de la palabra en ingles “acknowledgement”, que significaacuse de recibo



es utilizado por la capa inmediata superior, que corresponde a una capa de transporte (TCP10

o UDP11). Esta consideracion no constituye una premisa de este trabajo, puesto que se analizael mensaje del protocolo IP aislado del resto de los mensajes de otras capas.

Se podrıa considerar, en un analisis independiente, la influencia de un protocolo especıficoen la capa superior a IP en las posibilidades de aplicacion de tecnicas esteganograficas. Porejemplo, un protocolo de la capa superior que provea el servicio de entrega ordenada de susmensajes hacia su capa superior (e.g. TCP), con respecto a uno que no lo asegure (e.g. UDP).El protocolo que asegura el ordenamiento permitirıa aplicar consideraciones sobre la entregade los mensajes IP (i.e. se los envıa desordenados), puesto que en la recepcion en el hostde destino, la capa superior se encarga de ordenarlos para entregarlos a su respectiva capasuperior. En este ejemplo, el orden (o desorden deliberado) de los mensajes IP puede constituirun mensaje esteganografico. Para lograr este uso del protocolo, la implementacion de la capaIP debe conocer el contenido del mensaje que transporta, lo cual constituirıa una violacion ala abstraccion del modelo de capas. Otra aplicacion del ordenamiento de datagramas IP puederealizarse a partir del uso de IPSec, el cual consiste en un protocolo que provee los serviciosde autenticacion y encriptacion de los datagramas IP, en una capa superior a IP. IPSec proveesecuenciamiento de los datagramas para evitar ataques por repeticion[DK].

2.2.2. Analisis esteganografico de la estructura del mensaje IP

A continuacion se analiza la estructura del datagrama IP para encontrar formas de inter-pretacion de los campos de su encabezado que no esten contempladas en la especificacion y quepuedan ser utilizadas para una segunda interpretacion. Esta segunda interpretacion constituyeun canal encubierto y es el sustento de la comunicacion esteganografica. La base del analisisconsiste en que al aplicar las segundas interpretaciones no se vea malogrado el objetivo dela comunicacion legıtima a traves del protocolo IP. Esto permitirıa aplicar las modificacio-nes disenadas sobre un datagrama ya construido por el modulo IP y listo para ser entregadoa su capa inferior. El analisis esta basado en la interpretacion de la especificacion. Se evi-ta, de este modo, analizar implementaciones en particular. Esta consideracion implica que eldatagrama resultante (luego de aplicarle un mensaje esteganografico a partir de las tecnicaselaboradas en la presente seccion) debe poder ser interpretado correctamente en lo que respec-ta a la comunicacion legıtima por cualquier implementacion del protocolo IP que respete, sinsobreinterpretaciones, lo establecido en la especificacion del protocolo.

Se describe a continuacion, de manera sintetica, cada uno de los campos en el orden en elque aparecen en el encabezado del datagrama y en cada uno de ellos, si corresponde, se proponeuna aplicacion esteganografica encontrada a partir de la funcion que cumple en la transmisiondel mensaje del protocolo.

En la figura 2.4 se muestra el esquema del encabezado del mensaje del datagrama IP sobrela base de lo establecido en la especificacion.

Version Compuesto por 4 bits. El campo version describe el formato del encabezado del da-tagrama IP. En el presente trabajo se analiza la version 4. Por lo tanto, en todos los datagramas,este campo tendra valor 4 (en binario, los bits: 0100).

Evidentemente, este campo no puede ser modificado, ni interpretado de otra forma, puestoque cada version del protocolo posee (o puede poseer) una estructura particular. Un datagrama

10RFC: 793. Transmission Control Protocol, Defense Advanced Research Projects Agency, Informa-tion Processing Techniques Office, 1400 Wilson Boulevard, Arlington, Virginia 22209. September 1981.http://www.ietf.org/rfc/rfc0793.txt

11RFC 768, User Datagram Protocol, J. Postel, ISI, 28 August 1980 http://www.ietf.org/rfc/rfc0768.txt



Versión IHL Tipo de Servicio Largo Total

Identificador (ID) Flags Offset del Fragmento

Time to Live (TTL) Protocolo Checksum del Encabezado

Dirección de Origen

Dirección de Destino

Opciones Padding

Mensaje de la capa n + 1

bits 0 311684 19

Figura 2.4: Esquema de encabezado de datagrama IP y el mensaje de la capa superior

de version 4 no puede ser convertido en uno de otra version con solo modificar el campo ver-sion[FFPN]. Por lo tanto, si se modificara este valor, se perderıa el objetivo de la comunicacionlegıtima, dado que se obtendrıa un datagrama invalido.

En consecuencia, el campo Version es un campo constante.

IHL (Internet Header Lenght) Compuesto por 4 bits. Contiene el largo del encabezadodel datagrama IP, medido en palabras de 32 bits. En la figura 2.4 se muestra el encabezadodel datagrama encolumnado a 32 bits. El valor del campo IHL contiene la cantidad de filasde ese encolumnamiento del encabezado. Se observa que el valor mınimo de este campo es 5,y este valor puede variar a partir del uso del campo de Opciones, que es opcional dentro delencabezado del datagrama.

La especificacion menciona que el largo maximo del encabezado es 60 octetos, esto es, 15palabras de 32 bits (o 4 octetos). Este numero escrito en binario (1111) es el mas grandeque puede representarse con 4 bits. Ademas, la especificacion menciona que el largo tıpico delencabezado del datagrama es de 20 octetos, esto es, 5 palabras de 32 bits, que corresponde alvalor mınimo (sin el uso de Opciones).

Se nota que el campo IHL constituye un campo derivado, es decir, contiene un valor quees consecuencia de los componentes del encabezado del datagrama. Si se altera el contenido deeste campo, el modulo IP que recibe el datagrama interpretara de forma erronea el contenidodel mismo (i.e. el mensaje de la capa superior), puesto que si el valor de IHL es menor al valorreal (supongase que el encabezado tiene una longitud de 6 palabras de 32 bits y en IHL secoloco el numero 5), habra porciones del encabezado que se consideran como parte del mensajede la capa superior, y viceversa si IHL es mayor al real.

En consecuencia, el campo IHL no puede ser modificado por la aplicacion de esteganografıa.Asimismo, se debe tener en cuenta este campo si en la aplicacion de esteganografıa se modificala longitud del encabezado del datagrama (en el analisis del campo Opciones se ejemplifica lamodificacion de la longitud del encabezado).

La especificacion no es explıcita en aclarar que un datagrama con un valor de IHL menora 5 deba ser descartado. Podrıa existir, entonces, una implementacion de un modulo IP quecontemple un valor de IHL menor a 5 como valido, y que considere ese valor como 5. Si unguardian activo detecta un valor de IHL menor a 5, puede descartar el datagrama, para evitarla posible propagacion de un mensaje esteganografico. Por otra parte, la especificacion deberıaser estricta sobre que acciones tomar sobre el datagrama cuando el valor de IHL es menor a 5.



En la implementacion del guardian activo propuesto (seccion 3.2.2) se descartan los datagramascon valor de IHL menor a 5.

Tipo de Servicio Compuesto por 8 bits.Provee una indicacion de los parametros de calidad del servicio deseado. Esos parametros se

utilizan como guıa para determinar que tipo de servicio utilizar para transmitir un datagrama atraves de una red particular. Algunas redes poseen un tratamiento de datagramas diferenciadode acuerdo a la precedencia del servicio y priorizan el envıo de datagramas de precedenciasuperior a un valor en casos de alto trafico de datagramas.

Este campo esta compuesto por los bits con la siguiente semantica:

Bits 0 a 2: precedencia del datagrama.

• 111: Control de red.

• 110: Control Interred.

• 101: CRITIC/ECP. Llamada de emergencia crıtica (en ingles: Critical and Emer-gency Call Processing).

• 100: Flash Override (alta prioridad).

• 011: Flash (prioridad menor a la anterior).

• 010: Inmediato.

• 001: Prioridad.

• 000: Mensaje de rutina.

Bit 3: 0 = Demora normal (delay, en ingles), 1 = baja demora.

Bit 4: 0 = Tasa de transferencia normal, 1 = alta tasa de transferencia.

Bit 5: 0 = Confiabilidad normal, 1 = confiabilidad alta.

Bits 6 y 7: reservados para uso futuro.

La especificacion indica que el uso de los flags de baja demora, alta tasa de transferencia yalta confiabilidad (bits 3, 4 y 5 con valor 1) puede incrementar el costo del servicio (en algunsentido de costo). Indica tambien que, salvo en excepcionales casos, se deberıa asignar valor 1a dos de ellos como maximo.

Por otra parte, la precedencia 111 (control de red) esta disenada para ser utilizada unica-mente dentro del ambito de una sola red. La especificacion establece que el uso real y el controldel mismo es propio de cada red, de modo que no se establece un consenso generalizado. Siuna red asigna un uso particular a esa precedencia, es responsabilidad de esa red controlarel acceso y uso de esas designaciones de precedencia. La precedencia 110 (control interred) espara ser utilizada unicamente por controladores de gateways.

Cabe mencionar que este campo ha sido redefinido en el ano 1998 a traves de la RFC247412, muy a posteriori de la publicacion de la especificacion del protocolo en estudio, paraasignar su uso a Servicios Diferenciados[HVP]. Los Servicios Diferenciados son un metodopara garantizar la calidad de servicio (QoS, por sus siglas en ingles) en redes de gran tamano.El estudio de los Servicios Diferenciados se deja fuera del alcance del presente trabajo, puestoque el analisis esta basado en la especificacion original del protocolo (i.e. la RFC 791).

12Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, Request for Com-ments: 2474. K. Nichols (Cisco Systems), S. Blake (Torrent Networking Technologies), F. Baker (Cisco Systems)D. Black (EMC Corporation). December 1998. http://www.faqs.org/rfcs/rfc2474.html



Con respecto a la utilizacion de este campo para una comunicacion esteganografica, en unambiente de red basado en la especificacion de la RFC 791, se puede hacer uso de los bits 6 y 7,reservados para uso futuro. Por otra parte, la alteracion de los correspondientes a la indicacionde demora, tasa de transferencia y confiabilidad implicarıan una variacion del costo del servicio,aunque bien podrıan ser utilizados para la transmision de mensajes esteganograficos, con laconsideracion de que se modificarıa, en consecuencia, parte de la semantica del datagramaconstruido. Lo mismo puede realizarse con la modificacion de la seccion de precedencia (se debetener en cuenta que, por ejemplo, la modificacion de la precedencia de un datagrama con valorCRITIC/ECP, podrıa traer como consecuencia la demora de una comunicacion importantepara una emergencia).

Un guardian activo debe normalizar los bits que son reservados para uso futuro (e.g. colocarsiempre valor 00). En ciertos ambientes, se podrıan definir el uso de los modificadores dedemora, tasa de transferencia y confiabilidad y aplicar restricciones sobre los mismos. De estemodo, se podrıa modificar los valores de esos indicadores a los permitidos en la red. Lo mismopodrıa realizarse sobre el campo de precedencia, con el agregado de que la opcion de controlde red podrıa ser bloqueada en la red controlada por el guardian. Si no se acepta la opcion decontrol de red en la red del guardian activo, se descarta el datagrama.

Largo Total Compuesto por 16 bits. Contiene el largo total del datagrama, medido enoctetos (a diferencia del campo IHL, que se mide en palabras de 32 bits). El largo totalincluye el encabezado y el contenido. Este campo permite un valor maximo de 65,535 octetos(216− 1). La especificacion recomienda no enviar datagramas mayores a 576 octetos, dado queeste tamano es el que deben estar capacitados para procesar todos las implementaciones de IPde la red (estos son: 512 octetos para el contenido y 64 octetos para el encabezado). El emisordeberıa enviar un datagrama de tamano mayor a 576 solo si tiene certeza de que el receptorpuede procesarlo.

En conclusion, al igual que IHL, el campo Largo Total es un campo derivado. Es decir,este campo depende de la estructura del datagrama y no puede ser alterado sin afectar lainterpretacion del mismo, tal como se ha explicado para el caso de IHL.

Identificador (ID) Compuesto por 16 bits. El ID contiene un valor asignado por el emisorpara permitir la fragmentacion y posterior reensamblado de los fragmentos del datagrama.Este campo permite 65,536 valores diferentes (216), de 0 a 65,535.

La especificacion menciona que la eleccion del valor del ID esta basada en la necesidad deproveer una manera unica de identificar los posibles fragmentos de un datagrama particular. Elmodulo IP que reensambla los fragmentos recibidos, considera que fragmentos de datagramaspertenecen a un mismo datagrama si todos ellos poseen los mismos valores en los campos: ID,Protocolo, Direccion de Origen y Direccion de Destino13. El emisor esta obligado a escoger unvalor cualquiera de ID que cumpla que sea unico para el conjunto origen, destino y protocolo,por el tiempo en el que el datagrama transite por la red.

La especificacion comenta que la restriccion sobre el identificador con respecto al origen,destino y protocolo, puede hacer pensar la necesidad de la implementacion en el modulo emisorde una tabla que almacene los identificadores utilizados para cada conjunto origen-destino-protocolo. Sin embargo, tambien aclara que al tener la posibilidad de escoger 65,536 valoresdiferentes, se puede elegir un valor independientemente de los valores de origen, destino yprotocolo.

En conclusion, el campo ID puede contener un valor arbitrario, siempre que se asegure queno se repitan con el ID de otro datagrama en el lapso en el que el datagrama transita por la

13En el analisis de cada uno de los campos se detalla su objetivo.



red. Esta caracterıstica permite efectivamente utilizar el valor del campo ID para realizar unacomunicacion esteganografica. De este modo, un algoritmo de insercion de un mensaje estega-nografico (i.e. la funcion Emb), que actua por modificacion de portadores, puede modificar elvalor del campo ID que posee un datagrama construido por el modulo IP del emisor y asignaren ese campo un valor diferente. Este nuevo valor puede representar un caracter de un alfabetodentro del mensaje esteganografico.

Para ejemplificar el uso esteganografico del campo ID, se plantea el siguiente escenario.Supongase que se desea transmitir un mensaje esteganografico compuesto por letras del alfabetoespanol, sin distincion de mayusculas y minusculas (se tiene, de este modo, un total de 27 letrasdiferentes) y cada letra del mensaje se envıa en el campo ID de un datagrama IP. Supongaseque a cada letra del espanol se codifica con un numero de 0 a 26: la A corresponde al 0, la B

al 1, la Z al 26. La funcion Emb puede generar un valor n para el campo ID tal que letra = nmod 27, donde letra corresponde al codigo del mensaje esteganografico. Para codificar cadaletra, la funcion Emb puede escoger entre b65,53627 c = 2,427 valores diferentes.

La funcion Emb tiene que estar construida de forma tal de no repetir los valores de IDsdurante el tiempo estipulado para el transito del datagrama en la red. Bajo estas condiciones,la modificacion realizada al datagrama preserva la sintaxis y la semantica y permite comunicarun mensaje esteganografico, que es el objetivo buscado.

La funcion Ext que interpreta el datagrama obtiene el valor del campo ID, lo decodificay obtiene la letra del mensaje esteganografico. Almacena cada una de las letras y obtiene elmensaje completo luego de interpretar todos los datagramas. No hay necesidad de volver amodificar el datagrama (de hecho, la funcion Ext no conoce el valor de ID existente previo alprocesamiento de Emb). Las operaciones de Emb y Ext no interfieren en el procesamiento deldatagrama por parte de los modulos IP del emisor y receptor.

El ejemplo citado permite tambien ilustrar el diseno de las funciones Emb y Ext quecomuniquen mensajes esteganograficos tolerantes al ordenamiento de los datagramas en larecepcion: se ha dividido el espacio de valores de ID en conjuntos de 27 numeros para codificarcada letra, con un resultado de 2,427 conjuntos. Para codificar cada letra es posible utilizarcualquiera de los 2,427 numeros, uno de cada conjunto: la letra n-esima se codifica con el valorID = (27 ·k)+n, para algun k entre 0 y 2,426 (k es el numero de orden del conjunto utilizado).Si en cada datagrama se utiliza un valor de un conjunto consecutivo, esto es, en el primerdatagrama se utiliza un valor del primer conjunto de numero, en el segundo datagrama unvalor del segundo conjunto y ası sucesivamente. Si en el proceso de extraccion esteganografica,la funcion Ext obtiene en primer lugar un valor n1 perteneciente al conjunto de valores k1y luego un datagrama con un valor de ID n2 perteneciente al conjunto k2 tal que k1 > k2,entonces la letra codificada por n2 precede a la codificada por n1 en el mensaje esteganografico.La funcion Ext detecto una alteracion en la recepcion de los datagramas.

A continuacion se analiza la forma de evitar la propagacion del mensaje esteganografico.Supongase la existencia de un guardian activo que se encuentra en el camino entre el emisory el receptor del mensaje (el mismo puede ser un gateway de la red, como en los ejemplosanteriores). El guardian puede acceder al datagrama y al valor del campo ID. Supongase que,bajo el ejemplo descripto, no se distingue la existencia de una comunicacion esteganografica. Elobjetivo del guardian consiste en evitar la propagacion de posibles mensajes esteganograficossin alterar la sintaxis ni la semantica del datagrama. Este objetivo puede ser logrado sinsiquiera conocer la existencia de aplicacion de esteganografıa sobre campo ID del datagrama.Para ello, se propone que el guardian realice la modificacion del valor del campo ID de todoslos datagramas que recibe. Esta modificacion debe cumplir con la restriccion de que el IDresultante no debe repetirse entre datagramas distintos mientras estos transiten por la red.Para esta modificacion, puede aplicarse una funcion f(n) biyectiva que tome como dominio



el conjunto de elementos posibles de ID (0 ≤ n ≤ 65,535, n ∈ N) y cuya imagen pertenezcaal mismo conjunto. La funcion f deberıa ser impredecible para el emisor y receptor (ningunode ellos deberıa poder conocer como recuperar el valor inicial a partir del resultante), paraello, podrıa estar parametrizada por otros componentes del datagrama, como la direccion IPde origen, de destino y protocolo. Al ser una funcion biyectiva, se cumple que los valores de IDgenerados no van a repetirse en el lapso en el que el datagrama transita por la red siempre queel valor de ID original cumpla con esa condicion, esto ultimo es responsabilidad del modulo IPdel emisor y de la funcion Emb.

En la implementacion del artefacto (seccion 3.2.2) se muestra otra aplicacion practica dela modificacion del campo ID.

Flags Compuesto por 3 bits.Cada bit tiene el siguiente significado:

Bit 0: reservado, debe ser cero.

Bit 1 (Don’t fragment): DF 0 = el datagrama puede ser fragmentado. 1 = no se permitefragmentar el datagrama. La especificacion indica que a este flag puede asignarse valor1 (i.e. prohibir la fragmentacion del datagrama) en los casos en que el receptor no poseasuficientes recursos computacionales para reensamblar el datagrama. Como ejemplo deuso del mismo, la especificacion cita una estructura de bajo nivel, donde un host poseeun programa de arranque que recibe un datagrama, lo almacena en memoria y lo ejecuta.Ese datagrama no deberıa fragmentarse.

Otro uso del flag DF consiste en descubrir el tamano maximo que puede tener un da-tagrama sin necesitar ser fragmentado durante todo el trayecto desde el origen hacia eldestino, en una ruta interredes. Esta funcionalidad se denomina Path MTU Discovery yesta descripta en la RFC 1191[JM90].

Se denomina Unidad Maxima de Transmision (MTU, por sus siglas en ingles) al tamanomaximo de datagrama que puede ser transmitido a traves de la siguiente red. En general,se prefiere enviar datagramas del mayor tamano que no requieran fragmentacion a lolargo de la ruta de comunicacion (esto se debe a que la fragmentacion obliga a esperarpor todos los fragmentos y reservar recursos para los fragmentos que se posee hasta quese reciban todos). El emisor genera un datagrama del tamano de la maxima unidad detransmision conocida y asigna el flag DF en valor 1. Si en algun enrutador intermedio delcamino, el datagrama se debe fragmentar, entonces el enrutador correspondiente descartael datagrama (esta activo el flag DF) y genera un mensaje de control hacia el emisor queindica que el datagrama es muy grande.

Bit 2 (More fragments): MF 0 = ultimo fragmento. 1 = existen mas fragmentos.

La especificacion no es explıcita con respecto a que accion se deberıa tomar si el valor delcampo reservado, el primer bit de los flags, no es cero. Se podrıa suponer, en consecuencia,que este campo puede ser modificado sin alterar la semantica del datagrama. La especificaciondeberıa ser estricta en este aspecto. Un guardian activo debe modificar el valor de este campo,para asignarle valor cero en caso que no tuviere dicho valor, con el objetivo de impedir lapropagacion de un posible mensaje esteganografico en este campo. En la implementacion delartefacto (seccion 3.2.2) se ejemplifica la modificacion de este flag.

El flag DF indica el permiso de fragmentar el datagrama. Mientras que el flag MF tienesentido solo en datagramas que han sufrido fragmentaciones, dado que su objetivo es indicar siexisten mas fragmentos, o el actual es el ultimo fragmento de los que constituyen un datagrama.



Entre estos dos bits se desprende una posibilidad de incoherencia en los valores de los mismos:si DF= 1 y MF= 1. Aunque la especificacion no es estricta sobre las acciones a tomar sobre undatagrama con los flags con estos valores, se puede interpretar que esta combinacion resultaen un datagrama invalido. Con lo cual, puede ser descartado por un guardian activo, sindetrimento de una comunicacion genuina. En la implementacion del guardian activo propuesto(seccion 3.2.2), se descartan los datagramas con esta inconsistencia.

Se propone el siguiente experimento para analizar el comportamiento del flag DF. Para ello,se captura durante cinco minutos el trafico de red de una computadora con el sistema operativoGNU/Linux distribucion Kubuntu 10.1014 conectada a Internet. Se efectuan actividades de usode Internet tradicionales: ingreso a sitios web a traves del navegador Mozilla Firefox 15 y accesoa mensajes de correo electronico a traves del software Mozilla Thunderbird16.

En esta captura se observa un total de 11.017 datagramas IP. De ellos, 9.891 datagramasposeen el flag DF con valor 1. Los restantes 1.126 tienen el flag DF con valor 0. La totalidad delos datagramas fue transmitida sin fragmentacion, es decir, todos poseen el flag MF con valor0. No se encuentra, en el analisis de los datagramas obtenidos, un consenso generalizado sobreel uso del flag DF.

En conclusion, si se decidiera utilizar el flag DF para transmitir un mensaje esteganografico,a partir de la modificacion de dicho flag en un datagrama ya construido perteneciente a unacomunicacion genuina, se espera que no se vea alterado el objetivo de la comunicacion genuina.Si, para permitir la menor interrupcion de las comunicaciones genuinas, un guardian activomodifica el valor del flag para asignar siempre 0 (i.e. permitir siempre fragmentaciones deldatagrama), se vera afectada la operacion de Path MTU Discovery, que es tıpicamente unaoperacion de control (que, incluso, no esta especificada por la RFC 791, en estudio en estatesis). En la implementacion del artefacto (seccion 3.2.2) se muestra la modificacion de esteflag.

Sobre la base de lo expuesto, se observa que el flag DF constituye un canal supraliminal :no puede ser eliminado o modificado sin alterar parte del contenido semantico del portador.En este caso, la estrategia de modificacion por parte del guardian activo esta sustentada enque el perjuicio producido a raız de la modificacion semantica del portador puede ser conside-rado despreciable (Path MTU Discovery no es considerada una funcionalidad esencial para lacomunicacion de datagramas IP).

Offset del Fragmento17 Compuesto por 13 bits.Este campo indica a que porcion del contenido del mensaje del datagrama corresponde el

fragmento de mensaje. Contiene la posicion de inicio del contenido del datagrama respectodel mensaje total. Esta posicion esta medida en unidades de 8 octetos (64 bits). El primerfragmento tiene offset 0.

No se especifica que accion se deberıa tomar en caso de un fragmento que tuviera el bitDF en valor 1 (es decir, no fragmentar) y un valor diferente de cero en el campo offset delfragmento. Es decir, se presenta la posibilidad de la misma incoherencia que para el caso deDF y MF, ambos con valor 1. Analogamente, se puede suponer, que un datagrama con estosvalores tambien posee un valor ilegal, y un guardian activo puede descartarlo sin perjuicio dela comunicacion genuina.

A continuacion, se analiza la fragmentacion de datagramas.El offset del fragmento tiene significado solo en los casos en los que se trata de un datagrama

14http://www.kubuntu.org/15http://www.mozilla.org/16http://www.mozillamessaging.com/17Se prefiere utilizar el termino offset en ingles, en lugar del termino en espanol: desplazamiento.



Encabezado: E

datos: D

datagrama

original

Encabezado: E1

datos: D1

Encabezado: E2

datos: D2

Encabezado: E3

datos: D3

fragmentos

Figura 2.5: Modelo de un datagrama fragmentado en tres partes. Notese que el contenido del tercerfragmento es menor que los otros dos.

fragmentado. La especificacion indica que en el caso de un datagrama sin fragmentacion, soncero los valores del bit MF (More fragments) y del campo offset del fragmento.

El flag MF tiene valor 1 en todos los fragmentos, salvo en el ultimo. En la figura 2.5, elfragmento 3 tiene su flag MF en 0, mientras que los fragmentos 1 y 2 tienen su flag MF en 1.

Para realizar una fragmentacion, se debe dividir el campo de datos en porciones de 8octetos. Esto da un total de 213 = 8192 fragmentos de 8 octetos cada uno, es decir 65,536octetos, que coincide con el valor maximo del largo total. El fragmento mınimo tiene un largode 68 octetos: 60 octetos para el header y 8 para el contenido.

Los campos afectados por la fragmentacion son Opciones, flag MF, Offset del fragmento,IHL, largo total (TL) y Checksum del header.

Si el largo del datagrama (valor de TL) es menor o igual al MTU de la red donde se debecolocar el datagrama, se envıa el datagrama completo al siguiente paso en su procesamiento.Si, en cambio, es mayor, se divide el datagrama en dos fragmentos: el primer fragmento delmayor tamano posible (i.e. el valor de MTU) y el segundo del resto. El primer fragmento sesomete al siguiente paso para su envıo, mientras que el segundo fragmento se vuelve a dividirsi es mayor al MTU. Este procedimiento se repite hasta que el ultimo fragmento obtenido seamenor al MTU.

El receptor recibe el datagrama (o algun fragmento) y determina en primera instancia sicorresponde a una fragmentacion. Para determinar esto, se analiza el valor de los campos offsetdel fragmento y el flag MF. Si ambos tienen valor 0, entonces, el datagrama no fue fragmentadoy se procede a su procesamiento (e.g. obtener el contenido, para luego remitirlo a la capasuperior).

Los fragmentos que corresponden a un mismo datagrama son aquellos que poseen el mismovalor en los campos direccion de origen, direccion de destino, protocolo e ID. Cuando el receptorrecibe un fragmento de un datagrama nuevo, reserva espacio de memoria para un buffer18 dedatos y un buffer de encabezado, un mapa de bits para almacenar que bits del campo de datosfueron ya leıdos, e inicializa un temporizador. El contenido de datos recibido se coloca en lasposiciones correspondientes del buffer de datos y se marca como recibidas esas posiciones dentrodel mapa de bits. Cuando se trata del primer fragmento (el que tiene valor de offset en 0), secopia el encabezado en el buffer del encabezado. Cuando se recibe el ultimo fragmento (el quetiene valor 0 en el flag MF), se calcula el largo total. Si se recibio la totalidad del datagrama, seprocede al procesamiento del datagrama completo. Para determinar si se recibio el datagramacompleto se verifica si todos los bits del mapa de bits del contenido tienen valor 1 (dado que

18se utiliza la palabra buffer, en ingles, para indicar un area de memoria que se mantiene temporalmentemientras los datos se copian hacia otra area.



cada bit indica que esa posicion fue recibida).El timer se utiliza para liberar los recursos asignados (i.e. los bufers de memoria) si no se

recibe la totalidad del datagrama dentro del tiempo establecido. El valor del timer esta rela-cionado con el campo TTL y su maximo es de 4 minutos 15 segundos, como se indica en elanalisis de ese campo.

La especificacion indica que en el caso que dos o mas fragmentos recibidos de un mismodatagrama contengan el mismo rango de datos o un solapamiento parcial del mismo, el proce-dimiento de reensamblado usara la copia recibida mas recientemente para colocar en el bufferde datos que integra el datagrama completo.

Del analisis de los procedimientos de fragmentacion y reensamblado establecidos por laespecificacion se propone la aplicacion de las siguientes tecnicas esteganograficas:

Supongase el escenario donde un emisor de un datagrama se encuentra en la misma redque el gateway en analisis. El gateway recibe un datagrama originado por el emisor. Dadoque cada host conectado a su red conoce el MTU de la misma, cada emisor generadorde datagramas es capaz de colocar en su red datagramas sin fragmentacion, es decir,del tamano del MTU. Por lo tanto, si el gateway recibe un datagrama que se encuentrafragmentado y que fue generado por el emisor, puede ser interpretado como un mensajeesteganografico. El emisor bien podrıa haber enviado varios datagramas, en lugar de unofragmentado, lo cual provee un beneficio en performance y en consumo de recursos en elprocesamiento del datagrama (e.g. no se debe asignar recursos para la espera de todoslos fragmentos).

El gateway que actua como guardian activo esteganografico en este escenario y que debereenviar un datagrama hacia otra red, puede reensamblar los fragmentos antes de serreenviados (en el caso que la segunda red lo permita), para evitar que el eventual receptoren la segunda red detecte esa intencion y logre interpretar el comportamiento del emisorcomo un mensaje esteganografico.

Analogamente al caso anterior, en el procedimiento de fragmentacion se puede optar porun tamano del fragmento igual al valor del MTU, o menor al mismo (la especificacionmenciona explıcitamente esta segunda posibilidad como una opcion). En consecuencia,un gateway que efectue el proceso de fragmentacion puede elegir un tamano de fragmentodonde el tamano elegido constituya el mensaje a transmitir. Incluso, se puede adoptar unaestrategia de fragmentacion donde el tamano elegido sea diferente para cada fragmentodel datagrama. El receptor final del datagrama toma cuenta el tamano de cada uno losfragmentos y con esa la lista de tamanos reconstruye el mensaje esteganografico.

En el caso donde otro gateway, que se encuentre en el camino del datagrama hacia eldestino, actue como guardian activo, debe reensamblar el datagrama y, de ser necesario,fragmentarlo nuevamente para su reenvıo. Incluso, el guardian activo puede adoptar unaestrategia de fragmentacion con valores aleatorios para el tamano de cada uno de losfragmentos que genere un mensaje erroneo para el posible receptor esteganografico en larecepcion.

Se ha mencionado que la especificacion establece que en caso de existencia de solapamien-to de la porcion de datos de los fragmentos se utiliza la copia mas recientemente recibidade los datos. Esta caracterıstica bien puede ser aplicada para la transmision de mensajesesteganograficos. Al momento de fragmentar pueden generarse fragmentos consecutivoscon solapamiento, de modo que el contenido del campo de datos solapado sea el mismoen ambos fragmentos. El mensaje esteganografico puede ser interpretado a partir de lacantidad de octetos solapados en cada uno de los fragmentos.



Otra version de aplicacion de esta tecnica consiste en construir fragmentos solapadoscon diferentes valores en la porcion solapada del campo de datos del datagrama. Conel objetivo de que el datagrama recibido sea semanticamente equivalente al generadoinicialmente, el emisor esteganografico deberıa poder asegurar que el fragmento que con-tiene en la porcion solapada los datos incorrectos (i.e. diferentes al datagrama genuino),sea recibido antes que el otro fragmento, de modo que el resultado del reensamblado seaidentico al datagrama original. En este caso, el mensaje esteganografico esta interpretadoa partir de la cantidad de octetos solapados entre dos fragmentos consecutivos y de lacantidad de bits solapados entre los fragmentos que difieren entre sı. Cabe aclarar queno es facil de asegurar el orden de recepcion cuando el datagrama debe atravesar variasredes.

Al igual que en los casos anteriores, un guardian activo debe reensamblar el datagramaantes de reenviarlo. Incluso, el guardian activo puede construir sus fragmentos con sola-pamiento (donde los datos solapados sean los mismos en ambos fragmentos), de modode producir malas interpretaciones en el posible receptor esteganografico del datagrama.

Cabe mencionar que las acciones mencionadas tendientes a evitar la propagacion de losmensajes esteganograficos para los casos precedentes no son aplicables en todos los escenarios.Supongase el caso donde diferentes fragmentos de un mismo datagrama efectuan caminosdiferentes en el recorrido inter-redes hasta llegar a destino. Podrıa suceder que los gatewaysintermedios no tengan la posibilidad de reensamblar el datagrama para refragmentarlo, comose ha mencionado. En cambio, los metodos de proteccion esteganografica propuestos puedenser aplicados cuando se desea proteger la red interna de una organizacion que se encuentraconectada al exterior a traves de un solo gateway.

Tiempo de Vida (TTL)19 Compuesto por 8 bits.Este campo indica el maximo tiempo que se permite permanecer al datagrama en transito

en la red (o el sistema de redes interconectadas). El objetivo del mismo es que datagramasque no puedan ser enviados a destino sean descartados y, ademas, establecer un lımite de vidamaximo para cada datagrama.

Si el campo contiene el valor 0, en algun gateway intermedio de la comunicacion, se debedestruir el datagrama. Este campo debe ser modificado con el procesamiento del encabezadodel datagrama. La especificacion establece que el tiempo es medido en unidades de segundos ycada modulo IP que procesa el datagrama debe decrementar el valor de TTL en al menos unaunidad, aunque procese el mismo en un tiempo menor a un segundo. El campo TTL constituyeuna cota maxima de vida a un datagrama para su transmision, asignada por el emisor.

El valor maximo del Tiempo de Vida es 255, que corresponde a 255 segundos (o 4 minutos15 segundos). Ademas, dado que cada modulo IP que procese el encabezado debe decrementarel valor de TTL, se desprende que el datagrama no puede atravesar mas de 255 gateways hastallegar al destino final. Adicionalmente, los 4 minutos 15 segundos que se establecen como cotamaxima de la vida del datagrama en el sistema de redes, permiten asignar una cota mınima altiempo que debe transcurrir sin repetir los valores del campo ID.

El campo TTL puede ser utilizado para el envıo de un mensaje esteganografico de la si-guiente manera: Si el emisor y receptor del mensaje esteganografico pueden medir la cantidadde gateways o saltos que existen entre ellos, podran tener una estimacion de cuanto se de-crementara el valor de TTL en el envıo de un datagrama en el caso promedio. Supongaseuna medicion de 20 saltos entre ambos. Puede plantearse que el datagrama se encuentra enun caso desfavorable en un envıo particular y se consideran 40 saltos para el peor caso (i.e.

19En ingles el termino utilizado es Time to Live.



el doble). Por ejemplo, la funcion esteganografica de emision Emb puede modificar el valorde TTL colocado por el emisor legıtimo del datagrama y asignar un valor de TTL alto (i.e.cercano o igual al maximo, 255), o bien, puede asignar un valor de TTL igual a la mitad delmaximo (i.e. cercano a 120), considerado como un valor bajo. Con esta convencion, el receptoresteganografico (la funcion Ext), recibira un valor de TTL mayor a la mitad del valor posibleo menor a la misma. Cada uno de estos dos valores (i.e. mayor o menor a 120) tiene un sig-nificado en el mensaje acordado. En este caso, se transmite un valor esteganografico binario,representado por la interpretacion: “es alto” o “es bajo”. Este ejemplo no puede ser aplicadosi entre el emisor y receptor existe una gran cantidad de saltos en la generalidad de los casos(e.g. 200 saltos), que no permita realizar tal distincion.

Para ilustrar la factibilidad de la tecnica descripta, se expone el siguiente experimento. Sepretende medir el decremento del valor TTL entre dos computadoras conectadas a Internet.En el escenario empleado, el emisor se encuentra conectado a una red donde se encuentra ungateway que posee dos interfaces se red, una de ellas conectada a Internet a traves del serviciode la empresa Fibertel20 de Argentina. El receptor se encuentra directamente conectado aInternet a traves del servicio provisto por la empresa iPlan NSS S.A.21, tambien de Argentina.Se desconoce la interconexion entre las redes de ambas empresas. La computadora que actuacomo emisor (que construye los datagramas) utiliza el sistema operativo GNU/Linux con elkernel version 2.6.35. En la computadora de destino existe un servidor web que recibe peticionesHTTP. En ambas computadoras se inicia la captura del trafico de la red y, acto seguido, enla computadora de origen se solicita una peticion HTTP al servidor de destino a traves delnavegador Mozilla Firefox.

Se analiza el trafico de la red capturado en ambas computadoras con Wireshark y sepresenta en las figuras 2.6 y 2.7 un ejemplo de un datagrama particular en el emisor y receptorrespectivamente.

Figura 2.6: Ejemplo de datagrama IP visualizado con Wireshark, capturado en la computadora deorigen.

Se observa que el datagrama elegido tiene ID 7085 (en escritura de base decimal), que enambos casos coincide. En el datagrama capturado en el host de origen, la direccion IP de origenes 192.168.0.2 y la de destino es 190.210.61.213. En el datagrama capturado en el host dedestino, la direccion IP de origen es 201.235.164.8 y la de destino es 190.210.61.213 (estaultima coincide con la del datagrama en la computadora de origen). La razon por la que ladireccion IP de origen difiere es porque el host de origen esta conectado a Internet a travesde una red local que esta conectada a su vez a un gateway que la vincula con Internet. Ladireccion 192.168.0.2 corresponde a la direccion IP del host de origen dentro de la red local,

20http://www.fibertel.com.ar/21http://iplan.com.ar/



Figura 2.7: Ejemplo de datagrama IP visualizado con Wireshark, capturado en la computadora dedestino.

mientras que la direccion 201.235.164.8 corresponde a la del gateway en Internet (esto sedebe a que el host del datagrama de origen se encuentra en una red conectada a Internet atraves de un router que realiza la traduccion de direcciones de red, denominado NAT, por lassiglas de Network address translation22).

En el datagrama de origen, se ve que el modulo IP asigno el valor 64 al campo TTL (semuestra resaltado en la imagen de Wireshark). En el datagrama de destino, el valor de TTL es50. Esto significa que el datagrama atraveso 14 gateways hasta llegar a destino (64−50). El valor14 permite suponer la aplicacion de la tecnica esteganografica propuesta sobre el campo TTL.Se puede considerar, inclusive, el caso mas desfavorable en el doble de 14. Adicionalmente, seobserva en las imagenes presentadas, que el resto de los campos del encabezado del datagramacoinciden en su valor.

Para prevenir la aplicacion de esta tecnica, un guardian activo, puede siempre aumentarel valor de TTL de los datagramas que interprete a su maximo posible. Para realizar estamanipulacion, se deberıa tener cuidado con respecto a la ubicacion del guardian dentro de lared. Puesto que si un datagrama atraviesa al guardian (que actua de gateway) mas de una vez,y en ambas ocasiones este incrementa el valor del campo TTL, el datagrama podrıa quedar encirculacion infinita en el sistema de redes. Supongase este ejemplo como un loop en el envıodel datagrama en la figura 2.3, donde el gateway G2, en lugar de enviar el datagrama hacia lared de destino, lo envıa hacia otra de las rutas. En el ejemplo presentado en el experimento,se podrıa colocar el guardian activo en el gateway que conecta al host de origen a Internet atraves de la red de la empresa Fibertel.

Esta tecnica se aplica en la implementacion del artefacto descripta en la seccion 3.2.2.

Protocolo Compuesto por 8 bits.El campo Protocolo indica el protocolo de la capa n + 1 usado dentro del contenido del

mensaje del datagrama. El listado de numeros de protocolo asignado se encuentra especificadoen la RFC 79023.

Si se realiza una modificacion al valor del campo Protocolo, para la aplicacion de una tecnicaesteganografica, se altera la semantica del datagrama. En consecuencia, no es posible aplicaresteganografıa por modificacion de portadores sobre este campo. De otro modo, se puede teneren consideracion este campo para realizar esteganografıa por sıntesis de portadores, y construir,

22RFC 2663. P. Srisuresh, M. Holdrege. Lucent Technologies. August 1999. http://tools.ietf.org/html/rfc2663Los mecanismos de NAT quedan fuera del alcance del presente trabajo.

23Postel, J., “Assigned Numbers”, RFC 790, USC/Information Sciences Institute, September 1981.http://www.faqs.org/rfcs/rfc790.html



en consecuencia, un datagrama cuyo campo Protocolo tenga un valor representativo en unacomunicacion esteganografica.

Si bien cae fuera el estudio del presente trabajo, la RFC 790 define numeros para diferentesprotocolos24, pero no todos los numeros posibles para este campo (i.e. entre 0 y 255) tienen unprotocolo asociado. Con esta consideracion, un guardian activo podrıa descartar los datagramascuyo valor de Protocolo sea un numero no asignado, y ası evitar la posible propagacion de unmensaje esteganografico.

Checksum del encabezado Compuesto por 16 bits.Su objetivo es proteger el encabezado del datagrama de posibles errores en la transmision

o en el procesamiento del datagrama en los enrutadores.El algoritmo de calculo de checksum es el siguiente: se toma el encabezado en palabras

de 16 bits (se considera el campo checksum del encabezado con valor 0), se calcula la sumaaritmetica de complemento a 125 de todas las palabras y se calcula el complemento a 1 delresultado26.

El checksum del encabezado es recalculado cada vez que se modifica algun campo en elencabezado IP, por ejemplo, decrementar el TTL, fragmentacion, o agregado de Opciones.Asimismo, el checksum del encabezado se verifica cada vez que el datagrama sea procesado.

Dado que un datagrama cuyo checksum del encabezado se verifique invalido es descartado,se debe realizar el calculo del checksum luego de las modificaciones introducidas por metodosesteganograficos en el encabezado.

Direccion de origen Compuesto por 32 bits.Corresponde a la direccion del emisor del datagrama.

Direccion de destino Compuesto por 32 bits.Corresponde a la direccion del receptor del datagrama.Las direcciones estan compuestas por 4 octetos (32 bits) y, por cuestiones de simplicidad,

se las menciona, regularmente, como un conjunto de 4 numeros en escritura decimal, de 0 a255, separados por un punto[Tan97], por ejemplo: 192.168.0.2.

A continuacion, se detalla el uso de las direcciones de origen y destino establecidas en laespecificacion, para llevar a cabo la funcion de direccionamiento. Los hosts conectados a variasredes tienen direcciones diferentes en cada red.

El protocolo IP permite flexibilidad en la asignacion de direcciones a redes. Se puede dispo-ner una configuracion compuesta por un gran numero de redes pequenas, o un menor numerode redes con una mayor cantidad de hosts cada una. Para ello, las direcciones poseen unacodificacion que compone la direccion de red y del host.

La siguiente tabla muestra la codificacion de las direcciones IP en el formato direccion dered y de host.

Bits de mayor orden Formato Clase

0 7 bits de red, 24 bits del host a10 14 bits de red, 16 bits del host b110 21 bits de red, 8 bits del host c111 modo de direccionamiento extendido

24La RFC 1700 provee una version actualizada de la RFC 790 con los numeros de protocolo asignados.25Se suma bit a bit y al resultado se le adiciona el valor de carry, o acarreo de la suma.26Se cambian unos por ceros y ceros por unos.



El valor 0 en el area correspondiente al valor de red se refiere a la red donde se encuentrael host (conocida como “esta red”) y se utiliza solo en algunos mensajes de control ICMP.

Si bien no esta definido en la especificacion estudiada, el modo de direccionamiento exten-dido mencionado es subdividido en dos clases de direcciones: d y e, cuyos bits de mayor ordenson respectivamente: 1110 y 11110[Tan97]. La especificacion estudiada deja explıcitamente in-definido el modo de direccionamiento extendido, reservado para usos futuros. Las direccionesde red asignadas en Internet estan enumeradas inicialmente en la RFC 790.

La especificacion preve que un unico host fısico pueda actuar como si el mismo fuera varioshosts a partir del uso de distintas direcciones logicas en una misma interfaz fısica. Ademas,un mismo host puede tener varias interfaces fısicas en la misma red. Esta caracterıstica esdenominada multi-homing.

Si se modifica la direccion de destino (para aplicar esteganografıa), es posible que el da-tagrama no llegue al host deseado. La aplicacion de mensajes esteganograficos a partir de lamodificacion de las direcciones de origen y destino debe sustentarse en la configuracion demulti-homing: un mismo host receptor puede recibir datagramas a partir de dos direccionesdiferentes de la misma red. De igual modo, el emisor podrıa enviar desde diferentes direccio-nes de origen correctamente configuradas. Con esta aplicacion, el uso de una u otra direccionpermite interpretar un mensaje de forma esteganografica.

Para un guardian activo, el detectar o evitar la aplicacion del procedimiento descripto, esuna tarea difıcil de realizar. Para lograrlo, el gateway de una red debe mantener una listaactualizada de las direcciones IP asignadas a cada uno de los hosts de su red. Esto puedelograrse a partir de protocolos de configuracion automatica de direcciones. Tal es el caso delprotocolo DHCP (Dynamic Host Configuration Protocol)27. Al recibirse un datagrama de lared local con una direccion que no corresponde a una de la lista de direcciones validamenteasignadas, el guardian activo debe descartar el datagrama. Esto obliga a que cada host debaanunciarse a traves del protocolo de configuracion antes de poder iniciar sus comunicacionesen la red, con la consecuente demora en el proceso de puesta en regimen.

Adicionalmente, el guardian activo debe descartar los datagramas que posean direccionesinvalidas, como las correspondientes al modo de direccionamiento extendido que la especifica-cion ha reservado para usos futuros. El descarte de estos datagramas no afecta la comunicaciongenuina, puesto que se entiende que se trata de datagramas mal formados.

Opciones Este campo tiene longitud variable, su longitud maxima es de 40 bytes y puedeaparecer en el datagrama o no.

En general, el tamano disponible para las opciones del datagrama es escaso y, en conse-cuencia, deja sin aplicacion practica el uso de este campo[Tan97].

La especificacion establece que no es optativa la implementacion de la interpretacion delcampo en los modulos IP. En algunos datagramas en particular, su transmision puede seroptativa.

Existen dos tipos de formato de opciones:

Caso 1: Un unico octeto que indica el tipo de opcion.

Caso 2: Un octeto con el tipo de opcion, opcionalmente un octeto con el largo de laopcion (que contabiliza el octeto del tipo de opcion y el mismo octeto del largo de laopcion) y el contenido real de la opcion.

El octeto del tipo de opcion esta separado en tres campos:

27R. Droms, “Dynamic Host Configuration Protocol”, RFC 1541, October 1993, Bucknell University.http://www.faqs.org/rfcs/rfc1541.html



1 bit: corresponde al flag de copia (identificado con la letra C en la figura 2.8).

2 bits siguientes: corresponden a la clase de opcion (identificado como “clase” en la figura2.8).

5 bits siguientes: corresponden al numero de opcion (identificado como “num.” en lafigura 2.8).

0 1 2 3 4 5 6 7

C clase num.

bits

Figura 2.8: Campos del octeto tipo de opcion

El flag de copia indica si esa opcion se copia en todos los fragmentos, en los casos en quese realiza fragmentacion. Si vale 0 indica no se copia y si vale 1 que la opcion se copia.

El campo clase de opcion toma los siguientes valores:

00: opcion de control.

01: reservado para uso futuro.

10: opcion de depuracion (en ingles debbuging) y mediciones.

11: reservado para uso futuro.

Este campo puede contener varios tipos de opciones, es decir varios sub-campos. La es-pecificacion no establece restricciones sobre el orden en el que pueden aparecer las diferentesopciones dentro de este campo. Por lo tanto, este ordenamiento puede ser utilizado como unaforma de codificar un mensaje esteganografico. En consecuencia, un guardian activo debe mo-dificar el orden en el que se presentan las diferentes opciones dentro de este campo, para evitarsu uso esteganografico.

A continuacion, se analiza cada una de las opciones definidas en la especificacion:

Clase 00, numero 00000: Fin de la lista de Opciones. Ocupa solo un octeto, por locual, no posee el octeto de definicion del largo.

Esta opcion se utiliza para hacer alineacion (padding, en ingles) de las opciones a palabrasde 4 octetos (32 bits), debido a que el encabezado del datagrama debe tener una longitudmultiplo de 4 octetos. Este tipo de opciones se utiliza solo al final de todas las opcionesen caso que el largo de las mismas no coincida con el largo necesario para el encabezadodel datagrama.

La especificacion establece que esta opcion puede ser copiada, agregada o eliminada enel proceso de fragmentacion, o por alguna otra razon.

Respecto de la utilizacion de este tipo de opcion para la realizacion de esteganografıa, sepuede proponer el uso de este tipo de opcion en el caso que el datagrama no posea otrasopciones. Si bien, a priori no tiene una utilidad real (puesto que no se requiere haceralineacion de octetos cuando no se coloca otro tipo de opciones), la especificacion norestringe la posibilidad de utilizar unicamente este tipo de opcion en el encabezado deldatagrama. Sobre la base de esta idea, se deberıa colocar 4 veces este tipo de opcion, paralograr la alineacion necesaria a los 32 bits. En terminos de aplicacion esteganografica,la existencia de estas 4 opciones consecutivas en el datagrama constituyen un mensaje.Inclusive, dado que la longitud del campo de opciones es variable entre 0 y 40 bytes, con



valores posibles multiplos de 4 bytes, se podrıa adicionar 4, 8, 12..,40 opciones de estetipo.

Se debe tener en cuenta que el agregar este tipo de opcion (o cualquier otro tipo deopcion), al encabezado de un datagrama construido que no posee opciones, obliga amodificar el valor de los campos IHL (largo del encabezado) y Largo total.

Un guardian activo esteganografico debe eliminar estas opciones que encuentre que soninnecesarias (i.e. no cumplen una funcion de realizar alineacion) y, en consecuencia,modificar los campos de longitud mencionados.

Clase 00, numero 00001: No Operacion. Ocupa solo un octeto, por lo cual, no poseeel octeto de definicion del largo.

La especificacion establece que esta opcion puede ser utilizada entre otras opciones, porejemplo, para alinear el comienzo de la opcion siguiente al lımite de los 32 bits. Puedeser copiada, introducida o eliminada en el proceso de fragmentacion o por cualquier otrarazon.

Se observa que este tipo de opcion tiene un comportamiento similar al anterior. Mientrasuna indica que no se debe realizar operacion con ella, la otra tiene como objetivo laalineacion. La diferencia entre ambas es que la primera (la opcion de Fin de la lista deOpciones) se usa exclusivamente al final de todas las opciones, mientras que la segunda(No Operacion) se usa entre otras opciones. Por lo tanto, caben las mismas consideracio-nes de aplicacion del uso de este tipo opcion que el caso anterior, pero para la alineacionentre otras dos opciones. Supongase que al final de una opcion cualquiera, queda un octe-to para completar la frontera de los 4 octetos, para colocar otra opcion. Se podrıa agregaruna opcion de No Operacion o multiplos de 4 + 1 (i.e. 5, 9, 13...). El guardian activo debeoperar de forma analoga: debe eliminar las opciones de No Operacion innecesarias.

Adicionalmente, puede mencionarse que la especificacion no restringe la posibilidad decolocar, en el final de las opciones, varias opciones de tipo No Operacion consecutivasseguidas de una o mas opciones de Fin de la lista de Opciones. Con lo cual, se podrıaconsiderar un conjunto de opciones compuesto unicamente por opciones de No Operacionseguidas de opciones de Fin de la lista de Opciones.

Por otra parte, la especificacion indica que la opcion No Operacion es de uso opcional. Enconsecuencia, el solo uso de esta opcion entre otras dos opciones puede ser interpretadocomo un mensaje esteganografico. La otra forma de empleo de estas opciones serıa soloutilizar la opcion de Fin de la lista de Opciones al final de las mismas y no utilizaropciones de No Operacion.

El guardian activo debe ser disenado para evitar la propagacion de estos mensajes este-ganograficos. Para ello, debe eliminar todas las opciones de No Operacion que encuentreentre otras dos opciones e incorporar las opciones de Fin de la lista de Opciones que seannecesarias para completar la alineacion. De esta forma, los datagramas que transiten atraves de este guardian activo no contendran opciones de No Operacion.

El objetivo del guardian activo puede complementarse con la operacion inversa, en lugarde quitar las opciones de tipo No Operacion, puede incorporar nuevas. Por ejemplo, siun datagrama posee una opcion de No Operacion (que ocupa un octeto) entre otras dosopciones que alinean a la segunda de estas ultimas a la frontera de los 32 bits, el guardianactivo podrıa agregar 4 opciones de No Operacion a la ya existente (en caso de que nose vea superado el largo maximo del encabezado del datagrama). Con lo cual, al mismotiempo se mantiene la alineacion de la segunda opcion a la frontera de los 32 bits y seimposibilita el uso de la opcion de No Operacion para una comunicacion esteganografica.



Clase 00, numero 00010: Seguridad. Utilizada para transportar opciones de seguridad,compartimentacion, grupos de usuario y manejo de codigos de restricciones compatiblescon el Departamento de Defensa de Estados Unidos28.

Esta opcion debe ser copiada a los fragmentos en el proceso de fragmentacion. Puedeaparecer a lo sumo una vez en el datagrama.

El formato de esta opcion es el que se muestra en la figura 2.9.

10000010 00001011 SSS SSS CCC CCC HHH HHH TCC

Figura 2.9: Campos del tipo de opcion Seguridad

El primer octeto corresponde al tipo de opcion (flag de copiado en valor 1, clase 00,numero 00010), el segundo octeto corresponde a la longitud: 11 octetos (los dos primerosy 9 octetos de contenido).

El campo contenido esta subdividido en 4 campos:

• Seguridad : Campo S. 16 bits de longitud. Especifica uno de entre 16 niveles deseguridad (de los cuales, 8 estan reservados para uso futuro). Los mismos son:

Bits de identificacion (S) Descripcion

00000000 00000000 Unclassified11110001 00110101 Confidential01111000 10011010 EFTO (Encrypted For Transmission Only)10111100 01001101 MMMM01011110 00100110 PROG10101111 00010011 Restricted11010111 10001000 Secret01101011 11000101 Top Secret00110101 11100010 (Reserved for future use)10011010 11110001 (Reserved for future use)01001101 01111000 (Reserved for future use)00100100 10111101 (Reserved for future use)00010011 01011110 (Reserved for future use)10001001 10101111 (Reserved for future use)11000100 11010110 (Reserved for future use)11100010 01101011 (Reserved for future use)

Como se observa, las opciones de seguridad indican el nivel de confidencialidad quese requiere en la transmision del datagrama. La lista anterior, presentada en la espe-cificacion, ordena los valores posibles en orden creciente de nivel de confidencialidad.

• Compartimentos: Campo C. 16 bits de longitud. Si la informacion transmitida noesta compartimentada, tiene valor 0. Los otros valores son emitidos por la DefenseIntelligence Agency29 de Estados Unidos.

28Cabe mencionar que la especificacion del protocolo estudiada fue desarrollada sobre la base de los linea-mientos de seguridad del Departamento de Defensa de Estados Unidos (abreviado en la especificacion con lasigla DOD, por Department of Defense, en ingles). http://www.defense.gov/

29http://www.dia.mil/



El Departamento de Defensa de Estados Unidos publico en noviembre de 1991 laRFC 1108 que define las opciones de seguridad del protocolo IP30. Se deja fueradel alcance del presente trabajo el analisis de esta ultima RFC. Se centra el analisisteorico del protocolo en la RFC 791, tomada como guıa en el presente capıtulo.

• Manejo de Restricciones: Campo H. 16 bits de longitud. La especificacion indicaque los valores posibles de este campo estan definidos en el manual Defense Inte-lligence Agency Manual DIAM 65-19, “Standard Security Markings”, dejado fueradel presente trabajo.

• Codigo de Control de Transmision (en ingles Transmission Control Code): CampoTCC. 24 bits de longitud. Provee una forma de segregar trafico y definir comunidadesentre suscriptores. Compuesto por tres letras.

El uso de la opcion de seguridad detallada tiene un posible impacto en la eleccion de laruta a escoger para el datagrama en los nodos del camino que recorre el mismo. Puestoque la eleccion de un mayor grado de confidencialidad puede implicar la necesidad deevitar ciertas rutas (e.g. rutas que atraviesen determinados paıses). De forma similar alos flags de Tipo del mensaje, la especificacion de niveles de seguridad del datagramapuede incrementar el costo del envıo del mismo, para algun tipo de costo (e.g. tiempo deenvıo). Segun algunos autores, esta opcion es ignorada por los enrutadores, por lo quela unica funcion real es alentar a los potenciales espıas a que encuentren la informacionimportante mas facilmente[Tan97].

Con respecto a la aplicacion de esteganografıa con la utilizacion de la opcion Seguridad,se plantea nuevamente un caso en que se ve modificada la forma de transmision deldatagrama. Aunque, cabe resaltar que el objetivo principal de la comunicacion genuinapermanece intacto (i.e. el datagrama arriba a destino tal como lo requiere la invocacionrealizada por la capa superior del emisor). En este sentido, se podrıa plantear el uso deesteganografıa con la modificacion del nivel de seguridad del datagrama. Si un datagramano posee la opcion de Seguridad, un emisor esteganografico podrıa adicionarle dichocampo con un nivel de seguridad (e.g. Unclassified, No Clasificado). Esto constituirıa laaplicacion de esteganografıa a partir de un canal supraliminal, es decir, que no puede serquitado sin modificar la semantica del portador (en este caso el nivel de seguridad de latransmision).

Por otra parte, dado que existen varias opciones de Seguridad que se encuentran reser-vadas para un uso futuro, es posible plantear el uso de esos valores como portadores demensajes esteganograficos.

Un guardian activo debe definir niveles de seguridad aplicables a los datagramas quetransitan por las redes que el vincula y, en consecuencia, aplicar restricciones sobre eluso de esta opcion. En el caso mas restrictivo, puede eliminar el uso de la opcion deseguridad.

Cabe preguntarse por que si el campo S posee una longitud de 16 bits, lo cual da unos216 = 65,536 posibles valores, la especificacion define explıcitamente el uso de solo 16valores, de los cuales 8 fueron reservados para futuras definiciones. En este sentido, siun guardian activo encuentra un datagrama con una opcion de Seguridad que posee ensu campo S un valor no definido en la especificacion, debe extraer completamente esaopcion de seguridad del datagrama, por considerarla invalida.

Cabe mencionar que existe una definicion de una arquitectura de seguridad, denominada

30http://www.faqs.org/rfcs/rfc1108.html



IPSec31, que provee los servicios de seguridad necesarios para la comunicacion de data-gramas. Esta arquitectura de seguridad opera como una capa adicional que encapsula aldatagrama IP en estudio[Sta06]. La utilizacion generalizada del protocolo IPSec deja sinaplicacion practica al tipo de opcion de Seguridad del datagrama.

Clase 00, numero 00011: Loose Source and Record Route (LSRR)32. Esta opcionprovee un mecanismo para que el emisor del datagrama indique a los gateways intermediosla ruta que debe atravesar el datagrama. La ruta esta conformada por el conjunto degateways con el orden predefinido.

10000011 length pointer route data

Figura 2.10: Campos del tipo de opcion Loose Source and Record Route


El primer octeto contiene el codigo del tipo de opcion. El segundo, corresponde al largo dela opcion, que incluye el primer octeto, el octeto del largo, el octeto de puntero (pointer)y el espacio de la informacion de la ruta. El tercer octeto corresponde al puntero, dentrodel espacio de informacion de la ruta, que indica la posicion de la ruta que debe leerse encada instancia de procesamiento del datagrama, el contenido de esa posicion correspondea la direccion de un gateway. El valor del puntero es relativo al comienzo de la opcion,en consecuencia, su valor mınimo es 4. El area de ruta esta compuesto por un conjuntode direcciones de 32 bits (del mismo formato que las direcciones de origen y destino deldatagrama). La direccion de la ruta almacenada corresponde a la direccion propia delmodulo IP que es conocida en el ambiente en el que el datagrama es reenviado.

Si el valor del puntero es superior al de la longitud, la ruta almacenada esta completa yel enrutamiento debe basarse en la direccion de destino del datagrama.

Esta opcion se llama Loose Source porque cada gateway tiene permitido utilizar cualquierruta, con otros gateways en el camino, para alcanzar la siguiente direccion de la ruta. Esdecir, se permite reenviar el datagrama por gateways intermedios a los especificados.

Esta opcion debe ser copiada en cada uno de los fragmentos, en caso de realizarse frag-mentacion, y puede utilizarse hasta una vez en el datagrama.

La aplicacion esteganografica de esta opcion en un datagrama que no la utilice, podrıatener como objetivo obligar el enrutamiento del datagrama a incluir ciertos gatewaysconocidos que pueden estar involucrados en la comunicacion esteganografica. Por ejemplo,el algoritmo de extraccion esteganografica Ext que se encuentre en el camino, como seha ilustrado en los casos 3, 4, 5 y 6 de la figura 1.2.

Otra aplicacion esteganografica puede constituirla la colocacion de esta opcion con unaruta inicialmente asignada, como si el datagrama ya hubiera transitado por esos nodos.Esto se logra a partir de colocar un conjunto de direcciones en el campo route-data yel puntero inicial en el valor igual a la longitud total de la opcion. Con lo cual, cadagateway que procese el datagrama para reenviarlo debera decidir la ruta del mismo apartir de la direccion de destino del datagrama, del mismo modo que si no existiera esta

31Security Architecture for the Internet Protocol, R. Atkinson, Naval Research Laboratory, Network WorkingGroup, Request for Comments: 1825. Agosto 1995.

32Se prefiere utilizar el termino en ingles. La traduccion empleada en la bibliografıa[Tan97] es: Enrutamientolibre desde el origen.



opcion. A su vez, la funcion de extraccion recibira esta opcion con el conjunto de rutasintacto, tal como lo genero el modulo que embebio el mensaje esteganografico. El mensajeesteganografico radica en la interpretacion de la ruta contenida en esta opcion.

Como se puede observar, de la aplicacion descripta en el parrafo anterior, para fines este-ganograficos, la proteccion contra la propagacion de ese mensaje consiste en prohibir lautilizacion de este tipo de opcion. De modo que el guardian activo debe quitar esta opcionen los datagramas que procese. Esto trae, como consecuencia natural, el impedimento deutilizar con objetivos genuinos esta funcionalidad del protocolo.

Clase 00, numero 01001: Strict Source and Record Route (SSRR)33.

Esta opcion es similar a la anterior, con la diferencia que la ruta indicada por el emisordel datagrama (almacenada en el campo route-data de esta opcion) debe ser respetadapor cada gateway, sin adicionar intermediarios. Es decir, esta predefinido por el emisordel datagrama cada paso de la ruta.

Dada esta similitud, caben las mismas consideraciones de aplicacion de esteganografıa ydecisiones del guardian activo mencionadas para la opcion anterior.

Esta opcion es generalmente utilizada por los administradores de red para enviar datagra-mas de emergencia en caso de que las tablas de enrutamiento de los gateways intermediosse hayan corrompido, o para realizar mediciones de tiempos[Tan97]. Si el guardian activolimita el uso de esta opcion, se vera impedido el uso de esta funcionalidad.

Clase 00, numero 00111: Record Route34.


00000111 length pointer route data

Figura 2.11: Campos del tipo de opcion Record Route

Provee un mecanismo para almacenar la ruta que recorre el datagrama. El objetivo decada uno de los campos es el mismo que en la opcion Loose Source and Record Route.El tamano de la opcion permanece constante durante el recorrido del datagrama. Elemisor inicial del datagrama debe componer esta opcion con un tamano suficiente paraalmacenar todas las direcciones IP intermedias esperadas. El valor inicial del camporoute-data debe ser cero.

Cuando un modulo IP reenvıa un datagrama verifica si la opcion Record Route esta pre-sente, si es el caso, inserta su propia direccion IP (tal como es conocida en el entorno enel que se reenvıa el datagrama), en la posicion indicada por el valor del campo pointer,dentro del area route-data e incrementa el valor del campo pointer en 4.

Si el area route-data se encuentra completa (el valor del campo pointer es mayor allargo de la opcion, campo length), el datagrama debe ser reenviado, pero sin insertar ladireccion en el campo route-data. Si queda espacio, pero no el suficiente para insertar ladireccion completa (i.e. la direccion ocupa 4 octetos y si al campo pointer se le adiciona4, supera al campo length), el datagrama es considerado erroneo y debe descartarse.

33Al igual que en el caso anterior, se utiliza el nombre del tipo de opcion en ingles. La traduccion empleadaes: Enrutamiento estricto desde el origen.

34La traduccion correspondiente al espanol es: Registrar Ruta.



Esta opcion no se debe copiar en el proceso de fragmentacion, debe colocarse solo en elprimer fragmento y puede aparecer como maximo una sola vez en el mismo.

La aplicacion esteganografica de esta opcion es similar a la propuesta para la opcionLoose Source and Record Route. Se puede colocar esta opcion con una ruta inicialmenteasignada, como si el datagrama ya hubiera transitado por esos nodos de la red. Lo cual, selogra a partir de colocar un conjunto de direcciones en el campo route-data y el punteroinicial en el valor igual a la longitud total de la opcion. Como se menciono, de acuerdo ala especificacion, cada gateway que procese el datagrama para reenviarlo lo hara, pero noalmacenara su direccion. El destino esteganografico del datagrama (donde se encuentra lafuncion de extraccion Ext) recibira esta opcion con el listado de rutas intacto, tal como logenero el modulo que embebio el mensaje esteganografico. El conjunto de direcciones quecompone la ruta almacenada constituye el mensaje esteganografico, que es interpretadopor el algoritmo de extraccion.

En este caso, la proteccion contra esta actividad esteganografica consiste en la prohibi-cion del uso de esta opcion, con el consecuente impedimento de ser utilizada para finesgenuinos. El guardian activo que reciba un datagrama con esta opcion, debe quitarla yreenviar el datagrama.

Al momento de establecerse el protocolo (ano 1981), todos los datagramas transitabanpor, a lo sumo, nueve enrutadores. Por lo tanto, los 40 bits de opciones eran suficientespara almacenar la ruta[Tan97]. Actualmente, este valor es muy pequeno y deja sin utilidada estas opciones. En el ejemplo practico realizado en la descripcion del campo TTL, seobservo que el datagrama testigo atraveso 14 gateways intermedios en un escenario sobreInternet. Consecuentemente, este tipo de opcion no tiene utilidad practica actualmente.

En la implementacion propuesta del artefacto (seccion 3.2.2) se muestra una aplicacionpractica de la colocacion de una ruta inicialmente asignada descripta previamente.

Clase 00, numero 01000: Stream Identifier35.


10001000 00000100 Stream ID

Figura 2.12: Campos del tipo de opcion Stream Identifier

El primer octeto corresponde al tipo de opcion, el segundo al largo (con valor 436, esdecir, la opcion completa ocupa 4 octetos) y luego se coloca el Identificador (Stream ID),que ocupa 2 octetos.

Esta opcion provee una forma de agregar el identificador del flujo de redes SATNETpara ser transportado a traves de redes que no sustentan el concepto de flujo. Estaopcion debe ser copiada en el proceso de fragmentacion y puede aparecer a lo sumo unavez en el datagrama.

Esta opcion esta actualmente obsoleta[Dou06][Mic05], por lo que, para fines estega-nograficos podrıa utilizarse para embeber un valor de ID ficticio que forme para de unainterpretacion esteganografica (analoga a la desarrollada para el campo ID del datagra-ma). El guardian activo debe quitar esta opcion del datagrama, sin perjuicio de limitarfuncionalidades del protocolo actualmente en uso.

35La traduccion correspondiente al espanol es: Identificador del flujo.36En el texto publicado de la especificacion existe un error en el valor binario indicado en el campo corres-

pondiente al largo, aparece 00000010, cuando deberıa aparecer 00000100.



Clase 10, numero 00100: Internet Timestamp.


01000100 length pointer oflw flg

internet address

timestamp

. . .

Figura 2.13: Campos del tipo de opcion Internet Timestamp

El objetivo de esta opcion es proveer una forma de almacenar una marca de tiempo (eningles timestamp) en cada una de los gateways que procesan el datagrama.

Los campos que componen esta opcion son los siguientes:

• Tipo de opcion: Corresponde al primer octeto e identifica a este tipo de opcion,tiene valor 01000100.

• Largo de la opcion (length): Corresponde al segundo octeto. El valor que almacenacorresponde a la suma de todos los octetos de la opcion. El valor maximo es 40.

• Puntero (pointer): Corresponde al tercer octeto. Contiene el desplazamiento desde elcomienzo de esta opcion (desde el primer octeto de la misma) hasta el comienzo delespacio libre para la siguiente marca de tiempo. Este valor equivale a la cantidad deoctetos desde el primero de la opcion hasta el ultimo de la ultima marca de tiempoalmacenada mas uno. El menor valor admitido es 5 (dado que los cuatro primerosoctetos corresponden a campos que son encabezados de esta opcion). El area dealmacenamiento de marcas de tiempo se encuentra completa cuando el valor delcampo pointer es mayor que el de length.

• Overflow : Cuatro bits de tamano. Almacena la cantidad de modulos IP que procesa-ron el datagrama y no pudieron almacenar la marca de tiempo por falta de espacioen el area correspondiente. La especificacion no aclara que se debe realizar cuandoel flag de overflow alcanza su valor maximo (24 − 1 = 15).

• Flag (indicado como flg en el diagrama de la opcion): Cuatro bits de tamano. Losvalores posibles son:

◦ 0000: Almacenar unicamente marcas de tiempo, consecutivas, de cuatro octetoscada una.

◦ 0001: Almacenar las marcas de tiempo precedidas por la direccion IP del moduloque la registra.

◦ 0010: El campo de direcciones IP esta especificado previamente. Cada moduloIP almacena su marca de tiempo solo si su direccion coincide con la direccionIP siguiente (i.e. la que ocupa la posicion apuntada por el campo pointer).

• Marca de tiempo (timestamp): Cuatro octetos de tamano. En el se almacena eltiempo transcurrido desde la medianoche, segun el horario universal (UT). El tiempose almacena en milisegundos, alineado a derecha del campo. Si el sistema no puedeproveer el tiempo en milisegundos, o no posee la referencia respecto de UT, entonces,se puede insertar otra forma de marca de tiempo. Esta diferencia se indica colocandoel primer bit (el mas significativo) en valor 137.

37Notese que la cantidad de milisegundos del dıa es 86.400.000. Por lo tanto, el valor maximo que se debe



Al igual que en las opciones de indicacion y almacenamiento de la ruta, el largo deesta opcion esta predefinido por el emisor (quien construye el datagrama) y no varıa atraves de los diferentes procesamientos del datagrama. El contenido inicial del area dealmacenamiento de direcciones y de marcas de tiempo debe ser cero.

Cuando el area de almacenamiento de marcas de tiempo se completa (i.e. el valor depointer es superior al de length), el modulo IP que procesa el datagrama lo reenvıa sininsertar su marca de tiempo, y a su vez suma una unidad al valor del campo overflow,para finalmente indicar la cantidad de modulos IP que no pudieron insertar su marca detiempo. Si, en cambio, hay espacio en el area de almacenamiento de marcas de tiempo(i.e. el valor de pointer es inferior al de length), pero no el suficiente para almacenaruna marca de tiempo (se requieren 4 octetos si se almacena solo la marca de tiempo y 8octetos si ademas se almacena la direccion IP), se considera que el datagrama es erroneoy debe descartarse.

Esta opcion puede aparecer a lo sumo una vez en el datagrama y no debe copiarse a loseventuales fragmentos en el proceso de fragmentacion.

Esta opcion se utiliza generalmente para buscar posibles errores en los algoritmos deenrutamiento[Tan97]. Adicionalmente, se puede mencionar que esta opcion sufre de lamisma limitacion que las anteriores: el tamano del espacio para almacenar las direccionesy marcas de tiempo es escaso para las rutas promedio que deben realizar los datagramasactualmente.

Las aplicaciones esteganograficas que puede realizarse sobre este tipo de opcion son simi-lares a las propuestas para los casos de especificacion de ruta por el emisor (Loose Sourceand Record Route y Strict Source and Record Route) y de registrar ruta: el algoritmoEmb que modifica el datagrama ya construido puede incorporarle este tipo de opcion einicialmente incluir un listado ficticio de direcciones de red y marcas de tiempo. Cadagateway intermedio que procese el datagrama determinara que no habra espacio paraalmacenar su marca de tiempo y, en consecuencia, incrementara en una unidad el valordel campo overflow. El receptor esteganografico interpreta esa ruta como un mensajedirigido hacia el y lo decodifica de acuerdo al protocolo esteganografico convenido con supar emisor.

Un guardian activo debe limitar el uso de este tipo de opcion, ya sea, eliminar completa-mente esta opcion del datagrama, si la misma existe, o alterar el contenido que encuentrealmacenado (por ejemplo, puede modificar imperceptiblemente los tiempos registrados).

Otra aplicacion que puede realizarse sobre este tipo de opcion es, en cada nodo de pro-cesamiento del datagrama, que debe almacenar su marca de tiempo, alterar el dıgitomenos significativo de la misma, de forma que el valor resultante sea imperceptiblementesimilar al original (si se altera solo el ultimo bit, el error esta acotado en un milisegundo).Para contrarrestar esta practica, un guardian activo puede, por su parte, modificar deforma impredecible el bit menos significativo de cada una de las marcas de tiempo quealmacena esta opcion. Esta practica es similar a la sustitucion del bit menos significati-vo mencionada en la seccion 1.4 y es posible su aplicacion en las marcas de tiempo dediferentes protocolos[JG].

Padding El campo Padding (o relleno) del encabezado se utiliza para asegurar que el enca-bezado del datagrama tenga una longitud multiplo de 4 octetos (o 32 bits). Su contenido debe

almacenar es 86.399.999, en notacion binaria: 101001001100101101111111111. El cual contiene 28 dıgitos (bits).Por lo tanto, quedan 4 bits para completar los 32 que posee este campo. El primer bit de esos 4 es el que seutiliza para indicar que el valor almacenado corresponde a una marca de tiempo no estandar.



ser cero.Si bien el campo Padding se presenta como un campo diferente dentro de la descripcion de

los mismos en la especificacion del protocolo, la semantica es analoga al tipo de opcion Fin dela lista de Opciones que se ha descripto anteriormente. Cabe, por lo tanto, la aplicacion de lasmismas consideraciones sobre su uso en comunicaciones esteganograficas que las mencionadasen dicho tipo de opcion.

Por ultimo y con respecto a la seccion de datos del datagrama, cabe recordar que la mismacontiene el mensaje generado por la capa superior al modulo IP. Ese mensaje es recibido porel modulo IP para su envıo y colocado sin alteracion en el sector de datos. El estudio de laaplicacion de esteganografıa sobre la seccion de datos cae fuera de la presente tesis, puestoque corresponde analizar en particular el formato del mismo (e.g. una transmision realizadaa traves del protocolo TCP), que es independiente de la especificacion del protocolo IP enestudio.



2.3. Analisis de vulnerabilidades esteganograficas en el Proto-colo HTTP/1.1

El protocolo HTTP (Hypertext Transfer Protocol) es el estandar para la transferencia enla Web[Tan97]. Como se ha mencionado, la version de HTTP que se analiza en este trabajo esHTTP/1.1, que constituye la version vigente, definida en la RFC 2616. Cuando a continuacionse mencione a la especificacion del protocolo o, de manera abreviada, a la especificacion, sehara referencia a dicha RFC.

En la presente seccion de analiza la especificacion del protocolo para encontrar formasde realizar comunicaciones esteganograficas que utilicen como portador a los mensajes delprotocolo HTTP. Al igual que en el caso del analisis de IP, se toma como condicion que losestego-mensajes deben ser semanticamente equivalentes a los mensajes de la comunicaciongenuina.

2.3.1. Generalidades del protocolo HTTP

HTTP es un protocolo de capa de aplicacion (dentro de los modelos OSI y TCP/IP) parala distribucion y comunicacion. Es un protocolo generico y sin estado, que puede ser empleadopara varias tareas, ademas de la comunicacion de hipertexto en lenguaje HTML (HyperTextMarkup Language38). HTTP es usado globalmente para el intercambio de informacion en laWeb desde 1990 y actualmente es el protocolo de capa de aplicacion que tiene la mayor cantidadde trafico en Internet[Bau03].

La especificacion utiliza las palabras “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”,“SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY ” y “OPTIO-NAL” tal como estan interpretadas en la RFC 2119[Uni97]. Las implementaciones del protocolodeben cumplir con todos los items MUST y REQUIRED. Se definen dos niveles de cumplimien-to de requerimientos: las implementaciones que cumplen con todos los SHOULD se denominanincondicionalmente obedientes al protocolo, mientras que las que no cumplan con todos losSHOULD se denominan condicionalmente obedientes. Para el presente analisis, se supondra elcaso de implementaciones incondicionalmente obedientes. Es decir, se tomara tambien comonorma obligatoria del protocolo aquella que la especificacion indica como “SHOULD”. Poreste motivo, en lo sucesivo, no sera necesario hacer distincion entre los distintos niveles deobediencia al protocolo que propone la especificacion.

Al ser un protocolo de capa de aplicacion, HTTP se sustenta en un protocolo de conexionde transporte subyacente. En general se utiliza TCP e IP como protocolos de transporte y decapa de red, aunque la especificacion no lo restringe, por lo que se podrıa realizar una comuni-cacion HTTP sobre otro protocolo de transporte. La especificacion asume que el protocolo detransporte subyacente es de entrega confiable. Adicionalmente, establece que las implementa-ciones del protocolo deben asumir que las conexiones de la capa de transporte subyacente sonpersistentes. Esta consideracion esta sustentada en una mejora de rendimiento (se reduce lacarga de procesamiento y de envıo de mensajes en la red para el establecimiento y liberacionde esas conexiones).

Se recalca que se analiza las posibilidades de aplicacion esteganografica sobre la formaen la que el protocolo HTTP realiza las comunicaciones y sus estructuras. Si bien, un usoprincipal es la comunicacion de contenido de formato HTML, el analisis de las modificacionesesteganograficas sobre el contenido HTML (e.g. la alteracion del contenido de modo que larepresentacion resultante en un browser permanezca sin modificacion[RCN07]) quedan fueradel alcance del presente trabajo.

38http://www.w3.org/TR/html401/



En ciertas ocasiones sera necesario aclarar tambien el uso del contenido de los camposde datos que define el protocolo HTTP para transmitir informacion esteganografica (e.g. enforma de comentarios). Como ejemplo, se puede mencionar el software Reverse WWW Shell,que enmascara el contenido dentro de ciertos campos de HTTP[Col03][van]. Para ello, codificael contenido a enviar en Base 6439 y lo envıa en campos del mensaje, que simulan trafico normaldel protocolo HTTP.

HTTP es un protocolo de tipo cliente-servidor que opera con mensajes pedido/respuesta(request/reply). El cliente es el programa que establece conexiones con el objetivo de enviarpedidos (requests), se lo denomina agente de usuario (o user agent, en ingles) y puede serun browser, un editor, un crawler40 u otro software para el usuario final. El servidor es unprograma que acepta conexiones entrantes para responder a los pedidos (requests), con el envıode respuestas (replies). El servidor debe estar activo previo al envıo de pedidos del cliente. Unmismo software, o equipo de la red, puede actuar simultaneamente como cliente y servidor.

HTTP provee encabezados (headers) para enviar el pedido, con metodos para indicar eltipo de pedido y define a la ubicacion del recurso referido a partir de su URI (Uniform ResourceIdentifier41) o su URN (Uniform Resource Name42). Los mensajes son transmitidos en formatotipo MIME (Multipurpose Internet Mail Extensions43).

La figura 2.14 muestra el diagrama de secuencia de una interaccion entre un cliente y unservidor, comunicados de forma directa, donde el cliente envıa un pedido y el servidor envıasu respuesta, luego de procesar el mismo.

clienteservidor

(e.g. browser) (e.g. webserver)

pedido

respuestaprocesamiento

Figura 2.14: Diagrama de secuencia de una interaccion simple entre un cliente y un servidor

La comunicacion entre el cliente y el servidor puede llevarse a cabo a traves de intermedia-rios que reenvıan los mensajes de pedido y respuesta. Los intermediarios pueden ser: proxy,gateway o tunel. Un proxy es un agente que reenvıa los mensajes, recibe los pedidos para unaURI, reescribe todo o parte del mensaje y lo reenvıa al servidor identificado por la URI. Unproxy transparente es aquel que no modifica el mensaje de pedido o respuesta mas alla de lorequerido para su autentificacion e identificacion. Un proxy no-transparente es aquel que mo-difica el mensaje de pedido o respuesta para proveer un servicio adicional al agente de usuario.Un gateway es un servidor que actua como intermediario para otro servidor, actua como unacapa superior a la de otros servidores. Recibe los pedidos como si el fuera el servidor originaldonde se encuentra el recurso solicitado por el cliente. El cliente puede no estar notificado deque se comunica con un gateway. Un tunel actua como un punto de retransmision entre dosconexiones, sin modificar los mensajes. Los tuneles se utilizan cuando el mensaje debe pasarpor un intermediario (e.g. un firewall), cuando este no entiende el protocolo.

39S. Josefsson, Ed. RFC 3548 - The Base16, Base32, and Base64 Data Encodings. July 2003.http://www.faqs.org/rfcs/rfc3548.html

40un robot automatico que recorre la web41Berners-Lee, T., “Universal Resource Identifiers in WWW” RFC 1630, June 1994.42Sollins, K. and L. Masinter. “Functional Requirements for Uniform Resource Names”, RFC 1737, December

1994.43Freed, N., and N. Borenstein. “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet

Message Bodies”. RFC 2045, November 1996.



La figura 2.15 muestra un diagrama de secuencia de la interaccion entre un cliente y unservidor con tres intermediarios en el camino (e.g. tres proxys). El pedido y la respuesta pasana traves de cuatro conexiones. Cada participante se comunica con quien tiene a continuacionen la cadena.

Uno de los servicios que puede proveer un proxy no-transparente es el cache. Puede alma-cenar respuestas y enviarlas como si fueran generadas por el servidor de destino. Por ejemplo,en la figura 2.15, si el proxy B tuviera en su cache una copia de la respuesta al pedido querecibio, podrıa responder el sin necesidad de reenviar el pedido al proxy C, con el consecuenteahorro en comunicacion y procesamiento en la cadena de mensajes.

clienteservidor

(e.g. browser) (e.g. webserver)

pedido

respuesta

procesamiento

A B C

intermediarios

Figura 2.15: Diagrama de secuencia de una interaccion entre un cliente y un servidor con intermediarios

La RFC 3205[K. 02] especifica reglas y buenas practicas, orientadas a disenadores de pro-tocolos, para utilizar HTTP como sustrato de otro protocolo. Esto es, construir un protocoloen una capa superior a HTTP. Si bien menciona que HTTP no fue disenado para ser la ca-pa inferior de otro protocolo, entre las ventajas para esta utilizacion, la RFC menciona: sufamiliaridad y popularidad, la posibilidad de reutilizar bibliotecas de funciones existentes, laposibilidad de utilizar mecanismos de autenticacion y comunicacion cifrada, la capacidad deHTTP de atravesar firewalls (lo que incentiva a utilizarlos para disenar otros protocolos) y lanecesidad, en ciertos casos, de construir aplicaciones que obligatoriamente esten sustentadassobre HTTP.

Entre las desventajas, esta RFC menciona que HTTP comenzo como un protocolo simpley se lo hizo mas complejo con el agregado de funcionalidad no anticipada en el diseno original,que en general no es necesaria para un protocolo que se sustenta sobre el. Cabe mencionar quela version 1.1 de HTTP introdujo varias modificaciones respecto a la version 1.0, algunas deellas se introdujeron sin una evaluacion practica real[Bal]44.

La sobrecarga en la comunicacion que requiere HTTP, dado los campos del mensaje querequieren los mensajes, resulta en un rendimiento inferior respecto al diseno de un protocoload hoc. Por otra parte, dicha RFC indica que una aplicacion que no pueda operar en presenciade intermediarios en el camino del mensaje no debe utilizar HTTP como sustrato.

En el caso de utilizar un protocolo como sustrato, los mensajes del protocolo de la capasuperior se colocan en el campo de datos del protocolo inferior como una capa mas en la pilade capas de la arquitectura de protocolos. Cabe destacar que la esteganografıa no utiliza alprotocolo estrictamente como sustrato sino como portador de sus mensajes. Mas alla de estadistincion, las ventajas y desventajas mencionadas por la RFC 3205 pueden hacerse extensivasa la aplicacion de esteganografıa sobre HTTP.

44La especificacion de HTTP 1.1 triplica en largo a la de HTTP 1.0.



2.3.2. Formato y tipo de mensajes

Introduccion

Los mensajes HTTP pueden ser de pedido (request) o de respuesta (response). Ambos tiposde mensajes consisten en una lınea inicial, cero o mas campos de encabezado (conocidos comoheaders), luego una lınea en blanco (donde solo se coloca la marca de fin de lınea CRLF) queindica el fin de los campos del encabezado y, opcionalmente, el cuerpo del mensaje.

Los mensajes de pedido contienen la primera lınea del encabezado con el tipo de pedido(i.e. el metodo), conocida como Request-line, la version del protocolo (HTTP/1.1) y la URIdel recurso referido, y a continuacion lıneas con: los modificadores del pedido (entity-headerso entidades del encabezado), informacion del cliente y, opcionalmente, un cuerpo de pedido(entity-body).

Los mensajes de respuesta contienen un encabezado con una lınea de estado, que contieneun codigo de error o exito y su descripcion en forma de texto, seguido de un mensaje enformato tipo MIME que contiene informacion del servidor, entidades con metainformacion(entity-headers) y, opcionalmente, un contenido como parte de cuerpo del mensaje (denominadocontent o entity-body en la especificacion).

En orden de lograr mayor robustez, la especificacion establece que los servidores debenignorar cualquier lınea en blanco que preceda a la lınea de pedido (Request-Line) esperada. Siel servidor espera leer la primera lınea de un mensaje de pedido y en su lugar encuentra unasecuencia CRLR, debe ignorarla.

Esto permite la utilizacion para una comunicacion esteganografica. Puesto que la primeralınea en blanco de un mensaje de pedido es ignorada por el servidor, se puede incorporar aun mensaje construido una lınea en blanco que otorgue una interpretacion esteganografica.Un guardian activo debe colocar o quitar aleatoriamente lıneas en blanco antes de la primeralınea de un mensaje de pedido, para evitar la aplicacion de esta tecnica. Cabe mencionarque esta aplicacion solo es posible de ser realizada en los mensajes de pedido, por lo tantoestas comunicaciones esteganograficas pueden realizarse solo en direccion del cliente HTTPhacia el servidor y no en sentido contrario. En la seccion 3.2.3 se muestra un ejemplo de laimplementacion de esta tecnica.

Los campos del encabezado del mensaje HTTP se clasifican en: encabezados generales,encabezados de pedido, encabezados de respuesta y entidades de encabezado. Todos los camposdel encabezado siguen la sintaxis: nombre del campo, luego el caracter dos puntos (“:”) y acontinuacion el contenido del campo.

Los nombres de los campos son insensibles a mayusculas (case-insensitive). Por lo cual, esposible utilizar esta caracterıstica para una comunicacion esteganografica, donde el mensajeesteganografico surge a partir de la interpretacion de las mayusculas y minusculas utilizadas. Unguardian activo debe modificar las mayusculas y minusculas del nombre de todos los camposdel encabezado del mensaje HTTP para evitar la propagacion de estos posibles mensajesesteganograficos. Esta aplicacion se muestra en el artefacto implementado (seccion 3.2.3).

La especificacion define la secuencia CRLR como marca de fin de lınea para todos los elemen-tos del protocolo. Donde CR es el caracter de retorno de carro (carriage return), correspondienteal octeto de valor 13 en ASCII, y LF corresponde al caracter de nueva lınea (linefeed), corres-pondiente al octeto de valor 10 en ASCII. No se define la marca de fin de lınea para el cuerpodel mensaje.

Los valores de los campos del mensaje HTTP pueden ser separados en varias lıneas (tecnicaque se denomina folding). Para indicar que el contenido del campo fue cortado en varias lıneas,la lınea que continua debe comenzar con un caracter espacio o con un caracter tabuladorhorizontal (que corresponde al caracter de valor 09 en codificacion ASCII). Esta marca de



separacion se denomina LWS. De forma general, la especificacion aclara que puede haber masde una marca LWS consecutivas en la separacion del contenido de un campo en varias lıneasy el receptor puede reemplazar cualquier marca LWS por un caracter espacio (denominado SP,que corresponde al valor ASCII 32). Cuando un emisor genera un mensaje, debe esperar queel caracter LWS pueda ser reemplazado por un SP en la interpretacion del texto.

Es caracterıstica que concede la especificacion para el contenido de los campos del mensaje,permite que sea explotada para realizar una comunicacion esteganografica. El hecho de realizarfolding en el campo de un mensaje puede ser interpretado como un mensaje esteganografico.Por ejemplo, se puede codificar un numero en la cantidad de veces que sea realiza foldingsobre un mismo campo del mensaje. Esto siempre que el contenido del mensaje no se veaalterado con el reemplazo posterior de la marca LWS por un espacio SP (i.e. si el contenido delcampo no posee espacios, se alterarıa el texto original, o genuino). Por otra parte, se puedeutilizar la posibilidad de colocar consecutivamente varias marcas LWS, dado que todas ellas sonreemplazadas por un unico espacio al momento de interpretar el contenido del campo en elmodulo HTTP. En este sentido, la cantidad de marcas LWS consecutivas constituye un mensajeesteganografico.

Para contrarrestar esta aplicacion, un guardian activo (que puede estar implementado en unproxy transparente) puede reemplazar las marcas LWS de folding por SP, o bien, colocar marcasLWS adicionales que, aunque innecesarias, agreguen ruido en la comunicacion esteganografica.

Adicionalmente, la especificacion establece que el contenido del campo puede estar prece-dido por cualquier cantidad de secuencias LWS, aunque se prefiere un solo caracter SP. Estopuede ser utilizado de la misma forma descripta para el caso del folding. De forma analoga, elcontenido del campo no incluye LWS al final del mismo. Estas tecnicas son ejemplificadas en elartefacto implementado (seccion 3.2.3).

Algunos campos del encabezado permiten contener comentarios. Estos se colocan rodeadospor parentesis. En los campos en los que no se permiten comentarios, los parentesis se inter-pretan como parte del texto. La barra invertida “\” se utiliza como caracter de escape de sucaracter siguiente.

Los comentarios dentro de los campos del encabezado del mensaje tambien pueden ser utili-zados para realizar una comunicacion esteganografica. El texto colocado dentro del comentariopuede ser destinado al receptor esteganografico. Un guardian activo que intente contrarrestareste uso debe eliminar todos los comentarios que encuentre dentro de los campos que acep-tan comentarios, aunque esta practica limite la funcionalidad del protocolo. En el artefactopropuesto se aplican comentarios en los campos User-Agent y Server. El guardian activo im-plementado quita los comentarios de esos campos.

La especificacion aclara que el orden en el que son colocados los campos del encabezado noes relevante. Aunque establece que es una “buena practica” colocar en primer lugar los camposgenerales, seguido por los campos de pedido o respuesta y por ultimo los campos de entidad.

La posibilidad de envıo de los campos del encabezado en diferente orden puede ser tambienutilizada para la interpretacion de un mensaje esteganografico. Dado que es posible realizaruna comparacion entre el orden de los campos recibidos en un portador con respecto a unordenamiento preestablecido que tendrıan los mismos (e.g. al orden alfabetico), es posible, porejemplo, cuantificar la cantidad de posiciones que hay que mover a cada campo del mensajerecibido para que se ubique en su posicion de acuerdo a ese ordenamiento (e.g. alfabeticamente).La suma de todas esas posiciones puede representan un mensaje esteganografico. Para evitarla utilizacion de esta tecnica, un guardian activo debe reordenar los campos del encabezado,de modo de alterar aleatoriamente el orden existente.

La especificacion establece que es posible colocar varias veces el mismo campo del encabe-zado, con el mismo nombre si y solo si el contenido de ese campo es una lista separada por



comas, y es posible combinar todos los campos en uno solo de la forma “nombre del campo:valor”, donde el valor es la concatenacion de cada uno de los valores separados por una coma.El orden en el que se realiza la concatenacion es el orden en el que se reciben los camposseparados dentro del encabezado. En el caso de la existencia de multiples campos con el mismonombre, un proxy no debe modificar el orden de ellos.

La posibilidad de escribir multiples campos con el mismo nombre cuando el contenido deuno se trata de una lista separada por comas, para la aplicacion en una comunicacion estega-nografica implica por un lado que en el reordenamiento de los campos propuesto anteriormente,la funcion que embebe el mensaje no debe alterar el orden de los campos de igual nombre, ytodos esos campos deben ser tratados como uno solo al momento del computo del ordenamientopreacordado entre emisor y receptor esteganograficos. Es decir, para la extraccion del mensajeesteganografico se debe ignorar la existencia del resto de los campos de igual nombre luego deque se ha recibido el primero. Por otra parte, se puede realizar otra aplicacion esteganografica apartir del empleo de la posibilidad de escribir la lista de valores separados por comas en un solocampo o en multiples campos. Esto permite la interpretacion de un mensaje esteganograficode un bit (el caso del contenido del campo escrito en un solo campo corresponde a un valor delbit y el de varios campos con el mismo nombre para escribir el contenido corresponde al otrovalor del bit). Un guardian activo debe modificar aleatoriamente esta forma de escribir en elencabezado del mensaje los campos cuyo valor consiste en una lista separada por comas, a finde evitar la utilizacion de esta tecnica.

En el artefacto implementado (seccion 3.2.3), se ejemplifica la aplicacion del ordenamientode los campos y la posibilidad de transmitir una lista como un unico campo con los valoresseparados por comas, o como multiples campos.

La especificacion no establece un largo maximo para cada encabezado del mensaje. De todosmodos, indica que este tamano puede estar restringido por las aplicaciones que implementanel protocolo. Por ejemplo, en el servidor Apache HTTP Server45 este valor esta inicialmenteconfigurado en 8190 bytes y puede ser modificado en un parametro de configuracion46. Porotra parte, este servidor tiene limitado como valor inicial el largo de la lınea de pedido (i.e.Request-line) en 8190 bytes47. Estos valores pueden ser tenidos en cuenta al momento de aplicaresteganografıa sobre el encabezado del mensaje de pedido.

El cuerpo del mensaje (si esta presente) contiene la entidad cuerpo (entity-body) asociadacon el pedido o respuesta. La entidad del cuerpo puede ser transformada a partir de unacodificacion de transferencia (ver seccion 2.3.3).

Adicionalmente, la entidad cuerpo puede tener asociado campos de metainformacion quese colocan en el encabezado del mensaje y reciben el nombre de encabezados de entidad(entity-headers). Si el mensaje no presenta un cuerpo de entidad, los encabezados de enti-dad se refieren al recurso identificado en el pedido. Los encabezados de entidad definidosson: Allow, Content-Encoding, Content-Language, Content-Length, Content-Location, Content-MD5, Content-Range, Content-Type, Expires y Last-Modified. La especificacion establece quese puede extender estos encabezados sin modificar el protocolo, pero que no debe asumirse queel receptor del mensaje interprete el encabezado extendido. Los encabezados no reconocidosdeben ser ignorados por el receptor y deben ser reenviados por los proxys transparentes. Enel artefacto implementado (seccion 3.2.3) se presenta un ejemplo de adicion de un campo deencabezado propietario (i.e. no estandar).

Si bien la especificacion establece que los proxys transparentes deben reenviar los campos

45http://httpd.apache.org/46Corresponde al parametro LimitRequestFieldSize:http://httpd.apache.org/docs/2.0/mod/core.html#limitrequestfieldsize47Corresponde al parametro LimitRequestLine de la configuracion:http://httpd.apache.org/docs/2.0/mod/core.html#limitrequestline



de encabezado de entidad no reconocidos, un guardian activo debe eliminarlos de los mensajesque retransmite para evitar que esos campos sean utilizados con fines esteganograficos.

Algunos tipos de mensaje de pedido permiten la inclusion de un cuerpo del mensaje. Paralos tipos de mensaje de pedido que no aceptan un cuerpo de mensaje, la especificacion prohıbela colocacion de uno. Si el tipo de pedido del mensaje no incluye una forma de como manipularel cuerpo del mensaje, el mismo debe ser ignorado.

En los mensajes de respuesta, la decision de colocar un cuerpo de mensaje o no, dependedel tipo de pedido y del codigo de estado de la respuesta. Las respuestas a los mensajes depedido de tipo HEAD no deben incluir cuerpo. Asimismo, las respuestas con codigo de estado1xx (informacion), 204 (no hay contenido) y 304 (no fue modificado) no deben incluir cuerpo.El resto de las respuestas puede incluir cuerpo, aunque sea de longitud cero. Cuando no setransmite un cuerpo del mensaje, el mensaje HTTP finaliza cuando se encuentra la primeralınea en blanco luego de los campos del encabezado.

El largo del mensaje corresponde al largo del cuerpo del mensaje tal como aparece enel mensaje HTTP. Es decir, luego de aplicar las transformaciones de la codificacion de latransferencia.

Los campos generales del encabezado pueden ser aplicados tanto en mensajes de pedidocuanto en mensajes de respuesta. Estos campos son: Cache-Control, Connection, Date, Pragma,Trailer, Transfer-Encoding, Upgrade, Via y Warning. Esta lista se puede extender solo conun cambio de version del protocolo. De todos modos, la especificacion establece que se puedeextender esta lista si todas las partes que participan en la comunicacion reconocen su semantica.La extension de estos campos puede permitir realizar comunicaciones esteganograficas, por lotanto un guardian activo debe quitar los campos que no forman parte de la especificacion delprotocolo.

Mensajes de Pedido

Los mensajes de pedido (request) se componen de una lınea de pedido (Request-Line) obli-gatoria, luego, opcionalmente, el encabezado general, el encabezado del pedido y el encabezadode la entidad y el cuerpo del pedido, de presencia opcional, separado por una marca de fin delınea CRLF.

La sintaxis de la lınea de pedido es la siguiente:

Method SP Request-URI SP HTTP-Version CRLF

El metodo del pedido (Method) puede ser alguno de los siguientes: OPTIONS, GET, HEAD,POST, PUT, DELETE, TRACE y CONNECT. Los metodos GET y HEAD deben estar implementados portodos los servidores de proposito general, mientras que los otros son opcionales.

En la seccion 2.3.3 se trata la URI (Request-URI ) y la version HTTP (HTTP-Version). Laforma mas comun de utilizar la URI de pedido (Request-URI ) es para identificar un recurso enel servidor de destino, en cuyo caso se debe enviar la ruta absoluta del recurso como URI y laubicacion del servidor se coloca en el campo Host, que forma parte de los campos de pedido.Por ejemplo, para solicitar el recurso (metodo GET) ubicado en la ruta raız (“/”) del servidorconocido con el nombre www.fi.uba.ar :

GET / HTTP/1.1

Host: www.fi.uba.ar

La especificacion establece que si en la URI de pedido se indica el nombre del host comoparte de la URI absoluta, se debe ignorar el campo Host. Por ejemplo, en caso de que la lıneade pedido sea:



GET http://www.fi.uba.ar/ HTTP/1.1

el campo Host, si estuviese presente en el encabezado de ese pedido, debe ser ignorado.Estas dos formas de escribir el pedido de un recurso (a partir de incluir el nombre de

pedido en el campo Host o en la lınea de pedido), permiten una aplicacion esteganograficapara comunicar un bit. Un valor de un bit corresponde a cada una de las formas de escribir elpedido del recurso. Una funcion Emb que coloque el mensaje esteganografico puede modificarun mensaje HTTP existente para adaptar el pedido a una u otra forma de acuerdo al valorque se desea transmitir de forma esteganografica. Para impedir la aplicacion de esta tecnica,un guardian activo debe modificar la forma de indicar el pedido. Por ejemplo, puede reescribirla forma de realizar el pedido a la presentada como primer ejemplo (que incluye el campoHost), que es la recomendada en la especificacion (por motivos de compatibilidad con versionesanteriores del protocolo).

Los campos de pedido del encabezado permiten pasar al servidor informacion adicional so-bre el pedido y sobre el cliente, resultando en modificadores del pedido. Estos campos son: Ac-cept, Accept-Charset, Accept-Encoding, Accept-Language, Authorization Expect, From, Host, If-Match, If-Modified-Since, If-None-Match, If-Range, If-Unmodified-Since, Max-Forwards, Proxy-Authorization, Range, Referer, TE y User-Agent.

Los campos no reconocidos son tratados como campos de entidad. De forma analoga ala mencionada para los campos generales, esta lista puede extenderse y un guardian activodebe evitar las extensiones, para impedir el uso de las mismas con fines de comunicacionesesteganograficas.

Mensaje de Respuesta

El mensaje de respuesta es enviado por el servidor, luego de recibir un mensaje de pedido.El encabezado del mensaje de respuesta se compone de: la primera lınea que correspondea la lınea de estado del procesamiento (Status-Line), a continuacion siguen los encabezadosgenerales, los encabezados de respuesta y los encabezados de entidad. Luego se coloca una lıneaen blanco (i.e. solo la secuencia CRLF) para indicar el fin del encabezado y a continuacion elcuerpo opcional del mensaje de respuesta.

La lınea de estado tiene la siguiente sintaxis:

HTTP-Version SP Status-Code SP Reason-Phrase CRLF

Comienza con la version del protocolo HTTP (HTTP-Version), sigue con el codigo numericode estado (Status-Code) y la frase textual asociada (Reason-Phrase), separados por un caracterespacio (SP).

El codigo de estado (Status-Code) es un valor entero de tres dıgitos que representa elresultado del intento de interpretar el mensaje de pedido correspondiente, esta destinada aser interpretada por un sistema automata. La frase textual asociada (Reason-Phrase) tienecomo objetivo agregar una descripcion de texto del codigo de estado y esta destinado a serinterpretado por el usuario humano, la especificacion sugiere algunos codigos de respuesta ysus textos asociados. El primer dıgito del codigo de estado define la categorıa de respuesta,mientras que los ultimos dos dıgitos no poseen un rol definido. Los primeros dıgitos definidosson cinco y tienen la siguiente semantica:

1: Informativo. Se recibio la respuesta y se continua con el procesamiento.

2: Exito. Se recibio correctamente el pedido, y se pudo procesar con buen exito.

3: Redireccion. Se debe tomar una accion posterior para completar el pedido.



4: Error del cliente. El mensaje de pedido es erroneo.

5: Error del servidor. El servidor no pudo procesar el pedido (cuando aparentemente elpedido es correcto).

Se utiliza como convencion el referirse a un codigo terminado en xx (como 1xx ) para indicarcualquier codigo de respuesta que comienza en 1. No necesariamente los ultimos dos dıgitosdeben coincidir.

En consecuencia, este campo de la lınea de estado puede ser utilizado para lograr unacomunicacion esteganografica, dado que el mismo no posee un contenido estructurado, es decir,el campo acepta un texto libre. Un guardian activo debe modificar el contenido de este campopara evitar el uso de este campo con fines esteganograficos.

En la seccion 2.3.5 se describe cada uno de los codigos de respuesta sugeridos por la es-pecificacion y los textos asociados a cada uno. La especificacion establece que los codigos derespuesta son extensibles y que las implementaciones de HTTP no estan obligadas a inter-pretar la semantica de todos los codigos registrados, aunque sı deben interpretar la clase delcodigo de mensaje (identificada por el primer dıgito) y en caso de no interpretar un codigode error particular, actuar como si se tratara de uno generico de la misma clase. Un guardianactivo debe modificar los codigos de respuesta no definidos en la especificacion, de modo deconvertirlo en el codigo de respuesta generico de su clase, con el fin de evitar que el uso de losmismos posibilite una comunicacion esteganografica.

Los encabezados de respuesta permiten enviar informacion adicional sobre la respuesta queno puede ser colocada en la lınea de estado. La especificacion define los campos Accept-Ranges,Age, ETag, Location, Proxy-Authenticate, Retry-After, Server, Vary y WWW-Authenticate.Estos campos pueden ser extendidos. Los campos no reconocidos deben ser tratados comocampos de entidad. Un guardian activo debe impedir la comunicacion de campos no definidosen la especificacion, para evitar que estos sean utilizados con fines esteganograficos.

2.3.3. Parametros del Protocolo

Version HTTP El protocolo utiliza un esquema de numeracion de la version del proto-colo con la forma: “mayor”.“menor”. La version define el formato del mensaje. El formatode la version es el siguiente: "HTTP" "/" 1*DIGIT "." 1*DIGIT (i.e. ambos campos puedenestar compuestos por uno o mas dıgitos). En el caso del protocolo en estudio, correspondea HTTP/1.1. Los valores mayor y menor que componen la version del protocolo pueden serincrementados por separado.

La version HTTP de una implementacion es la mayor version en la que la que la aplicaciones al menos condicionalmente obediente. Un proxy o gateway no debe modificar la version de unmensaje para incrementarla, debido a que la misma indica las capacidades del emisor. La con-version de un encabezado entre versiones HTTP puede requerir modificar algunos campos delencabezado o puede estar prohibida entre las versiones entre las que se realiza la conversion48.

La especificacion aclara que los ceros al inicio de cada uno de los valores que componenla version deben ser ignorados por el receptor y que no deben ser enviados. Esta aclaracionpermite utilizar esta caracterıstica como una aplicacion esteganografica. El envıo de uno o masceros al comienzo de cada uno de los valores puede codificar un mensaje. Para contrarrestaresta aplicacion, un guardian activo debe eliminar los ceros iniciales de cada uno de los camposde la version del protocolo. Cabe aclarar que si el valor de alguno de los dos componentes dela version del protocolo es cero, este se debe colocar (e.g. si el valor de menor es cero, de todasformas se debe colocar el punto separador y el cero final, por ejemplo HTTP/1.0).

48El estudio de la conversion entre versiones se deja fuera del alcance, dado que en el presente trabajo seestudia la version HTTP/1.1 conforme a su especificacion.



En el artefacto implementado (seccion 3.2.3) se muestra el agregado de un 0 antes delnumero “mayor”, para expresar la version como HTTP/01.1. Con esto se codifica un bit delmensaje esteganografico.

Uniform Resource Identifiers (URI) La URI (Identificacion Uniforme del Recurso) con-siste en una cadena de caracteres que identifica a partir del nombre, ubicacion u otra carac-terıstica a un recurso. Adicionalmente, cuando su valor es un asterisco (“*”) la URI representaque no aplica a un recurso en particular, este caso se permite solo cuando el metodo del pedidono necesariamente aplica sobre un recurso.

La URI puede ser representada en forma absoluta o en forma relativa a partir de otra URIbase conocida, segun el contexto en el que se use. Las URIs absolutas comienzan con el nombredel esquema seguido del caracter dos puntos “:”. La especificacion no establece un lımite parael largo de la URI. Los servidores deben poder interpretar la URI de todos los recursos quesirven. Si la URI es mas larga de lo que puede manejar, el servidor debe retornar un mensajede error con el codigo de estado 414 (Request-URI Too Long).

Para el protocolo HTTP se utiliza el esquema http, con la siguiente sintaxis:"http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

El valor del puerto (port) es opcional y, si no se especifica, se asume 80. Esto permite unaimplementacion esteganografica en un proxy transparente, que agregue el puerto 80 (se agrega:80 luego del nombre del host) en los casos en los que el puerto no se coloque. El mensajeesteganografico radica en la interpretacion de la presencia del valor 80 o no, cuando se tratadel puerto estandar. Para otros valores de puerto, es obligatorio explicitarlo, por lo tanto enese caso no se puede utilizar para la comunicacion esteganografica. Un guardian activo debemodificar la presencia del “:80”. Puede quitarlo cuando exista y agregarlo cuando no se hayacolocado (para introducir ruido en la posible comunicacion esteganografica). Esta tecnica esaplicada en el artefacto implementado (seccion 3.2.3).

La especificacion establece que se debe evitar el uso de direcciones IP como identificacionesdel nombre, en favor del uso de nombres (y se permite a los proxys modificar el valor por eldel nombre).

El valor de abs path representa la ubicacion absoluta del recurso. Si no se coloca abs path,se asume “/”. Esto permite una aplicacion esteganografica: cuando el valor de abs path es nulo,puede elegirse colocar el caracter “/” o no hacerlo. Lo cual, deja la posibilidad a ser utilizadopara una codificacion de un mensaje esteganografico. Un guardian activo debe modificar esecontenido en esos casos (e.g. puede colocar arbitrariamente el caracter “/”).

La comparacion, para determinar si dos URIs coinciden o no, se realiza octeto por octetosensible a mayusculas (case-sensitive), con las siguientes excepciones:

Si el valor del puerto no se especifica, se asume 80.

La comparacion de nombres de host debe ser indiferente a mayusculas (case-insensitive).

La comparacion de nombres de esquema indiferente a mayusculas (case-insensitive).

El valor de abs path vacıo se interpreta como “/”.

Los caracteres que no estan identificados como reservados o inseguros son equivalentes asu codificacion en secuencias de escape49. La secuencia de escape se forma con el caracter “%”seguido de dos dıgitos correspondientes a la codificacion en base hexadecimal del caracter. Los

49Una secuencia de escape, como %7E, proporciona un mecanismo general para representar caracteres invisibleso difıciles de escribir[KR91] (en este caso, el caracter “~”).



caracteres no numericos de la escritura hexadecimal pueden colocarse tanto en mayusculascuanto en minusculas. En las implementaciones es comun escribir la forma “%7e” que corres-ponde al caracter “~”. Las implementaciones deben tener cuidado de no realizar el reemplazoen secuencias de escape mas de una vez sobre la misma cadena. Dado que transformar a secuen-cias de escape una cadena que ya ha sido transformada puede resultar en la mala interpretaciondel caracter “%”[T. 98].

La especificacion ejemplifica la equivalencia de URIs con las siguientes:

http://abc.com:80/~smith/home.html

http://ABC.com/%7Esmith/home.html

http://ABC.com:/%7esmith/home.html

Se propone aplicar la propiedad de indiferencia a mayusculas de la comparacion de nombresde host y nombres de esquema para el uso esteganografico. Se puede realizar una comunicacionesteganografica a partir de la interpretacion de mayusculas o minusculas de cada caracterde estas dos partes de la URI. Una implementacion esteganografica existente en un proxytransparente puede modificar en este sentido una URI ya conformada. Un guardian activodebe modificar con el mismo criterio esas partes de la URI para evitar la propagacion de esosmensajes.

Por otra parte, dada la equivalencia de caracteres con su representacion en secuencias deescape, se tiene otra posibilidad de aplicacion de esteganografıa a partir de la modificacion dela escritura de la URI. Una funcion que embeba un mensaje esteganografico puede reemplazar(e.g. aleatoriamente) caracteres no reservados, ni inseguros por su version en secuencia deescape. Por ejemplo, se puede reemplazar letras del abecedario por su correspondiente secuenciade escape. El mensaje esteganografico estarıa representado, por ejemplo, por la cantidad deletras del abecedario escritas como secuencia de escape. Notese, ademas, que el reemplazo ensecuencias de caracteres es insensible a mayusculas (e.g. “%7e” es equivalente a “%7E”), por loque tambien puede usarse para la interpretacion de un mensaje esteganografico. Un guardianactivo debe evitar la comunicacion de secuencias de escape innecesarias y reemplazarlas porsu correspondiente caracter. Adicionalmente, puede agregar reemplazos de otras secuencias deescape, aunque las mismas sean innecesarias, para agregar ruido a la posible interpretacionesteganografica.

En los casos propuestos de modificacion de la URI, la semantica de la misma permaneceinalterada, es decir, la version modificada y la no modificada de la URI son equivalentes (i.e.refieren al mismo recurso).

Formato de Fecha y Hora Las marcas de fecha y hora se representan en Greenwich MeanTime (GMT), sin excepcion.

El protocolo permite tres formas diferentes de representar las marcas de fecha y hora. Semuestra a continuacion el ejemplo enunciado en la especificacion:

Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123

Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036

Sun Nov 6 08:49:37 1994 ; ANSI C’s asctime() format

La primera forma es la preferida como estandar en Internet, esta formada por una cadena decaracteres de longitud fija. La segunda es la forma de uso comun (al momento de la escritura dela RFC), pero tiene el inconveniente de que el ano se escribe en dos dıgitos, en lugar de cuatro.La especificacion establece que los servidores deben interpretar las tres formas de escrituray que ellos deben generar las marcas de fecha y hora solamente con el primer formato. La



cadena de fecha y hora es sensible a mayusculas y no debe incluir secuencias LWS, mas alla delos caracteres SP de cada una de las formas.

Dado que existen tres formatos para la escritura de marcas de fecha y hora que debeninterpretar los servidores, se puede utilizar para una comunicacion esteganografica, solo enel sentido del cliente hacia el servidor, porque el servidor debe emitir las marcas de tiempoen uno solo de los formatos. En este sentido, la escritura de las marcas de tiempo en cadauno de los formatos puede tener una interpretacion dentro de un mensaje esteganografico. Unguardian activo debe reescribir la marca de tiempo en alguno de los otros formatos para evitarla propagacion del mensaje esteganografico.

Conjuntos de caracteres El conjunto de caracteres refiere al metodo utilizado junto contablas de conversion de secuencias de octetos en secuencias de caracteres. No todos los conjuntosde caracteres pueden representar todos los caracteres y, por otra parte, puede existir mas de unarepresentacion para un caracter particular. El parametro del conjunto de caracteres utilizadoen el mensaje es obligatorio, no se debe dejar que el servidor adivine el mismo, aun cuando setrate de ISO-8859-1.

Los conjuntos de caracteres de HTTP son definidos por nombres en forma insensible amayusculas (lo que permite la aplicacion de las tecnicas esteganograficas ya descriptas), cual-quier valor es permitido, y se recomienda a las aplicaciones utilizar solo los definidos en IANACharacter Set registry50.

Dado que es posible codificar el encabezado en diferentes conjuntos de caracteres, se puedeutilizar para realizar una comunicacion esteganografica donde el mensaje correspondiente surjaa partir de la interpretacion del conjunto de caracteres utilizado. Una funcion de aplicacionesteganografica puede recodificar un mensaje HTTP a otro conjunto de caracteres, siempre queesto sea posible (por ejemplo, en ISO-8859-1 puede representarse todos las letras del idiomaespanol, las vocales con sus tildes, en mayusculas y minusculas, mientras que en ISO-8859-2no puede representarse la letra “n”). Un guardian activo debe realizar la misma tarea en casode ser posible, es decir, recodificar el mensaje para modificarle el conjunto de caracteres, yevitar de esta maneja que el conjunto de caracteres del mensaje pueda ser utilizado comointerpretacion de un mensaje esteganografico.

Codificacion del contenido Los valores de codificacion del contenido indican la transforma-cion que se ha aplicado sobre un contenido (content). Se utilizan principalmente para permitircomprimir el contenido del recurso. El nombre de la codificacion del contenido es insensiblea mayusculas (lo cual tambien puede ser utilizado en una comunicacion esteganografica). Loscampos del encabezado HTTP que se utilizan son Accept-Encoding (para indicar a la otra parteque tipo de codificaciones se puede interpretar) y Content-Encoding (para indicar que tipo decodificacion se aplica sobre el contenido). Estos valores indican que mecanismo debe utilizarsepara quitar la codificacion sobre el contenido.

Los valores posibles son:

gzip: Codificacion producida por el metodo de compresion gzip (GNU zip51). Este for-mato es Lempel-Ziv (LZ77)[75.] con un CRC de 32 bits.

compress: Codificacion producida por el software de UNIX compress y corresponde alalgoritmo adaptativo Lempel-Ziv-Welch (LZW)[75.].

50Reynolds, J. and J. Postel. “Assigned Numbers”, STD 2, RFC 1700, October 1994.http://www.faqs.org/rfcs/rfc1700.html

51http://www.gzip.org/



deflate: Corresponde al formato zlib definido en la RFC 195052 en combinacion con elmecanismo de compresion deflate definido en la RFC 195153.

identity: No se realiza transformacion. Es el valor por defecto.

Dado que existen varias formas posibles de realizar una transformacion al contenido, sepuede utilizar esta propiedad para realizar una comunicacion esteganografica. El algoritmo deincorporacion del mensaje esteganografico debe asegurarse que la otra parte puede interpretaruna codificacion diferente a la que presenta el portador sobre el que actua. Esto se obtiene apartir de la interpretacion del campo Accept-Encoding que se haya recibido con anterioridad.Luego, se debe recodificar el contenido en la codificacion deseada (y modificar el parametro delencabezado correspondiente: Content-Encoding), que tenga una interpretacion esteganografica.Un guardian activo debe realizar otra recodificacion del contenido. Por ejemplo, puede en todoslos casos y de manera segura (i.e. el mensaje HTTP no cambia su interpretacion), quitar lacodificacion, es decir, retransmitir el contenido como identity.

Adicionalmente, la especificacion establece que se puede utilizar la identificacion x-gzip

como equivalente a gzip y x-compress como equivalente a compress, por motivos de com-patibilidad con implementaciones preexistentes de HTTP. Estas dos formas de denominar ala misma codificacion permiten su empleo en una comunicacion esteganografica, dado quees posible escoger dos nombres diferentes (donde cada uno puede tener una interpretacionesteganografica diferente), sin alterar la semantica del portador. Un guardian activo debe in-tercambiar aleatoriamente los nombres equivalentes, para evitar este uso.

Codificacion de la Transferencia Los valores de Codificacion de la Transferencia se uti-lizan para indicar la transformacion que puede o debe realizarse sobre el cuerpo del mensaje(entity-body) para asegurar el transporte seguro del mensaje a traves de la red. Los valoresde Codificacion de la Transferencia se utilizan en los campos TE y Transfer-Encoding delencabezado.

Existen dos tipos de valores para la codificacion de la transferencia: para indicar compresiondel mensaje HTTP (identity, gzip, compress y deflate) y para indicar que la transmisiondel mensaje HTTP se realice por porciones (chunked), chunks, en ingles. Adicionalmente,es posible definir un valor adicional como extension a las codificaciones de la transferencia,definido de la forma:

parameter = attribute "=" value. Los mismos son insensibles a mayusculas, lo que per-mite aplicar nuevamente la tecnica esteganografica descripta.

A diferencia del parametro de Codificacion del contenido, la Codificacion de la Transferenciaes una propiedad del mensaje HTTP, no del contenido original del recurso. Adicionalmente, elparametro Codificacion del contenido tiene efecto entre los extremos de la comunicacion HTTP(i.e. cliente-servidor), mientras que el parametro Codificacion de la Transferencia tiene efectoentre saltos de la comunicacion HTTP (e.g. proxy-proxy consecutivos)[Bal].

La codificacion chunked modifica el cuerpo del mensaje para ser transferido como una seriede porciones. Cada porcion comienza con su propio indicador de tamano en octetos (expresadoen base hexadecimal), seguida opcionalmente de los campos del encabezado. Esto permiteproducir contenido dinamicamente para ser transferido, junto con la informacion necesariapara que el receptor verifique si ha recibido el contenido completo. La ultima porcion debeser de tamano 0. La codificacion chunked debe ser la ultima aplicada al cuerpo del mensaje y

52Deutsch, P. and J. Gailly. “ZLIB Compressed Data Format Specification version 3.3”, RFC 1950, May 1996.http://www.ietf.org/rfc/rfc1950.txt

53Deutsch, P., “DEFLATE Compressed Data Format Specification version 1.3”. RFC 1951, May 1996.http://www.ietf.org/rfc/rfc1951.txt



no puede ser aplicada mas de una vez sobre el cuerpo del mensaje. Esto permite al receptordeterminar el largo de la transferencia del mensaje.

La transformacion del cuerpo de un mensaje HTTP en chunked consiste en la fragmenta-cion del mismo en varios mensajes HTTP. Esta funcionalidad permite la aplicacion para unacomunicacion esteganografica de manera analoga a la propuesta para el caso de la fragmenta-cion de datagramas IP. Un algoritmo que embeba un mensaje esteganografico puede modificarun mensaje HTTP existente para fragmentarlo en varios, donde cada mensaje HTTP contieneel tamano del contenido y el cuerpo de ese contenido. El mensaje esteganografico surge de lainterpretacion de la cantidad de porciones (chunks) y del tamano de cada una de ellas (la espe-cificacion no restringe el tamano de las porciones). A los fines del receptor genuino, la sucesionde mensajes HTTP sera vista como si el contenido se hubiera generado dinamicamente y sehubiera enviado por partes, a medida que las mismas se encontraban listas para ser entregadas.

Un guardian activo, analogamente al caso desarrollado para la fragmentacion de datagramasIP, debe modificar la estructura de la fragmentacion del contenido del mensaje. Es decir,modificar el tamano de las porciones y, en consecuencia, la cantidad de las mismas. Estolo realiza a partir de reensamblar las porciones del contenido del cuerpo y construir nuevosmensajes HTTP. Para lograr esto, se puede tanto esperar a recibir la totalidad del cuerpo delmensaje (y aplicar una nueva particion o enviarlo en un unico fragmento) cuanto modificarcada una de las porciones a medida que son recibidas de modo de fragmentar cada una de ellasen porciones mas pequenas. Evidentemente, la primera de las opciones es la que introducemayor demora en la transferencia en la red, la cual aumenta en relacion al aumento de tamanodel contenido del mensaje.

Si el servidor recibe un mensaje con una Codificacion de Transferencia que no es capazde interpretar, debe responder con un mensaje de error de codigo: 501 No Implementado(Unimplemented).

Tipos de Media HTTP utiliza los tipos de media definidos en la RFC 159054. Para indicarel tipo de media del contenido del cuerpo del mensaje se utiliza el campo Content-Type delencabezado, mientras que el campo Accept se utiliza para negociar un tipo de media que sedesea recibir. El valor del tipo de media sigue la siguiente sintaxis:

media-type = type "/" subtype *( ";" parameter )

Los valores de tipo (type) y subtipo (subtype) son insensibles a mayusculas (lo que permitela aplicacion de esteganografıa sobre el contenido de los mismos, como se ha descripto en loscasos precedentes). Los parametros son importantes para la interpretacion del tipo de mediay su presencia o ausencia es significativa, los mismos se escriben de la forma: atributo=valor.No se debe utilizar la marca LWS entre el tipo y el subtipo, ni entre el nombre del atributo ysu valor.

Cuando el contenido del cuerpo del mensaje es de tipo texto, HTTP define como separadorde lıneas la cadena de caracteres CRLF. La especificacion relaja ese requerimiento y permite parael transporte de texto el uso indistinto de los caracteres CR y LF, siempre que sean empleadosconsistentemente en todo el texto del cuerpo del mensaje. Las implementaciones de HTTPdeben aceptar cualquiera de las tres formas como representacion de la separacion de lıneas.Esta flexibilidad de HTTP aplica solo al contenido del cuerpo del mensaje de tipo texto. Elvalor por defecto del codificacion de caracteres del cuerpo de tipo texto es ISO-8859-1.

La flexibilidad de las marcas de fin de lınea dentro del contenido de tipo texto del pro-tocolo permite el aprovechamiento como una interpretacion para un mensaje esteganografico.Si el contenido es de tipo texto, el algoritmo que embebe el mensaje esteganografico puede

54Postel, J., “Media Type Registration Procedure”, RFC 1590, November 1996.http://www.ietf.org/rfc/rfc1590.txt



reemplazar todas las marcas de fin de lınea por cualquiera de las tres posibles (CRLF, CR o LF).Donde cada una de ellas tiene una interpretacion en el contexto del mensaje esteganografico.Un guardian activo debe reemplazar aleatoriamente esas marcas de fin de lınea por cualquierade las tres formas para evitar la aplicacion de esta tecnica.

Por otra parte, dado que la codificacion por defecto del texto es ISO-8859-1, si el texto seencuentra en dicha codificacion, resulta indistinto comunicar explıcitamente el tipo de codifi-cacion que no hacerlo. Esto tambien puede ser aplicado para la comunicacion esteganografica,de modo que la indicacion explıcita de esa codificacion reciba una interpretacion diferente a laausencia de la misma. Un guardian activo debe, en esos casos, agregar o quitar esa indicacionen forma aleatoria.

La especificacion establece que todos los mensajes que contienen un cuerpo de entidaddeben incluir un campo de encabezado Content-Type y, solo en el caso de no existir ese campo,el receptor del mensaje puede intentar adivinar el tipo de contenido a partir de la inspeccion delcontenido del mismo o a partir de la extension del nombre de la URI utilizada para identificara ese recurso. En caso de que no se logre identificar el tipo de contenido, debe tratarse comodel tipo application/octet-stream (i.e. una cadena de octetos de tipo generico).

La posibilidad de no colocar el encabezado Content-Type en ciertas ocasiones permite quela existencia o no de este encabezado pueda ser interpretado en el marco de una comunicacionesteganografica. Por ejemplo, en el caso de tratarse de un contenido de formato PDF, el emi-sor del mismo puede tener la certeza de que el receptor sera capaz de interpretar el tipo decontenido a partir de la inspeccion de su contenido y decidir no colocar el encabezado Content-Type55. Para evitar el uso de esta tecnica esteganografica, un guardian activo debe colocar eseencabezado en todos los mensajes que no lo contengan.

Nombres de producto El valor del nombre del producto (product token) permite a las apli-caciones comunicar entre sı el nombre del software y su version. La sintaxis de este parametroes de la forma: product = token ["/" product-version]

El parametro permite un valor de sub-producto en caso que este forme parte significati-va del producto. El valor del sub-producto se coloca separado por un espacio en blanco, acontinuacion del nombre principal. Se puede colocar mas de un valor de sub-producto y, porconvencion, los mismos se escriben en orden de importancia en la identificacion de la aplica-cion. La especificacion aclara que el contenido del parametro debe ser corto y conciso y nodebe ser utilizado para transmitir publicidad u otro tipo de informacion no esencial. Dentro dela version (product-version) se admite cualquier contenido, pero el mismo debe utilizarse paradiferenciar versiones sucesivas del mismo producto.

Este parametro se utiliza en los campos User-Agent, para identificar el nombre del cliente,y Server para identificar el nombre del servidor.

El sitio http://www.useragentstring.com/ recopila una lista de valores de este parametroutilizados por diferentes versiones de clientes HTTP en el campo User-Agent56.

A continuacion se muestra el valor del campo User-Agent obtenido a partir de una capturadel trafico de red con Wireshark y el uso de Mozilla Firefox en el sistema operativo GNU/Linuxdistribucion Kubuntu 10.10. Notese que al ser una version del sistema operativo compiladaespecıficamente por la distribucion, tiene colocado el nombre del mismo dentro del contenidodel campo, con comentarios adicionales entre parentesis.

55En el ejemplo mencionado, los archivos de formato PDF contienen en su primera lınea una cadena decaracteres que indica el formato del archivo y la version del mismo. Para el caso de la version 1.4, esta cadenaes: %PDF-1.4 [Ado01]. El analisis de esa primera lınea le permite a un cliente HTTP determinar el tipo decontenido.

56La lista de valores se encuentra separada por producto en la pagina:http://www.useragentstring.com/pages/useragentstring.php



User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; es-AR; rv:1.9.2.13)

Gecko/20101206 Ubuntu/10.10 (maverick) Firefox/3.6.13

Como ejemplo del campo Server del servidor HTTP que se encuentra en el sitio web de ladistribucion Ubuntu57, se obtiene:

Server: Apache/2.2.14

Dentro de la seccion de consideraciones de seguridad de la especificacion del protocolo,se advierte que los valores de los campos User-Agent y Server pueden ser explotados por unenemigo para determinar si un cliente o servidor particular posee un agujero de seguridadconocido por tratarse de alguna version particular y aclara que esta informacion puede serutilizada para propositos para los cuales no fue pensada.

El campo User-Agent se usa principalmente con fines estadısticos y para ayudar a mantenercompatibilidad de las paginas web en formato HTML con respecto a varios browsers[Bob03].

Dado que no existen restricciones sobre el contenido de este parametro, el mismo puedeser utilizado para realizar una comunicacion esteganografica a partir de la modificacion delexistente en un mensaje HTTP. Esta modificacion puede ser libre (i.e. se puede escribir cual-quier texto) o puede realizarse de acuerdo a ciertas opciones, por ejemplo, se puede elegir unvalor dentro de los presentes en el sitio http://www.useragentstring.com/. Incluso, se puedenaplicar pequenas modificaciones que no alteren la semantica del valor original, por ejemplo,como realiza la distribucion Kubuntu, que agrega la identificacion del sistema operativo perono modifica el nombre del producto, ni su version. Un guardian activo debe aplicar, por suparte, modificaciones al contenido de este parametro que impidan que el mismo sea utilizadoen el marco de la comunicacion esteganografica. Por ejemplo, puede reemplazar el valor porotro perteneciente a la lista del sitio mencionado, que guarde equivalencia con el original.

Valores de Calidad HTTP utiliza parametros de calidad para indicar la importancia re-lativa (o peso) de diferentes opciones en la negociacion de parametros. El valor de peso esnormalizado como valor real entre 0 y 1, donde 0 representa el mınimo y 1 el maximo. Si unparametro tiene un valor de calidad igual a 0, indica que ese valor del campo es inaceptablepara el cliente. El valor de calidad puede tener tres dıgitos decimales como maximo. La sintaxisde este parametro (denominado qvalue) se muestra a continuacion:

qvalue = ( "0" [ "." 0*3DIGIT ] )

| ( "1" [ "." 0*3("0") ] )

Esta sintaxis muestra que los ceros finales son opcionales. Esto permite aplicarlo en elmarco de una comunicacion esteganografica, donde la cantidad de ceros innecesarios que sonexplıcitamente colocados sea interpretada como un mensaje. Por ejemplo, puede colocarse1 o 1.000 con equivalencia en la comunicacion genuina. Un guardian activo debe modificaraleatoriamente la cantidad de dichos ceros innecesarios. Puede agregar o quitarlos, de modoque esta caracterıstica no pueda ser empleada para la comunicacion esteganografica.

Etiquetas de idioma Las etiquetas de idioma representan el idioma natural hablado, es-crito o preferido por los seres humanos para sus comunicaciones a traves del protocolo. Esteparametro se utiliza en los campos Accept-Language, para indicar los idiomas aceptados, yContent-Language, para indicar el idioma en el que se encuentra el contenido del cuerpo delmensaje.

57http://www.ubuntu.com/



La sintaxis de las etiquetas de idioma esta definida en la RFC 176658. Consiste en una o maspartes separadas por el caracter “-”. La primera parte es la etiqueta primaria del idioma. Cadaparte esta compuesta por un codigo de uno a ocho caracteres alfanumericos y son interpretadosde forma insensible a mayusculas (lo cual permite, la aplicacion de esteganografıa en la variacionde las mayusculas, como se ha ejemplificado anteriormente). No se permite espacios en blanco eneste parametro. La etiqueta principal, compuesta de dos letras, corresponde a las abreviaturasde idioma definidas en el estandar ISO-639. La etiqueta secundaria, escrita en forma de dosletras, corresponde al codigo de paıs como esta definido en el estandar ISO-3166. Si el servidorno dispone de una version del contenido que coincida con el idioma definido en la sub-etiquetade idioma, debe responder con el idioma similar que disponga, o con el correspondiente a laetiqueta principal.

En este parametro, la modificacion del contenido puede devenir en una modificacion dela semantica, puesto que si se modifica el contenido del campo Accept-Language, el servidorrespondera, en caso de tener disponible, con una version del contenido en el idioma preferidoindicado en ese campo. Es posible realizar ciertas modificaciones en la primera sub-etiqueta queresulten en un valor equivalente al de la etiqueta original. Por ejemplo, se podrıa modificar elvalor ES-AR (que corresponde a espanol de Argentina) por ES-UY (que corresponde a espanol deUruguay). En este caso, puede considerarse que las respuestas del servidor seran equivalentes.Un guardian activo debe evitar la aplicacion de esta tecnica y modificar, en consecuencia,el valor de este parametro. Por ejemplo, puede quitar el valor de la sub-etiqueta y dejarunicamente el de la etiqueta principal, aunque esto resulte en una alteracion de la comunicaciongenuina (generalmente imperceptible).

Etiquetas de Entidad Las Etiquetas de Entidad se utilizan para comparar dos o masetiquetas del mismo recurso pedido. Este parametro se utiliza en los campos del encabezadoETag, If-Match, If-None-Match e If-Range.

Este parametro se compone de un indicador opcional de debilidad de comparacion, repre-sentado por: W/ y a continuacion una cadena de caracteres opaca. Por ejemplo: W/123456789o 123456789.

La etiqueta de entidad fuerte puede ser compartida entre dos recursos solo si estos sonequivalentes, octeto por octeto. Mientras que la etiqueta de entidad debil (representada porel prefijo “W/”) puede ser compartida por dos recursos solo si son equivalentes y pueden sersustituidos entre sı sin cambios significativos de semantica.

Dado que las etiquetas de entidad son valores que representan al recurso solicitado, tienenlas propiedades de los identificadores (i.e. no deben colisionar con las entidades de otros recur-sos). En consecuencia, se puede aplicar la misma tecnica desarrollada para el caso del campoID del datagrama del protocolo IP. La funcion esteganografica que embebe un mensaje puedemodificar el valor de la etiqueta de entidad recibida a partir, por ejemplo, de una funcionde generacion de hash, para generar un segunda etiqueta que representa un mensaje estega-nografico. Un guardian activo debe modificar el valor de la etiqueta de entidad con las mismasconsideraciones, es decir, no se debe repetir con valores de etiquetas de entidad diferentes (i.e.de otros recursos). Esto se puede lograr de la misma manera con una funcion de hash.

Rangos de Unidades El protocolo permite que el cliente solicite que solo una parte (unrango) del recurso solicitado sea incluido en la respuesta. Este parametro se utiliza en loscampos del encabezado Range y Content-Range. Un recurso puede ser fraccionado en subrangos

58Alvestrand, H., “Tags for the Identification of Languages” RFC 1766, March 1995.http://www.ietf.org/rfc/rfc1766.txt



de acuerdo a diferentes unidades. La unica unidad definida en el protocolo es el byte. Lasimplementaciones pueden ignorar los rangos definidos en otras unidades diferentes al byte.

2.3.4. Metodos de pedido

En la presente seccion se describe cada uno de los metodos de pedido definidos en la espe-cificacion. Asimismo, la especificacion establece que la lista de metodos puede ser extendida.Para evitar que esta caracterıstica se use con el objetivo de una comunicacion esteganografica,un guardian activo debe bloquear los mensajes de pedido que contengan un metodo no definidoen la especificacion en estudio.

Los metodos GET y HEAD no deben tener otro significado mas que la recuperacion de infor-macion. Por ello, son denominados metodos seguros. Aunque en el servidor se realicen accionescolaterales, el cliente invoca este metodo sin conocimiento de esos posibles efectos. Esto per-mite que otros metodos (POST, PUT y DELETE) puedan producen acciones inseguras a partir desu invocacion en mensajes de pedido.

Lo metodos pueden ser idempotentes, esto es, cuando los efectos colaterales de la invocacionde una o mas veces el mismo metodo son equivalentes a los producidos por la invocacion deese metodo una unica vez. Los metodos GET, HEAD, PUT y DELETE poseen esta propiedad,mientras que los metodos OPTIONS y TRACE no poseen efectos colaterales, por lo tanto, soninherentemente idempotentes. Cabe mencionar que una secuencia de metodos idempotentespuede dar como resultado que el conjunto de metodos aplicado no sea idempotente. Esto seproduce en el caso en que un resultado depende de un valor que fue modificado en la mismasecuencia de metodos.

La propiedad de idempotencia de los metodos puede ser aprovechada para realizar unacomunicacion esteganografica, no en la forma de modificacion de portadores, sino como sıntesisde los mismos (i.e. el envıo repetitivo de mensajes de pedido, que actuan como portadores).Por ejemplo, una funcion esteganografica Emb que actua en un proxy transparente y recibe unmensaje de pedido con el metodo DELETE (que pretende la eliminacion en el servidor de destinodel recurso identificado), puede enviar repetidamente el mensaje dos o mas veces. En este caso,la cantidad de veces que se ha enviado el mismo mensaje de pedido constituye un mensajeesteganografico para la funcion Ext. Esta funcion puede eliminar los mensajes repetitivos (dadasu caracterıstica de idempotencia) o reenviarlos al servidor final como cualquier otro mensaje,dado que no tendra otro efecto diferente que el haber enviado un solo mensaje. Para evitaresta practica esteganografica, un guardian activo situado en el camino entre estas dos funcionesesteganograficas, debe tomar esas consideraciones y eliminar los mensajes repetitivos con losmetodos idempotentes.

La especificacion establece que los mensajes de pedido se pueden enviar en secuencia con-junta59, es decir, se envıan varios pedidos sin esperar las respuesta, y aclara que esto no deberealizarse para metodos no idempotentes.

OPTIONS El metodo OPTIONS permite al cliente obtener informacion sobre los requeri-mientos y acciones asociadas al recurso identificado por la URI de pedido, sin que este pedidoimplique la ejecucion de acciones sobre el mismo ni la recuperacion de informacion. Si la URIde pedido es un asterisco (“*”), el mensaje de pedido actua sobre el servidor en general. Elobjetivo de este tipo de pedido es similar al de un mensaje ICMP mencionado anteriormente,ademas permite solicitar la descripcion de las capacidades del servidor. Dado que a partir dela comunicacion de este tipo de mensajes HTTP es posible realizar una comunicacion estega-nografica, un guardian activo debe bloquear estos mensajes, que si bien limitan la funcionalidad

59en ingles se utiliza el termino pipeline



del protocolo, no constituye una comunicacion de contenidos propiamente dicha.La especificacion permite que los mensajes de pedido con este metodo incluyan un cuerpo

de entidad, pero no define un uso de ese cuerpo. El objetivo es permitir, en futuras extensionesdel protocolo, realizar pedidos de informacion al servidor mas detallados. Un servidor que nointerprete esas extensiones puede descartar el cuerpo del mensaje. En este sentido, la posibilidadde incorporar un cuerpo de mensaje a un mensaje de pedido con el metodo OPTIONS puedeser aprovechado para realizar una comunicacion esteganografica y debe ser bloqueado por unguardian activo (i.e. quitar el cuerpo al reenviar el mensaje de pedido).

Las respuestas de tipo 200 OK deben indicar las funcionalidades opcionales implementadaspor el servidor y que son aplicables al recurso solicitado, las cuales incluyen posibles extensionesa la especificacion. Como se ha mencionado anteriormente, un guardian activo debe eliminarla mencion a campos extendidos de la especificacion. Adicionalmente, el mensaje de respuestapuede incluir un cuerpo opcional, que contenga informacion opcional sobre las opciones de lacomunicacion. La especificacion no define el formato de ese cuerpo de mensaje y deja abiertala posibilidad a que el mismo sea definido en futuras extensiones del protocolo. Es por esto queun guardian activo debe quitar el cuerpo del mensaje de respuesta, a fines de evitar su empleoen comunicaciones esteganograficas.

GET El metodo GET pide al servidor la informacion referenciada por la URI del pedido.Esta informacion puede ser un recurso existente en el servidor (i.e. un archivo almacenado) oel resultado de un procesamiento que se realice con la interpretacion del mensaje.

El metodo puede ser de ejecucion condicional si el encabezado del mensaje de pedidocontiene algun campo de verificacion de condicion: If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match o If-Range. Esto permite reducir el trafico en la red, a partir de evitartransferir contenido que el cliente posee o que fueron colocados en cache. Asimismo, el metodoGET puede tener la semantica de pedido parcial, si se incluye el encabezado Range, el cualpermite obtener porciones de recursos.

HEAD El metodo HEAD es identico a GET, salvo que el servidor no debe incluir el cuerpo delrecurso en el mensaje de respuesta. Solo se coloca la metadata en los campos del encabezadodel mensaje de respuesta, que debe ser identica a la que se colocarıa en respuesta al mismomensaje de pedido con el metodo GET. Se utiliza principalmente para verificar la existencia derecursos referidos por links (enlaces) de otros recursos.

POST El metodo POST se utiliza para que el servidor reciba un contenido (que se envıa enel cuerpo del mensaje de pedido) como subordinado del recurso referido en la URI de pedido.La forma de procesar el contenido enviado esta determinada por el recurso referenciado en laURI de pedido. Este metodo se utiliza principalmente para enviar al servidor bloques de datosque generalmente provienen del llenado de un formulario.

La respuesta al metodo POST puede no generar un recurso nuevo, en cuyo caso el servidorresponde el mensaje con el codigo de estado 200 (OK ) o 204 (No Content). En caso de que secree un nuevo recurso, la respuesta incluye el estado 201 (Created).

PUT El metodo PUT le pide al servidor que almacene el contenido del mensaje de pedido enun recurso indicado en la URI de pedido. Si el recurso identificado por esa URI ya existe, seconsidera que el mensaje consiste en una nueva version del mismo, y debe ser reemplazado. Eneste caso, el servidor responde con un mensaje de estado 200 (OK ) o 204 (No Content). En casocontrario, si la URI referencia a un recurso valido, el servidor puede crear el mismo y almacenarel contenido. En este caso, el servidor responde con un mensaje de estado 201 (Created). En



caso de no poder crear o modificar el recurso solicitado, el servidor debe responder con unmensaje de error apropiado (codigo de estado 5xx ). El servidor puede decidir que el recursosolicitado debe colocarse en otra direccion, para ello, le informa al cliente con un mensaje depedido de estado 301 (Moved Permanently).

La especificacion deja libertad con respecto a como el metodo PUT afecta el estado delservidor.

DELETE El metodo DELETE le pide al servidor que elimine el recurso identificado por la URIde pedido. Este metodo puede ser anulado en el servidor. El cliente no puede asegurar que, auncuando se haya recibido un codigo de respuesta de exito, se haya ejecutado satisfactoriamentela accion solicitada. El servidor debe responder con codigo de estado 200 (OK ) si la respuestaincluye una entidad que describa el estado, 204 (No Content) en caso de que la respuestano incluya contenido o 202 (Accepted) si la accion no fue realizada al momento de enviar larespuesta.

TRACE El metodo TRACE se usa para invocar una operacion de respuesta que copie el mismomensaje de pedido. El mensaje de pedido no debe incluir un contenido. El mensaje de respuestase envıa con el codigo de estado 200 (OK ) y en el cuerpo del mismo se coloca el mensaje depedido completo. En el campo Content-Type se coloca el valor message/http.

Este metodo se utiliza para diagnosticar que recibe un servidor o un proxy, luego de unacadena de reenvıos intermedios del mensaje. El campo Max-Forwards permite indicar la can-tidad de saltos que debe dar el mensaje (i.e. la cantidad de reenvıos). Cuando este campollega a 0, debe ser respondido por quien lo procesa (que puede ser el servidor final o un proxyintermedio).

Un guardian activo debe bloquear los mensajes de pedido de metodo TRACE que contengancontenido, para evitar que se propague una comunicacion esteganografica.

Dado que este tipo de mensaje tiene fines de diagnostico, es posible incluir encabezados enel mensaje de pedido (funcion esteganografica Emb) y quitar esos encabezados en el mensajede respuesta (funcion esteganografica Ext), que se encontraran en el cuerpo de ese mensaje.Este ejemplo es diferente a los ilustrados en la figura 1.2, puesto que la inclusion y extraccionse realizan en el camino de ida y de regreso, respectivamente. De acuerdo con los nivelesde seguridad esteganografica deseados, es posible decidir que un guardian activo bloquee losmensajes de pedido de tipo TRACE, para evitar la utilizacion de los mismos en comunicacionesesteganograficas.

CONNECT Este metodo esta reservado para utilizar con un proxy que puede cambiardinamicamente a modo tunel60.

La especificacion en estudio no lo describe (solo lo menciona), por lo que se deja fuera delalcance del presente trabajo.

En general, este metodo se encuentra bloqueado en la mayorıa de los proxys publicos ycorporativos[AD03].

2.3.5. Codigos de respuesta

En la presente seccion se detallan brevemente los codigos de estado de los mensajes derespuesta. Se comienza con la descripcion de cada uno de los tipos de mensaje, identificado

60El modo tunel permite encapsular mensajes de un protocolo dentro del area de datos del mensaje HTTP.El proxy que recibe este pedido actua como un mero reenvıo del mismo hacia el servidor al que esta dirigidoel mensaje, no interfiere con la comunicacion del protocolo encapsulado (i.e. el contenido encapsulado resultaopaco para el proxy)[Luo98].



por un numero y xx.

1xx Informacion

Este tipo de codigo representa respuestas provisionales. El mensaje incluye la lınea deestado, opcionalmente campos de encabezado, sin cuerpo de contenido.

El cliente debe estar preparado para aceptar una o mas respuestas de codigo 1xx antes derecibir la respuesta esperada a su mensaje de pedido. Los mensajes 1xx no esperados debenser ignorados por el cliente.

Esta caracterıstica de los mensajes de respuesta de estado 1xx permite aplicar una comu-nicacion esteganografica a partir de la sıntesis de mensajes de respuesta de codigo de estado1xx, luego de haber recibido un mensaje de pedido. Este tipo de comunicacion esteganograficano es por modificacion de portadores, sino por sıntesis. Para evitar la propagacion de estascomunicaciones, un guardian activo debe bloquear los mensajes de este tipo en respuesta aun mensaje de pedido genuino que no lo solicita explıcitamente (el cliente puede indicar en sumensaje de pedido que desea una respuesta de estado 100 Continue), o bien, generar nuevosmensajes de respuesta de codigo 1xx que no modifiquen la semantica de la comunicacion, sinoque agreguen ruido en la posible comunicacion esteganografica.

100 Continue El cliente debe continuar con su pedido. Se informa al cliente que el comienzode su pedido fue aceptado y si queda un remanente en el pedido del cliente, debe enviarlo. Si elpedido del cliente fue completamente enviado al momento de recibir este mensaje de respuesta,se debe ignorar este mensaje. El servidor debe comenzar a enviar su respuesta luego de que elcliente haya completado el envıo de su pedido.

Un uso genuino de este mensaje se plantea cuando el cliente envıa un mensaje de pedidocon un campo Expect con valor 100-continue para indicar al servidor que desea enviar el cuerpodel mensaje. El servidor puede responder con el codigo 100 (Continue) o con otro codigo definalizacion, si no aceptara el mensaje de pedido (en este caso, el servidor no debe ejecutar elmetodo del pedido).

Este tipo mensaje de respuesta es un ejemplo de los que pueden ser utilizados como sıntesisde portadores para generar una comunicacion esteganografica, mencionado en la descripcioninicial.

101 Switching Protocols El servidor entendio el mensaje de estado y desea cumplir elpedido a partir de una comunicacion en otra version del protocolo. Esto se realiza a partir dela inclusion del campo Upgrade dentro del mensaje de respuesta y debe ser aplicado solo enlos casos en los que resulte conveniente por algun motivo.

La especificacion no expresa que se debe realizar si en el campo Upgrade se coloca la mismaversion del mensaje actual. En consecuencia, un guardian activo debe bloquear los mensajescon ese valor en el campo Upgrade, para evitar usos esteganograficos.

2xx Exito

Este tipo de mensajes indica que el servidor recibio, interpreto y acepto correctamente elmensaje de pedido.

200 OK El pedido se completo con exito. La semantica de la respuesta depende del metododel mensaje de pedido:

GET: Se envıa el recurso solicitado.



HEAD: Se envıa los campos de encabezado correspondientes al recurso solicitado, como sise hubiera ejecutado el metodo GET, pero sin el cuerpo del mismo.

POST: Se envıa un cuerpo que describe el resultado de la accion.

TRACE: El cuerpo de la respuesta contiene el mensaje de pedido recibido por el servidor.

201 Created El pedido fue completado y como resultado se creo un nuevo recurso en elservidor. La ubicacion de ese recurso se puede retornar en el campo Location de la respuesta.El servidor debe crear el recurso antes de enviar este tipo de respuesta. En caso contrario, debeenviar un mensaje de estado 202 (Accepted).

202 Accepted Se acepto el pedido para procesarlo, pero no se ha completado el procesa-miento al momento de enviar la respuesta. Esta respuesta no implica un compromiso por partedel servidor. El proposito es permitirle al servidor aceptar un pedido para un proceso poste-rior (e.g. un proceso por lote diario) que no requiera conexion con el cliente al momento decompletarlo.

203 Non-Authoritative Information La metainformacion (contenida en los campos de larespuesta) que se incluye en este mensaje no es definitiva, sino que puede ser un subconjuntoo un superconjunto de la version original.

204 No Content El servidor completo el pedido, pero no tiene un contenido para responder,sino que desea enviar la metainformacion del contenido, en forma de encabezados de entidad.Se utiliza para que el cliente no modifique el contenido que muestra, que genero el envıo delmensaje de pedido.

205 Reset Content El servidor completo el pedido, y el cliente debe reiniciar el contenidoque origino el envıo del mensaje de pedido. Este tipo de mensajes de respuesta no debe incluirun cuerpo de mensaje.

206 Partial Content El servidor completo el pedido de un mensaje de GET parcial sobreel recurso. El mensaje de pedido debe incluir el campo Range, que indica el rango deseado ypuede incluir un campo de pedido condicional If-Range. El servidor debe incluir los siguientescampos en la respuesta:

Content-Range: que indica el rango del recurso incluido en la respuesta.

Date.

ETag y/o Content-Location: si el encabezado se podrıa haber enviado en una respuestade codigo 200 (OK ) para el mismo mensaje de pedido.

Expires, Cache-Control y/o Vary : si el valor del campo difiere respecto del enviado parael mismo rango en una respuesta anterior.

3xx Redireccion

Este tipo de mensajes de respuesta indica que el cliente debe tomar una accion adicionalpara completar el pedido. El cliente debe detectar saltos de redireccion infinitos, para evitartrafico innecesario en la red.



300 Multiple Choices El recurso solicitado corresponde a una de un conjunto de represen-taciones, cada una con su ubicacion especıfica. El servidor le envıa esta respuesta al cliente paraque escoja la representacion preferida y redirija el pedido a esa. La respuesta incluye una listade ubicaciones y caracterısticas para que el cliente elija. Si el servidor posee una representacionpreferida, debe incluirla en el campo Location.

301 Moved Permanently El recurso referenciado en la URI de pedido fue cambiado dedireccion a una nueva URI, la cual debe ser utilizada en futuras referencias a ese recurso. Lanueva URI se indica en el campo Location de la respuesta. La especificacion establece que siel pedido fue un metodo diferente a HEAD, el mensaje de respuesta debe incluir un hipertexto(HTML) con el hiperlink a la nueva URI.

Un guardian activo debe asegurarse que el hipertexto contenido en el cuerpo de la respues-ta no sea utilizado como metodo de comunicacion esteganografica. Para ello, debe modificarel texto de ese mensaje, de modo de alterar la interpretacion de un posible extractor estega-nografico.

Dado que el hipertexto mencionado posee una estructura libre, las aplicaciones estega-nograficas que de el puede hacerse quedan fuera del protocolo HTTP y, por ende, del alcancedel presente trabajo.

302 Found El recurso solicitado se encuentra temporalmente en otra URI, pero el clientedebe utilizar la misma URI usada para futuros pedidos del mismo recurso. La URI temporaldebe ser indicada en el campo Location. Al igual que en la respuesta de tipo 301 (MovedPermanently), el mensaje debe contener un hipertexto con un hiperlink a la nueva URI. Delmismo modo, un guardian activo debe modificar ese hipertexto.

303 See Other La respuesta al pedido puede ser encontrada en otra URI y el cliente debeobtenerla a partir de un mensaje con el metodo GET a esa URI. La nueva URI no necesariamentesustituye la referenciada en el recurso pedido, esta direccion se coloca en el campo Location.Al igual que en los casos descriptos anteriormente, debe contener un cuerpo de hipertexto quecontenga un hiperlink a la nueva URI.

304 Not Modified Si el cliente envıa un pedido GET condicional a un recurso y el mismotiene permiso de acceso al recurso, pero el contenido del mismo no fue modificado, el servidordebe responder con este codigo de estado. La respuesta no debe contener un cuerpo y debecontener los siguientes campos de encabezado:

Date.

ETag y/o Content-Location.

Expires, Cache-Control y/o Vary si el contenido de estos campos varıa del enviado enuna respuesta previa sobre este recurso.

305 Use Proxy El recurso pedido debe ser accedido a traves de un proxy, que se indica enel campo Location, a traves de su URI. El cliente debe repetir el pedido a traves del proxyindicado.

306 (Unused) Este codigo fue definido en una version previa de la especificacion en estudioy no se utiliza mas. El codigo permanece reservado.

Un guardian activo debe bloquear los mensajes de respuesta de este tipo para evitar elposible uso en una comunicacion esteganografica.



307 Temporary Redirect El recurso solicitado reside temporalmente en una URI diferentea la solicitada en el mensaje de pedido. En futuras invocaciones al mismo recurso, el clientedebe volver a utilizar la misma URI de pedido que empleo en su mensaje original. La URItemporal se indica en el campo Location del encabezado. Al igual que en los casos mencionadosanteriormente, la respuesta debe incluir un hipertexto con un hiperlink a la URI referida, quedebe indicar al usuario del cliente la informacion necesaria para redirigir el pedido a la nuevaURI.

4xx Error del cliente

Se utiliza para los casos en los que se conoce que el cliente cometio un error. Excepto queel mensaje de pedido sea HEAD, el mensaje de respuesta debe incluir un cuerpo que indiqueuna explicacion del error y si el mismo es temporal o permanente. Estos mensajes de error sonaplicables a cualquier tipo de pedido. El cliente debe mostrar al usuario el contenido incluidoen el mensaje de respuesta.

400 Bad Request El mensaje de pedido no pudo ser interpretado por el servidor debidoa un error de sintaxis. Puede generarse este mensaje, tambien, si el largo del encabezado esmayor al aceptado por el servidor.

401 Unauthorized El pedido requiere autorizacion. El mensaje de respuesta debe incluirel campo de encabezado WWW-Authenticate que contiene un desafıo (challenge) aplicable alrecurso pedido. El cliente puede repetir el pedido con el correspondiente campo de encabezadoAuthorization. Si el pedido ya incluıa este campo, entonces el mensaje de respuesta con estecodigo indica que el servidor rechaza la autorizacion. El analisis del mecanismo de autorizacionqueda fuera del alcance del presente trabajo, puesto que el mismo no esta definido en laespecificacion.

402 Payment Required Este codigo esta reservado para usos futuros. Por lo tanto, debeser bloqueado por un guardian activo, con el fin de evitar practicas esteganograficas.

403 Forbidden El servidor interpreto el pedido, pero rechaza procesarlo, incluso con laaplicacion de un esquema de autorizacion. Si el pedido no fue HEAD y el servidor desea comunicarel motivo por el cual se rechaza procesarlo, puede incluir el texto con las razones en el cuerpodel mensaje. Si el servidor no desea revelar esta informacion, puede responder con un mensajede codigo 404 (Not Found).

Dado que no existe una semantica definida en la especificacion para el mensaje de res-puesta que contiene las razones del rechazo, es posible utilizar ese texto en el marco de unacomunicacion esteganografica (i.e. el texto puede ser interpretado de acuerdo a la convencionentre el emisor y receptor esteganograficos). En consecuencia, un guardian activo debe modi-ficar el texto o, incluso, quitar el texto del cuerpo del mensaje, para evitar el posible uso encomunicaciones esteganograficas.

404 Not Found El servidor no encontro un recurso en la ubicacion indicada por la URI depedido. No se da informacion sobre si esta condicion es temporal o permanente. Habitualmente,se utiliza este codigo de respuesta cuando el servidor no desea revelar el motivo por el cual serechaza el pedido o cuando no aplica otro tipo de respuesta.

Dado que la especificacion sugiere que los codigos 403 (Forbidden) y 404 (Not Found)pueden utilizarse indistintamente con el fin de no revelar informacion adicional al cliente,



el uso de los mismos podrıa ser intercambiado y, en consecuencia, aprovecharse para unainterpretacion esteganografica: si la respuesta corresponde a 403 (Forbidden) se le asigna unsignificado esteganografico y si corresponde a 404 (Not Found), uno diferente.

Un guardian activo debe modificar aleatoriamente estos dos codigos en los mensajes derespuesta para evitar su utilizacion en el marco de una comunicacion esteganografica (e.g.colocar el codigo de respuesta 404 en ambos casos).

405 Method Not Allowed El metodo del mensaje de pedido no esta permitido para elrecurso indicado en la URI del pedido. La respuesta debe incluir el campo Allow con la listade metodos permitidos para ese recurso.

406 Not Acceptable El recurso identificado en la URI del pedido solo puede generar en-tidades que poseen caracterısticas de contenido que no figuran en la lista de las aceptablesenviadas por el cliente en su mensaje.

A menos que se trate del metodo HEAD, la respuesta debe contener un cuerpo con la lista decaracterısticas de entidades disponibles para que el cliente escoja la mas apropiada. El formatoesta especificado en el campo Content-Type del encabezado.

407 Proxy Authentication Required Es similar al codigo 401 (Unauthorized), peroel cliente debe autenticarse frente al proxy. El proxy debe responder con el campo Proxy-Authenticate que contiene el desafıo (challenge) aplicable al recurso solicitado.

408 Request Timeout El cliente no envio un pedido en el tiempo en que el servidor estabapreparado para esperar.

409 Conflict El pedido no se pudo completar debido a un conflicto con el estado del re-curso. El cuerpo de la respuesta debe incluir suficiente informacion para que el usuario puedaidentificar la raız del conflicto y resolverlo. Los conflictos ocurren en general frente al metodoPUT, dado que puede ser invocado concurrentemente por dos clientes.

Al igual que en los casos anteriores, el contenido de texto de este tipo de respuesta puedeser utilizado para realizar una comunicacion esteganografica, y la especificacion no determinaun formato para este contenido. En consecuencia, debe ser modificado por un guardian activo.

410 Gone El recurso pedido no esta disponible mas en el servidor y no se posee informacionacerca de una direccion de redireccion. Esta condicion se considera permanente. Si el servidorno desea proveer esta informacion, puede responder con un mensaje 404 (Not Found).

Al igual que se menciono al describir el codigo 404 (Not Found), al permitirse el usoindistinto, puede ser empleado como tecnica esteganografica. Un guardian activo debe modificarlos mensajes de respuesta de estos tipos de codigo, por ejemplo, modificar todos para quecontenga el codigo 404 (Not Found). Estas aplicaciones esteganograficas limitan la informacionque el servidor envıa al cliente.

411 Length Required El servidor no acepta el pedido si no incluye el campo Content-Length que contenga el largo del cuerpo del mensaje de pedido.

412 Precondition Failed La precondicion evaluada en alguno de los campos del encabezadodio resultado falso al ser evaluada en el servidor.



413 Request Entity Too Large El servidor rechaza procesar el pedido porque posee unaentidad mas larga de la que este puede o espera procesar. Si este problema es temporario, sedebe incluir el campo Retry-After que le indique al cliente cuando puede reintentar.

414 Request URI Too Long El servidor rechaza procesar el pedido debido a que la URIdel mismo es mas larga de lo que el servidor espera interpretar. En general se produce porexceso de parametros en la URI del pedido.

415 Unsupported Media Type El servidor rechaza procesar el pedido debido a que elformato de la entidad del mensaje de pedido no esta soportado por el recurso de la URI depedido.

416 Requested Range Not Satisfable El pedido incluye un campo Range en el encabe-zado cuyo valor no es compatible con la longitud del recurso de la URI de pedido y el mensajede pedido no incluye el campo If-Range (i.e. el rango en bytes es superior a la longitud delrecurso). La respuesta debe incluir el campo Content-Range con la longitud del recurso.

417 Expectation Failed El valor del campo Expect no se pudo interpretar. Esto se debe aque la implementacion del servidor no conoce el contenido de ese campo.

5xx Error del servidor

Este tipo de mensajes indica que el servidor no puede completar el pedido. Excepto si setrata de un mensaje de pedido de tipo HEAD, se debe incluir un texto que explique el motivodel error que indique si la condicion es temporal o permanente. Como se ha mencionado en loscasos anteriores, no hay una sintaxis definida para este texto y, en consecuencia, el mismo debeser modificado por un guardian activo para evitar su uso en una comunicacion esteganografica.

La RFC 3205, citada anteriormente, especifica que no se deben utilizar los codigos derespuesta de HTTP para transmitir un mensaje de un protocolo que se sustenta sobre el y queese protocolo no debe definir nuevos codigos de error. La razon es que el cliente y el servidorpueden estar conectados a traves de varios proxys o caches intermediarios. Estos intermediariospueden usar el codigo de respuesta del mensaje HTTP para tomar alguna accion adicional. Porejemplo, un cache que recibe una respuesta 200 (OK ) puede agregar la entrada al cache parareutilizarla en respuestas futuras.

Bajo estas consideraciones, una aplicacion esteganografica, que si bien no utiliza HTTPcomo sustrato, no debe modificar el codigo de respuesta del mensaje HTTP, para evitar alterarla comunicacion genuina (salvo en los casos mencionados de similitud semantica: e.g. codigode repuesta 404 por 403, donde la especificacion da la opcion al servidor de emitir uno u otrocodigo de acuerdo a su polıtica de confidencialidad).

500 Internal Server Error El servidor encontro una situacion inesperada que no le permitecompletar el pedido.

501 Not Implemented El servidor no soporta la funcionalidad contemplada en el pedido(no tiene implementado el metodo del mensaje de pedido).

502 Bad Gateway El servidor, mientras actua como gateway o proxy, recibio una respuestainvalida desde el servidor siguiente que accedio para responder el pedido.



503 Service Unavailable El servidor no puede procesar el pedido debido a una sobrecargatemporal o a cuestiones de mantenimiento. El servidor puede incluir en el mensaje de respuestael campo Retry-After, para indicar al cliente cuando podra reintentar con su pedido.

504 Gateway Timeout El servidor, mientras actua como gateway o proxy, no recibio unarespuesta valida desde el servidor especificado en la URI en un tiempo determinado.

505 HTTP Version Not Supported El servidor no soporta, o rechaza soportar la versiondel protocolo HTTP utilizada en el mensaje de pedido. El mensaje de respuesta debe conteneruna entidad que indique por que esa version no esta soportada y que otros protocolos sonsoportados por el servidor.

2.3.6. Campos del encabezado

En la presente seccion se describen cada uno de los campos de encabezado estandar quedefine la especificacion del protocolo. Cabe mencionar que existen campos adicionales definidosen otras RFCs, posteriores a la publicacion de la RFC en estudio, quedando fuera del alcancedel presente trabajo por no pertenecer a la misma61. Entre ellos, se destacan los campos quepermiten la comunicacion de informacion de estado entre mensajes (denominada Cookie)62.

Accept El campo Accept del encabezado del mensaje de pedido se utiliza para indicar lostipos de contenido que son aceptables en la respuesta. Consiste en una lista separada por comas,donde cada elemento de la lista esta compuesto por el tipo de contenido como se describio enel apartado Tipos de Media de la seccion 2.3.3, seguido de parametros que lo modifican, entreellos, el valor de calidad en la aceptacion de ese tipo de contenido (si no se coloca el valor decalidad, se asume 1). Si no se emite el campo Accept, se asume que el cliente puede interpretarcualquier tipo de contenido. Si se emite el campo Accept y el servidor no puede responder concontenido que figure dentro de los aceptables, entonces debe emitir un mensaje de respuestade codigo 406 (Not Acceptable).

Si se coloca */* como tipo de media (de la forma tipo/subtipo), se refiere a todos los tiposy subtipos, y se puede establecer parametros generales.

Si se coloca en el valor del campo Accept el contenido */*, resulta equivalente a no colocarel campo. Por lo tanto, este contenido puede ser utilizado en el marco de una comunicacionesteganografica. Un guardian activo debe eliminar los campos Accept que incluyan solo estevalor, para evitar la propagacion de esas posibles comunicaciones. Lo mismo ocurre cuando secoloca explıcitamente el valor de q=1 como modificador del tipo de contenido, al ser opcional,debe ser eliminado por un guardian activo.

De forma analoga a la aplicacion esteganografica de tipo LSB (Least significant bit) men-cionada para el caso de la modificacion de las marcas de tiempo del datagrama IP, se puedealterar el valor de q (valor de calidad) de manera que no produzca cambios perceptibles en lasemantica del mensaje. Por ejemplo, si se tiene:

Accept: text/plain; q=0.5, text/html

61Para mas informacion, la RFC 4229: HTTP Header Field Registrations, M. Nottingham, J. Mogul (HP Labs).December 2005. http://www.ietf.org/rfc/rfc4229.txt, contiene un listado actualizado de campos de encabezadode HTTP registrados.

62La administracion de Cookies esta descripta en la RFC 2965: HTTP State Management Mecha-nism, D. Kristol (Bell Laboratories, Lucent Technologies), L. Montulli (Epinions.com, Inc.), October 2000.http://www.ietf.org/rfc/rfc2965.txt



significa que el cliente prefiere recibir el contenido en forma de texto HTML (al no haber unmodificador q se interpreta que su valor es 1), si el servidor no posee una version del recursoen ese formato, la puede enviar en texto plano (text/plain), con un grado de aceptacion del50 % por parte del cliente.

Este mismo campo, sin una modificacion semantica practicamente perceptible, puede en-viarse como:

Accept: text/plain; q=0.499, text/html

donde en lugar de q=0.5 se coloco q=0.499. En este caso, el valor del parametro de calidad,puede ser utilizado para transmitir un mensaje esteganografico y debe ser modificado (nue-vamente, de forma imperceptible y aleatoria) por un guardian activo. Por ejemplo, se puedemodificar a q=0.502.

Accept-Charset Este campo se utiliza en los mensajes de pedido para indicar al servidorque tipos de conjuntos de caracteres son aceptados por el cliente. El contenido del campotiene una estructura similar a la del campo Accept : consiste en una lista separada por comasde conjuntos de caracteres, cada uno con su valor de calidad, opcional. Si este campo noesta presente en el mensaje de pedido, se interpreta que cualquier conjunto de caracteres esigualmente aceptable.

El conjunto de caracteres ISO-8859-1 recibe un valor de q=1 si no se lo menciona explıcita-mente en la lista, por lo tanto, colocar ISO-8859-1; q=1 entre una lista de otros conjuntos decaracteres y no hacerlo tiene la misma semantica. En consecuencia, un guardian activo debequitar el contenido ISO-8859-1; q=1 cuando se encuentre dentro de una lista, para evitar quesu presencia (o ausencia) tenga un objetivo dentro de una comunicacion esteganografica.

Adicionalmente, caben las mismas consideraciones de aplicacion esteganografica sobre elparametro q descriptas para el campo Accept.

Accept-Encoding Este campo es similar a Accept. Restringe las codificaciones del contenidode la respuesta que son aceptadas por el cliente. De igual forma, si se coloca el caracter *

como contenido del campo, representa a todas las posibles codificaciones del contenido noexplıcitamente mencionadas.

La codificacion identity es siempre aceptable, a menos que se indique explıcitamenteidentity; q=0. Si no se emite el campo Accept-Encoding, el servidor puede asumir que seaceptan todas las codificaciones de caracteres y el servidor debe enviar el contenido con lacodificacion identity de forma preferida.

Las aplicaciones esteganograficas sobre este valor de campo fueron descriptas en el apartadoCodificacion del contenido de la seccion 2.3.3.

Accept-Language Este campo es similar a Accept. Restringe el conjunto de idiomas que espreferido en respuesta al pedido. El contenido de este campo consiste en una lista de codigosde idioma, cada uno acompanado opcionalmente por su valor de calidad. Si este campo noesta presente en el mensaje de pedido, el servidor debe asumir que todos los idiomas sonigualmente aceptables. Si esta presente, son aceptables todos los idiomas con valor de calidadq mayor a 0.

En este campo, son aplicables las propuestas sobre Etiquetas de idioma detalladas en la sec-cion 2.3.3. Asimismo, se puede aplicar las consideraciones esteganograficas sobre el parametrode calidad descriptas para los otros campos Accept.

Adicionalmente, cabe mencionar que la especificacion del protocolo no aclara que acciondebe tomarse en los casos de todos los campos Accept... descritos anteriormente cuando se



coloca un solo valor y se agrega un parametro q menor a 1. Puede suponerse que al aceptarseuna sola opcion el valor de q sea equivalente a 1, y de esa manera es equivalente a que elmodificador q no figure en el contenido del campo.

Accept-Ranges Este campo permite al servidor indicar su capacidad de aceptar pedidosde rangos para un recurso. Los valores posibles de este campo son none (cuando no se aceptael pedido de un recurso en rangos) o el nombre de la unidad que define rangos (por ejemplo:bytes). Los servidores no estan obligados a indicar esta funcionalidad. En cuyo caso, si elcliente envıa un mensaje de peticion de un rango que el servidor no acepta, el servidor deberesponder con el codigo de estado 406 (Not Acceptable).

Age Este campo del encabezado de respuesta transmite el tiempo estimado desde que fuegenerada la respuesta en el servidor de origen. El contenido del campo es una cantidad enteraque representa el tiempo medido en segundos. Una respuesta en cache es fresca si su edad noexcede el lımite de frescura. Este campo se debe emitir cuando la respuesta sea generada apartir del cache y su presencia indica que la respuesta fue obtenida del cache.

De la misma forma que para las marcas de tiempo del datagrama IP, es posible aplicaresteganografıa a partir de realizar modificaciones en los dıgitos menos significativos del con-tenido del campo Age. En consecuencia, un guardian activo debe modificar aleatoriamente elcontenido de ese campo. En general, es conveniente aumentar (en cantidades imperceptibles)el valor de este campo para adoptar una polıtica conservadora respecto del cache.

Allow Este campo permite listar el conjunto de metodos que es permitido aplicar sobreel recurso identificado por la URI de pedido. El contenido del campo consiste en la lista demetodos separados por comas, por ejemplo:

Allow: GET, HEAD, PUT

El listado de metodos aceptados para el recurso es definido por el servidor al momento degenerar la respuesta. Un proxy no debe modificar la lista de metodos de este campo, auncuando no entienda o no implemente alguno de ellos.

Authorization Este es un campo de pedido que contiene las credenciales con la informacionde autenticacion de un cliente que desea autenticarse con un servidor.

Cache-Control El campo Cache-Control permite, tanto al cliente cuanto al servidor, esta-blecer directivas a todos los mecanismos de cache que se encuentran en el camino del mensaje.El objetivo de las directivas es prevenir que el cache actue de forma adversa con los pedidos yrespuestas. Estas directivas tıpicamente sobrescriben las reglas generales de los algoritmos decache. Si hay conflicto entre reglas, se aplica la interpretacion mas restrictiva (i.e. la que masse aproxima a preservar la semantica).

A continuacion se detalla el mecanismo de cache de HTTP en relacion al interes de apli-cacion esteganografica, para pasar luego a la descripcion de las directivas del campo Cache-Control.

El cache tiene como objetivo mejorar el rendimiento (performance) en sistemas de infor-macion distribuida. El objetivo del cache en HTTP es en algunos casos eliminar la necesidadde enviar pedidos (para lo cual se emplea un mecanismo de expiracion) y, en otros casos, eli-minar la necesidad de enviar respuestas completas (para lo que se emplea un mecanismo devalidacion). Para ello, se almacenan respuestas a pedidos en un almacenamiento intermedio,denominado cache, que son utilizadas para posteriores pedidos sobre los mismos recursos. Para



permitir el uso de cache, la especificacion flexibiliza la transparencia semantica del protoco-lo: cuando el cliente o el servidor lo solicita explıcitamente o cuando se envıa un mensaje deadvertencia (warning) que indica al usuario que se ha relajado la transparencia semantica deoperacion sobre el recurso o servidor.

El cache puede ser compartido cuando se utiliza para enviar respuestas a varios usuarioso no-compartido cuando las entradas almacenadas se utilizan para dar respuesta a un solousuario.

El cache debe responder con la copia mas actualizada del recurso que posea almacenadacuando se cumpla alguna de las siguientes condiciones:

el cache ha verificado la equivalencia del contenido con el servidor de origen del recursoa partir de la revalidacion del mismo.

se trata de una copia fresca del recurso. Esto es, cumple al menos la directiva menosrestrictiva propuesta por el cliente, servidor y el cache (i.e. la entrada cumple con latransparencia semantica del protocolo).

se trata de una respuesta de codigo 304 (Not Modified), 305 (Proxy Redirect) o error (4xxo 5xx).

El cliente puede especificar la edad maxima de una respuesta no validada, si es cero, obligaal cache a revalidar todas las respuestas. Tambien puede especificar que desea obtener respues-tas obsoletas (hasta una edad maxima de obsolescencia), lo cual puede violar la polıtica detransparencia semantica propuesta por el servidor. El objetivo, en este caso, es aumentar ladisponibilidad en casos de conectividad pobre.

La expiracion puede estar controlada por el servidor. En primer lugar, el servidor puedeindicar una fecha de expiracion en el futuro, de modo de permitirle al cache entregar copiasen pedidos siguientes dentro de la fecha de vigencia, sin necesidad de contactar al servidor.El servidor espera que la semantica del recurso no cambie significativamente hasta la fecha deexpiracion. Si el servidor indica la fecha de expiracion explıcitamente en el pasado, fuerza alcache a que revalide el contenido en cada pedido. Dado que en este caso solo se interpreta quela fecha es en el pasado, pero no se toma en cuenta el valor exacto de la misma, es posiblemodificar el valor de la fecha del pasado por otro arbitrario (tambien en el pasado) con elobjetivo de emplearlo en el marco de una comunicacion esteganografica. El cuidado que debetener la funcion esteganografica Emb es sobre la sincronizacion de su reloj con el reloj delservidor: por un lado determinar que la fecha corresponde realmente al pasado y no se trata deuna desviacion en el propio reloj y por otra parte, al realizar la modificacion de la fecha, lograrque la fecha final sea realmente en el pasado. Esto asegura que no se modifica la semantica deeste contenido. Un guardian activo debe modificar la fecha en el pasado por otra, tambien en elpasado, para evitar que la misma sea utilizada en la comunicacion esteganografica. Asimismo,debe observar los mismos cuidados mencionados para la funcion Emb.

Cabe mencionar que la especificacion establece que los servidores de origen y los cachesdeben utilizar NTP63 o un protocolo de sincronizacion global de los relojes.

contra el servidor de origen (o un cache intermedio) para determinar si su entrada enve-jecida es todavıa utilizable. Para realizar las validaciones existen los metodos de pedido deejecucion condicional. Cuando el servidor de origen del recurso genera una version del mismo,le adjunta algunos validadores que son almacenados en el cache junto con el contenido delmismo. Cuando un cliente ejecuta un metodo condicional, indica los validadores que debe uti-lizarse. El cache compara el validador del mensaje de pedido contra el validador de la entrada

63Mills, D., “Network Time Protocol (Version 3) Specification, Implementation and Analysis”, RFC 1305,March 1992.



del cache almacenado. Si la comparacion resulta verdadera, responde con un mensaje de codi-go 304 (Not Modified) y no envıa el contenido del recurso en el mensaje de respuesta (solo elencabezado). El campo ETag provee una etiqueta de entidad que actua como validador opaco.Un validador es considerado fuerte cuando cambia su valor cada vez que cambie el contenidodel recurso (un validador fuerte puede ser, por ejemplo, la cantidad de modificaciones del re-curso). Un validador se denomina debil si no siempre cambia cuando se modifica el recurso (unvalidador debil puede ser el dıa de modificacion del recurso: puede haber varias modificacionesdel recurso en el mismo dıa). El soporte para validadores debiles es opcional. El cliente puedeutilizar validadores debiles solo para solicitar (metodo GET) recursos completos.

A menos que se impida con una directiva especıfica, los caches intermedios deben almacenarsiempre las respuestas exitosas en su tabla de cache y pueden enviarlas como respuesta sinvalidacion si la entrada es fresca. Cuando un cache recibe una respuesta del servidor de origenque indica que el contenido no fue modificado, i.e. con codigo de estado 304 (Not Modified),los encabezados recibidos en la respuesta sobrescriben a todos los almacenados en la entradadel cache.

Las directivas del campo Cache-Control deben ser reenviadas a traves de las aplicacionesde proxys y gateways, independientemente de si son capaces de interpretarlas, dado que lasmismas son aplicables para todos los participantes en el camino del mensaje. No es posibleindicar directivas a un cache especıfico.

La sintaxis del campo Cache-Control consiste en una lista formada por una o mas directivas,que pueden contener opcionalmente parametros. Cuando una directiva no contiene parametros,aplica al mensaje completo, en caso contrario, aplica a un conjunto de campos indicado. Lasdirectivas pueden ser de pedidos al cache o directivas de respuestas del cache. Las directivas delcache son: max-stale, min-fresh, only-if-cached, public, private, no-cache, no-store,no-transform, must-revalidate, proxy-revalidate, max-age y s-maxage. Tambien, se per-mite extender estos campos con nuevas directivas. El cache debe ignorar las extensiones queno reconoce.

Para evitar un uso esteganografico de las directivas no estandar (i.e. extensiones), un guar-dian activo debe bloquearlas, es decir, quitarlas de este campo.

A continuacion se detalla cada una de las directivas. Las siguientes son las directivas queafectan que mensajes se puede almacenar:

public: indica que la respuesta puede ser almacenada en cache compartido.

private: indica que la respuesta, o parte de ella, esta destinada a un usuario en particulary no debe almacenarse en un cache compartido, pudiendo almacenarse en un cache no-compartido.

no-cache: indica que el cache no puede utilizar la respuesta para un pedido futurosin antes revalidarla contra el servidor de origen. Esta directiva puede contener, comoparametro, nombres de campos. En este caso, el cache puede utilizar la respuesta para unpedido futuro, pero no puede enviar esos campos sin antes revalidarlos frente al servidorde origen.

La especificacion no establece restricciones sobre los campos que pueden aparece en estadirectiva, por lo cual, es posible agregar campos que no aparezcan en el contenido delmensaje y utilizar esto como metodo de comunicacion esteganografica. Es por ello queun guardian activo debe eliminar de los parametros de esta directiva, los campos que noaparezcan en el mensaje.

Cuando esta directiva se coloca en un mensaje de pedido, el cliente indica que desearevalidar el contenido frente al servidor de origen, es decir, que no se utilice un cache pararesponder al pedido.



no-store: el objetivo es evitar el almacenamiento de informacion sensible. Puede serenviado tanto en los pedidos cuanto en las respuestas. En cualesquiera de los casos dondesea enviada, el cache no debe almacenar el mensaje de pedido ni de respuesta, ni partedel mismo.

El servidor puede indicar la fecha de expiracion de dos formas: con el campo Expires ycon la directiva max-age del campo Cache-Control. Si el mensaje incluye ambas formas deindicar la fecha de expiracion (i.e. incluye el campo Expires y la directiva max-age del campoCache-Control), se debe considerar solo la directiva max-age, independientemente del valorde ambas. Si el servidor no explicita una fecha de expiracion, el cache la puede determinar apartir de un algoritmo heurıstico. Una respuesta se considera envejecida si la edad actual esmayor a la edad asignada a la misma a traves de esta directiva.

La forma en la que se indica la fecha de expiracion puede ser utilizada como un mensajeen un comunicacion esteganografica, es decir se puede utilizar la directiva max-age, el campoExpires o, incluso, colocar ambos campos. Es por esto que un guardian activo debe normalizarla forma de escritura del mismo (i.e. optar por una de las formas en todos los casos). Adicional-mente, la especificacion establece que si se incluyen ambas representaciones simultaneamente(i.e. la directiva max-age en el campo Cache-Control y el campo Expires), tiene prioridad ladirectiva max-age.

Las directivas que afectan el mecanismo de expiracion y validacion son:

s-maxage: esta directiva puede ser utilizada en los mensajes de respuesta para indicar alcache compartido que la misma no puede ser utilizada luego del perıodo indicado en estasin antes revalidarla frente al servidor de origen (el valor de esta directiva sobrescribe elvalor de max-age y del campo Expires).

max-age: indica que el cliente puede aceptar una respuesta cuya edad no sea mayor altiempo indicado en la directiva (en segundos). Implica que la respuesta puede ser colocadaen cache (i.e. public), a menos que se indique otra cosa en otra directiva.

Si esta directiva se utiliza en un mensaje de pedido como max-age=0, se fuerza a cadacliente en el camino del mensaje a que revaliden su entrada del cache.

min-fresh: indica que el cliente puede aceptar una respuesta cuyo tiempo de frescura nosea menor que la edad actual mas el valor especificado en esta directiva.

max-stale: indica que el cliente puede aceptar una respuesta que esta excedida en sutiempo de expiracion. Si se coloca un parametro, indica que el cliente acepta una respuestaexcedida en no mas del tiempo enviado como parametro.

only-if-cached: indica al cache que entregue la respuesta que tiene almacenada en elcache, si cumple con las otras restricciones del pedido. En caso de no poder hacerlo, deberesponder con codigo de estado 504 (Gateway Timeout).

must-revalidate: la utiliza el servidor de origen para indicar al cache que debe revalidarla entrada del cache para utilizarla en el futuro en caso de que este envejecida por eltiempo de expiracion impuesto por el servidor. Esta directiva deja sin efecto a la directivamax-stale que puede enviar el cliente.

proxy-revalidate: tiene el mismo significado que must-revalidate, con la diferenciaque aplica solo para caches compartidos.

Por ultimo, la directiva no-transform indica a los proxys intermedios que no deben trans-formar el recurso en ningun aspecto, incluido el contenido y los encabezados.



Connection Este campo permite al emisor especificar las opciones deseadas para una cone-xion particular. No debe ser reenviado por un proxy. El valor close para este campo permiteal emisor indicar al receptor que la conexion sera cerrada luego de que se complete la respuesta.En este caso, debe considerarse que la conexion no debe ser persistente luego de completar elpedido y su respuesta. Si la implementacion no soporta conexiones persistentes, debe indicarel valor close en cada mensaje.

Content-Encoding Este campo se utiliza como modificador del tipo de contenido (Content-Type). Cuando este campo esta presente en el mensaje, indica que se aplicaron codificacionesadicionales al contenido del cuerpo del mensaje y que para decodificar el contenido debenaplicarse en el orden correcto para obtener el tipo de contenido indicado en el campo Content-Type. Se utiliza principalmente para indicar la compresion del contenido. Un proxy puedemodificar la codificacion para transformarlo en una nueva codificacion, al enviarlo al clienteque realizo el pedido.

Si el contenido se envıa en una codificacion diferente a identity, el servidor debe incluirlo,en caso contrario, es optativo incluir este campo. En consecuencia, un guardian activo debeeliminar la presencia de este campo en el mensaje de respuesta cuando el contenido del mismoes solo identity, de modo de evitar que la presencia de este campo con este contenido puedaser interpretada en el marco de una comunicacion esteganografica.

Si se aplican multiples codificaciones a un contenido, en este campo se debe colocar la listade codificaciones aplicadas en el orden en que se realizaron.

Se ejemplificaron otras formas de aplicacion esteganografica en el apartado Codificacion delcontenido de la seccion 2.3.3.

Content-Language Este campo describe el idioma de la entidad contenido. No necesaria-mente es equivalente a todos los idiomas utilizados en el cuerpo de entidad. Si no se especificaeste campo, se asume que el contenido esta destinado a cualquier audiencia. Esto puede ocurrircuando el emisor considere que no aplica a un idioma en particular, o cuando no se conoce elidioma real del contenido. En este campo puede listarse multiples idiomas si el contenido puedeestar destinado a multiples audiencias (puede estar representado en varios idiomas al mismotiempo). Este campo se puede aplicar a cualquier tipo de contenido, es decir, no se limita atextos.

En este campo, son aplicables las propuestas sobre Etiquetas de idioma detalladas en laseccion 2.3.3.

Content-Length Este campo indica el tamano del cuerpo de entidad expresado en un nume-ro decimal mayor a cero que corresponde a la cantidad de octetos enviados al receptor del men-saje o, en el caso de una respuesta al metodo HEAD, del contenido que se enviarıa si el metodofuese GET. Este campo debe enviarse cuando el largo del contenido pueda ser determinado antesde comenzar a enviar el mensaje de respuesta.

Content-Location Este campo puede ser usado para reemplazar la ubicacion provista en laURI del mensaje de pedido cuando el recurso puede ser accedido desde una ubicacion diferentea la URI de ese mensaje. Se utiliza principalmente cuando un recurso tiene multiples entidadesasociadas a el y existe una manera de acceder a cada una en forma individual. El contenidode este campo puede ser una URI absoluta o relativa (en cuyo caso se interpreta relativa a laURI de pedido).

La especificacion establece que el significado de este campo no esta definido para los metodosPUT y POST y que los servidores son libres de ignorarlos en esos casos. En consecuencia, un



guardian activo debe eliminar este campo en los mensajes de pedido y respuesta de estosmetodos.

Content-MD5 Este campo permite proveer el resumen MD5 (definido en la RFC 186464)del cuerpo entidad del mensaje con el fin de realizar comprobaciones de integridad del mismoante modificaciones accidentales en su transmision (la especificacion aclara que este campo nopermite una prueba contra un ataque malicioso). Este campo no lo deben generar los proxys ogateways intermedios, dado que el objetivo del mismo es una verificacion entre extremos, perosı pueden verificarlo.

Content-Range Este campo se envıa para indicar a que rango del total corresponde laporcion de contenido enviada en el cuerpo del mensaje. La sintaxis del contenido del campoes: bytes inicio-fin/largo total. Por ejemplo, para indicar los primeros 500 bytes de un largode 1234:

Content-Range: bytes 0-499/1234

Si no se conoce el largo total, o es complicado de determinar, en su lugar se emite un caracter“*”.

Si el valor final del rango es menor al valor inicial o si el largo total es menor al valorfinal del rango, se considera que el rango es invalido y el receptor del campo debe ignorarlo, yprocesar el mensaje como si no se hubiera enviado ese campo. En consecuencia, un guardianactivo debe quitar el campo que posea esta caracterıstica al momento de reenviar un mensaje,para evitar que sea utilizado en una comunicacion esteganografica.

Cuando el servidor envıa una respuesta de codigo 206 (Partial Content), debe incluir estecampo con el rango enviado.

Content-Type Este campo permite indicar el tipo de contenido de la entidad cuerpo enviadaen el mensaje (o en el caso de una respuesta al metodo HEAD, del contenido que se enviarıa siel metodo del pedido hubiera sido GET).

El contenido de este campo se ha detallado en el apartado Tipos de Media de la seccion2.3.3.

Date Este campo representa la fecha y hora en la que el mensaje fue originado. Este campodebe incluirse en todos los mensajes, excepto:

En caso que la respuesta tenga un codigo de estado 100 (Continue) o 101 (SwitchingProtocols), incluir este campo es optativo. Por lo tanto, un guardian activo debe quitarlode esos mensaje, para evitar que sea utilizado en una comunicacion esteganografica.

Si la respuesta lleva un codigo de error del servidor 500 (Internal Server Error) o 503(Service Unavailable) y es un problema para el servidor generar la fecha y hora.

Si el servidor no posee un reloj que le permita generar una aproximacion razonable de lahora.

El cliente debe enviar este campo solo en los casos en los que el mensaje contenga uncuerpo de contenido (mensajes PUT y POST) y aun en estos casos es opcional. Es por esto queun guardian activo debe quitar este campo de estos mensajes.

64The Content-MD5 Header Field. J. Myers (Carnegie Mellon), M. Rose (Dover Beach Consulting, Inc.).October 1995. http://www.ietf.org/rfc/rfc1864.txt



Como se ha mencionado en casos anteriores, el tiempo puede modificarse de forma queno altere la semantica del contenido, a partir de variar el dıgito menos significativo y utilizarese dıgito para construir un mensaje esteganografico. Por lo tanto, un guardian activo debemodificar el dıgito menos significativo, con el fin de evitar esta aplicacion esteganografica.

ETag Este campo de respuesta provee una forma de comparar contenidos de un mismorecurso (con el objetivo de determinar si coinciden). El valor de este campo corresponde a unaetiqueta de entidad. Por ejemplo:

ETag: "xxyyzz"

Expect Este campo de pedido permite indicar al cliente el comportamiento del servidor querequiere el cliente. Los valores posibles para este campo son: 100-continue u otro valor, nodefinido en la especificacion (denominado expectation-extension), que puede estar definido poruna clave (token) o una cadena de caracteres literal con parametros. Excepto para las cadenasde caracteres literales, las comparaciones de los valores de este campo se realizan de formainsensible a mayusculas.

Si el servidor no es capaz de interpretar o procesar el comportamiento solicitado por estecampo, debe responder con un mensaje de error con codigo de estado 417 (Expectation Failed)o con algun otro mensaje de error 4xx si ocurre algun otro problema con el pedido.

Al no haber una sintaxis definida para las extensiones a los valores de este campo (laespecificacion preve que haya extensiones en el futuro), se deja la posibilidad de una adaptaciondel protocolo para la comunicacion entre un cliente y un servidor en particular. Esta adaptacionpuede tener fines de comunicacion esteganografica, por lo tanto debe ser bloqueada por unguardian activo. El cual, debe eliminar el campo cuando encuentre en su contenido un valorno estandar.

Adicionalmente, un guardian activo debe modificar las mayusculas y minusculas del valor100-continue, para evitar que la representacion de las mismas pueda ser utilizada en el marcode una comunicacion esteganografica.

Expires Este campo permite indicar la fecha y hora a partir de la cual la respuesta esconsiderada obsoleta. El contenido de este campo es una fecha y hora tal como se detallo enel apartado Formato de Fecha y Hora de la seccion 2.3.3. Los valores invalidos o iguales a“0”, deben ser tratados como si correspondieran al pasado (i.e. ya expirado). La forma quetiene el servidor de marcar una respuesta como ya expirada, es enviar en el contenido delcampo Expires la misma fecha colocada en el contenido del campo Date de la respuesta. Paraindicar que una respuesta no expira, el servidor debe colocar en este campo una fecha de valoraproximadamente un ano posterior a la del momento de envıo de la respuesta. Los servidoresno deben enviar fechas de expiracion posteriores a un ano en el futuro.

Para este campo, caben las mismas consideraciones de aplicacion esteganografica descriptasen la seccion 2.3.3. Adicionalmente, dado que los valores invalidos son todos considerados comoen el pasado, un guardian activo debe modificar el valor de las fechas invalidas o en el pasado,para que no pueda utilizarse en una comunicacion esteganografica, por ejemplo, se puedecolocar el mismo valor que posee el campo Date de esa respuesta. De forma analoga a lasfechas en el futuro, un guardian activo debe modificar las fechas posteriores a un ano en elfuturo, ya que las mismas no estan aceptadas por la especificacion.

From Este campo del encabezado de pedido contiene la direccion de correo electronico dela persona que utiliza el software cliente. El contenido de este campo tiene que corresponder



a una direccion de correo electronico que pueda ser interpretada por la computadora. Laespecificacion sugiere su uso para fines de registro de auditorıa y para identificar el emisor depedidos invalidos o no deseados. Este campo puede entrar en conflicto con consideraciones deprivacidad del usuario.

Es posible realizar comunicaciones esteganograficas a partir de este campo, dada la natu-raleza del mismo. Esto es, no modifica la comunicacion propiamente dicha. Adicionalmente,una persona puede tener varias direcciones de correo electronico, todas ellas validas, y utilizaruna u otra de acuerdo a una codificacion preacordada con el receptor.

Para evitar la propagacion de estas tecnicas, un guardian activo debe quitar este campodel mensaje al momento de reenviarlo. Si bien, esto no producira alteraciones sobre la comu-nicacion legıtima, limitara la posibilidad de realizar las acciones de auditorıa que establece laespecificacion.

En la implementacion del artefacto propuesta (seccion 3.2.3), se ejemplifica la aplicacionesteganografica de este campo.

Host Este campo del mensaje de pedido indica el nombre de host en Internet y el numero depuerto del servidor que debe recibir el pedido del cliente. Estos son obtenidos de la URI originaldel recurso, como la ingresa el usuario u otra referencia al recurso. El cliente debe incluir estecampo en todos los mensajes de pedido. Si la URI de pedido no contiene un nombre de host, elcliente debe enviar el campo con contenido vacıo. Si el mensaje no posee este campo, se deberesponder con un mensaje de error con codigo de estado 400 (Bad Request).

Un servidor puede representar a mas de un nombre de Host. Este campo permite al servidordeterminar a que recurso se refiere el pedido cuando el mismo administra multiples nombresde hosts. La sintaxis de este campo es:

Host: host [ : port ]

El valor del puerto (campo port) es opcional, si no se indica se asume el puerto estandar80. Esta propiedad permite aplicar una comunicacion esteganografica sobre este campo, comose menciono en el tıtulo Uniform Resource Identifiers (URI) de la seccion 2.3.3.

If-Match Este campo del mensaje de pedido se utiliza para hacer que un metodo sea con-dicional. Un cliente que recibio previamente versiones del recurso solicitado y posee etiquetasde entidad correspondientes a las mismas (que se enviaron en el campo ETag), puede solicitarla ejecucion del metodo subordinada a la comparacion con las etiquetas de entidad que posee.

Este campo se utiliza en general con el metodo de actualizacion (UPDATE), para asegurarque se realiza la actualizacion del contenido solo si antes se habıa obtenido la ultima versiondel mismo. Si no se cumple la comparacion, el servidor debe responde con un mensaje de errorcon codigo de estado 412 (Precondition Failed). El caracter “*” iguala cualquier etiqueta deentidad existente del recurso (la comparacion con “*” se evalua verdadera solo existe algunaetiqueta de entidad generada para ese recurso), esto es, existe una representacion del recursosolicitado.

La sintaxis de este metodo es una lista de etiquetas de entidad (formadas por cadenas decaracteres entre comillas) separadas por comas o, el caracter “*” con significado especial. Porejemplo:

If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"

Puesto que el orden de los mismos no afecta el resultado de la comparacion para la deter-minacion de la ejecucion del metodo condicional, se puede aplicar esteganografıa a partir de lainterpretacion del orden de los elementos respecto del orden alfabetico. Esto puede aplicarse en



caso de estar compuesta por mas de un elemento. Para evitar la propagacion de esta tecnica, unguardian activo debe reordenar los elementos de la misma. En la seccion 2.3.3 se desarrollo elanalisis de las etiquetas de entidad y su aplicacion esteganografica independientemente de laaplicacion sobre un campo del mensaje.

If-Modified-Since Este campo del mensaje de pedido se utiliza para hacer que la ejecuciondel metodo sea condicional. Si el recurso no fue modificado luego de la fecha indicada en elcampo, el servidor no envıa el contenido del recurso en el mensaje de respuesta, en su lugarenvıa un mensaje con codigo de estado 304 (Not Modified). El contenido de este campo es unafecha, como se describio en la seccion 2.3.3. El objetivo de este metodo es utilizar eficientementeun cache de contenidos, con mınimas transferencias de mensajes.

Si el mensaje de pedido contiene un metodo GET y la fecha de este campo es invalida (e.g. esuna fecha posterior a la del servidor al momento de procesar el mensaje), la respuesta debe serigual que si no existiera este campo en el mensaje. Esto permite aplicar esteganografıa sobreeste campo, a partir de agregarlo con una fecha invalida a un mensaje que no lo contiene. Elmensaje esteganografico tiene dos estados posibles: no existe el campo o existe el campo conuna fecha invalida. En los dos casos la comunicacion genuina no se ve alterada65. Para evitaresta tecnica esteganografica, un guardian activo debe quitar los campos If-Modified-Since queposean una fecha invalida. Adicionalmente, puede agregar este campo con una fecha invalidaen los mensajes de pedido que no lo poseen.

If-None-Match Este campo del mensaje de pedido permite hacer condicional la ejecuciondel metodo. Es similar al campo If-Match en cuanto a su utilizacion y su forma de operacion.La diferencia con aquel es que si alguna de las etiquetas de entidad enviadas en el contenidodel campo coincide con la etiqueta de entidad del recurso solicitado, el servidor no debe llevara cabo el metodo de pedido, excepto que el mensaje de pedido contenga conjuntamente elcampo If-Modified-Since y la fecha de modificacion del mismo indique que se debe realizar elmetodo. Si se coloca el caracter “*” como contenido de este campo, el significado es que elmetodo no debe realizarse si existe una representacion del recurso referenciado (esto permiteevitar colisiones en el uso concurrente del metodo PUT).

Dada la similitud, sobre este campo es posible aplicar la misma tecnica de comunicacionesteganografica detallada para el campo If-Match.

If-Range Este campo del mensaje de pedido permite solicitar al servidor que envıe un frag-mento (rango) del recurso referenciado solo si se cumple la condicion establecida en el contenidodel campo. Si la condicion no se cumple (o el servidor no tiene la posibilidad de enviar un ran-go del recurso) la respuesta debe incluir el contenido completo del recurso. Este campo debeutilizarse conjuntamente con el campo Range para definir el rango solicitado del recurso.

El contenido de este campo consiste en una lista de etiquetas de entidad o en una fecha.Si el contenido es una lista de etiquetas de entidad, el campo se interpreta de la misma formaque If-Match. Si es una fecha se interpreta como If-Unmodified-Since.

Las aplicaciones esteganograficas del mismo son analogas a las desarrolladas para los cam-pos If-Match (en el caso de tratarse de etiquetas de entidad) y de If-Modified-Since. Al agregareste campo (y, en consecuencia, el campo Range) y una fecha invalida, se tiene el mismo resul-tado en la comunicacion genuina que si el mensaje de pedido no incluyera estos dos campos.

65Cuando se dice que no se ve alterada la comunicacion genuina, se refiere a que el flujo de mensajes es equi-valente con la aplicacion de la tecnica esteganografica propuesta que sin ella. En general, el costo computacionalde procesamiento puede ser diferente en los casos propuestos (i.e. el servidor debe determinar si la fecha esinvalida).



Adicionalmente, la especificacion establece que este campo debe ignorarse si no se colocajunto con el campo Range. Esto permite aplicar otra tecnica esteganografica a partir de laequivalencia entre un mensaje de pedido que tiene solo el campo If-Range y otro que no tieneambos campos. Un guardian activo debe bloquear esta aplicacion, para ello, bien puede colocaraleatoriamente el campo If-Range a mensajes que no poseen ambos campos, o quitarlo cuandoel mensaje de pedido no posee el campo Range.

If-Unmodified-Since Este campo del mensaje de pedido es analogo al campo If-Modified-Since para convertir el metodo en condicional. El servidor debe realizar la operacion si elrecurso referido no fue modificado desde la fecha indicada en este campo. En caso contrario,debe responder con un mensaje con codigo de estado 412 (Precondition Failed).

Last-Modified Este es un campo que coloca el servidor con la fecha en la que el supone queel recurso referenciado en el pedido fue modificado por ultima vez. Los servidores deben enviareste campo siempre que sea posible (puesto que permite un uso efectivo del cache a partir dela ejecucion de metodos condicionales).

Location Este campo de respuesta se utiliza para redirigir al cliente a otra ubicacion paracompletar el pedido. El contenido del mismo es una unica URI absoluta. Si la respuesta es delestado 201 (Created), el contenido de este campo refiere a la ubicacion del recurso creado. Sila respuesta es alguna de codigo 3xx, refiere a la ubicacion preferida por el servidor para elrecurso solicitado.

Max-Forwards Este es un campo del mensaje de pedido. Fue mencionado en la descripciondel metodo TRACE de la seccion 2.3.4. El objetivo del mismo es limitar la cantidad de reenvıosentre proxys o gateways hasta llegar al servidor de destino. Su contenido es un numero enteroque representa la cantidad maxima de saltos permitidos para el mensaje. La especificacion noestablece un lımite para este valor. Es utilizado para los metodos TRACE y OPTIONS. El usoesteganografico del mismo es analogo al desarrollado para el campo TTL de los mensajes IP(en el protocolo IP, el campo TTL se utiliza en todos los mensajes, ademas de estar limitadoa un valor de 255).

Este campo puede ser ignorado en el resto de los metodos de la especificacion. Por locual, en esos metodos puede ser aplicado como comunicacion esteganografica, a partir de lainterpretacion de la mera presencia o ausencia del mismo, ademas del valor contenido. Es porello que un guardian activo debe quitar este campo en los metodos donde no tiene utilidad.

Pragma Este campo permite incluir la aplicacion de directivas especıficas que pueden aplicarsobre cualquier participante a lo largo de la cadena de envıo del mensaje entre el cliente y elservidor. Desde el punto de vista del protocolo, todas las directivas representan un compor-tamiento opcional. La sintaxis de este campo permite incluir como contenido: no-cache o uncontenido definido como extension del protocolo de tipo clave = valor. Las directivas debenser reenviadas a traves de los proxys y gateways independientemente del significado para ellos,dado que las mismas pueden aplicar para todos los participantes en la cadena de reenvıos delmensaje (no es posible aplicar una directiva para un participante especıfico). Si la directiva notiene un significado para la aplicacion que la interpreta, se ignora.

Si se indica no-cache, todos los participantes en el reenvıo del mensaje deben retransmitirlohacia el servidor final como si no tuvieran una copia del contenido actualizada en su cache. Esequivalente a este mismo valor en el campo Cache-Control.



Este campo tiene una relacion interesante con la aplicacion de tecnicas esteganograficas.Dado que el contenido no-cache asegura que el mensaje recorre toda la cadena de reenvıoshasta llegar al servidor, esta directiva asegura que el mensaje HTTP sera recibido por elreceptor esteganografico, que puede encontrarse en la cadena o ser el servidor final, como semostro en la figura 1.2.

Por otra parte, al permitirse la inclusion de directivas no definidas en la especificacion, esposible emplear este campo para el envıo de un mensaje esteganografico: la directiva especıficacorresponde al mensaje. En este sentido, un guardian activo debe bloquear este campo cuandoel mismo incluya directivas no estandar.

Proxy-Authenticate Este campo de respuesta debe ser incluido en las respuesta con codi-go de estado 407 (Proxy Authentication). Consiste en un desafıo que indica el esquema deautenticacion y parametros para el proxy aplicables para la URI de pedido.

El procedimiento de autenticacion esta definido en la RFC 261766 y queda fuera de la RFCen estudio.

Proxy-Authorization Este campo del mensaje de pedido permite al cliente identificarsefrente a un proxy que lo requiere. El contenido de este campo contiene credenciales con lainformacion de autenticacion del agente de usuario para el proxy. Este campo aplica solo parael primer proxy que recibe el mensaje en la cadena de reenvıos. El esquema de autenticacionesta definido en la RFC 2617.

Range Este campo de pedido permite al cliente solicitar un rango del recurso, en lugar delrecurso completo. El servidor puede ignorar este campo y devolver el recurso completo.

El contenido del campo comprende un rango de bytes o un conjunto de rangos separadospor comas. El rango se define por los valores en bytes de inicio y opcionalmente el valor defin. Ambos valores se separan por un caracter “-”. Si no se indica el valor de fin del rango,se supone que abarca hasta el final de la entidad. En el contenido del campo se antepone eltermino bytes para indicar la unidad del rango. Si el valor de comienzo del rango es superioral tamano de la entidad recurso, el servidor debe responder con un mensaje de estado 416(Requested range not satisfiable). En caso contrario, responde con el rango solicitado en unmensaje con estado 206 (Partial Content). Por ejemplo, para solicitar los primeros 500 bytesdel recurso:

Range: bytes=0-499

Si el rango es invalido (i.e. el segundo valor del rango es inferior al primero), el servidordebe ignorar el campo y tratar el mensaje de pedido como si este campo no existiera. Estopuede ser utilizado en el marco de una comunicacion esteganografica (i.e. colocar el campoRange con un rango invalido es equivalente, en terminos de la comunicacion genuina, a nocolocar el campo) y debe ser bloqueado por un guardian activo.

Referer Este campo de pedido permite al cliente especificar la direccion (URI) del recursodesde la cual se obtuvo la URI del mensaje de pedido. Este es un campo informativo para elservidor, le permite generar listas de auditorıa, de enlaces al mismo, etc.

La especificacion menciona cuestiones de privacidad respecto a este campo que puedendevenir en un uso abusivo de la informacion del usuario. Por ejemplo, el analisis del contenidode este campo puede permitir determinar patrones de lectura del usuario o, incluso, puede

66Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., Sink, E. and L. Stewart,“HTTP Authentication: Basic and Digest Access Authentication”, RFC 2617, June 1999.



dejar en descubierto la URI de un documento cuya publicacion resulte inapropiada. Sugiere,para ello, que el software que utiliza el cliente disponga de un modo anonimo que deshabiliteel envıo de este campo y del campo From.

Adicionalmente, este campo puede contener una URI que no tenga existencia, sino querepresente un mensaje en el marco de una comunicacion estegangrafica. Es por esto, y dadaslas consideraciones de seguridad sugeridas por la especificacion, que para evitar la aplicacionde esteganografıa sobre este campo un guardian activo debe eliminarlo del mensaje. Lo cualresulta en una perdida de la funcionalidad que este campo brinda.

Retry-After Este campo del mensaje de respuesta permite al servidor indicar cuanto tiempodebe esperar el cliente antes de realizar otro pedido. Si se envıa en un mensaje de codigode estado 503 (Service Unavailable), se indica en cuanto tiempo se espera que el servicio seencuentre disponible nuevamente. Si el mensaje de respuesta es de codigo 3xx, indica al clienteque espere el tiempo mencionado antes de realizar la redireccion.

El contenido de este campo es una marca de tiempo o un perıodo de tiempo expresado ensegundos como un numero entero. Dado que existen dos formas de expresar el tiempo (comouna fecha fija o un perıodo a partir de la fecha recibida), se puede emplear este campo en unacomunicacion esteganografica, donde cada una de las dos formas de expresar el contenido tengaun significado particular. Un guardian activo debe modificar la forma de expresar el campo, conel objetivo de limitar esta aplicacion. Cabe mencionar que la modificacion introducida por elguardian activo puede alterar el contenido de la marca de tiempo puesto que, en general, su relojno esta sincronizado con el reloj del servidor. Aunque, como se ha mencionado anteriormente,se puede considerar imperceptibles esas modificaciones de las marcas de tiempo.

Server Este campo de respuesta contiene informacion acerca del software utilizado por elservidor para procesar el pedido. Los proxys no deben modificar el valor de este campo. Lasintaxis es la detallada en el apartado Nombres de producto de la seccion 2.3.3, donde se men-ciono la aplicacion esteganografica del mismo, analoga para nombres de producto de agentesde usuario.

Este campo permite tambien incluir comentarios adicionales al nombre del software. Estoscomentarios deben ser quitados por un guardian activo de forma de evitar su uso con finesesteganograficos.

Adicionalmente a las aplicaciones esteganograficas expuestas anteriormente para este tipode contenido, la especificacion menciona que revelar informacion acerca del software del ser-vidor puede dejarlo expuesto a ataques de seguridad en caso de fallas de seguridad conocidaspublicamente y sugiere a las implementaciones, permitir configurar el valor de este campo (locual, de forma secundaria y no intencional, alienta a una aplicacion esteganografica sobre elmismo).

TE Este campo del mensaje de pedido indica que extension de codificacion de transferenciaacepta el cliente en la respuesta y cual no acepta. Este campo permite como parametro la voca-blo trailers o un valor de codificacion de la transferencia con su parametro de aceptacion. Elvalor trailers indica que el cliente espera recibir campos de encabezado al final del contenidocuando el recurso se envıa en forma de porciones (chunked). Los valores de codificacion de latransferencia fueron detallados en el apartado Codificacion de la Transferencia de la seccion2.3.3.

Este campo es de tipo hop-by-hop (de un salto al siguiente), es decir, tiene significado en elcontexto de un unico reenvıo del mensaje. Por lo tanto, la aplicacion de esteganografıa sobre



el mismo solo puede realizarse si la extraccion del mensaje (Emb) se encuentra en el siguientenodo HTTP de procesamiento en la cadena de reenvıos que sigue el mensaje.

Trailer Este es un campo que indica que el conjunto de campos que se coloca como contenidoesta presente en la cola del mensaje (trailer, en ingles) en la codificacion de transferencia porporciones (chunked).

Sobre este campo es posible aplicar las mismas consideraciones esteganograficas de ordena-miento alfabetico expresadas que para los campos generales del encabezado. Se debe tener encuenta que si se modifica el ordenamiento de los nombres de los campos indicados en Trailer,se debe modificar el orden de los campos que se colocan en la cola del mensaje, de formaconsistente.

Este campo tambien es de tipo hop-by-hop, por lo tanto solo se puede aplicar esteganografıasi la funcion Emb se encuentra en el siguiente nodo de la cadena de reenvıos.

Transfer-Encoding Este campo indica que tipo de transformacion se ha aplicado al cuerpodel mensaje para proporcionar una comunicacion segura entre el emisor y receptor del mismo.Si se aplican multiples transformaciones, el contenido de este campo debe indicarse como unalista de las mismas, en el orden en el que fueron aplicadas. La codificacion de la transferenciafue desarrollada en la seccion 2.3.3.

Upgrade Este campo permite al cliente especificar otros protocolos de comunicacion de capade aplicacion que implementa y que prefiere utilizar si el servidor considera apropiado utilizar.El servidor debe responder con un mensaje con codigo de estado 101 (Switching Protocols)con el campo Upgrade para indicar que protocolo comenzar a utilizar. Como ejemplo de estecampo:

Upgrade: HTTP/2.0

La especificacion define solo la palabra clave HTTP para ser usada como nombre de proto-colo y los numeros de version como se describio en la seccion 2.3.3. Permite tambien utilizarcualquier otra palabra reservada para remitirse a otro protocolo, aunque indica que es util solosi es entendida por el emisor y el receptor del mensaje. Esto permite una aplicacion estega-nografica sobre el campo, dado que puede incluirse cualquier codigo de nombre de protocoloy versiones que incluso sean inexistentes67. Un guardian activo debe limitar la aplicacion deesteganografıa sobre este campo a partir de bloquear el uso de protocolos inexistentes.

Este es otro campo tambien de tipo hop-by-hop, por lo tanto solo se puede aplicar estega-nografıa si la funcion Emb se encuentra en el siguiente nodo de la cadena de reenvıos.

User-Agent Este campo del mensaje de pedido contiene informacion acerca del softwareagente de usuario que origina el pedido. Este campo es para fines estadısticos, de auditorıa ypara que el servidor adapte la respuesta a las eventuales limitaciones conocidas del softwarecliente. El cliente debe incluir este campo en los mensajes de pedido.

El contenido de este campo fue detallado en el apartado Nombres de producto de la seccion2.3.3, donde se menciono la aplicacion esteganografica del mismo. Al igual que se menciono en elcampo Server, este campo permite incluir comentarios, que deben ser quitados por un guardianactivo.

67En el ejemplo anterior, extraıdo del texto de la especificacion, se indica la version 2.0 de HTTP, la cual noexiste al momento de la redaccion del presente trabajo.



Vary Este campo de respuesta indica a los proxys que interpretan el mensaje que camposdel mensaje tomar para determinar cuando se puede utilizar una respuesta en cache en lu-gar de solicitar un contenido limpio al servidor original. El valor “*” indica que el cache nopodra determinar a partir de los campos del encabezado de mensajes de pedido subsecuentessi la respuesta en cache es apropiada o no.

El contenido de este campo, que consiste en una lista de nombres de campos de encabezado,indica que la representacion transferida del recurso fue elegida sobre la base de un algoritmobasado solo en los valores de esos campos. Al igual que los campos del encabezado del mensaje,los campos del contenido de este campo son insensibles a mayusculas. Esta caracterıstica, delmismo modo que el ordenamiento de la lista de campos, puede ser utilizada como tecnica decomunicacion esteganografica, como en los casos anteriores y debe ser evitada por un guardianactivo a partir de modificar las mayusculas del contenido y de reordenar sus valores.

Via Este campo debe ser utilizado por gateways y proxys para indicar los receptores partici-pantes y sus versiones del protocolo en la cadena entre el cliente y el servidor en los mensajes depedido cuanto en las respuestas. Se utiliza para realizar el seguimiento del mensaje e identificarlas capacidades de todos los emisores en el camino que recorre el mensaje. Cada intermediarioagrega su identificacion al final de la lista, de modo que la lista queda ordenada de acuerdocon el orden de aparicion de quienes procesaron el mensaje.

La sintaxis de este campo es una lista de valores que representa a cada uno de los partici-pantes. Cada uno de estos valores esta formado por:

protocolo y version, por ejemplo: HTTP/1.1. Si el protocolo es HTTP, el nombre delprotocolo es opcional, conjuntamente con el caracter “/” que lo acompana.

identificacion del proxy o gateway que lo recibio. Puede estar representada por: nombredel host:puerto o por un seudonimo que lo representa. El seudonimo se emplea para norevelar la direccion real del intermediario. La especificacion establece que los proxys ogateways que actuan como firewall no deben, como comportamiento por defecto, reenviarlos nombres y puertos de los proxys de la red interna de la region del firewall, en su lugardeben colocar seudonimos. Si el puerto es el estandar 80, no es obligatorio colocarlo. Porejemplo: prueba.fi.uba.ar o aleph:8000.

comentario adicional. Puede usarse para identificar el software del intermediario (esanalogo a los campos Server y User-Agent). La especificacion establece que los comen-tarios son opcionales y pueden ser eliminados por un proxy antes de reenviar el mensaje.

Como ejemplo de este campo (en este caso, fred es el nombre de un proxy interno del cualno quiere revelarse su direccion):

Via: 1.0 fred, 1.1 nowhere.com (Apache/2.2)

Dado que colocar el nombre HTTP y el puerto 80 es optativo y no afecta la representacion dela lista, es posible utilizar esta caracterıstica en el marco de una comunicacion esteganografica,como se ha mencionado en los casos anteriores. Un guardian activo debe modificar esta formade escritura para limitar este uso. Asimismo, el guardian activo debe limitar el uso de loscomentarios para que los mismos no sean utilizados como comunicacion esteganografica.

Adicionalmente, la especificacion establece que, en organizaciones que requieran un altogrado de privacidad sobre su estructura interna, un proxy puede combinar multiples valoresconsecutivos de la lista del campo Via en uno solo. Esto debe realizarse solo si las diferentesentradas de la lista poseen el mismo protocolo y si la identificacion ha sido reemplazada porun seudonimo. Como ejemplo, la especificacion muestra que el campo:



Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy

puede acortarse como:

Via: 1.0 ricky, 1.1 mertz, 1.0 lucy

Sobre este campo puede, tambien, aplicarse consideraciones similares a las propuestas enel estudio del campo Opciones del datagrama IP, para los tipos de opcion que permiten alma-cenar la ruta que recorre el datagrama. En aquel analisis esteganografico se propuso adicionarinicialmente a la lista del campo de intermediarios valores ficticios que representen un men-saje esteganografico. Sobre el campo Via puede aplicarse la misma tecnica. La diferencia eneste caso es el mayor grado de libertad sobre el contenido de este campo: se puede emplearseudonimos y no existe un lımite de tamano maximo preestablecido.

Warning Este campo se utiliza para transportar informacion adicional acerca del estado ode la transformacion del mensaje que no puede ser reflejada en otros campos del mensaje.El contenido de este campo esta compuesto por una lista de una o varias indicaciones (i.e.warnings), cada una formada por los siguientes parametros separados por espacios:

codigo de warning. Compuesto por tres dıgitos.

agente del warning. Corresponde a la identificacion de quien genero el campo Warning.La escritura de esta identificacion es igual a la que se realiza en la del campo Via (i.e. sepuede escribir como nombre de host y puerto o como seudonimo).

texto del warning. Debe estar escrito en lenguaje natural para ser interpretado por unhumano que recibe la respuesta. El idioma por defecto es ingles y la codificacion de carac-teres ISO-8859-1. Se puede ingresar texto en otra codificacion, la misma debe establecerseen este campo, segun lo establece la RFC 204768.

fecha del warning. Marca de tiempo en el formato estandar de HTTP. Este parametro esopcional.

La especificacion establece que se puede colocar un solo campo Warning o multiples cam-pos, cada uno con un elemento de la lista. El orden en el que se encuentran los campos Warningrepresenta el orden de prioridad de los avisos (aunque la especificacion aclara que esta regla noes estricta). Esto debe ser tenido en cuenta al momento de aplicar esteganografıa: por un lado,si se reordena la lista de campos del encabezado (como se propuso como tecnica esteganograficaen la seccion 2.3.2) y por otra parte, no debe reordenarse la lista de valores del contenido deeste campo.

El cache no debe eliminar el mensaje de Warning, sino que debe almacenarlo junto conel contenido del recurso cuando recibe el mensaje. Si reemplaza una copia del recurso delcache por la recibida en el mensaje, tambien debe reemplazar el posible mensaje de warningque esta contenga.

Los codigos de warning 1xx describen el estado de frescura o revalidacion de una respuesta.Pueden ser generados por el cache cuando realiza un proceso de revalidacion. No deben sergenerados por clientes. Los codigos 2xx describen algun aspecto del cuerpo de entidad delrecurso o encabezado que no fue rectificado en la revalidacion del cache.

Los codigos de warning establecidos por la especificacion son:

68K. Moore, University of Tennessee, November 1996. “MIME (Multipurpose Internet Mail Extensions) PartThree: Message Header Extensions for Non-ASCII Text”. Request for Comments: 2047.



110 Response is stale: debe ser incluido cuando la respuesta sea obsoleta.

111 Revalidation failed : la debe incluir un proxy cuando envıe una respuesta obsoletaa causa de no poder revalidar el contenido del recurso necesario en la respuesta, porproblemas de comunicacion con el servidor.

112 Disconnected operation: se debe incluir si el cache esta desconectado del resto de lared.

113 Heuristic expiration: si el servidor de origen de la respuesta no incluyo un tiempo decaducidad de la misma, el cache lo debe calcular a partir de una heurıstica. Si el tiempoa calcular es mayor a 24 horas y la respuesta se incluyo en el cache hace mas de 24 horas,se debe enviar este codigo.

199 Miscellaneous warning : El texto que se incluye con este codigo puede contener cual-quier contenido arbitrario, para ser presentado al usuario. El agente de usuario no deberealizar operaciones automaticas sobre este tipo de codigo.

214 Transformation applied : Debe ser agregado por un proxy si el le aplico transforma-ciones que modifiquen la codificacion del contenido (especificada en el campo Content-Encoding) o el tipo de contenido (especificado en el campo Content-Type) de la respuesta.Si ya existe el encabezado con este valor, no se debe volver a agregar.

299 Miscellaneous persistent warning : Puede incluir cualquier texto arbitrario para serpresentado al usuario. El agente de usuario que recibe este codigo no debe realizar ope-raciones automaticas.

Al ser opcional el parametro fecha, esta puede ser aplicada con fines esteganograficos apartir de la interpretacion de su presencia o ausencia. Un guardian activo debe bloquear lainclusion de fecha de todos los campos para evitar su uso en una comunicacion esteganografica,si bien, esto modifica una funcionalidad no esencial del protocolo. Asimismo, al permitirsevarias codificaciones de caracteres posibles para el texto del warning, el guardian activo debenormalizar los textos (i.e. transformar la codificacion a, por ejemplo, la estandar ISO-8859-1)a fin de evitar que el tipo de codificacion pueda representar un mensaje esteganografico.

La posibilidad de colocar varios encabezados Warning, cada uno con su contenido, en lugarde colocar uno solo con una lista de elementos tambien permite aplicar una comunicacionesteganografica. Un guardian activo debe modificar esta forma de escribir el contenido delcampo, ya sea generar un solo campo Warning con todos los valores a partir de los multiplescampos que pueden existir o, al reves, a partir de un unica lista de elementos del campoWarning, generar varios campos.

Este campo permite adicionar un texto libre en varios de sus posibles codigos, con el objetivode ser entregado a un humano, sin interpretacion automatica, tal es el caso de los mensajesde codigo preestablecido 199 y 299. El texto libre destinado a ser interpretado por un humanopuede ser utilizado para la comunicacion de un mensaje esteganografico. Un guardian activodebe asegurarse que no se realiza esteganografıa sobre ese campo a partir de eliminar ese texto,o de reemplazarlo por otro texto. Si bien, esta polıtica limita la utilidad de este tipo de campo.

WWW-Authenticate Este es un campo de respuesta que debe ser incluido en los mensajesde codigo de estado 401 (Unauthorized). El contenido de este campo consiste en al menos unaclave de desafıo que indica el esquema de autenticacion y sus parametros, aplicable al recursosolicitado en la URI de pedido.

Como se menciono anteriormente, el procedimiento de autenticacion esta definido en laRFC 2617 y queda fuera de la RFC en estudio.



2.3.7. Otras consideraciones

Seguridad La especificacion detalla algunas cuestiones de seguridad conocidas como limita-ciones del protocolo que deben ser tenidas en cuenta por las implementaciones.

Por una parte, el agente de usuario almacena informacion personal acerca del usuario(nombre, ubicacion, direccion de correo electronico, etc). La especificacion advierte que sedebe tener cuidado que esa informacion se filtre de forma no intencionada hacia otras fuentesa traves de mensajes HTTP. Menciona tambien que se conocen errores en implementacionesen este sentido que dejaron expuesta informacion personal y perjudicaron al desarrollador delsoftware que implemento el protocolo.

Si bien la especificacion no se refiere conceptualmente a la realizacion de una comunicacionesteganografica sobre el protocolo, es interesante mencionar la analogıa que se plantea con elfiltrado de informacion sensible a traves del protocolo.

La especificacion indica que los servicios que hacen uso de HTTP no deben colocar informa-cion sensible en la URI de pedido (e.g. en parametros de la URI), puesto que la misma puedeser almacenada para cuestiones de auditorıa. Puede utilizarse, como opcion para el envıo deinformacion, formularios enviados con el metodo POST. En relacion al presente trabajo, estosugiere que no se realice una comunicacion esteganografica sobre la modificacion de la URI, enel sentido de dejar expuesto porciones del mensaje esteganografico es la misma.

Por otra parte, se menciona que los proxys son, por naturaleza, man-in-the-middle (estanen el camino de la comunicacion). Representan, por tanto, una oportunidad de ataque de tipoman-in-the-middle[Sta06] y si son comprometidos pueden devenir en serios problemas de segu-ridad y privacidad (los proxys disponen de informacion privada de usuarios y organizaciones).Sobre todo, se sugiere proteger el registro de operaciones del proxy (el log) y la informacion al-macenada en el cache, puesto que este representa una forma de persistencia de la comunicacion,una vez que ella ha finalizado.

En este caso tambien se plantea un paralelismo entre la recomendacion de la especificaciony la aplicacion de esteganografıa, puesto que, como se ha mostrado y descripto en la figura1.2, las funciones esteganograficas Emb y Ext se implementan sobre proxys (o gateways) en elcamino de la comunicacion. Como se ha observado anteriormente, esto constituye una violaciona las polıticas de seguridad.

Aplicaciones tolerantes La especificacion advierte que no todas las aplicaciones pueden sercorrectas en su implementacion del protocolo y recomienda que las aplicaciones sean tolerantesfrente a desviaciones del protocolo en los casos en que estas puedan interpretarse de formano ambigua. Explıcitamente, menciona que los clientes deben ser tolerantes al interpretar lalınea de estado y los servidores en la lınea de pedido que incluye el metodo, y las aplicacionesdeben aceptar cualquier cantidad de espacios o de tabuladores entre el nombre del campoy su contenido, aunque se requiere un solo espacio. Esto fue mencionado como una posibleexplotacion esteganografica cuando se describio el formato de mensajes en la seccion 2.3.2.

Asimismo, si bien la especificacion establece que el fin de lınea esta compuesto por la secuen-cia CRLF, en la seccion de recomendacion de implementacion de tolerancia frente a desviacionesdel protocolo, se sugiere que pueda ser interpretado como separador de lıneas el caracter LF

independientemente y se ignore el caracter CR. Esto permite una aplicacion esteganograficaque considere un mensaje interpretado a partir del caracter utilizado en la separacion de lıneasde los campos del mensaje. Para evitar la utilizacion de esta tecnica, un guardian activo debetransformar todos los separadores de lınea a la forma sugerida CRLF.



2.4. Comparacion entre IP y HTTP en funcion del estudio rea-lizado

En ambos protocolos se han analizado las estructuras que brindan para la comunicacion decontenido y se ha dejado intencionalmente de lado, el analisis del contenido propiamente dichotransportado por los mensajes de los protocolos. Estas estructuras se encuentran en lo que sedenomina en ambos casos, campos del encabezado del mensaje.

Ambos protocolos estudiados son sin estado, es decir, las comunicaciones realizadas conellos no mantienen parametros entre mensajes distintos, la comunicacion no tiene fases de es-tablecimiento y liberacion, por esto se dice que son sin conexion. En este tipo de protocolos, sedebe contemplar mecanismos para evitar la perdida de mensajes, desorden o duplicacion. Estacaracterıstica impacta sobre el diseno de un protocolo esteganografico que requiera una comu-nicacion confiable entre las partes y se sustente en estos protocolos. Estos mecanismos puedenestar inspirados en otros protocolos que cumplen con esos requerimientos (e.g. el protocoloTCP).

El protocolo IP es de capa de red y su objetivo principal es la comunicacion de mensajesentre dos hosts que actuan como pares en la comunicacion (los hosts pueden estar situados endiferentes redes). Todos los mensajes son independientes entre sı69. El protocolo HTTP es decapa de aplicacion, su objetivo principal es permitir una comunicacion de tipo cliente-servidorentre dos aplicaciones, donde en general cada mensaje de pedido es respondido con un mensajede respuesta70. La aplicacion cliente realiza pedidos de elementos (denominados recursos) a laaplicacion servidor.

Ademas del proposito diferente de ambos protocolos, se destaca la diferencia entre comu-nicacion entre pares y comunicacion cliente-servidor. En este ultimo caso, por ejemplo, elservidor no puede iniciar una comunicacion hacia el cliente. Esto repercute, por una parte, enla aplicacion esteganografica que puede realizarse sobre este protocolo, puesto que el patronde trafico es: primero se envıa un mensaje de pedido y luego un mensaje de respuesta. Si sedeseara enviar un mensaje esteganografico desde el servidor hacia el cliente, por el metodo demodificacion de portadores, se deberıa esperar que el cliente envıe un pedido al servidor, paraque este lo responda con un mensaje que podra ser utilizado como el portador buscado para sumodificacion. Este tipo de patron de trafico no ocurre, a priori, en el caso de la comunicacionen el protocolo IP71.

Por otra parte, esta diferencia tiene implicancias en el diseno de los algoritmos estega-nograficos: mientras que en IP todos los datagramas poseen la misma estructura (por lo tanto,es posible considerar la aplicacion de las tecnicas esteganograficas a todos los datagramas), losmensajes HTTP son de dos tipos diferentes: mensajes de pedido y mensajes de respuesta. Enconsecuencia, algunas tecnicas solo pueden ser aplicadas sobre mensajes de pedido (e.g. modi-ficar algun elemento de la lınea de pedido) y otras solo pueden ser aplicadas sobre mensajesde respuesta.

Ambos protocolos estan disenados para que sus mensajes atraviesen nodos intermedios enel camino entre emisor y receptor. Estos intermediarios pueden realizar operaciones sobre elmensaje que pueden alterar su estructura. Las aplicaciones esteganograficas sustentadas sobreestos protocolos deben tener en cuenta este fenomeno para operar correctamente.

69en este contexto se entiende como mensaje al conjunto de los eventuales fragmentos de datagramas, es decir,se habla de datagramas completos.

70se ha mencionado en la seccion 2.3.5 que el servidor puede, opcionalmente, enviar al cliente un mensajecon codigo de estado 100 (Continue) para indicar al cliente que el comienzo (o la totalidad) de su pedido fuerecibido y luego de ese mensaje de envıa la respuesta al pedido propiamente dicho.

71si bien cabe mencionar que si la comunicacion que se realiza entre las capas de aplicacion de dos hosts esHTTP, los mensajes del protocolo IP subyacente tendran el mismo patron de trafico que los de HTTP.



Ambos protocolos proveen un campo del mensaje para indicar la cantidad maxima dereenvıos (saltos) que se permite al mensaje. En el caso de IP corresponde al campo TTL, quese encuentra presente en todos los mensaje y tiene una longitud de 8 bits, por lo que puederepresentar hasta 255 saltos72. Mientras que en el caso de HTTP, existe el campo Max-Forwardsque es opcional y se utiliza solo para dos de los metodos de pedido (TRACE y OPTIONS), y noposee un valor lımite fijado por la especificacion. Se ha mencionado la posibilidad de aplicacionde tecnicas esteganograficas para ambos casos. IP es un protocolo que esta disenado paraque sus mensajes naturalmente atraviesen varias redes hasta llegar al receptor (con variosnodos de reenvıos). Por eso, y para evitar un el reenvıo indefinido del mensaje entre nodos, seestablece la obligatoriedad de fijar un lımite maximo a la cantidad de saltos. A diferencia, lascomunicaciones a traves de HTTP se realizan generalmente sin intermediarios entre el clientey el servidor. En virtud de lo cual, el protocolo no obliga a limitar la cantidad de saltos entodos los mensajes.

Una de las principales diferencias entre las estructuras de los mensajes de ambos protocoloses que los mensajes del protocolo IP tienen una composicion de campos de encabezado a nivel debits mientras que los de HTTP tienen una composicion de tipo cadenas de caracteres. Es decir,los campos del encabezado del mensaje IP tiene un tamano fijo medido en bits (salvo el campode Opciones que tiene un tamano variable, pero con un lımite maximo fijo), por ejemplo losflags son de un bit. Los campos del encabezado de HTTP son cadenas de caracteres organizadasen diferentes lıneas que dividen un campo de otro (incluso dentro del contenido de un campose puede adicionar marcas de fin de lınea73). El tratamiento a nivel de caracteres implicaconsideraciones que no existen en el tratamiento a nivel de bit. Tal es el caso de la codificacionde caracteres, es decir, la forma en la que se representan los caracteres. En los campos de HTTPno existe a priori un lımite maximo de tamano y, en general, tienen tamanos variables74. Estacaracterıstica tiene incidencia en la capacidad para embeber que posee cada uno de los tiposde mensajes. En principio, se podrıa agregar una cantidad ilimitada de campos a los mensajesHTTP (limitado solo por cuestiones practicas de las implementaciones del protocolo), mientrasque en el datagrama IP, el tamano del encabezado esta limitado a 60 bytes.

Por otra parte, la estructura del encabezado del datagrama IP es rıgida, es decir, loscampos que lo componen tienen una posicion determinada y no se puede modificar. En elencabezado de los mensajes HTTP, los campos no tienen un orden preestablecido (aunque laespecificacion sugiere un orden de importancia) y los mismos pueden ser colocados en cualquierorden. Esta caracterıstica permite que el ordenamiento de los campos pueda representar unmensaje esteganografico, lo que no es posible en el protocolo IP.

Adicionalmente, no son obligatorios todos los campos del encabezado HTTP en todos losmensajes (la especificacion define cuarenta y siete campos estandar). Esto permite que la solaexistencia de un campo pueda ser considerada como un mensaje esteganografico. Para evitar eluso de esta tecnica se propuso limitar el uso de ciertos campos en el mensaje, lo cual restringefuncionalidades del protocolo. Mientras que en el caso del datagrama IP solo es opcional elcampo Opciones.

En el protocolo HTTP existen varios campos del encabezado del mensaje que permitencontener como valor listas de elementos donde, en general, cada elemento es independientedel otro y su orden de aparicion tampoco influye (lo cual permitio realizar una propuesta deaplicacion esteganografica sobre ese orden). En el datagrama IP, el unico campo que contiene

72en rigor, como se ha mencionado, el campo TTL representa el tiempo maximo, en segundos, que se permiteque el mensaje circule por las redes hasta llegar a destino, y se decrementa con cada reenvıo.

73esto se conoce como folding y se ha realizado una propuesta de aplicacion esteganografica que explota estacaracterıstica.

74se menciono que si bien no existen lımites impuestos por la especificacion del protocolo, en la practica existenlımites que imponen las implementaciones populares del protocolo, como el servidor Apache Web Server.



un conjunto de sub-campos posibles es el campo Opciones y sobre el orden de las mismastampoco se establecen restricciones, lo cual tambien puede ser aprovechado en el marco de unacomunicacion esteganografica.

Para ambos protocolos se ha propuesto tecnicas esteganograficas que no modifican el ta-mano del portador al ser aplicadas (e.g. modificar el campo ID del datagrama IP o modificarel orden de los campos del encabezado del mensaje HTTP) y otras tecnicas que aumentan eltamano del mensaje portador al ser aplicadas (e.g. agregar el campo Opciones en el datagra-ma IP cuando el mismo no existe o agregar campos adicionales en el encabezado del mensajeHTTP).

El protocolo HTTP otorga la posibilidad de emplear extensiones al protocolo a partir delempleo de campos que no estan definidos en la especificacion. Para evitar que estos campospuedan actuar como canales encubiertos en una comunicacion esteganografica, se propuso queun guardian activo quite esos campos del mensaje (aunque esto supone una limitacion a lasfuncionalidades provistas por el protocolo). En el caso del datagrama IP, no existe la posibilidadde campos personalizados. Solo existen tipos de opciones, dentro del campo Opciones, quetienen un valor para un uso reservado en una futura extension del protocolo. Por la mismarazon, tambien se ha propuesto limitar el uso de esos campos reservados.


Capıtulo 3

Implementacion de un artefacto

En este capıtulo se presenta el diseno de un artefacto de software que muestre por un lado lafactibilidad de la comunicacion de mensajes esteganograficos de tipo texto sobre los protocolosestudiados y, por otra parte, la forma de evitar estas tecnicas a partir de una guardian activo.

Esto se ha desarrollado para cada uno de los dos protocolos estudiados en forma indepen-diente. Es decir, se implementa un artefacto que cumple los roles de escritor, lector y guardianesteganografico sobre los mensajes del protocolo IP, y otro artefacto que cumple los mismosroles sobre los mensajes del protocolo HTTP.

3.1. Descripcion del escenario de aplicacion

Se ha mencionado que el principal objetivo de la esteganografıa consiste en el disimulodel acto de comunicacion. En este sentido, se toma como idea base que la aplicacion de estastecnicas puede ayudar a realizar acciones de filtracion o robo de informacion. En el casode empresas, en general, las filtraciones de informacion son producidas por empleados de laempresa que se comunican con otra parte en el exterior de la misma. Especialistas en seguridadinformatica indican que, estadısticamente, la mayorıa de los ataques informaticos no provienedel exterior, sino del interior de las propias empresas[Exp09] (e.g. usuarios de las redes internasque logran causar danos dentro de los sistemas de la companıa).

En noviembre de 2010 tomo trascendencia mundial la publicacion en un sitio web (Wiki-leaks1) de mas de 250.000 comunicaciones diplomaticas confidenciales entre el Departamentode Estado de Estados Unidos y mas de 270 sedes diplomaticas en diferentes paıses del mun-do, entre ellas, embajadas2[The10][Chi10]. La filtracion de estas comunicaciones fue realizada,de manera disimulada, por un soldado del propio ejercito estadounidense perteneciente al de-partamento de inteligencia[Sco10] que grabo archivos de computadora confidenciales en discoscompactos[La 10].

El caso Wikileaks constituye una practica esteganografica (tal lo es la filtracion, o robodisimulado, de informacion), si bien no constituye una practica de comunicacion esteganograficade protocolo, es un ejemplo de robo de informacion perpetrado por una persona interna a laorganizacion y del peligro que puede ocasionar para la misma. Este caso ensena tambien quedeben ser reforzados en particular todos los puntos de acceso a los sistemas que almacenaninformacion que debe mantenerse secreta (ademas del acceso fısico a los sistemas, los permisos yrestricciones particulares de acuerdo a los usuarios). Es comun indicar que un ataque dedicadoes difıcil de evitar[van].

1http://wikileaks.org/2http://cablegate.wikileaks.org/

108


El artefacto de software que se presenta en este capıtulo esta disenado para funcionar en lacomputadora que actua como gateway entre la red interna de una organizacion y su conexiona Internet. El rol de guardian del artefacto actua como guardian esteganografico activo entrelos participantes de la comunicacion genuina a traves de los protocolos estudiados. Preserva lasemantica de los mensajes de protocolo para no malograr la comunicacion genuina a traves delprotocolo3.

El artefacto desarrollado sobre el protocolo IP esta disenado para funcionar en un nodode la red que actue como router en el camino de la comunicacion (este puede ser un equipoinformatico que vincule la red de una organizacion con Internet). Analogamente, el artefactodesarrollado sobre el protocolo HTTP esta disenado para funcionar como proxy HTTP en elcamino entre el cliente y el servidor HTTP (puede ser utilizado como un proxy de uso obligatoriodentro de una organizacion). En consecuencia, se puede tomar como consideracion que todaslas comunicaciones informaticas, a traves de los protocolos estudiados, entre la organizacion yel exterior de la misma deben transitar por la computadora que ejecuta el artefacto.

El diseno del artefacto tiene como objetivo principal mostrar la factibilidad practica detecnicas esteganograficas analizadas sobre los protocolos y la posibilidad de evitar el uso deesas tecnicas.

3.2. Diseno del artefacto

3.2.1. Consideraciones generales del artefacto

El artefacto de software construido fue desarrollado en el lenguaje de programacion C++.Se ha utilizado como plataforma para el desarrollo, el sistema operativo GNU/Linux Kubuntuversion 11.104. Para compilar el codigo fuente se ha utilizado el compilador GCC5 version4.6.1. Se provee junto al presente informe todos los archivos fuente desarrollados, y un archivoMakefile para realizar la compilacion con GNU make6.

En lo que respecta a la portabilidad del software desarrollado, si bien existen compiladoresde C++ para otros sistemas operativos (e.g. Visual C++7 para Microsoft Windows), se hanutilizado estructuras y funciones propias del sistema operativo de base (e.g. para el caso delos servicios de red: sockets de Unix). Si se quisiera desarrollar el software para otros sistemasoperativos (i.e. multiplataforma), podrıa desarrollarse sobre un framework que aısle, entreotros, los servicios de red. Esto es, una capa que abstraiga de la plataforma subyacente, lasfunciones y estructuras utilizadas[Zav08]. Dado que el artefacto tiene un proposito sobre dosprotocolos diferentes, se decidio la compilacion de dos ejecutables, uno para actuar sobre cadaprotocolo.

En ambas versiones del artefacto (para cada uno de los protocolos), se ha implementadola comunicacion esteganografica de forma unidireccional (half-duplex ). Es decir, una vez quese ejecuta en una computadora (e.g. la computadora de Alicia) el artefacto con el rol de es-critor esteganografico, el mismo realizara las modificaciones a los mensajes portadores paraaplicar el mensaje, sin realizar lectura esteganografica. Lo mismo ocurre con el rol del lectoresteganografico (llevado a cabo en la computadora de Boby): se desempena como lector delmensaje esteganografico durante toda la ejecucion del artefacto. Esta decision no implica unaperdida de generalidad ni disminucion de los objetivos propuestos (mostrar la aplicacion de

3En los casos en que las acciones realizadas por el guardian activo puedan ser consideradas como que lasmismas afectan la comunicacion genuina, se aclarara la decision tomada al aplicarlas.

4http://www.kubuntu.org/news/11.10-release5http://gcc.gnu.org/6http://www.gnu.org/s/make/7http://msdn.microsoft.com/en-us/vstudio/



las tecnicas sobre los protocolos), respecto de una implementacion que permita la comunica-cion esteganografica en forma bidireccional (full-duplex ). La diferencia consistirıa en que enla version full-duplex, los participantes alteran sus roles de emisor y receptor esteganografico:cada vez que reciben un mensaje del protocolo deben aplicarle el algoritmo de lectura estega-nografica (Ext) y cada vez que envıan un mensaje, deben aplicarle el algoritmo de escrituraesteganografica (Emb).

El escenario propuesto para la aplicacion de las funciones para embeber y extraer el mensajeesteganografico en el artefacto desarrollado es el ilustrado en el caso 4 de la figura 1.2 descriptaen el capıtulo 1. Tanto la funcion para embeber el mensaje esteganografico cuanto la funcionpara extraer el mensaje operan exteriormente a los modulos emisor y receptor de los mensajesgenuinos del protocolo. Adicionalmente, el receptor esteganografico del modulo implementadono intenta reconstruir el portador original que recibio el emisor esteganografico, tal como semenciono en la descripcion de dicha figura. Esto es por dos motivos: en ciertos casos, a travesde la aplicacion de algunas tecnicas esteganograficas no es posible conocer como era el mensajegenuino previo a la modificacion correspondiente y, por otra parte, el hecho de que el receptoresteganografico del artefacto mantenga el mensaje modificado al reenviarlo, permite ver enlas pruebas realizadas que ese mensaje es interpretado por el receptor del protocolo (i.e. lacomunicacion genuina se realiza sin problemas, aun cuando el receptor del protocolo recibeuna version modificada por el artefacto respecto del mensaje que genero el emisor par).

Dado que el artefacto desarrollado implementa el protocolo de comunicacion de formaunidireccional, no se han implementado mecanismos de confirmacion de recepcion del mensaje,ni de sincronismo para realizar la comunicacion. En consecuencia, si por ejemplo, en el trayectoentre el emisor y receptor esteganografico un datagrama portador es descartado (por algunmotivo ajeno al artefacto desarrollado), el receptor esteganografico perdera parte, o todo elmensaje. Cabe senalar que estos requerimientos estan fuera del objetivo propuesto para eldesarrollo del artefacto.

Es de destacar que la aplicacion esteganografica introduce inexorablemente una demora enel acto de comunicacion entre el emisor y el receptor del protocolo. Puesto que tanto el emisor,receptor y guardian esteganografico intermedios deben interpretar el mensaje de protocolo,aplicarle los algoritmos respectivos y luego reenviar el mensaje. Naturalmente, la demora en elreenvıo aumenta cuanto mas procesamiento se realice sobre el portador.

En el apendice D se presenta el prototipo de cada uno de los metodos de las clases. En el CDque se entrega junto con el presente informe se incluye los archivos de codigo fuente completo,junto con el mecanismo de compilacion, los ejemplos propuestos y un archivo LEAME.txt quecontiene las indicaciones para realizar la compilacion y las pruebas propuestas.

Se ha separado en diferentes directorios los archivos fuente correspondientes a las clases,segun su aplicacion:

HTTP : contiene las clases que implementan la interpretacion de los mensajes del proto-colo HTTP y los algoritmos esteganograficos sobre los mensajes del mismo.

IP : ıdem anterior, para el caso del protocolo IP.

utils: contiene clases de proposito general, independientes del artefacto desarrollado, entreellas: funciones avanzadas sobre el manejo de strings, sockets de Unix, memoria compar-tida, semaforos, etc.

StegProtocol : contiene las clases que modelizan un administrador de mensaje, que permiteprincipalmente leer y escribir un mensaje esteganografico en fragmentos, para poderaplicar los mismos sobre el portador.



A continuacion, se detalla las clases involucradas en la administracion del mensaje estega-nografico.

La clase principal se denomina StegProtocol e implementa operaciones para: leer un mensajea partir de un archivo de texto, escribir el mensaje en un archivo de texto, agregar bits almensaje para construirlo a partir de la lectura esteganografica (permite agregar de a un bit ode a varios), extraer bits del mensaje para ser enviados. Ademas, se implementaron metodospara serializar en una cadena de caracteres un objeto de esta clase con su estado interno8.

Cada uno de los caracteres del mensaje que administra la clase StegProtocol esta formadopor 5 bits. Es decir, se definen 25 = 32 caracteres posibles. Estos son (en orden): las letras enmayusculas de la A a la Z (26 caracteres), el punto, la coma, el caracter espacio, el signo deinterrogacion de cierre, el salto de lınea y un sımbolo para representar el fin del mensaje (e.g. laletra A esta representada por 00000, mientras que el caracter de fin de mensaje esta representadopor 11111). En el apendice C se muestra la codificacion en bits que corresponde a cada letradel alfabeto utilizado. El conjunto de caracteres escogido permite comunicar mensajes de tipotexto en espanol (excepto la representacion de la letra ~N), mientras que minimiza la cantidadde bits necesarios para representar cada caracter9.

De la Clase StegProtocol heredan dos clases que extienden su funcionalidad. Las mismasson:

SingleStegProtocol : Implementa el uso de la clase padre a partir del patron de disenoSingleton[Eri]. La clase se instancia una unica vez al iniciar el proceso y todas las invoca-ciones devuelven una referencia a la unica instancia. Esto permite mantener centralizadala administracion del mensaje esteganografico dentro del proceso.

SharedStegProtocol : Encapsula la administracion del mensaje esteganografico en un areade memoria compartida del sistema operativo (se utilizan las estructuras de comunicacio-nes entre procesos, IPC, que provee el sistema operativo). De este modo, varios procesoscomparten la informacion de estado de una unica instancia de la clase. Esta clase pue-de ser vista como una extension de la implementacion del patron Singleton a multiplesprocesos.

A continuacion se detalla las implementaciones particulares sobre cada uno de los dosprotocolos.

3.2.2. Artefacto sobre el protocolo IP

La version del artefacto correspondiente al protocolo IP esta disenada para ser ejecutadaen un nodo que actue como gateway (enrutador) en la comunicacion IP.

Para la manipulacion de los datagramas IP (i.e. lectura y modificacion) que son enviados atraves de las operaciones de comunicacion del sistema operativo, dentro del ambito del artefactodesarrollado, se decidio utilizar la biblioteca libnetfilter queue10 del proyecto netfilter.org. Estabiblioteca provee una interfaz (API ) que permite acceder en espacio de usuario (en inglesuserspace) a los datagramas que se encuentran en la cola de procesamiento del kernel del sistemaoperativo. Permite modificar el contenido de los datagramas y reinyectarlos en el procesamientodel kernel, y tambien permite rechazar el procesamiento del datagrama. Es decir, permite

8se utiliza el termino serializar para referir a la accion de construir una cadena de bits a partir de una estruc-tura compuesta ubicada en la memoria, en este caso, un objeto. La estructura original puede ser reconstruida apartir de aplicar la operacion inversa sobre la cadena de bits.

9Por ejemplo, el alfabeto ASCII representa a cada caracter con 7 bits, mientras que el ASCII extendidorequiere de 8 bits por caracter. http://www.asciitable.com/

10http://www.netfilter.org/projects/libnetfilter queue/



descartar datagramas. Para realizar el linkeo con dicha biblioteca, en los sistemas operativosutilizados de desarrollo fue necesario instalar esta biblioteca con el siguiente comando:

sudo apt-get install libnetfilter-queue-dev.Cabe mencionar que el kernel de Linux provee funciones para la construccion de datagramas

sin estar sujetos a un protocolo especıfico. Esta funcionalidad permite construir un datagramaa partir de una cadena de bits arbitraria (e.g. podrıa construirse un datagrama que no seasintacticamente valido de acuerdo al protocolo IP). Es decir, es posible construir datagramaspersonalizados. Esta estructura se denomina Raw Sockets[ith08][Mix]. De todos modos, no esposible utilizar esta estructura para cubrir las necesidades del artefacto desarrollado, dado quecon la misma no es posible quitar los datagramas de la pila de procesamiento de la arquitecturade protocolos del kernel11. Por lo tanto cuando se requiere alterar un datagrama (i.e. con elobjetivo de embeber un mensaje esteganografico o limitar la propagacion de los mismos), no sepuede impedir que el sistema operativo procese el datagrama original inalterado. En cambio,este tipo de estructura puede ser utilizado si se desea aplicar esteganografıa por sıntesis deportadores, a diferencia de la modificacion de portadores.

3.2.2.1. Detalle de la implementacion

A continuacion se detalla el diseno de clases para el modulo esteganografico sobre el pro-tocolo IP. Se comienza por el diagrama sintetico12 de clases involucradas que se muestra en lafigura 3.1, luego se describe el rol de cada una de las clases y a continuacion se detallan lastecnicas esteganograficas implementadas.

SingleStegProtocol

StegProtocol IPDatagram

IPStegDatagram

IPSession

IPStegSession

IPHeader1 1

Figura 3.1: Diagrama sintetico de clases del artefacto sobre IP

Esta version del artefacto se desarrolla en un unico proceso del sistema operativo, es decir,es monoproceso. Dado que IP es un protocolo sin conexion, la recepcion de cada datagramaes independiente. Cuando ocurre la recepcion de un datagrama, es invocada la ejecucion deuna funcion que provee la biblioteca libnetfilter queue. Esta funcion es de tipo callback13, yrealiza la invocacion a los metodos que implementan los algoritmos esteganograficos (lector,escritor y guardian). Para la administracion del mensaje esteganografico se utiliza la claseSingleStegProtocol mencionada anteriormente.

La clase IPDatagram modeliza al datagrama IP. Esta compuesta por un encabezado IP y unarea de datos del datagrama. Provee metodos para cargar el datagrama a partir de un bufferde caracteres. La clase IPHeader modeliza el encabezado del datagrama IP. Posee metodospara asignar y obtener cada uno de los campos del encabezado y para cargar el encabezado apartir de un buffer. La implementacion interna del encabezado del datagrama esta sustentada

11http://www.ntua.gr/rin/rawfaq.html#2212Por claridad, en el diagrama se omiten los atributos y metodos de las clases13En espanol el termino es retrollamada.



en un atributo de tipo struct del lenguaje, con cada uno de los campos del datagrama. Deeste modo, la representacion en memoria de este atributo, visto como una cadena de bits,coincide con la cadena de bits correspondientes al datagrama que se comunica por la red. Cabecomentar que la forma en la que se ordenan los bytes (o palabras) que componen cada uno delos campos del datagrama puede ser diferente a la forma en la que se ordenan en la memoriade la computadora. Esta caracterıstica se denomina endianness. En las comunicaciones dered se almacena el byte mas significativo en la posicion de memoria de menor direccion (estaforma se denomina big-endian), mientras que en la computadora de arquitectura Intel, comola utilizada para el desarrollo, el byte mas significativo se coloca en la posicion de memoriade mayor direccion (esta forma se denomina little-endian)[Tan97]. El sistema operativo proveefunciones para cambiar la representacion de los numeros entre una forma y otra de almacenarloen memoria. Estas funciones son utilizadas en la clase IPHeader cada vez que se accede a cadacampo del encabezado del datagrama. Adicionalmente, cada vez que se modifica un valor delencabezado, se recalcula el valor del campo Checksum.

La clase IPSession encapsula una comunicacion de datagramas IP. Realiza las operacionesde inicializacion de las estructuras de la biblioteca libnetfilter queue y configura la funcion call-back para procesar los datagramas recibidos. La funcion callback se implemento como metodoestatico de esta clase. Al invocarse esta funcion, instancia un objeto de la clase IPDatagram,lo carga con el contenido recibido y luego lo reenvıa, para continuar con su procesamiento enel sistema operativo, con la funcion correspondiente de la API de la biblioteca utilizada. Estaclase tiene como responsabilidad el reenvıo de los datagramas sin alterarlos.

La clase IPStegSession hereda de IPSession, encapsula una sesion de comunicacion IP conaplicacion de esteganografıa sobre los datagramas o con un guardian que la impida. Esta clasereimplementa la funcion callback mencionada. La cual, cada vez que se invoca, instancia unobjeto de la clase IPStegDatagram para interpretar el datagrama recibido, y de acuerdo a comose la haya configurado, actua como nodo transparente (reenvıa el datagrama sin modificacion),aplica esteganografıa, lee el estego-mensaje, o aplica ruido sobre el datagrama (actua comoguardian activo).

La clase IPStegDatagram hereda de IPDatagram. Implementa el protocolo de comunicacionesteganografica sobre el datagrama. Tiene un metodo para escribir bits del mensaje estega-nografico en el datagrama (denominado ApplyStegMessageToDatagram), otro metodo paraleer el mensaje esteganografico del datagrama (denominado ReadStegMessageDatagram) y untercer metodo (denominado ApllyWardeningToDatagram) para realizar modificaciones al da-tagrama que impidan la comunicacion del mensaje esteganografico sobre la base de las tecnicasimplementadas en los otros dos metodos.

En la figura 2.3 de la seccion 2.2.1 se mostro que el datagrama debe atravesar la ruta queincluye al emisor y al receptor esteganografico para que pueda realizarse con exito esta comu-nicacion. Para aplicar una prueba de concepto de esta restriccion, se tomo como decision quese aplican las tecnicas del metodo ApplyStegMessageToDatagram solo cuando la direccion IPde destino del datagrama coincida con una direccion configurada inicialmente. En un escenariode rutas estatico predefinido, esto permite suponer que el datagrama pasara por el receptoresteganografico. El cual, de forma analoga, determinara si la direccion IP de origen del data-grama coincide con una direccion configurada inicialmente. Esto permite suponer que al llegaral receptor esteganografico, el datagrama fue reenviado anteriormente por su par emisor.

El metodo de escritura esteganografica (ApplyStegMessageToDatagram) actua solo sobredatagramas IP de version 4. Obtiene bits del mensaje esteganografico a partir de la unicainstancia de la clase singleton SingleStegProtocol y realiza las siguientes operaciones sobre eldatagrama:

Modifica el campo ID. Incorpora dos bits del mensaje sobre este campo. De los 16 bits



que componen a este campo, modifica el bit de la posicion 0 y el de la posicion 8. Encada caso coloca un bit leıdo del mensaje.

Modifica el campo TTL para incorporar un bit del mensaje esteganografico. La inter-pretacion esteganografica que se realiza sobre este campo es de dos estados: es un valoralto (mayor a 120), o es un valor bajo (menor o igual a 120), como se menciono en laexplicacion de este campo en la seccion 2.2.2.

Si el bit del mensaje esteganografico que se debe colocar es un 1, se asigna en este campoel valor 240 (que representa un valor alto), de modo que al llegar el datagrama al receptory ser este campo decrementado en cada nodo de procesamiento permanezca en un valoralto14. Si el bit del mensaje esteganografico que se debe colocar es un 0, se asigna en estecampo el valor 120 que representa un valor bajo (si el valor de este campo previamentees menor a 120, no se modifica).

Modifica el valor del flag reservado (corresponde al bit de la posicion 0 del campo Flags).Coloca en este campo un bit extraıdo del mensaje esteganografico.

Modifica el flag DF, que indica el permiso de fragmentar el datagrama. Realiza estaoperacion solo si el datagrama no esta fragmentado, es decir, si el flag MF y el campo Offsettienen valor 0. En este campo coloca el valor del bit leıdo del mensaje esteganografico.

El campo Opciones es utilizado para la comunicacion esteganografica de forma para-metrizable al lanzar el ejecutable. Se implemento la interpretacion de un parametro deconfiguracion que indica usar alta o baja capacidad esteganografica. Este parametropuede ser visto como una estego-clave ks de tipo binaria (puede tomar solo dos valoresposibles), que modifica el comportamiento del estego-algoritmo.

Si se elige “alta”, se agrega la opcion Record Route al campo de Opciones del datagrama.Esta operacion se realiza solo si el campo Opciones se encuentra vacıo. Si se indica aplicarbaja capacidad esteganografica, no se realiza operacion sobre el campo Opciones. Se puedenotar que el receptor esteganografico debe estar configurado de forma equivalente, parainterpretar correctamente el mensaje.

Esta aplicacion es la mencionada en la descripcion de este tipo de opcion en la seccion2.2.2: se coloca un ruta inicialmente asignada, como si el datagrama ya hubiera transitadopor esos nodos. Para esto, se coloca un conjunto de direcciones en el campo route-datade la opcion y el puntero inicial en el valor igual a la longitud total de la opcion. De estaforma, es posible almacenar hasta 9 direcciones IP, cada una de 32 bits. Las direccionesIP que se colocan corresponden a 32 bits que se extraen del mensaje esteganografico. Espor esto que las mismas pueden ser direcciones inexistentes o invalidas en el ambito dela red o conjunto de redes que atraviesa el datagrama. Si en el mensaje esteganograficohay menos de 32 bits, se completa con bits 0 las posiciones remanentes.

De este modo, este campo permite colocar hasta 9 · 32 = 288 bits del mensaje estega-nografico.

Como se analizo en la seccion 2.2.2, la opcion Record Route posee en el comienzo dela misma un codigo de opcion, la indicacion del largo de la opcion y el puntero a lasiguiente ruta. Cada uno de estos atributos se almacena en 1 byte (8 bits). Luego sealmacenan las direcciones IP de la ruta, cada una de 4 bytes. En la implementacion seha decidido alinear esta opcion al encolumnado de 4 bytes presentado en la descripcion

14En el ejemplo presentado en la seccion citada, el campo era decrementado en 14 unidades en el transito porInternet.



del datagrama. Para ello, se adiciona en el comienzo del campo Opciones una opcion NoOperation, que posee una longitud de 1 byte. De este modo, el ultimo byte de RecordRoute queda alineado a multiplos de 4 bytes, o palabras de 32 bits. Lo cual es un requisitodel protocolo, para la indicacion del tamano del encabezado en el campo IHL.

Analogamente con el protocolo de comunicacion esteganografica implementado, el guardianactivo realiza las siguientes acciones sobre el datagrama:

Si el valor del campo IHL es menor a 5, descarta el datagrama, puesto que el mismopuede ser considerado invalido.

Si el datagrama posee los flags DF y MF simultaneamente con valor 1, descarta el datagra-ma. Puesto que, como se ha detallado en el analisis de los flags, que ambos flags tenganvalor 1 constituye una inconsistencia.

Coloca en 0 el flag DF en el caso que el flag MF y el campo Offset tengan valor 0. Esdecir, prohıbe la fragmentacion del datagrama siempre que el mismo no se encuentrepreviamente fragmentado.

Asigna valor 0 al flag reservado.

Coloca un valor aleatorio en el campo ID, para evitar el uso del mismo para transmitirun mensaje esteganografico.

Coloca aleatoriamente un valor alto o bajo en el campo TTL.

Quita el campo Opciones, para evitar el uso como portador de un mensaje esteganografi-co. Si bien se limita una funcionalidad del protocolo (que indica parametros adicionalessobre el envıo del datagrama), como se menciono, este campo puede almacenar una grancantidad de bits del mensaje esteganografico.

El artefacto desarrollado es configurable a partir de un archivo de configuracion que esindicado como parametro en la invocacion de la ejecucion. El archivo de configuracion es detipo texto. En cada lınea del mismo se indica un parametro de configuracion con la sintaxis:nombre:valor. Donde nombre corresponde al nombre del parametro de configuracion y valor

corresponde al valor que se le asigna al mismo.Los parametros de configuracion son:

name: nombre del proxy esteganografico. Por ejemplo: Alicia, Boby o Walter.

proxy type: tipo de host esteganografico. Los valores posibles para este parametro son:

• transparent : actua como reenvıo de mensajes sin aplicar esteganografıa.

• steg reader : actua como lector de mensajes esteganograficos.

• steg writer : actua como escritor de mensajes esteganograficos.

• warden: actua como guardian esteganografico.

message file: Ruta al archivo de donde se lee el mensaje esteganografico que se deseacomunicar (si se trata de un escritor).

IP address: Direccion IP del emisor esteganografico (si es un lector) o del destinatarioesteganografico (si es un escritor). Este parametro indica que se embeba o extraiga elmensaje esteganografico solo sobre los mensajes que cumplen con esa direccion.



high capacity : si se coloca este parametro con valor true, se incrementa la capacidad paraembeber del portador. Para ello, utiliza el campo Opciones para almacenar la opcionRecord Route. En caso contrario, no se utiliza el campo Opciones. Los valores posiblespara este parametro de configuracion son true y false.

3.2.2.2. Pruebas realizadas

Para las pruebas realizadas en los hosts con funcion de gateway, se ha utilizado el sistemaoperativo GNU/Linux Ubuntu Server15 version 10.10, de 32 bits. Con el objetivo facilitar elarmado de la infraestructura del ambiente de pruebas, estos gateways se han instalado comomaquinas virtuales sobre el software de virtualizacion VirtualBox16.

Para configurar el reenvıo de datagramas IP en los equipos que actuan como gateways,se ha editado el archivo de configuracion /etc/sysctl.conf y se ha colocado el valor 1 enla variable net.ipv4.ip forward17. Por otra parte, para compilar el codigo fuente desarrollado,en los sistemas utilizados, fue necesario instalar el compilador GCC, que no se provee en lainstalacion inicial. Para ello, se ejecuto el comando: sudo apt-get install gcc g++.

Para que el datagrama pueda ser procesado por la biblioteca libnetfilter queue, es necesa-rio indicarlo con el siguiente comando, que es ejecutado previo a la invocacion del artefactodesarrollado: sudo iptables -A FORWARD -j NFQUEUE --queue-num 0.

Usuario Alicia

escritor esteg.

Walter

guard. esteg.

proxy transparente

lector esteg.

Boby192.168.3.1

192.168.3.2 192.168.4.1

192.168.4.2192.168.0.2

192.168.0.70

Red 1 Red 2 Red 3

Figura 3.2: Escenario de pruebas del artefacto sobre IP

Los equipos participantes de las pruebas se comunican entre sı a partir de una interconexionde tres redes. En la Red 1 se encuentran un usuario convencional (que no realiza aplicacionesni lecturas esteganograficas) y Alicia, que actua como router entre la Red 1 y la Red 2. En laRed 2 se encuentra tambien Walter, que actua como router entre la Red 2 y la Red 3. En estaultima se encuentra Boby. En la figura 3.2 se muestra el esquema de interconexion de redes ylos participantes. Se muestra tambien las direcciones IP de cada uno de los participantes enlas redes donde se encuentran conectados. Las lıneas horizontales grisadas en el diagrama de lafigura indican que en esas redes puede haber otros hosts conectados. La figura muestra que siel usuario de la Red 1 desea enviar un datagrama a Boby, el mismo debe pasar necesariamentepor Alicia y Walter (en este escenario no hay otra ruta posible para ir desde ese origen aese destino). Este escenario es una representacion del mencionado caso 4 de la figura 1.2 delcapıtulo 1.

En las pruebas realizadas, Alicia cumple el rol de escritor esteganografico, Boby el de lectory Walter en un caso actua como router transparente (reenvıa los datagramas sin modificarlos)y otro caso como guardian esteganografico.

15http://www.ubuntu.com/business/server/overview16http://www.virtualbox.org/17Esta configuracion no se encuentra activa en la instalacion de la distribucion utilizada.



Se propone comunicar el siguiente mensaje esteganografico, que se encuentra almacenadoen el archivo m.txt : GANAMOS LA BATALLA

Prueba con alta capacidad esteganografica, sin guardian

En la primera prueba se configura la comunicacion con alta capacidad esteganografica. Acontinuacion se muestra el archivo de configuracion de Alicia (alicia.conf ):

name:alicia

proxy_type:steg_writer

message_file:m.txt

IP_address:192.168.4.2

high_capacity:true

A continuacion se muestra el archivo de configuracion de Boby:

name:boby

proxy_type:steg_reader

IP_address:192.168.0.2

high_capacity:true

Para comenzar la prueba, se inicia la ejecucion del artefacto con los respectivos parametrosen cada uno de los participantes. Para realizar el analisis posterior del datagrama, en el equipode Walter se inicia la captura de trafico de la red con tcpdump18, que permite capturar el traficode la red a partir de una aplicacion de lınea de comando (es decir, se ajusta al entorno de lamaquina de pruebas utilizada). El trafico capturado con tcpdump es guardado en un archivopara luego abrirlo con Wireshark, donde se puede realizar el analisis a partir de la interfazgrafica.

Para enviar datagramas desde el host Usuario hacia Boby se decide utilizar el comandoping, que envıa mensajes del protocolo ICMP. Estos mensajes obligan al receptor a responder-los al emisor con el mismo contenido con el cual fue enviado en su campo de datos del protocoloICMP y permiten detectar errores de comunicacion (e.g. perdida de datagramas)[Pos81]. Elcomando ping se puede parametrizar con la cantidad de mensajes que se desea que se envıen(a partir del parametro -c). Se invoca la ejecucion para el envıo de un solo mensaje (-c 1).En la consola de ejecucion del usuario (de nombre Tribilin en el ejemplo), se observa que elcomando ping funciono correctamente. Se copia a continuacion la salida de esa consola:

pablete@Tribilin:~/Escritorio/Tesis/artefacto$ ping -c 1 boby

PING boby (192.168.4.2) 56(84) bytes of data.

64 bytes from boby (192.168.4.2): icmp_req=1 ttl=62 time=19.8 ms

RR: n003-000-000-000.static.ge.com (3.64.199.75)

mx-ll-171.7.66-9.dynamic.3bb.co.th (171.7.66.9)

129.107.7.192

0.0.0.0

0.0.0.0

0.0.0.0

0.0.0.0

0.0.0.0

0.0.0.0

18http://www.tcpdump.org/



--- boby ping statistics ---

1 packets transmitted, 1 received, 0% packet loss, time 0ms

rtt min/avg/max/mdev = 19.811/19.811/19.811/0.000 ms

A continuacion se muestra la salida de la consola de Boby, donde se puede ver que serecibio correctamente el mensaje esteganografico (entre otras indicaciones sobre el datagramarecibido) y el mismo se muestra entre corchetes.

root@boby:/home/boby/artefacto# ./steg_ip boby.conf

Clave: name valor: boby

Clave: proxy_type valor: steg_reader

Clave: IP_address valor: 192.168.0.2

Clave: high_capacity valor: true

Datagrama leido:

Leido: IP HL: 15, IP version: 4, ID IP: 0, TTL: 239, DST: 192.168.4.2

ID leido: 0

ReservedFlag leido: 1

DF leido: 0

Leer Opciones

MENSAJE RECIBIDO: [GANAMOS LA BATALLA]

Datagrama colocado:


La consola de Alicia muestra que se ha aplicado esteganografıa sobre un datagrama, comose puede ver a continuacion:

root@alicia:/home/alicia/artefacto# ./steg_ip alicia.conf

Clave: name valor: alicia

Clave: proxy_type valor: steg_writer

Clave: message_file valor: m.txt

Clave: IP_address valor: 192.168.4.2

Clave: debug valor: true

Clave: high_capacity valor: true

Datagrama leido:


ID leido: 0

ID colocar: 0

TTL leido: 63

TTL colocar: 240

Reserved Flag colocar: 1

DF colocar: 0

Modificar opciones

Datagrama colocado:


A continuacion se pretende mostrar como se comunica el mensaje esteganografico en elejemplo del caso de prueba. Sobre la base de la captura realizada en el equipo de Walter, seanaliza el datagrama modificado por Alicia, en funcion de las tecnicas aplicadas.

La figura 3.3 muestra una porcion de la pantalla de Wireshark con el detalle del datagrama.

Campo ID : el campo ID del datagrama mostrado tiene valor 0. Es decir, son 16 bits 0.Por lo tanto los dos bits colocados por la funcion Emb en este caso son 00.



Figura 3.3: Datagrama capturado en el host Walter, para la primera prueba.

Campo TTL: Tiene valor 240. Es un valor alto. Embebe un bit 1.

Flag reservado: Tiene valor 1. Corresponde a un bit con ese valor del mensaje estega-nografico.

Flag DF : Tiene valor 0. Corresponde a un bit con ese valor del mensaje esteganografico.

Campo Opciones: Dado que se aplica alta capacidad esteganografica, se debe analizar estecampo. Se puede observar que el campo Opciones se encuentra utilizado completamente(tiene una longitud de 40 bytes) y la primera opcion es No Operation, su valor es 01 enrepresentacion hexadecimal, como se ve en la imagen de Wireshark, lo que equivale a losbits 00000001.

A continuacion comienza la opcion Record Route: el primer byte es 07 en hexadecimal,lo que equivale a los bits: 00000111, que es el codigo de esta opcion. El siguiente bytees el largo: 27 en hexadecimal, corresponde a 39 bytes. Es decir, ocupa todo el tamanodel campo Opciones, salvo el primer byte ocupado por la opcion anterior. El tercer bytecontiene el puntero al siguiente lugar vacıo en el espacio de direcciones: 28 en hexadecimal,corresponde al byte 40. Dado que el puntero supera al largo en una unidad, denotaque el area de direcciones esta completa y ningun router intermedio puede agregar masdirecciones (que es lo buscado por la funcion Emb).

Luego, se encuentra el area de direcciones, que contiene los bits del mensaje estega-nografico tal como se extraen del mismo. Es decir, en la implementacion realizada no serealizo una validacion de las direcciones IP resultantes. Si el espacio para colocar bitsdel mensaje esteganografico es mayor que los bits restantes en el mensaje, entonces secompleta con bits 0. En la imagen se ve que hay tres direcciones IP con valores y el restoson ceros.

De la imagen, se ve que los bits representados en hexadecimal son:



03 40 C7 4B AB 07 42 09 81 6B 07 C0.

Esto equivale a la representacion binaria:

0000001101000000110001110100101110101011000001110100001000001001100000010110

10110000011111000000

Con estas tecnicas se puede embeber un total de 293 bits por datagrama (288 bits en elcampo de direcciones IP de Record Route y 5 bits en el resto del encabezado). En consecuencia,la capacidad esteganografica es de 293 bits / datagrama IP. El datagrama modificado tieneuna longitud de 60 bytes, lo que equivale a 480 bits. La tasa esteganografica del algoritmoEmb, medida en cantidad de bits del mensaje esteganografico que es posible embeber sobre lacantidad de bits del portador, para este caso es:

293 bits

480 bits= 0, 610 . . .

Para obtener el mensaje esteganografico, se agrupa los bits de a 5 y, luego de aplicar losreemplazos de equivalencias de caracteres detallados en el apendice C, se obtiene cada caractercorrespondiente. A continuacion se muestra el mensaje a partir de los bits obtenidos:

00110︸︷︷︸6 ≡ G

00000︸︷︷︸0 ≡ A

01101︸︷︷︸13 ≡ N

00000︸︷︷︸0 ≡ A

01100︸︷︷︸12 ≡M

01110︸︷︷︸14 ≡ O

10010︸︷︷︸18 ≡ S

11101︸︷︷︸29 ≡

01011︸︷︷︸11 ≡ L

00000︸︷︷︸0 ≡ A

11101︸︷︷︸29 ≡

00001︸︷︷︸1 ≡ B

00000︸︷︷︸0 ≡ A

10011︸︷︷︸19 ≡ T

00000︸︷︷︸0 ≡ A

01011︸︷︷︸11 ≡ L

01011︸︷︷︸11 ≡ L

00000︸︷︷︸0 ≡ A

11111︸︷︷︸31 ≡ fin de mensaje

Se observa que el mensaje reconstruido coincide con el mensaje esteganografico que sedeseaba comunicar19.

Prueba con baja capacidad esteganografica, sin guardian

Se realiza una nueva prueba, esta vez, se configura a Alicia y Boby para utilizar bajacapacidad esteganografica (el parametro de configuracion high_capacity se coloca con valorfalse). Se mantiene a Walter en el rol de router transparente. Se reinicia la ejecucion de todaslas instancias del artefacto y la captura en Walter con tcpdump. Para comenzar la prueba,se ejecuta el comando ping desde el mismo equipo. Se observa que luego de 19 mensajes delprotocolo ICMP en la consola de Boby aparece el mensaje esteganografico mostrado, al igualque en la primera prueba.

En la consola del usuario de pruebas se observa que el comando ping funciono correctamentepara todos los casos. Lo cual muestra que esta configuracion del artefacto cumple con el objetivode la preservacion semantica, como se observa a continuacion.

pablete@Tribilin:~/Escritorio/Tesis/Informe$ ping -c 19 boby









19Cabe aclarar que los bits que aparecen despues del caracter de fin de mensaje se omiten.















--- boby ping statistics ---

19 packets transmitted, 19 received, 0% packet loss, time 18025ms

rtt min/avg/max/mdev = 11.477/16.540/23.046/2.708 ms

La figura 3.4 muestra el detalle del primer datagrama del trafico capturado en el hostWalter. A continuacion se analiza los componentes del datagrama con respecto a las tecnicasaplicadas.

Figura 3.4: Datagrama capturado en el host Walter, para la segunda prueba.

Campo ID : el campo ID del datagrama mostrado tiene valor 0. Al igual que en la pruebaanterior. Los dos bits colocados por la funcion Emb son 00.

Campo TTL: Tiene el mismo valor que en la primera prueba: un valor alto. Esto embebeun bit 1.

Flag reservado: Tiene valor 1, igual que en la primera prueba.

Flag DF : Tiene valor 0. Corresponde a un bit con ese valor del mensaje esteganografico,de la misma forma que en la primera prueba.

Campo Opciones: No esta presente, como era esperable con la configuracion de bajacapacidad esteganografica. En este caso el encabezado tiene una longitud de 20 bytes



(160 bits), a diferencia del datagrama de la primera prueba que tiene una longitud de 60bytes.

A partir de las tecnicas aplicadas con esta configuracion del artefacto se comunican 5 bitspor datagrama. Es decir, la capacidad esteganografica es de 5 bits / mensaje portador. Seobserva que los 5 bits embebidos en el datagrama de esta prueba coinciden con los primeros 5bits embebidos en el datagrama de la prueba anterior. Para obtener el mensaje esteganograficocompleto se debe realizar el mismo analisis sobre los 19 datagramas. En este caso, la longituddel datagrama es de 20 bytes, es decir, 160 bits. Por lo tanto, la tasa esteganografica delalgoritmo Emb con esta configuracion es:

5 bits

160 bits= 0, 03125

Adicionalmente, se puede observar que en cada datagrama se embeben 5 bits y al mismotiempo, con el alfabeto del protocolo esteganografico implementado, se necesitan 5 bits pararepresentar un caracter. Por lo tanto, con las aplicacion de estas tecnicas, se embebe un caracterdel alfabeto del protocolo esteganografico por cada mensaje portador. El mensaje propuesto enlas pruebas realizadas (GANAMOS LA BATALLA) esta conformado por 19 caracteres del alfabeto(18 corresponden al mensaje propiamente dicho y un caracter adicional de fin de mensaje).Esto muestra que se necesitan 19 datagramas para comunicar este mensaje.

Prueba con guardian esteganografico

A continuacion se presenta una prueba adicional del artefacto para mostrar el funciona-miento del guardian activo. Para esta prueba, se configura a Alicia y Boby con alta capacidadesteganografica, como en el primer caso, y a Walter en este caso con el rol de guardian es-teganografico. Se reinicia la ejecucion de las aplicaciones y se inicia una captura del traficode red con tcpdump en el host Boby (el objetivo es mostrar el datagrama recibido luego delas modificaciones introducidas por Walter). Se inicia la ejecucion del comando ping en lamisma consola de pruebas. Se observa que luego de mas de 20 ejecuciones Boby no recibe elmensaje esteganografico. En la consola de pruebas, se observa que el comando ping funcionacorrectamente, lo cual indica que el guardian activo permite la realizacion de la comunicaciongenuina.

Se muestra a continuacion un fragmento de la ejecucion del comando ping.

pablete@Tribilin:~/Escritorio/Tesis/Informe$ ping -c 19 boby







La figura 3.5 muestra el detalle del primer datagrama capturado en Boby. Este datagra-ma permite efectuar el mismo analisis que el realizado para la reconstruccion del mensajeesteganografico en las pruebas anteriores, como se presenta a continuacion.

Campo ID : el campo ID del datagrama mostrado tiene valor 0. La funcion Ext interpretalos bits 00.

Campo TTL: Tiene un valor bajo (65). Esto es interpretado por la funcion Ext como unbit 0.



Figura 3.5: Datagrama capturado en el host Boby, para la tercera prueba, con Walter como guardianactivo.

Flag reservado: Tiene valor 0.

Flag DF : Tiene valor 0.

Campo Opciones: No se encuentra presente. El guardian esteganografico quito este cam-po.

En consecuencia, el receptor esteganografico interpreta los siguientes 5 bits: 00000, quecorresponden a la letra A. Asimismo, el receptor no recibe los 288 bits colocados por la funcionEmb, dado que el campo Opciones fue eliminado por el guardian.

Por lo tanto, el guardian activo cumple correctamente con su objetivo de evitar la propaga-cion de la comunicacion esteganografica y, a la vez, permite la realizacion de la comunicaciongenuina.

Por otra parte, se puede notar que si bien en esta prueba y en la primera se configuro altacapacidad esteganografica (es decir, a los datagramas se les incorporo la opcion Record Route),en la primera prueba se observa que el comando ping muestra, debajo de la confirmacion derecepcion del mensaje, la lista de direcciones IP. Tal es el caso de la siguiente, que aparece enprimer termino:

RR: n003-000-000-000.static.ge.com (3.64.199.75)

El prefijo RR indica que se trata de la opcion Record Route. Ademas, el comando ping

intenta obtener el nombre que corresponde a esa direccion IP (3.64.199.75).Este listado de direcciones IP no se observa en la ultima prueba, ya que el guardian este-

ganografico elimino el campo Opciones y, en consecuencia, la opcion Record Route. Tampocose observa en la prueba realizada con baja capacidad esteganografica.

Como conclusion de lo expuesto, se puede decir que si bien las tecnicas implementadas parala configuracion de alta capacidad esteganografica tienen una gran tasa esteganografica com-parado con la version de baja capacidad esteganografica, poseen un impacto en la invisibilidaddel esquema esteganografico. En otras palabras, la aparicion de la lista de direcciones dentrodel resultado del comando ping puede levantar sospecha frente a un observador externo.



3.2.3. Artefacto sobre el protocolo HTTP

La implementacion del artefacto sobre este protocolo actua como Proxy HTTP en la co-municacion entre el cliente (un navegador web, e.g. Mozilla Firefox ) y un servidor (e.g. ApacheWeb Server).

Se desarrollo un proxy que puede ser configurado para actuar con alguno de los siguien-tes roles: proxy transparente (reenvıa los mensajes que recibe, sin modificarlos), escritor es-teganografico (embebe porciones del mensaje esteganografico en el mensaje HTTP), lectoresteganografico (interpreta el mensaje esteganografico en el mensaje recibido) o guardian ac-tivo esteganografico (introduce ruido en el mensaje para evitar la aplicacion de las tecnicasesteganograficas, sin alterar las comunicaciones genuinas).

En la seccion 2.4 se menciono que la existencia de dos tipos de mensajes HTTP (i.e.mensajes de pedido y mensajes de respuesta) obliga a la aplicacion de tecnicas especıficassobre cada tipo de mensaje portador. En este sentido, el rol de emisor y lector esteganograficodel artefacto se diseno configurable para indicar si se desea aplicar esteganografıa sobre elmensaje de pedido o sobre el de respuesta20.

Se puede observar en este caso que es necesario que el proxy que realiza la escritura este-ganografica realice su comunicacion hacia otro proxy, y que la cadena de reenvıos entre proxysdebe incluir al receptor esteganografico. A diferencia de lo implementado para el protocoloIP, el emisor esteganografico aplica su algoritmo sobre todos los mensajes que debe reenviar,independientemente del destino final. Por ejemplo, si debe actuar sobre los mensajes de pedido,aplica su mensaje a todos los mensajes de pedido que deba reenviar. Lo mismo ocurre parael receptor esteganografico: aplica el algoritmo de lectura sobre todos los mensajes que recibe,independientemente del origen. La diferencia con el caso de IP es que los mensajes HTTP estandirigidos al servidor y deben atravesar los reenvıos de los proxys, mientras que los datagramasIP pueden estar destinados a un host en una red intermedia y no necesariamente atravesartodos los routers.

3.2.3.1. Detalle de la implementacion

En la figura 3.6 se muestra el diagrama de clases sintetico de las clases involucradas en estaversion del artefacto y a continuacion se describe cada una de ellas.

SharedStegProtocol

StegProtocol

HTTPHeader HTTPHeaderFieldHTTPMessage1 1

HTTPProxy

1 *

HTTPConnection

TCPSockect TCPSockect

1 *

(cliente) (servidor)

Figura 3.6: Diagrama de clases sintetico del artefacto sobre HTTP

La clase principal del proxy HTTP es HTTPProxy. Esta clase posee un metodo Setup que esinvocado con los parametros de configuracion para su funcionamiento: puerto TCP donde debeesperar conexiones entrantes, nombre del proxy (e.g. “Alicia”), tipo de proxy (transparente,lector, escritor o guardian esteganografico), sentido en el que se aplica esteganografıa (en los

20Se ha mencionado que la implementacion del protocolo esteganografico desarrollado en el artefacto es uni-direccional, half-duplex.



mensajes de pedido o de respuesta), nombre o direccion del proxy HTTP al que se debe conectaral reenviar los mensajes (en caso de poseer otro proxy en la cadena de reenvıos) y puerto TCPde ese proxy de destino. La ejecucion de este metodo queda a la espera de conexiones entrantesen el puerto de espera (queda bloqueada en la funcion accept del socket). Cuando recibe unaconexion entrante de un cliente, crea otro proceso (a partir de la invocacion a la funcion fork()del sistema operativo) y lo inicializa con el metodo SetupClient de esta misma clase. Es decir,por cada cliente que se conecta al servidor se crea un nuevo proceso.

El metodo SetupClient atiende los pedidos del cliente, el cual esta conectado a traves delsocket TCPSocket (cliente) incluido en la figura 3.6. Recibe del buffer de la conexion unacadena de bytes hasta completar el contenido de un mensaje HTTP. El buffer recibido esinterpretado por la clase HTTPMessage. Con el mensaje recibido, determina si se debe aplicaresteganografıa sobre el mismo, en caso afirmativo, invoca a los metodos correspondientes dela clase HTTPMessage, luego invoca el reenvıo del mensaje procesado (implementado en elmetodo SendHTTPMessage).

Para el envıo de mensajes de pedido, HTTPProxy mantiene una lista de conexiones salien-tes, modelizadas por la clase HTTPConnection (representada en la figura 3.6). Si no se habıaenviado un mensaje anteriormente al destino (un proxy siguiente en la cadena de envıos o elservidor final), se construye un objeto de la clase HTTPConnection, se realiza la conexion aldestino y se envıa el mensaje.

Cada vez que se establece una nueva conexion con un destino del mensaje de pedido, secrea un nuevo proceso (con la invocacion a fork()) con la finalidad de atender las respuestasdel servidor o proxy de destino. Es decir, se crea un nuevo proceso por cada nuevo destinodel mensaje que se debe atender (si el mensaje de pedido debe ser enviado a un unico proxy,se establece una sola conexion). El nuevo proceso es inicializado con el metodo SetupServer yopera de forma analoga al que espera el envıo de mensajes del cliente: recibe el mensaje, aplicalos algoritmos esteganograficos sobre el mismo y lo reenvıa al cliente a traves de la conexionestablecida mencionada anteriormente.

Los algoritmos esteganograficos (lectura, escritura, adicion de ruido por el guardian activo)estan implementados en la clase HTTPMessage. Esta clase implementa los metodos para inter-pretar un mensaje HTTP completo a partir de un buffer. El mensaje interpretado es separadoen sus piezas componentes: lınea de pedido (si es un mensaje de pedido) o lınea de estado (sies un mensaje de respuesta), conjunto de campos con sus valores y cuerpo del mensaje. Deforma analoga, puede reconstruir una cadena de caracteres a partir de concatenar las partescomponentes del mensaje para obtener un mensaje para enviar.

El conjunto de campos del encabezado que componen el mensaje HTTP esta modelizadopor la clase HTTPHeader. Esta clase contiene metodos para agregar, eliminar y modificar elcontenido y el nombre de los campos. Los campos se organizan en una lista que puede conteneruno o mas objetos de la clase HTTPHeaderField. Esta clase posee los metodos para acceder ymanipular cada campo en particular.

Dado que se ejecutan multiples procesos, el mensaje esteganografico es administrado por laclase SingleStegProtocol que utiliza para almacenarlo una estructura de memoria compartida(shared memory). El acceso a esta memoria es regulado a partir del uso de un semaforo.Ambas estructuras y sus funciones de acceso son provistas por el sistema operativo. El uso delsemaforo fue encapsulado en una clase a tal efecto (no incluida en el diagrama de clases, porser considerado de un rol auxiliar). Esta clase provee dos metodos Wait() y Signal(), el primerodeja al proceso en espera hasta la liberacion del semaforo, el segundo libera al semaforo. Elprocesamiento del mensaje HTTP, realizado en la clase HTTPProxy espera la liberacion delsemaforo (Wait()), obtiene el mensaje esteganografico del area de memoria compartida (tantopara leerlo como para escribirlo), aplica el algoritmo esteganografico para obtener el portador



modificado, luego envıa el mensaje y libera el semaforo (Signal()).A continuacion se describe las tecnicas esteganograficas aplicadas y el protocolo propuesto

que se ha implementado sobre el mensaje de pedido, en el orden en que se realizan sobre elportador:

Se agrega el campo de encabezado correspondiente a la direccion de correo electronico(el campo From). Si este campo ya existıa en el mensaje, no se aplica la tecnica. En estecampo se embebe un solo bit del mensaje esteganografico: si se debe colocar un bit devalor 1, se coloca como contenido de campo la direccion [email protected].

Si se debe colocar un bit 0, se coloca la direccion [email protected].

Cabe mencionar que, al ser la direccion de correo electronico un campo formado por unacadena de caracteres, podrıa ser utilizado para embeber mayor cantidad bits del mensajeesteganografico. Con el artefacto desarrollado se pretende mostrar la factibilidad del usode este campo con estos fines.

Se incorpora un campo propietario. En este campo se embebe un bit del mensaje es-teganografico. Si se debe agregar un bit de valor 1, se agrega un campo con el nombreExample1, si se debe agregar un bit de valor 0, se agrega un campo con el nombre Exam-ple0.

Cuando se trata de un mensaje dirigido a un servidor en el puerto 80, se embebe un bit apartir de indicar explıcitamente o no el valor 80, que es el valor de puerto estandar. Estamodificacion se realiza tanto en la lınea de pedido, cuanto en el contenido del campoHost. Si se debe colocar un bit de valor 1, se indica explıcitamente el valor 80, en casocontrario, se quita el numero 80.

Se transforma un campo que contiene una lista de valores en multiples campos, cada unocon un unico valor de la lista. Esto se realiza en virtud de lo permitido por la especificacionen el manejo de campos con valores de listas. El campo que se decide modificar de estaforma es Accept-Charset. Como se ha descripto anteriormente, este campo contiene unalista de codificaciones de caracteres que el cliente puede aceptar. En este campo se embebeun bit. Si se debe colocar un bit de valor 1, se convierte el campo con la lista a multiplescampos. Para embeber un bit de valor 0, se coloca la lista en un unico campo.

Se agregan comentarios, que son indicados entre parentesis en el valor del campo. Sedecidio colocar comentarios en el campo User-Agent, que contiene informacion acerca delsoftware que utiliza el usuario. Se coloca un comentario compuesto por 3 letras. Cadaletra esta formada por 5 bits que se extraen del mensaje esteganografico. Para obtenerun valor que corresponda a un caracter imprimible, el valor de los 5 bits (que puede estarcomprendido entre 0 y 31) se suma al valor del caracter arroba (@) en la codificacionASCII utilizada por el lenguaje de programacion.

En consecuencia, con esta tecnica se embeben 15 bits del mensaje esteganografico.

Se reordenan los campos del encabezado. Los campos se reordenan de a pares. Para ello,se contabiliza la cantidad de campos de nombre diferente que contiene el mensaje (loscampos de igual nombre son colocados juntos). Luego, se divide esa cantidad por 2 (si seobtiene un valor no entero, se toma la parte entera). La cantidad obtenida es la cantidadde bits que se embeben con esta tecnica en el mensaje portador especıfico. Se extrae delmensaje esteganografico tantos bits como los que se debe colocar. Inicialmente se ordenanlos campos alfabeticamente. Se toman los campos de a pares y se reordenan entre sı dela siguiente manera: si el bit del mensaje esteganografico es de valor 1, se coloca primero



el campo mayor segun el orden alfabetico, y si el bit es de valor 0, se coloca primero elcampo menor en orden alfabetico. Se repite el procedimiento hasta colocar todos los bits.

Se aplica folding al contenido de los campos. El folding permite representar un caracterespacio (SP) por un salto de lınea mas un espacio. Se contabiliza la cantidad de camposque poseen al menos un caracter espacio en su contenido. Esta es la cantidad de bitsdel mensaje esteganografico que se embebe con esta tecnica. Se arma una lista de bits(extraıdos del mensaje esteganografico) cuyo tamano es la cantidad de bits a colocar.Por cada campo con un espacio, si el bit a colocar tiene valor 1, se aplica folding. Si, encambio, el bit tiene valor 0, se quita el folding del campo.

Se agregan caracteres LWS (caracter espacio o tabulador) al comienzo del valor de cadacampo (dado que son ignorados en la interpretacion del contenido del campo). En cadacampo se embeben 3 bits. Si el ultimo bit de los tres es un 1, se agregan tabuladores, sies un 0, se agregan espacios. Con los otros dos bits se forma un numero (de 0 a 3), se loincrementa en una unidad y el valor obtenido es la cantidad de espacios o tabuladoresque se colocan al comienzo del valor del campo.

Se modifican las mayusculas y minusculas de los nombres de cada campo, dado quesegun la especificacion se ignora si el nombre se encuentra en mayusculas o minusculas.Se embebe un bit en cada campo. Si el bit del mensaje es un 1, se coloca la primeraletra del nombre del campo en mayusculas, si el bit es un 0, se coloca la primera letradel nombre del campo en minusculas.

En este caso tambien podrıa haberse decidido modificar las mayusculas y minusculas demas de una letra del nombre del campo, con la finalidad de embeber mas de un bit encada campo.

Se embebe un bit del mensaje esteganografico en una lınea adicional antes de la lınea depedido del mensaje. Si el bit del mensaje es un 1, se agrega una lınea adicional antes dela lınea de pedido. En caso contrario, se quita la posible lınea adicional.

Se embebe un bit en la forma de escribir la version HTTP del mensaje en la lınea depedido. Dado que es equivalente colocar HTTP/1.1 que HTTP/01.1, si se debe colocar unbit de valor 1 del mensaje, se utiliza la segunda forma, y para colocar un bit de valor 0,se utiliza la primera. Esta tecnica se aplica solo si la version HTTP del mensaje portadores 1.1.

A continuacion se describe las operaciones que realiza el guardian esteganografico imple-mentado sobre el mensaje de pedido, tendientes a evitar la eficacia de las tecnicas anteriores:

Se quita el folding de todos los campos.

Se quita todos los caracteres LWS del comienzo del valor del campo.

Se coloca en minusculas los nombres de todos los campos.

Se quita todas las lıneas en blanco antes de la lınea de pedido.

Se quita todos los comentarios de todos los campos (esto limita una funcionalidad delprotocolo, aunque no esencial).

Se cambia el orden de los campos en el encabezado. Se los ordena alfabeticamente.

Se transforma en un unico campo el campo Accept-Charset (esto se podrıa aplicar, adi-cionalmente, sobre cualquier campo de tipo lista).



Se quita el numero de puerto, cuando se trata del puerto 80.

Se quita el campo From, para colocar la direccion de correo electronico del usuario (estaaccion limita una prestacion no esencial del protocolo, como se comento en la explicacionrespectiva).

Se quita los campos desconocidos (i.e. propietarios), no definidos por la especificacion.De las pruebas realizadas, se encontro que existen campos que no estan definidos en laespecificacion del protocolo estudiada, pero que son de uso comun en las comunicacionesentre cliente y servidor actualmente, estos son: Proxy-Connection, Cookie y Set-Cookie.Por lo tanto, estos campos tambien se conservan.

Se modifica la forma en la que se indica la version de HTTP del mensaje en la lınea depedido. Se reemplaza HTTP/01.1 por HTTP/1.1.

A continuacion se enumeran las tecnicas aplicadas sobre los mensajes de respuesta porparte del escritor esteganografico.

Se incorpora un campo propietario, de forma equivalente a la realizada para el mensajede pedido.

Se agregan caracteres LWS al comienzo de los valores de todos los campos. Se embeben 3bits del mensaje esteganografico por cada campo.

Se modifican las mayusculas y minusculas del nombre de los campos, de forma equivalentea lo que se realiza para el mensaje de pedido. Se embebe un bit en cada campo.

Se agregan comentarios en el campo Server, que contiene informacion sobre la identi-ficacion del servidor, de forma analoga a la informacion sobre el cliente en el campoUser-Agent. Al igual que para el mensaje de pedido, se embeben 15 bits con esta tecnica.

Las siguientes son las modificaciones que aplica el guardian esteganografico sobre los men-sajes de respuesta:

Se quita el folding de todos los campos.

Se quitan los caracteres LWS del comienzo de todos los campos.

Se coloca en minusculas los nombres de todos los campos.

Se quitan los comentarios de todos los campos (nuevamente, se ve alterada una prestaciondel protocolo, aunque no esencial).

Se modifica el orden de los campos en el encabezado: se los ordena alfabeticamente.

Se quitan los campos desconocidos o propietarios, al igual que sobre el mensaje de pedido.

El artefacto desarrollado es configurable a partir de un archivo de configuracion que esindicado como parametro en la invocacion de la ejecucion, al igual que lo mostrado para elartefacto sobre IP.

Los parametros de configuracion son:

name: nombre del proxy esteganografico. Por ejemplo: Alicia, Boby o Walter.

port : puerto TCP donde espera conexiones el proxy. Por ejemplo: 5556.

proxy type: tipo de host esteganografico. Los valores posibles para este parametro son:



• transparent : actua como reenvıo de mensajes sin aplicar esteganografıa.

• steg reader : actua como lector de mensajes esteganograficos.

• steg writer : actua como escritor de mensajes esteganograficos.

• warden: actua como guardian esteganografico.

message file: Ruta al archivo de donde se lee el mensaje esteganografico que se deseacomunicar (si se trata de un lector).

steg direction: sentido de la comunicacion en el que se envıa el mensaje esteganografico(corresponde al tipo de mensajes sobre el que se aplican las tecnicas esteganograficas).Las opciones para este parametro son:

• to server : se toma como portador solo a los mensajes de pedido (los que envıa elcliente al servidor).

• to client : se toma como portador solo a los mensajes de respuesta (los que envıa elservidor al cliente).

proxy dest name: direccion o nombre del proxy al que se debe conectar este proxy. Esteparametro es opcional, si no se indica, se asume que el proxy se comunica directamentecon los servidores finales.

proxy dest port : puerto TCP del proxy al que se debe conectar este proxy. Al igual queel parametro proxy dest name, es opcional.

3.2.3.2. Pruebas realizadas

Prueba sin guardian esteganografico

Se plantea el siguiente escenario para realizar pruebas y analisis sobre el artefacto construi-do. Se utiliza como cliente el navegador Mozilla Firefox version 8.0, se utiliza un servidor webinstalado en la computadora de pruebas Apache version 2.2.2021, se ejecutan tres instanciasdel artefacto como proxy: un escritor (denominado Alicia), un lector (denominado Boby), y untercer proxy con el rol de proxy transparente en un caso de prueba y guardian esteganografi-co en otro caso de prueba (denominado Walter). Todos los participantes se encuentran en lamisma computadora. La ruta de comunicacion entre los mismos se muestra en el esquema dela figura 3.7.

Cliente

Mozilla Firefox

Alicia

Proxy HTTP

escritor esteg.

Walter

Proxy HTTP

guard. esteg.

proxy transparente

Proxy HTTP

lector esteg.

Boby

pedido

respuesta

Servidor

Apache HTTP Server

Figura 3.7: Ruta de comunicacion entre los participantes de las pruebas del artefacto HTTP

Se realiza la prueba de aplicacion esteganografica sobre los mensajes de pedido (i.e. los quese dirigen hacia el servidor). El proxy Alicia espera conexiones en el puerto 5556 y se conecta aun proxy en el puerto 5558 del mismo host (i.e. localhost), el mensaje esteganografico se lee delarchivo mensaje.txt. A continuacion se muestra el archivo de configuracion del proxy Alicia:

21instalado a partir del sistema de instalacion de la distribucion del sistema operativo utilizado



port:5556

name:alicia

proxy_type:steg_writer

message_file:mensaje.txt

steg_direction:to_server

proxy_dest_name:localhost

proxy_dest_port:5558

El proxy Walter se configura para que espere conexiones en el puerto 5558 y se conectea un proxy en el puerto 5557 del mismo equipo. A continuacion se muestra el archivo deconfiguracion del mismo para el caso de prueba en el que actua como proxy transparente:

port:5558

name:walter

proxy_type:transparent

proxy_dest_name:localhost

proxy_dest_port:5557

El proxy Boby se configura para que espere conexiones en el puerto 5557. El archivo deconfiguracion es el que se muestra a continuacion:

port:5557

name:boby

proxy_type:steg_reader

steg_direction:to_server

Se configura el navegador Mozilla Firefox para que realice sus conexiones a traves del proxyAlicia. Esto se realiza en la pantalla de configuracion de la conexion dentro de las preferenciasavanzadas de la red, como se muestra en la figura 3.8.

Figura 3.8: Configuracion de Mozilla Firefox para utilizar como proxy a Alicia (puerto 5556)

En el archivo mensaje.txt se coloca el siguiente mensaje esteganografico que Alicia debecomunicar a Boby: NOS VEMOS EL VIERNES

Se tiene en el directorio publico del servidor web un sitio formado por gran cantidad dearchivos HTML que tienen enlaces entre sı22 que, a partir de accederlos con el navegador web,permiten generar un escenario de trafico genuino para ser utilizado como portadores.

22El sitio corresponde a un archivo de informacion genealogica desarrollado con el software Genopro(http://www.genopro.com/ ).



Se ejecutan las tres instancias diferentes del artefacto (el archivo ejecutable generado por elMakefile tiene el nombre: steg_http). Cada instancia en una consola diferente, con el parame-tro correspondiente a la ruta al archivo de configuracion respectivo. Inmediatamente se iniciala captura del trafico con Wireshark. En la primera prueba, Walter cumple el rol de proxytransparente.

Se inicia la navegacion por el sitio en Mozilla Firefox: se hace click en los enlaces que setienen en las paginas web accedidas. Se observa que el acceso al sitio funciona correctamente(i.e. de la misma forma que sin el uso del proxy). En la salida por consola de Boby se observaque luego de dos mensajes HTTP (correspondientes a seguir dos enlaces del sitio) se ha recibidoel mensaje esteganografico propuesto y el mismo es mostrado en pantalla.

A continuacion se muestra la salida por pantalla de la consola de Alicia. La primera lıneacorresponde a la invocacion del ejecutable:

pablete@Tribilin:~/Escritorio/Tesis/artefacto$ ./steg_http alicia.conf

proxy_name: alicia

Este es el proceso servidor: 22938

Hacer open pasivo en: 5556

server: socket creado 3

server: se hizo el bind

Server: se hizo el listen con el socket 3

Conexion entrante establecida

Iniciado el proceso hijo: 22942

[+] Aplicar esteganografia al mensaje de pedido.

connect(localhost, 5558)

Iniciado el proceso que recibe pedidos del servidor: 22943

[+] Aplicar esteganografia al mensaje de pedido.

A continuacion se muestra la salida por pantalla de la consola de Boby. Se puede observarque se realizaron lecturas esteganograficas sobre dos portadores (i.e. los mensajes de pedido),y a continuacion se muestra (entre corchetes) el texto del mensaje esteganografico:

pablete@Tribilin:~/Escritorio/Tesis/artefacto$ ./steg_http boby.conf

proxy_name: boby








[-] Leer esteganografia del mensaje de pedido.




MENSAJE RECIBIDO: [NOS VEMOS EL VIERNES]

A continuacion se muestra la salida por pantalla de la consola de Walter:

pablete@Tribilin:~/Escritorio/Tesis/artefacto$ ./steg_http walter.conf












En la figura 3.9 se muestra una imagen de pantalla de Wireshark con la primera porcion dela captura del trafico entre Boby y el servidor web. La pantalla mostrada es la que correspondea la funcionalidad de seguimiento de una comunicacion TCP entre dos partes, a diferencia delas pantallas mostradas en los casos anteriores, que corresponden al detalle de un datagrama.En esta pantalla se observa el primer mensaje de pedido con su respuesta y el segundo mensajede pedido. El mensaje de respuesta se encuentra intacto, tal como lo genero el servidor (seconfiguro la aplicacion de esteganografıa para los mensajes de pedido). Se puede observar queel cuerpo del mensaje fue comprimido por el servidor para enviarlo al cliente (el mensaje incluyeel campo Content-Encoding con el valor gzip).

Figura 3.9: Pantalla de Wireshark con la captura (parcial) del trafico entre Boby y el servidor web.

Para mostrar como se obtiene el mensaje esteganografico embebido, a continuacion seanaliza el primer mensaje de pedido de la figura 3.9 sobre la base de las tecnicas esteganograficas



descriptas que se han aplicado sobre el mismo, en el orden en que se han aplicado.

Campo From: Esta presente y su contenido es: [email protected]. Corresponde aun bit 0.

Campo propietario: Se encuentra el campo Example1. Corresponde a un bit 1.

Colocar explıcitamente el numero de puerto 80: el puerto del servidor es el 80 y el numeroesta explıcitamente colocado, por lo tanto, representa un bit de valor 1.

Campo Accept-Charset como lista en un solo campo o multiples veces el mismo campo:Accept-Charset esta presente y se encuentra en un unico campo como una lista de valores.Representa un bit 0.

Comentarios en el campo User-Agent : En este campo, el ultimo comentario presente esWIN, cada letra representa 5 bits del mensaje esteganografico.

• El valor de la letra W es 87. Codifica al numero 87 − 64 = 2323. Corresponde a losbits 10111.

• El valor de la letra I es 73. Codifica al numero 73− 64 = 9. Corresponde a los bits01001.

• El valor de la letra N es 78. Codifica al numero 78− 64 = 14. Corresponde a los bits01110.

En consecuencia, los 15 bits embebidos en este campo son: 101110100101110.

Reordenamiento de los campos de a pares:

• Accept-Charset y accept24: el mayor esta primero25. Corresponde a un bit 1.

• Accept-Language y Accept-Encoding : el mayor esta primero. Corresponde a un bit1.

• Example1 y From26: el menor esta primero. Corresponde a un bit 0.

• Proxy-Connection y host : el mayor esta primero. Corresponde a un bit 1.

• Referer y User-Agent : el menor esta primero. Corresponde a un bit 0.

Con esta tecnica se embebieron, en este caso, 5 bits. Estos son: 11010.

Folding sobre los campos: Los campos que tienen espacios en su contenido son Accept-Encoding y User-Agent.

• Accept-Encoding posee folding. Corresponde a un bit 1.

• User-Agent no posee folding. Corresponde a un bit 0.

Con esta tecnica se embebieron, en este caso, 2 bits. Estos son: 10.

Caracteres LWS al comienzo del valor de cada campo: en cada campo se embeben 3 bits.

• Al comienzo del valor de Accept-Charset hay dos espacios: los dos primeros bitscorresponden a un 1, esto es: 01. El ultimo bit corresponde a un 0. Los tres bits deeste campo son: 010.

2364 es el valor del caracter @.24el ordenamiento no toma en cuenta mayusculas y minusculas.25si un termino contiene a otro y es mas largo que ese, entonces es posterior alfabeticamente.26se puede notar que ambos campos fueron incorporados en pasos anteriores de la funcion Emb.



• Al comienzo del valor de accept hay un caracter tabulador27. Corresponde a los bits001 (el ultimo bit es 1 por ser un tabulador).

• Al comienzo del valor de Accept-Language hay tres espacios. Los tres bits de estecampo son: 100.

• Al comienzo del valor de Accept-Encoding hay dos tabuladores. Los tres bits de estecampo son: 011.

• Al comienzo del valor de Example1 hay tres tabuladores. Los tres bits de este camposon: 101.

• Al comienzo del valor de From hay un tabulador. Los tres bits de este campo son:001.

• Al comienzo del valor de Proxy-Connection hay dos tabuladores. Los tres bits deeste campo son: 011.

• Al comienzo del valor de host hay tres tabuladores. Los bits de este campo son: 101.

• Al comienzo del valor de Referer hay un tabulador. Los bits de este campo son: 001.

• Al comienzo del valor de User-Agent hay un espacio. Los bits de este campo son:000.

Con esta tecnica, en este portador se embebieron los siguientes 30 bits del mensajeesteganografico: 010001100011101001011101001000

Mayusculas y minusculas del nombre de los campos:

• Accept-Charset : comienza con mayusculas. Embebe un bit 1.

• accept : comienza con minusculas. Embebe un bit 0.

• Accept-Language: comienza con mayusculas. Embebe un bit 1.

• Accept-Encoding : comienza con mayusculas. Embebe un bit 1.

• Example1 : comienza con mayusculas. Embebe un bit 1.

• From: comienza con mayusculas. Embebe un bit 1.

• Proxy-Connection: comienza con mayusculas. Embebe un bit 1.

• host : comienza con minusculas. Embebe un bit 0.

• Referer : comienza con mayusculas. Embebe un bit 1.

• User-Agent : comienza con mayusculas. Embebe un bit 1.

Los bits embebidos con esta tecnica en este portador son: 1011111011.

Lınea adicional antes de la lınea de pedido: no se encuentra una lınea antes de la lıneade pedido (la palabra GET esta en la primera lınea). Embebe un bit de valor 0.

Sobre la forma de escribir la version HTTP del mensaje: la version HTTP esta escritacomo HTTP/01.1. Embebe un bit de valor 1.

Con estas tecnicas se embebieron un total de 68 bits. Para obtener el mensaje estega-nografico, se los agrupa de a 5 y se obtiene cada caracter correspondiente, como se muestra acontinuacion:

27en la captura de pantalla de Wireshark de la figura 3.9, el tabulador se ve como un punto, de esta manera sediferencia visualmente del caracter espacio. En general, todos los caracteres que no tengan una representacionimprimible son mostrados por Wireshark con un punto.



01101︸︷︷︸13 ≡ N

01110︸︷︷︸14 ≡ O

10010︸︷︷︸18 ≡ S

11101︸︷︷︸29 ≡

10101︸︷︷︸21 ≡ V

00100︸︷︷︸4 ≡ E

01100︸︷︷︸12 ≡M

01110︸︷︷︸14 ≡ O

10010︸︷︷︸18 ≡ S

11101︸︷︷︸29 ≡

00100︸︷︷︸4 ≡ E

01011︸︷︷︸11 ≡ L

11101︸︷︷︸29 ≡

101

Con 68 bits, se comunicaron 13 caracteres del alfabeto esteganografico propuesto y 3 bitsadicionales. Se observa que el mensaje parcial transmitido es “NOS VEMOS EL ”. Si se repiteel mismo analisis para el segundo mensaje de pedido, se obtiene el mensaje esteganograficocompleto recibido por Boby.

En este caso, el mensaje portador (i.e. el encabezado HTTP del mensaje de pedido) tieneuna longitud de 511 bytes, lo que equivale a 4.088 bits. Esta longitud corresponde al mensajemodificado por la funcion Emb, tal como es el que procesa el servidor. La tasa esteganograficadel algoritmo Emb implementado aplicado sobre el portador analizado es:

68 bits

4,088 bits= 0, 016 . . .

La capacidad esteganografica es de 68 bits / mensaje HTTP.El mensaje esteganografico propuesto tiene una longitud de 21 caracteres (20 letras y el

caracter de fin de mensaje), los cuales se representan en 21 · 5 = 105 bits. Dada la capacidadesteganografica de 68 bits / mensaje HTTP, la longitud relativa del mensaje esteganograficopor la capacidad esteganografica del protocolo esteganografico implementado es:

105 bits

68 bits= 1, 54 . . .

El mensaje esteganografico propuesto debe ser fragmentado en d1, 54 . . .e = 2 partes. Esdecir, se necesitan 2 mensajes portadores para transmitir el mensaje esteganografico propuesto,que coincide con lo observado en la ejecucion del artefacto en la consola de Boby.

Prueba con guardian esteganografico

Como segunda prueba del presente artefacto, se configuro a Walter para que actue con elrol de guardian esteganografico, se reinicio la ejecucion de todos los proxys y la captura deWireshark y se realizo nuevamente la navegacion sobre el sitio web con Mozilla Firefox.

Se observo que la navegacion del sitio se realizo correctamente, al igual que en la pruebaanterior. Por otra parte, en la consola de Boby, luego de haber visitado mas de diez enlacesentre archivos (donde cada uno genera un mensaje HTTP portador), no se habıa recibido elmensaje esteganografico. Esto denota que el guardian cumplio con su objetivo.

A continuacion se copia la salida mostrada en la pantalla de la consola de Boby (que en laprimera prueba mostro el mensaje esteganografico recibido):

pablete@Tribilin:~/Escritorio/Tesis/artefacto$ ./steg_http boby.conf

proxy_name: boby


























En la figura 3.10 se muestra la pantalla de Wireshark con una captura parcial de la comu-nicacion entre Boby y el servidor web.

Figura 3.10: Pantalla de Wireshark con la captura (parcial) del trafico entre Boby y el servidor web,con Walter con el rol de guardian activo.

Se puede observar que, entre otros, todos los campos tienen el nombre completamente enminusculas, no aparece en ningun caso el numero 80 en el valor del puerto, no hay caracteres



LWS al comienzo del nombre de los campos, no hay comentarios, no hay folding en el contenidodel valor de los campos, no hay campos propietarios y no figura el campo From con direccionesde correo electronico.

Prueba de verificacion de los encabezados recibidos por el servidor

Por ultimo, a continuacion se describe una prueba realizada para determinar los encabe-zados recibidos por el servidor a traves de la aplicacion esteganografica para el caso dondelos proxys son solamente Alicia y Boby. Se desarrollo un script en lenguaje PHP que permi-te mostrar los campos del encabezado que recibe el servidor, en el apendice E se muestra elcodigo fuente de ese script. Se configuro y ejecuto las aplicaciones de la misma forma que en laprimera prueba del artefacto. Luego, se ingreso a la URL http://localhost/prueba headers.php.Se obtuvo la pantalla que se muestra en la figura 3.11.

Se puede observar que el servidor recibe los mismos encabezados HTTP que se analizaronen la captura de Wireshark (salvo por el campo Referer, que en este ultimo caso no se incluye,dado que a la URL de prueba se ha ingresado directamente, sin seguir un enlace). Se puede verque el servidor ignora los caracteres LWS al comienzo del valor de cada campo (tal como se haexplicado oportunamente en el analisis de la especificacion) y ha reemplazado el folding de loscampos por un unico caracter espacio. Adicionalmente, se ve que el servidor recibe el campopropietario incorporado (Example1 ) y el comentario agregado en el campo User-Agent (WIN).

Figura 3.11: Encabezados del mensaje HTTP mostrados por el servidor a partir de un script enlenguaje PHP.


Capıtulo 4

Conclusiones y futuras lıneas deinvestigacion

4.1. Conclusiones

En el presente trabajo se ha analizado los protocolos de comunicacion IP y HTTP desdeel punto de vista de su capacidad para transmitir informacion a partir de la aplicacion deesteganografıa, es decir, a traves de reglas no definidas en la especificacion del protocolo quepermitan una comunicacion disimulada. Se denomino a esta caracterıstica de los protocoloscomo vulnerabilidades esteganograficas. Se ha mencionado que esta practica viola una polıticade seguridad sobre el protocolo[Lam73].

A partir del estudio pormenorizado de la especificacion de los protocolos, se propusie-ron tecnicas que aprovechan cada una de las vulnerabilidades esteganograficas encontradas.Paralelamente, se analizo la forma de impedir la aplicacion de esas tecnicas a partir de laconstruccion de un guardian activo que modifique los mensajes que transitan por el canal decomunicacion al cual tiene acceso. Se han dado ejemplos que permiten a un guardian activomodificar los mensajes para agregar contenido de forma esteganografica que sirva para confun-dir a un observador[AD03]. Las modificaciones al mensaje portador se han sustentado en quelas mismas no alteran la comunicacion genuina sobre el protocolo.

Se han comentado las diferencias que surgieron del analisis entre ambos protocolos respectode su uso en aplicaciones esteganograficas. En particular, se ha resaltado como diferencia, laestructura del encabezado de los mensajes IP (compuesto por campos fijos con ordenamientoestatico, medidos en bits) respecto de los de HTTP (compuesto por cadenas de caracteres, conposibilidad de ordenamiento variable) y su influencia en las tecnicas posibles.

Se ha desarrollado un artefacto de comunicacion esteganografica que implementa algu-nas de las tecnicas analizadas sobre ambos protocolos. Analogamente, se ha desarrollado unguardian activo para evitar la transmision de los mensajes esteganograficos con las tecnicasimplementadas y se han presentado los resultados de las pruebas realizadas.

La construccion del artefacto permitio comprobar la factibilidad de la aplicacion de lastecnicas implementadas para la comunicacion esteganografica. Al mismo tiempo, la construc-cion del guardian activo permitio contrarrestar la aplicacion de las tecnicas implementadas.Se pudo observar que, en todas las pruebas, las comunicaciones basadas en los protocolosfuncionaron correctamente.

Por otra parte, el analisis de las pruebas sobre el artefacto permitio ilustrar, con un ejemplo,el impacto sobre la invisibilidad esteganografica en relacion a la capacidad esteganografica sobreel portador. Cuanto mayor es la capacidad esteganografica aplicada sobre un portador, mayores la probabilidad de perdida de invisibilidad. Se menciono que la perdida de invisibilidad

138


puede malograr el objetivo de comunicacion disimulada.A lo largo del analisis de los protocolos de comunicacion se ha notado que las vulnerabilida-

des esteganograficas presentes en ellos responden principalmente a ambiguedades, vaguedadeso libertades en las especificaciones de los mismos. Esto es, puntos en los que la definicion delprotocolo no es estricta, sino que, en algunos casos, se deja a criterio de las implementacionesconcretas la accion a tomar bajo ciertos valores en algunos campos de los mensajes, o permiteel agregado de campos que en ciertos casos no poseen un objetivo real.

Se han detectado canales supraliminales en los protocolos de comunicacion estudiados.Estos canales no pueden ser eliminados sin alterar el contenido semantico del mensaje trans-mitido, o alterar alguna funcionalidad no esencial del protocolo. Por tanto, esta constituyela mayor vulnerabilidad esteganografica de los protocolos de comunicacion. Se ha visto quepara paliar esta situacion, se pueden aplicar las modificaciones necesarias a los mensajes queefectuen la eliminacion de esos canales. De este modo, las partes que se comuniquen no podranutilizar el canal de manera transparente, dado que estas modificaciones a los mensajes producenrestricciones a funcionalidades provistas por el protocolo utilizado.

Como ejemplo de canal supraliminal, se puede mencionar los campos que almacenan la rutadel mensaje en el datagrama IP en el campo Opciones. La existencia de la ruta, ademas de sucontenido, constituye un mensaje esteganografico. Si se quita la ruta del mensaje, se deja sinuna funcionalidad del protocolo a quienes hacen uso genuino de esta prestacion1.

Por otra parte, se menciono que el ancho de banda de un canal supraliminal es, en general,menor que el de un canal subliminal en un mensaje de un protocolo, un campo que constituyeun canal supraliminal puede tomar dos estados posibles: su presencia o su ausencia (i.e. cadacanal supraliminal es un elemento binario). Aunque, en un mismo mensaje de protocolo, puedenexistir al mismo tiempo varios canales supraliminales simultaneos. Cada uno, aporta un dıgitobinario de un mensaje esteganografico.

El mayor desafıo que presenta el analisis de vulnerabilidades esteganograficas, radica enque las tecnicas empleadas para la incorporacion de mensajes dentro de portadores son ad hoc,es decir, especıficas del protocolo y de cada una de sus definiciones. Esto requiere un analisisy conocimiento profundo de cada uno de los protocolos que se desea proteger de la accionde esteganografistas y, a la vez, no permite la aplicacion de reglas generales en un canal decomunicacion. Las tecnicas tendientes a evitar o disminuir la actividad esteganografica no sonmas que un conjunto de reglas particulares disenadas a medida, aplicadas en conjunto.

Se puede notar que el diseno de un protocolo que impida la aplicacion de tecnicas estega-nograficas implica una definicion muy rıgida, que no deje comportamientos resultantes libradosa la decision de los implementadores del protocolo. A su vez, las especificaciones rıgidas tienencomo contrapartida que las implementaciones serıan mas complejas que las implementacionescon especificaciones menos rıgidas: i.e. en una implementacion de una especificacion rıgida sedeberıa verificar una mayor cantidad de precondiciones para aceptar un mensaje como validodentro de las reglas del protocolo, con respecto a una implementacion mas laxa. Por lo tanto,la implementacion de una especificacion rıgida de un protocolo demandara mas recursos deprocesamiento.

Luego de haber repasado las posibilidades de aplicacion esteganografica y mencionado algu-nos usos relevantes en diferentes momentos de la historia, se puede concluir que la posibilidadde aplicacion de tecnicas esteganograficas es una de las caracterısticas que se deberıa teneren cuenta en el diseno de un protocolo. Ademas de otras caracterısticas que generalmente sonconsideradas, entre las cuales se puede mencionar: tolerancia a fallos del canal o protocolo sub-yacente, capacidad de autocorreccion de errores, velocidad de procesamiento e interpretacion,

1En el artefacto implementado no se ha tenido en cuenta la existencia de la ruta (i.e. de la opcion RecordRoute) como canal supraliminal, sino solo su contenido.



compatibilidad entre plataformas diferentes2, escalabilidad, etc.Se dice que la existencia de canales encubiertos en los protocolos de comunicacion es algo

que deberıan considerar los administradores de redes. Ademas, las empresas, en general, noconocen los riesgos reales a la seguridad sobre la explotacion de canales encubiertos[AD03].

Las diferentes propiedades de un protocolo presentan un compromiso entre sı. Por ejemplo,la prevision de una futura escalabilidad del protocolo es una cualidad deseable del mismo (ex-tensibilidad para adaptaciones futuras con compatibilidad hacia atras3). Esta cualidad obligaa dotar de flexibilidad a la estructura del mensaje del protocolo, a traves de la definicion decampos adicionales que tengan una semantica no definida en el momento de escribir la especi-ficacion. Puesto que esos campos no forman parte del contenido del mensaje, son candidatos apermitir la aplicacion de tecnicas esteganograficas en ese protocolo, es decir, constituyen vulne-rabilidades esteganograficas. La cual, es una cualidad no deseable del protocolo. Otro ejemplolo constituye el empleo de varios nombres para denominar una misma cosa, por motivos decompatibilidad con una version anterior del protocolo. Tal es el caso de los nombres x-gzip ygzip, expresado en la seccion 2.3.3.

Estas son decisiones que deben ser tomadas al momento de disenar el protocolo comuni-cacion en relacion al peligro del goteo de informacion en el ambiente donde se aplique. Loscomponentes de la seguridad son la proteccion, deteccion y reaccion. Reaccionar frente a unatacante que explota un canal encubierto en general es muy tardıo y costoso[RCN07].

En general, la posibilidad de existencia de canales encubiertos no puede ser completamenteeliminada[RCN07], aunque puede ser reducida a partir del ciertas consideraciones de disenodel protocolo de comunicacion.

Por ultimo, el desarrollo del presente trabajo permitio cumplir con un importante objetivopropuesto: la formacion de un espıritu crıtico al estudiar las especificaciones de protocolos.Esto se logro a partir de buscar otras formas de utilizar los mecanismos y estructuras queproveen los protocolos, diferentes a las que se establecen en sus especificaciones. A partir deeste tipo de analisis es posible proponer mejoras a los protocolos, anticipar posibles problemaso vulnerabilidades (en el caso del presente trabajo, violar polıticas de seguridad a partir delfiltrado inadvertido de informacion).

4.2. Futuras lıneas de investigacion

Como futuras lıneas de investigacion han surgido los siguientes temas a lo largo del desa-rrollo del trabajo:

En el presente trabajo se ha analizado el protocolo IP de forma aislada, es decir, conindependencia del protocolo utilizado en sus capas superior e inferior. Se podrıa analizarla posibilidad de aplicar tecnicas esteganograficas sobre el protocolo IP con consideracio-nes adicionales sobre el protocolo existente en la capa superior, o en protocolos de variascapas superiores. Se ha mencionado como ejemplo en la seccion 2.2.1 que la aplicacion deesteganografıa sobre el protocolo IP con la consideracion de la existencia de un protocolode capa superior que asegure el ordenamiento de los mensajes (tal es el caso de TCP)permitirıa utilizar como informacion esteganografica las propias caracterısticas del ordende los mensajes.

Analizar la factibilidad de aplicar sobre IPv6 (Internet Protocol version 6 )4 las tecnicas

2e.g. plataformas con diferente forma de almacenar datos de mas de un byte (endianness) como es el casode la Capa de Presentacion del modelo OSI[Tan97]

3i.e. un mensaje de protocolo de una version dada del mismo debe poder ser interpretada por una implemen-tacion del protocolo de una version anterior

4la version del protocolo IP que reemplazara en el uso al protocolo IPv4 analizado en el trabajo



esteganograficas propuestas para el protocolo IP estudiado.

Puede existir la posibilidad de aplicar nuevas tecnicas esteganograficas o que las tecnicaspropuestas puedan transportarse a este protocolo.

Elaborar definiciones de los protocolos estudiados que minimicen las vulnerabilidadesesteganograficas: se podrıa disenar nuevas versiones de los protocolos estudiados, quecumplan con el requisito de que mensajes de estos nuevos protocolos sean compatiblescon las versiones estudiadas (e.g. un mensaje del nuevo protocolo IP, que minimiza lasvulnerabilidades esteganograficas deberıa ser interpretado con la misma semantica en unaimplementacion de IPv4). Evidentemente, no todos los mensajes que son sintacticamentevalidos para los protocolos estudiados (e.g. IPv4) lo seran para los protocolos redisenadoscomo rıgidos. En este escenario, los enrutadores intermedios del mensaje deberan des-cartar los mensajes (i.e. no reenviarlos), mientras que los enrutadores que implementanel protocolo de acuerdo al estandar no rıgido, no advertirıan anomalıas.

Por ejemplo, en el protocolo IP modificado se podrıa especificar que si el datagramano debe ser fragmentado (flag Don’t fragment con valor 1) o no tiene fragmentos, elencabezado del protocolo no debe llevar campo de identificacion (ID). Puesto que estecampo se utiliza solo a los fines de la fragmentacion. Como consecuencia, se evita laposibilidad de utilizar el ID como canal encubierto en una comunicacion esteganografica.En este ejemplo, se obtiene adicionalmente un ahorro de bits en dichos casos, aunqueel mismo implicarıa, en general, un mayor uso de procesamiento computacional para laconstruccion e interpretacion del datagrama, tanto para los nodos emisores y receptoresde la comunicacion legıtima, cuanto para los enrutadores intermedios con capacidad dedescartar los datagramas sintacticamente invalidos.

Analizar la importancia de la invisibilidad en la aplicacion de tecnicas esteganograficas enlos protocolos estudiados: a lo largo del analisis realizado, se han presentado las posibili-dades de aplicacion de tecnicas esteganograficas a partir de modificaciones que no alterenla semantica de los mensajes transmitidos, desde la optica de las implementaciones delos protocolos que tienen parte en el acto de comunicacion. Se ha dejado de lado en elanalisis, el impacto de esas modificaciones a los mensajes con respecto a la invisibilidadesteganografica. Esto es, un mensaje modificado de acuerdo a algunas reglas propuestaspodrıa despertar sospecha de un acto de comunicacion esteganografica. Este estudio nose ha desarrollado, puesto que el foco estuvo puesto en la definicion del protocolo ensı misma, si bien en el analisis del artefacto sobre IP se ha mostrado un ejemplo quepuede tener impacto sobre la invisibilidad.

Para este estudio se podrıa aplicar tecnicas de analisis de la entropıa de los mensajes[Sha48],como de analisis estadıstico de la estructura del mensaje.

Analizar la posibilidad de implementar funcionalidades adicionales sobre el artefactodesarrollado. Estas funcionalidades permitirıan cumplir objetivos de seguridad sobre lacomunicacion esteganografica, tales como:

• Autenticacion: para que el receptor esteganografico pueda tener certeza que su paremisor es quien el espera que sea.

• Cifrado: para evitar que un tercero que acceda al mensaje esteganografico puedainterpretarlo[Piy10].

• Integridad : para evitar el agregado, eliminacion o modificacion de mensajes estega-nograficos.



• Proteccion frente a repeticiones del mensaje: para proteger el esquema de comuni-cacion esteganografica frente al ataque de un tercero que envıe portadores que hayaalmacenado anteriormente.

Esto implica, ademas, analizar el impacto que pueden tener estos mecanismos en eltamano de los mensajes que se debe transmitir y en la capacidad esteganografica efectiva.

Analizar la demora introducida en la comunicacion debido a la aplicacion de las tecnicasesteganograficas implementadas en el artefacto.

Se ha comentado que el artefacto desarrollado introduce inevitablemente una demoraen la comunicacion a raız del procesamiento adicional que se debe realizar sobre losmensajes.

Analizar los protocolos estudiados con la inclusion de las modificaciones, agregados y co-mentarios de todas las otras especificaciones (RFCs) que los referencien. Tal es el ejemplode la RFC 2474 que reasigna la semantica del campo Tipo de Servicio del datagramaIPv4, para la introduccion de Servicios Diferenciados, que fue dejado fuera del alcancedel trabajo, o la RFC 2965 que incorpora la funcionalidad de estado entre mensajes deHTTP (en campos denominados cookies: Set-Cookie y Cookie).

Disenar un protocolo de comunicacion esteganografica confiable (seccion 1.3) que permi-ta la comunicacion de mensajes esteganografico largos (i.e. mayores a la capacidad paraembeber del mensaje de protocolo) sobre los protocolos estudiados. El protocolo estega-nografico debe tener en cuenta que los mensajes esteganograficos se envıan fragmentadosen diferentes mensajes de protocolo (se debe reensamblar los fragmentos de mensajesesteganograficos) y, que puede existir perdida de algun mensaje de protocolo, con la con-secuente perdida del mensaje esteganografico (e.g. el protocolo IP es un protocolo queimplementa un servicio de envıo no confiable).

Analizar la aplicacion de tecnicas de Inteligencia Artificial para la deteccion de activi-dades esteganograficas sobre los protocolos estudiados o genericos: se podrıa estudiar laposibilidad de desarrollar guardianes activos genericos. Esto es, algoritmos que sin unconocimiento de la estructura del protocolo de comunicacion utilizado como portador,puedan encontrar patrones de comportamiento y emitir alertas cuando consideran que seaplican tecnicas esteganograficas sobre los mensajes (i.e. se violan reglas de seguridad).Para el diseno de estos algoritmos se podrıa aplicar tecnicas de Inteligencia Artificial,como algoritmos geneticos5.

Analizar la posibilidad de uso del protocolo HTTP como portador de un protocolo es-teganografico en un esquema donde HTTP opera como sustrato de otro protocolo. Estoimplicarıa determinar si las tecnicas esteganograficas propuestas para HTTP se puedenaplicar en el nuevo protocolo que utiliza a HTTP como sustrato y, si aparece la posibilidadde aplicar nuevas tecnicas esteganograficas en este protocolo.

Por ultimo, dado que Wireshark permite la extension de sus funcionalidades de analisis deprotocolos a partir del desarrollo de plugins6, se podrıa disenar un plugin que interpretelas comunicaciones esteganograficas implementadas en el artefacto para los protocolos IPy HTTP.

5Existen algunos estudios sobre deteccion de Watermarks en diferentes tipos de portadores, como archivosde audio[Dav].

6http://wiki.wireshark.org/Development



Existe un filtro generico de Wireshark, denominado MATE (Meta Analysis and TracingEngine)7 para realizar un meta-analisis de mensajes de protocolos. El mismo permiteextraer informacion a partir de la relacion de varios mensajes entre sı. Si bien MATE esun plugin generico, podrıa servir como punto de partida para el desarrollo de un pluginespecıfico.

7http://wiki.wireshark.org/Mate


Apendice

144


A. Etimologıa del vocablo esteganografıa

De la etimologıa del termino esteganografıa se desprende el vocablo griego steganos, quesignifica “secreto o cubierto” y el sufijo graphia: “escritura”[Col03]. Literalmente significa “es-critura cubierta”.

A continuacion se enuncian los vocablos relacionados con el termino esteganografıa. Lasacepciones estan basadas en [Bai50].

στεγω (stego):

1. Cubrir, recubrir, poner en cubierto, encubrir, proteger, defender.

2. Esconder, mantener escondido.

3. Contener, encerrar, mantener encerrado, no dejar escapar.

4. Soportar, resistir, retener.

στεγαζω: Cubrir.

στεγανη: Cobertura.

στεγαγos (adj.):

1. Que sirve para cubrir.

2. Discreto, silencioso.

3. Opaco, espeso.

B. Protocolo IP

En el presente apendice se enuncian porciones de la especificacion del Protocolo IP quecomplementan el analisis del capıtulo 2.

B.1. Primitivas del modulo IP sugeridas por la RFC

La especificacion sugiere, aunque no obliga, las siguientes primitivas del modulo IP paraser usadas por la capa superior. Para el envıo de mensajes:

SEND (src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt => result)

Donde:

src: Direccion de origen.

dst : Direccion de destino.

prot : Protocolo.

TOS : Tipo de servicio.

TTL: Tiempo de vida (en ingles time to live).

BufPTR: Puntero al bufer donde se encuentran el mensaje a enviar.

len: Largo del buffer.

Id : Identificador.



DF : Flag Don’t Fragment (No fragmentar).

opt => result : Respuesta:

• OK : Datagrama enviado correctamente.

• Error : Error en los argumentos o en la red local.

Para la recepcion de mensajes:

RECV (BufPTR, prot, => result, src, dst, TOS, len, opt)

BufPTR: puntero al buffer donde se coloca el mensaje leıdo.

prot : Protocolo.

result : Respuesta:

• OK : Datagrama recibido correctamente.

• Error : Error en los argumentos.

len: Largo del buffer.

src: Direccion de origen.

dst : Direccion de destino.

TOS : Tipo de servicio.

opt : Opciones.



C. Protocolo esteganografico propuesto

A continuacion se muestra la codificacion en bits y su valor numerico en base decimalcorrespondiente a cada letra del alfabeto del protocolo esteganografico propuesto:

A→ 00000 ≡ 0

B→ 00001 ≡ 1

C→ 00010 ≡ 2

D→ 00011 ≡ 3

E→ 00100 ≡ 4

F→ 00101 ≡ 5

G→ 00110 ≡ 6

H→ 00111 ≡ 7

I→ 01000 ≡ 8

J→ 01001 ≡ 9

K→ 01010 ≡ 10

L→ 01011 ≡ 11

M→ 01100 ≡ 12

N→ 01101 ≡ 13

O→ 01110 ≡ 14

P→ 01111 ≡ 15

Q→ 10000 ≡ 16

R→ 10001 ≡ 17

S→ 10010 ≡ 18

T→ 10011 ≡ 19

U→ 10100 ≡ 20

V→ 10101 ≡ 21

W→ 10110 ≡ 22

X→ 10111 ≡ 23

Y→ 11000 ≡ 24

Z→ 11001 ≡ 25

.→ 11010 ≡ 26

,→ 11011 ≡ 27

?→ 11100 ≡ 28

(espacio)→ 11101 ≡ 29

(fin de lınea)→ 11110 ≡ 30

(fin de mensaje)→ 11111 ≡ 31



D. Prototipos de metodos del artefacto

D.1. Archivos del manejo del protocolo esteganografico (StegProtocol/)

D.1.1. StegProtocol.cpp

StegProtocol :: StegProtocol ()

StegProtocol ::~ StegProtocol ()

/** Coloca en la variable message el mensaje contenido en el buffer interno del mensaje.

* El mensaje se devuelve en forma de texto plano.

* \param message variable donde se colocara el texto del mensaje.

* \return cantidad de caracteres del mensaje.

*/

int StegProtocol :: getMessageText(std:: string& message)

/** Abre el archivo de entrada para leer el texto.

* \param filename nombre del archivo a abrir.

* \return 0 en caso de exito.

* \return -1 en caso de no poder abrir el archivo.

*/

int StegProtocol :: ReadInputFile(const char* filename)

/** Asigna el archivo donde se almacenara el mensaje de salida.

* \param filename ruta del archivo donde se escribira el mensaje obtenido.

* \return -1 en caso de no poder abrir el archivo para escritura.


*/

int StegProtocol :: setOutputFile(const char* filename)

/** Escribe el mensaje obtenido en el archivo de salida.

* \return numero positivo: cantidad de bytes escritos.

* \return -1 si no esta especificado el archivo de salida.

* \return -2 si el mensaje no esta completo.

* \return -3 si se produjo un error al escribir en el archivo.

*/

int StegProtocol :: WriteMessageToFile ()

/** Agrega bits al buffer de mensaje interno.

* Los bits se leen desde la izquierda (bit mas significativo) de la variable inputbuffer.

* \param inputbuffer buffer binario de donde leer los bits.

* \param buffersize tamanio del buffer , medido en bits.


* \return -1 en caso de error.

*/

int StegProtocol :: addBitsToMessage(unsigned int inputbuffer , unsigned int buffersize)

/** Agrega 8 bits al mensaje , leidos de inputbuffer.

* \param inputbuffer variable de donde se leen los ocho bits para agregar al mensaje.



*/

int StegProtocol :: addBitsToMessage(unsigned char inputbuffer)

/** Agrega el char al buffer del mensaje.

* Se interpretan los ultimos cinco bits del char. Los tres primeros se colocan en cero.

* \param inputbuffer variable de donde se toman los cinco bits

* \return 0

*/

int StegProtocol :: addEncodedBitsToMessage(unsigned char inputbuffer)

/** Coloca en el parametro outputbuffer una cantidad deseada de bits , indicada en el parametro buffersize.

* Los bits colocados son quitados del mensaje interno.

* \param outputbuffer buffer donde se colocara los bits de salida. Los bits leidos son colocados en la posicion mas

* significativa del buffer.

* \param buffersize cantidad de bits a colocar


* \return otro valor: cantidad de bits realmente colocados (se coloca menos de los solicitados si no habia mas en el

* buffer ).

*/

int StegProtocol :: extractBitsFromMessage(unsigned int* outputbuffer , unsigned int buffersize)

/** Devuelve bits del mensaje en la variable outputbuffer.

* Lee hasta 8 bits.

* \param outputbuffer buffer donde se colocaran los bits leidos.


* \return otro valor: corresponde a la cantidad de bits leidos.

*/

int StegProtocol :: extractBitsFromMessage(unsigned char* outputbuffer)



/** Coloca un caracter al mensaje. El caracter esta codificado en forma de caracter imprimible (generado con el

* metodo extractPrintableCharFromMessage ).

* Este metodo sirve para agregar al mensaje cadenas de caracteres en los casos en los que la esteganografia se

* utiliza sobre un protocolo orientado a las cadenas de caracteres (i.e. HTTP). El formato es el siguiente:

* . Se toman 5 bits (que corresponden a una unidad de caracter , aunque puede

* corresponder a parte de dos elementos componentes del mensaje) y se obtiene el valor "c".

* Se obtiene el caracter imprimible v = c + 64 (el caracter 64 corresponde a la "@")

* \param c caracter imprimible codificado a colocar.


* \return 1 correspondiente a un caracter colocado.

*/

int StegProtocol :: addPrintableCharToMessage(char c)

/** Coloca una cadena de caracteres al mensaje. La cadena de caracteres esta codificado en forma de caracter

* imprimible (generado con el metodo extractPrintableCharFromMessage ).

* Este metodo sirve para agregar al mensaje cadenas de caracteres en los casos en los que la esteganografia se

* utiliza sobre un protocolo orientado a las cadenas de caracteres (i.e. HTTP).

* \param input cadena de caracteres imprimible codificada a colocar.


* \return otro valor correspondiente a la cantidad de caracteres colocados.

*/

int StegProtocol :: addPrintableStringToMessage(const char* input)

/** Extrae un caracter del mensaje , en forma de caracter imprimible.

* Este metodo sirve para colocar cadenas de caracteres en los casos en los que la esteganografia se utiliza sobre

* un protocolo orientado a las cadenas de caracteres (i.e. HTTP).

* El formato es el siguiente:

* . Se toman 5 bits (que corresponden a una unidad de caracter , aunque puede corresponder a parte de dos elementos

* componentes del mensaje) y se obtiene el valor "v".

* . Se obtiene el caracter imprimible c = v - 64 (el caracter 64 corresponde a la "@")

* \param output buffer donde se coloca el caracter leido.


* \return otro valor correspondiente a la cantidad de caracteres colocados en el buffer output.

*/

int StegProtocol :: extractPrintableCharFromMessage(char* output)

/** Extrae caracteres del mensaje , en forma de cadena imprimible.

* \param output buffer donde se coloca la cadena leida.

* \param buffersize cantidad maxima de caracteres a colocar en el buffer.


* \return otro valor correspondiente a la cantidad de caracteres colocados en el buffer output.

*/

int StegProtocol :: extractPrintableStringFromMessage(char* output , int buffersize)

/** Agrega un bit al mensaje.

* \param bit_input bit a agregar. Si es igual a 0, se agrega el bit 0. Si es distinto de 0, se agrega el bit 1.



*/

int StegProtocol :: addOneBitToMessage(unsigned int bit_input)

/** Extrae un bit del mensaje.

* Coloca en el buffer de salida: 1 o 0.

* \param output buffer donde se colocara el bit extraido.


* \return otro valor: cantidad de bits extraidos.

*/

int StegProtocol :: extractOneBitFromMessage(unsigned int* output)

/** Devuelve la cantidad de bits del mensaje.

* Los bits que no llegan a cubrir un caracter de la entrada no se computan dentro del largo del mensaje.

* \return cantidad de bits del mensaje.

*/

int StegProtocol :: getSizeInBits () const

/** Limpia el buffer del mensaje y devuelve todas las variables a 0. */

void StegProtocol :: clearMessage ()

/** Obitene el largo necesario para serializar el objeto a un stream.

* \return largo del objeto serializado , medido en octetos.

*/

unsigned int StegProtocol :: CalculateSizeOfSerializeOfject () const

/** Coloca en el buffer stream el objeto serializado.

* \param stream buffer donde se coloca el objeto serializado.

*/

void StegProtocol :: SerializeObjectToStream(unsigned char* stream) const

/** Coloca en el buffer stream el objeto serializado.

* \param stream buffer donde se coloca el objeto serializado.

*/

void StegProtocol :: CopyObjectFromSerializedStream(const unsigned char* stream)

/* Metodos protected */

/** Devuelve bits del buffer interno en outputbuffer.

* Lee hasta 8 bits.


* \param cant cantidad de bits a leer.



* \param initial_offset posicion desde la que se comienzan a escribir los bits en la variable de salida.



*/

int StegProtocol :: _extractBitsFromInternalBuffer(unsigned char* outputbuffer , unsigned int cant ,

unsigned int initial_offset)

/** Devuelve bits del buffer interno en outputbuffer , de tipo unsigned int.

* Lee hasta 8 bits.



* \param initial_offset posicion desde la que se comienzan a escribir los bits en la variable de salida.



*/

int StegProtocol :: _extractBitsFromInternalBuffer(unsigned int* outputbuffer , unsigned int cant ,

unsigned int initial_offset)

/** Copia los bits del buffer de entrada inputbuffer de tipo int , en la salida de tipo unsigned char.

* Copia hasta el tamanio de bits que permite la variable unsigned char.


* \param inputbuffer buffer de donde se leeran los bits para copiar.



* \return otro valor: corresponde a la cantidad de bits copiados.

*/

int StegProtocol :: _copyBitsFromIntToChar(unsigned char* outputbuffer , unsigned int inputbuffer ,

unsigned int cant) const

D.1.2. SingleStegProtocol.cpp

SingleStegProtocol :: SingleStegProtocol ()

SingleStegProtocol ::~ SingleStegProtocol ()

/** Devuelve la instancia (Singleton) de la clase.

* \return Instancia de la clase.

*/

SingleStegProtocol* SingleStegProtocol :: getInstance ()

D.1.3. SharedStegProtocol.cpp

SharedStegProtocol :: SharedStegProtocol(const char* proxy_name ): _mem()

SharedStegProtocol ::~ SharedStegProtocol ()

/** Crea el espacio de memoria compartida , identificado por la clave key , obtenida en el constructor.



*/

int SharedStegProtocol :: CreateSharedArea ()

/** Abre el espacio de memoria compartida , identificado por la clave key , obtenida en el constructor.



*/

int SharedStegProtocol :: OpenSharedArea ()

/** Destruye el espacio de memoria compartida , identificado por la clave key , obtenida en el constructor.

* El espacio de memoria compartida debe haber sido abierto o creado previamente.



*/

int SharedStegProtocol :: DestroySharedArea ()

/** Lee el mensaje esteganografico del area de memoria compartida.



*/

int SharedStegProtocol :: LoadFromSharedArea ()

/** Almacena el mensaje esteganografico del area de memoria compartida.



*/

int SharedStegProtocol :: SaveToSharedArea ()



D.2. Archivos del artefacto IP (IP/)

D.2.1. IPDatagram.cpp

IPDatagram :: IPDatagram ()

IPDatagram ::~ IPDatagram ()

/** Carga el datagrama desde un buffer.

* \param len longitud del buffer.

* \param buffer variable desde donde se lee para completar el datagrama.

* \return 0 en caso de exito

* \return -1 en caso de error

*/

int IPDatagram :: LoadDatagramFromBuffer(int len , char* buffer)

/** Devuelve el datagrama en un buffer.

* \param buffer donde se copia el datagrama

* Importante: el buffer de destino debe tener al menos el tamanio del datagrama.

* Se puede invocar previamente el metodo GetDatagramSize () para obtener el tamanio que

* debe tener el buffer.

* \return -1 en caso que el datagrama sea invalido

* \return otro valor , correspondiente a la longitud copiada

*/

int IPDatagram :: GetDatagramBuffer(unsigned char* buffer)

/** Devuelve la longitud del datagrama en bytes.

* \return longitud del datagrama en bytes

*/

int IPDatagram :: GetDatagramSize ()

/** Funcion de Debug para mostrar en la salida el contenido binario de un buffer.



*/

void IPDatagram :: PrintRawData(int len , char* buffer)

/** Devuelve una referencia al encabezado. */

const IPHeader* IPDatagram :: GetHeader () const

/** Muestra el contenido del datagrama en stderr.

* Se utiliza para permitir visualizar (y debug) del funcionamiento.

* \param ShowPretyAddress true para mostrar la direccion IP separada en octetos , false

* para mostrarla en hexadecimal.

*/

void IPDatagram :: PrintDebugDatagram(bool ShowPretyAddress) const

D.2.2. IPHeader.cpp

IPHeader :: IPHeader ()

IPHeader ::~ IPHeader ()

/** Carga el encabezado del datagrama IP desde el buffer.





*/

int IPHeader :: LoadHeaderFromBuffer(int len , char* buffer)

/** Devuelve el encabezado del datagrama en un buffer.

* \param buffer donde se copia el encabezado

* Importante: el buffer de destino debe tener al menos 60 bytes de espacio.


* \return otro valor , correspondiente a la longitud copiada

*/

int IPHeader :: GetHeaderBuffer(unsigned char* buffer)

/** Devuelve la longitud del encabezado del datagrama en bytes.

* \return longitud del encabezado del datagrama en bytes

*/

int IPHeader :: GetHeaderSize ()

/* Obtencion de campos */

unsigned short int IPHeader :: getOffset () const

bool IPHeader :: getReservedFlag () const

bool IPHeader :: getDontFragmentFlag () const

bool IPHeader :: getMoreFragmentsFlag () const

/** Copia en el buffer el campo de opciones.

* \param buffer variable donde se copiara el campo opciones.

* Importante: el buffer debe tener reservado hasta 40 bytes , para asegurarse que no se

* copia sobre memoria no inicializada.

* \return cantidad de bytes copiados.

*/

int IPHeader :: getOptions(unsigned char* buffer) const

/* Asignacion de valores de campos */



void IPHeader :: setVersion(unsigned char version)

void IPHeader :: setToS(unsigned char ToS)

void IPHeader ::setID(unsigned short int ID)

void IPHeader :: setReservedFlag(bool flag)

void IPHeader :: setDontFragmentFlag(bool flag)

void IPHeader :: setMoreFragmentsFlag(bool flag)

void IPHeader :: setTTL(unsigned char TTL)

void IPHeader :: setProtocol(unsigned char Protocol)

void IPHeader :: setSrcAddress(unsigned int address)

void IPHeader :: setDestAddress(unsigned int address)

/** Coloca las opciones en el encabezado del datagrama.

* \param len largo del buffer de opciones len debe ser multiplo de 4 (para alinear las opciones del encabezado a 4

* octetos)

* \param buffer variable donde se encuentran las opciones


* \return -1 en caso de opciones invalidas

*/

int IPHeader :: setOptions(unsigned int len , unsigned char* buffer)

/** Quita todas las opciones del datagrama.

*/

void IPHeader :: removeOptions ()

/* ------------- METODOS AUXILIARES ------------------------- */

/** Calcula el checksum del encabezado IP y lo coloca en el campo ip_sum.

* Para determinar el largo del encabezado , inspecciona el campo ip_hl.

* Si este campo no esta correctamente asignado el valor del checksum puede ser erroneo.

* \param header encabezado del datagrama IP.



*/

int IPHeader :: _ComputeHeaderChecksum ()

/** Aplica el algoritmo de checksum del encabezado IP.

* \param buf buffer donde se encuentra el encabezado.

* \param nwords longitud (medida en cantidad de palabras) del encabezado.

* \return checksum calculado en base a la especificacion IP.

*/

unsigned short IPHeader ::_csum(unsigned short *buf , int nwords) const

/** A partir de una variable numerica que contiene la direccion IP , se arma una string

* con la direccion en forma de separacion por puntos entre cada octeto.

* El metodo transforma la direccion almacenada en little -endian (en unsigned int) a la

* forma big -endiand para poder armar la string

* \param buffer cadena de caracteres donde se escribira la direccion

* \param address direccion IP expresada en forma little -endian

*/

void IPHeader :: _convertIPAddrToString(std:: string& buffer , unsigned int address) const

/** Convierte una direccion IP de la forma escrita como string en su numero que la representa , para enviarla en un

* datagrama.

* \param IPAddress direccion IP escrita como string , separada por puntos , por ejemplo: 192.168.0.2

* \return 0 en caso que el formato de la direccion sea invalido

* \return otro valor corresponde a la direccin IP en formato numerico

*/

unsigned int IPHeader :: convertStringIPAddrToNumber(std:: string& IPAddress)

D.2.3. IPSession.cpp

IPSession :: IPSession ()

IPSession ::~ IPSession ()

/** Inicializa la cola libnetfilter_queue para el envio y recepcion de datagramas IP.

* \param debug true para indicar que se muestre por stderr el datagrama leido.

* false en caso que se desee lo contrario


* \return -1 si fallo la funcion nfq_open ()

* \return -2 si fallo la funcion nfq_unbind_pf ()

* \return -3 si fallo la funcion nfq_bind_pf ()

* \return -4 si fallo la funcion nfq_create_queue ()

* \return -5 si fallo la funcion nfq_set_mode ()

*/

int IPSession ::Setup(bool debug)

/** Loop de recepcion (lectura) de la cola. */

void IPSession ::Run()

/** Destruye el manejador de la cola de datagramas de la sesion.


* \return -1 en caso de error al ejecutar nfq_destroy_queue

* \return -2 en caso de error al ejecutar nfq_close

*/

int IPSession :: CloseSession ()



/** Funcion Callback que ejecuta libnetfilter_queue al recibir un datagrama.

* Procesa el datagrama: lo reenvia tal como llega.

* Si se habia indicado el modo debug , se imprime en stderr los datos importantes del datagrama.


*/

int IPSession :: Callback(nfq_q_handle *myQueue , struct nfgenmsg *msg , nfq_data *pkt , void *cbData)

D.2.4. IPStegDatagram.cpp

/** Constructor

* \param high_capacity indica si se debe aplicar alta capacidad esteganografica en la

* lectura y escritura de los mensajes esteganograficos del datagrama.

* Si se aplica high_capacity=true , se considera el campo Options del datagrama IP.

*/

IPStegDatagram :: IPStegDatagram(bool high_capacity ): IPDatagram ()

IPStegDatagram ::~ IPStegDatagram ()

/** Carga el datagrama desde un buffer.





*/

int IPStegDatagram :: LoadDatagramFromBuffer(int len , char* buffer)

/** Aplica esteganografia sobre el datagrama leido.

* Corresponde a la funcion esteganografica Emb referida en el informe.

* \return -1 en caso de error (el datagrama no habia sido leido ).

* \return -2 en caso de tratarse de un datagrama de version desconocida (distinta de la version 4).

* \return otro valor: corresponde a la cantidad de bits del mensaje esteganografico colocados dentro del datagrama.

*/

int IPStegDatagram :: ApllyStegMessageToDatagram ()

// printf (" APLICAR !\n");

/** Lee el mensaje esteganografico contenido en el datagrama y lo adiciona al buffer esteganografico principal.

* Corresponde a la funcion esteganografica Ext referida en el informe.


* \return -2 en caso de tratarse de un datagrama de version desconocida (distinta de la version 4).

* \return -3 si ya se habia procesado el mensaje esteganografico

* \return otro valor: corresponde a la cantidad de bits del mensaje esteganografico leidos del datagrama.

*/

int IPStegDatagram :: ReadStegMessageDatagram ()

/** Aplica condiciones de guardian esteganografico sobre el datagrama leido:

* - aplica ruido en los campos posibles.

* - descarta datagramas con ciertas caracteristicas de malformacion.

* Esto se utiliza para evitar la propagacion de mensajes esteganograficos (esta operacion se aplica en el guardian ,

* Walter)

* \return 0 en caso de exito en la modificacion esteganografica realizada por el guardian.

* \return 1 en caso de que el datagrama deba ser descartado.


*/

int IPStegDatagram :: ApllyWardeningToDatagram ()

D.2.5. IPStegSession.cpp

IPStegSession :: IPStegSession ()

IPStegSession ::~ IPStegSession ()

/** Inicializa la cola libnetfilter_queue para el envio y recepcion de datagramas IP.

* \param remote_IPAddress direccion IP del emisor esteganografico (si es un lector esteganografico)

* o del destinatario (si es escritor ).

* \param debug true para indicar que se muestre por stderr el datagrama leido.

* false en caso que se desee lo contrario

* \param Session_type indica el tipo de sesion esteganografica:

* NORMAL: El datagrama se reenvia sin modificacion.

* STEG_WRITER: Es una sesion de escritura de mensajes esteganograficos.

* STEG_READER: Es una sesion de lectura de mensajes esteganograficos.

* STEG_WARDEN: Es una sesion IP que evita la propagacion de mensajes esteganograficos.

* \param high_capacity indica si se debe aplicar alta capacidad esteganografica en la

* lectura y escritura de los mensajes esteganograficos del datagrama.

* Si se aplica high_capacity=true , se considera el campo Options del datagrama IP.


* \return -1 si fallo la funcion nfq_open ()

* \return -2 si fallo la funcion nfq_unbind_pf ()

* \return -3 si fallo la funcion nfq_bind_pf ()

* \return -4 si fallo la funcion nfq_create_queue ()

* \return -5 si fallo la funcion nfq_set_mode ()

*/

int IPStegSession ::Setup(unsigned int remote_IPAddress , bool debug , IPStegSession_t Session_type , bool high_capacity)

/** Funcion Callback que ejecuta libnetfilter_queue al recibir un datagrama.

* Procesa el datagrama:

* le aplica consideraciones esteganograficas: lectura o escritura.

* Si se habia indicado el modo debug , se imprime en stderr los datos importantes del datagrama.


*/

int IPStegSession :: Callback(nfq_q_handle *myQueue , struct nfgenmsg *msg , nfq_data *pkt , void *cbData)



D.3. Archivos del artefacto HTTP (HTTP/)

D.3.1. HTTPConnection.cpp

HTTPConnection :: HTTPConnection (): _dest_name (), _port(), _socket ()

HTTPConnection ::~ HTTPConnection ()

/** Constructor de copia.

* \param conexion objeto desde donde realiza la copia.

*/

HTTPConnection :: HTTPConnection(const HTTPConnection &conexion ): _dest_name (), _port(), _socket(conexion._socket)

HTTPConnection :: HTTPConnection(StringInc& dest_name , StringInc& port , int sockfd ): _dest_name (), _port(), _socket ()

/** Operacion de asignacion.

* \param conexion objeto desde donde realiza la copia.

*/

HTTPConnection& HTTPConnection :: operator =( const HTTPConnection &conexion)

/** Se conecta al servidor pasado por parametro.

* \param dest_name nombre del servidor al que debe conectarse.

* \param port numero de puerto del servidor al que debe conectarse.

* \return 0 si se conecto

* \return 1: si hubo error en la conexion

*/

int HTTPConnection :: ConnectToHTTP(StringInc& dest_name , StringInc& port)

/** Verifica si los parametros de conexion corresponden a la conexion actual.

* \param dest_name nombre del servidor de destino.

* \param port numero de puerto (como string) del servidor de destino.

* \return true en caso de que correspondan a la conexion actual. false en caso contrario.

*/

bool HTTPConnection :: checkIfIsConnection(StringInc& dest_name , StringInc& port)

/** Envia n caracteres del mensaje message al destino.

* \param message puntero al mensaje

* \param n cantidad de bytes a enviar



*/

int HTTPConnection :: SendHTTPMessage(StringInc& message , unsigned int n)

/** Recibe del socket.

* \param ptr buffer donde se almacenan los datos recibidos.

* \param maxlong longitud maxima a recibir.


* \return otro valor: cantidad de bytes recibidos.

*/

int HTTPConnection :: recibir_binario(void *ptr , unsigned int maxlong)

/** Devuelve el descriptor del socket.

* \return valor del descriptor del socket.

*/

int HTTPConnection :: getSockFd ()

D.3.2. HTTPHeader.cpp

/** Funcion auxiliar para quitar repeticiones de una lista de StringInc.

* \param first primer string a comparar.

* \param second segunda string a comparar.

* \return true si ambas strings son iguales en comparacion case -insensitive.

* \return false en caso contrario.

*/

/** Constructor */

HTTPHeader :: HTTPHeader ()

/** Destructor */

HTTPHeader ::~ HTTPHeader ()

/** Reinicializa el contenido de todos los campos. */

void HTTPHeader ::clear ()

/** Devuelve el contenido del cuerpo del mensaje , que sale del campo Content -Length

* \return -1 en caso de desconocer el largo del contenido del campo.

* \return otro valor: corresponde al largo del contenido del campo.

*/

int HTTPHeader :: getContentLength () const

/** Devuelve el campo correspondiente al nombre solicitado.



* \return puntero al campo encontrado.

* \return NULL en caso de tratarse de otro tipo de mensaje

*/

const HTTPHeaderField* HTTPHeader :: getFieldFromName(const StringInc& field_name) const

/** Determina si existe un campo con el nombre dado en field_name.

* La comparacion se realiza case insensitive.

* \param field_name nombre del campo que se desea determinar si existe.

* \return trie si existe un campo con ese nombre

* \return false en caso contrario

*/

bool HTTPHeader :: existFieldWithName(const StringInc& field_name) const

/** Determina si existe un campo con el nombre dado en field_name.

* La comparacion se realiza case insensitive.

* \param field_name nombre del campo que se desea determinar si existe.

* \return trie si existe un campo con ese nombre

* \return false en caso contrario

*/

bool HTTPHeader :: existFieldWithName(const char* field_name) const

/** Devuelve una cadena de caracteres que corresponde al encabezado completo.

* \return encabezado completo.

*/

StringInc HTTPHeader :: getFullHeaders () const

/** Devuelve el contenido del campo correspondiente al nombre solicitado.

* Si el campo aparece mas de una vez , devuelve el contenido de la primer

* aparicion. Usar getFullFieldValue si se desea obtener el contenido concatenado

* de todas las apariciones del campo.

* \param field_name nombre del campo del que se desea obtener el valor.

* \return texto del valor del campo encontrado.

*/

StringInc HTTPHeader :: getFieldValue(const StringInc& field_name) const

/** Idem anterior , pero recibe un parametro de tipo const char*

* \param field_name nombre del campo del que se desea obtener el valor.


*/

StringInc HTTPHeader :: getFieldValue(const char* field_name) const


* Si el campo aparece mas de una vez , concatena los valores de todas las apariciones.

* Los valores se concatenan con una coma , dado que se trata de una lista.

*\param field_name nombre del campo del que se desea obtener el valor.


*/

StringInc HTTPHeader :: getFullFieldValue(const StringInc& field_name) const


* Si el campo aparece mas de una vez , concatena los valores de todas las apariciones.

* Los valores se concatenan con una coma , dado que se trata de una lista.

*\param field_name nombre del campo del que se desea obtener el valor.


*/

StringInc HTTPHeader :: getFullFieldValue(const char* field_name) const

/** Convierte una lista ingresada en multiples campos , en un solo campo con la lista.

* Por ejemplo , convierte:

* Accept -Charset: ISO -8859 -1

* Accept -Charset: utf -8;q=0.7

* Accept -Charset: *;q=0.7

* en:

* Accept -Charset: ISO -8859-1,utf -8;q=0.7 ,*;q=0.7

* \param field_name nombre del campo a convertir

* \return cantidad de apariciones de ese campo

*/

unsigned int HTTPHeader :: convertMultipleFildToOnlyOne(const StringInc& field_name)

/** Realiza la operacion inversa al metodo convertMultipleFildToOnlyOne.

* Es decir , convierte un campo unico en multiples campos.

* Si el campo no es unico , tambien lo convierte.

* \param field_name nombre del campo que se desea convertir.

* \return cantidad de veces que aparecia el campo.

*/

unsigned int HTTPHeader :: convertOneFieldToMultiple(const StringInc& field_name)

/** Idem unsigned int convertOneFieldToMultiple(const StringInc& field_name)

* pero recibe como parametro un const char*.


* \return cantidad de veces que aparecia el campo.

*/

unsigned int HTTPHeader :: convertOneFieldToMultiple(const char* field_name)

/** Agrega un campo a la lista de campos.

* \param field_name nombre del campo

* \param field_value valor del campo

*/

void HTTPHeader :: addField(const StringInc& field_name , const StringInc& field_value)


* \param field_name nombre del campo



* \param field_value valor del campo

*/

void HTTPHeader :: addField(const char* field_name , const char* field_value)

/** Agrega un campo a la lista de campos a partir de una linea completa del encabezado.

* \param header_line buffer que contiene la linea del encabezado HTTP. Tiene que tener la forma:

* Content -Type: text/plain

* \param line_size tmanio maximo a leer del buffer , si vale 0, se lee todo.

* \return -1 en caso de ser una linea invalida.

* \return 0 en otro caso

*/

int HTTPHeader :: addField(StringInc& header_line , unsigned int line_size)


* \param header_field objeto HTTPHeaderField para insertar

*/

void HTTPHeader :: addField(const HTTPHeaderField& header_field)

/** Devuelve el nombre del Host de destino. El nombre se obtiene del campo Host

* \return nombre del host de destino , si se trata de un mensaje de pedido.

* \return cadena vacia en caso de tratarse de otro tipo de mensaje

*/

StringInc HTTPHeader :: getDestHostName () const

/** Elimina el o los campos del header de la lista con el nombre pasado como parametro.

* \param field_name nombre del campo a eliminar.

* \return cantidad de campos con ese nombre eliminados.

*/

unsigned int HTTPHeader :: removeFieldWithName(const StringInc& field_name)




*/

unsigned int HTTPHeader :: removeFieldWithName(const char* field_name)

/** Elimina todos los campos de nombre desconocido.

* Estos son los que no esten definidos en el protocolo , ademas , se permite los

* siguientes , por ser de uso frecuente en las comunicaciones analizadas:

* Proxy -Connection

* Cookie

* Set -Cookie

* \return cantidad de campos eliminados.

*/

unsigned int HTTPHeader :: removeUnknownFields ()

/** Cuenta la cantidad de campos con el nombre field_name.

* \param field_name nombre del campo que se desea conocer la cantidad.

* \return cantidad de campos con ese nombre.

*/

unsigned int HTTPHeader :: countFieldsWithName(const StringInc& field_name) const

/** Contabiliza la cantidad de campos que tienen al menos un caracter SP en el campo valor.

* Sirve para determinar en que campos realizar folding (el folding se puede realizar solo en los espacios ).

* \return cantidad de campos que poseen al menos un caracter SP.

*/

unsigned int HTTPHeader :: countFieldsWithSPInValue () const

/** Cuenta la cantidad de campos con el nombre field_name.

* \param field_name nombre del campo que se desea conocer la cantidad.

* \return cantidad de campos con ese nombre.

*/

unsigned int HTTPHeader :: countFieldsWithName(const char* field_name) const

/** Devuelve la cantidad de campos headers cargados. */

unsigned int HTTPHeader :: getHeadersCount () const

/** Computa la cantidad de campos de encanbnezado con nombre diferente.

* Esto es , si un campo aparece mas de una vez con el mismo nombre , se computa una sola vez.

*/

unsigned int HTTPHeader :: getUniqueHeadersCount () const

/** Agrega el contenido del buffer concatenandolo como valor al ultimo campo insertado.

* Sirve para agregar contenido cuando se ha hecho folding.

* \param header_line buffer que contiene la linea del encabezado HTTP.

* \param line_size tmanio maximo a leer del buffer , si vale 0, se lee todo.

* \return -1 en caso de error: i.e. de que no exista ningun campo.


*/

int HTTPHeader :: AppenValueToLastField(StringInc& header_line , unsigned int line_size)

/** Agrega el contenido del buffer concatenandolo como valor al campo de nombre field_name.

* Sirve para agregar comentarios en campos.

* \param field_name nombre del campo a buscar.

* \param value_to_append buffer que contiene el contenido a agregar.



*/

int HTTPHeader :: AppenValueToField(const StringInc& field_name , const StringInc& value_to_append)



/** Reemplaza el contenido del campo con nombre field_name con el valor de value.


* \param value buffer que contiene el contenido a agregar.



*/

int HTTPHeader :: ReplaceValueFromField(const StringInc& field_name , const StringInc& value)

/** Agrega el contenido del buffer concatenandolo en forma de comentario HTTP

* (i.e. entre parentesis) al campo de nombre field_name.


* \param comment_to_append buffer que contiene el comentario a agregar.



*/

int HTTPHeader :: AppenHTTPCommentValueToField(const StringInc& field_name , const StringInc& comment_to_append)

/** Quita todos los comentarios de todos los valores de los campos. */

void HTTPHeader :: RemoveAllComments ()

/** Imprime en la salida estandar el listado de nombres de los campos en el orden en que se encuentran */

void HTTPHeader :: PrintFieldNames ()

// ///////////////////////////////////////////////////////////////////////////

// Metodos para la aplicacion de las tecnicas esteganograficas especificas //

// ///////////////////////////////////////////////////////////////////////////

/** Ordena alfabeticamente de forma case -insensitive los campos por su nombre. */

void HTTPHeader ::sort()

// ///////////////////////////////////////////////////////////////

/** Agrega espacios al comienzo del valor del campo , de acuerdo a lo indicado en la lista lista_numeros.

* Cada uno de los valores de lista_numeros indica cuantos espacios se debe agregar al comienzo de cada uno de los

* campos.

* El bit menos significativo de esa cantidad indica el tipo de caracter que se agregara:

* 1 para un tabulador: TAB

* 0 para el espacio: SP

* \param lista_numeros lista con la cantidad de espacios que hay que agregar en cada una de los encabezados del

* mensaje.

*/

void HTTPHeader :: AddLWSAtBegginning(std::vector <unsigned int >& lista_numeros)

/** Lee los espacios existentes al comienzo de cada del valor de cada campo y los agregar en la lista.

* \param lista_numeros lista donde se coloca la cantidad de espacios leidos en cada uno de los valores de campos.

* \return tamanio de la lista de cantidad de espacios.

*/

unsigned int HTTPHeader :: ReadLWSAtBegginning(std::vector <unsigned int >& lista_numeros)

/** Quita todos los caracteres LWS del comienzo del contenido del campo.

* Para utilizar por parte del guardian.

*/

void HTTPHeader :: RemoveLWSAtBegginning ()

// ///////////////////////////////////////////////////////////////

// ///////////////////////////////////////////////////////////////

/** Modifica las mayusculas y minusculas del nombre de los campos , de acuerdo a lo indicado en lista_numeros.

* Por convencion del protocolo esteganografico , se coloca en mayusculas o minusculas solo la primera posicion.

* \param lista_numeros lista donde se debe indicar para cada uno de los campos si se

* debe aplicar mayusculas (valor 1 en la n-esima posicion) o minusculas (valor 0 en la n-esima posicion ).

*/

void HTTPHeader :: ApplyCaseSensitiveToFieldNames(std::vector <unsigned int >& lista_numeros)

/** Lee las mayusculas y minusculas de cada uno de los nombre de los campos y coloca en

* lista_numeros un 1 si el nombre del campo comienza con mayusculas y 0 si comienza con minusculas.

* \param lista_numeros lista donde se coloca la 1 o 0 en cada posicion de acuerdo a si

* el primer caracter del nombre del campo se encuentra en mayusculas o minusculas.

*/

unsigned int HTTPHeader :: ReadCaseSensitiveFromFieldNames(std::vector <unsigned int >& lista_numeros)

/** Convierte todos los nombres de campos a minusculas.


*/

void HTTPHeader :: RemoveCaseSensitiveFromFieldNames ()

// ///////////////////////////////////////////////////////////////

// ///////////////////////////////////////////////////////////////

/** Aplica folding a los campos del encabezado.

* Aplica hasta un maximo de un folding por campo. Previamente , quita el folding existente.

* Intenta aplicarlo en el primer caracter SP que encuentra (para levantar menos sospecha ).

* \param lista_numeros lista donde se debe indicar para cada uno de los campos si se

* debe aplicar folding: 1 para aplicar folding , 0 para no aplicarlo.

*/

void HTTPHeader :: AddFoldingToValues(std::vector <unsigned int >& lista_numeros)



/** Lee el folding de los campos del encabezado y lo coloca en la lista de numeros.

* Los valores a colocar son 1 o 0.


* en el campo se realizo folding o no.

* \return cantidad de foldings leidos

*/

unsigned int HTTPHeader :: ReadFoldingFromValues(std::vector <unsigned int >& lista_numeros)

/** Quita el folding de todos los campos del encabezado.


*/

void HTTPHeader :: RemoveFoldingFromValues ()

// ///////////////////////////////////////////////////////////////

// ///////////////////////////////////////////////////////////////

/** Modifica el orden de los campos de acuerdo al listado indicado en lista_numeros.

* Los campos se toman de a pares , y se coloca primer el menor , si el valor del vector

* es 0, o viceversa , si el valor del vector es 1.

* Inicialmente , los campos se ordenan alfabeticamente. Luego se aplican estas consideraciones.

* \param lista_numeros vector que contiene valores 1 y 0 en cada posicion , que indica

* si se debe alterar el orden del par de campos o no.

*/

void HTTPHeader :: ApplyOrderToValues(std::vector <unsigned int >& lista_numeros)

/** Lee los valores de ordenamiento de los campos , de acuerdo a las modificaciones

* introducidas por ApplyOrderToValues(lista_numeros ).


* el primer campo del par de campos es mayor o menor que el segundo campo.

* \return cantidad de bits leidos

*/

unsigned int HTTPHeader :: ReadOrderFromValues(std::vector <unsigned int >& lista_numeros)

/** Ordena alfabeticamente los campos , para cambiar el orden. */

void HTTPHeader :: ChangeOrderFromValues ()

D.3.3. HTTPHeaderField.cpp

/** Constructor */

HTTPHeaderField :: HTTPHeaderField (): _field_name (), _field_value ()

/** Destructor */

HTTPHeaderField ::~ HTTPHeaderField ()

/** Constructor adicional que recibe los parametros para asignarlo completo. */

HTTPHeaderField :: HTTPHeaderField(const StringInc& field_name , const StringInc& field_value , unsigned int initial_pos ): _field_name (), _field_value ()

/** Constructor de copia. */

HTTPHeaderField :: HTTPHeaderField(const HTTPHeaderField &header ): _field_name (), _field_value ()

/** Operador de asignacion =

*/

HTTPHeaderField& HTTPHeaderField :: operator =( const HTTPHeaderField &header)

/** Determina si es menor respecto de otro objeto HTTPHeaderField ,

* en forma alfabetica respecto al nombre.

* \param header encabezado contra el que comparar.

* \return true si el nombre del campo es menor al de header.


*/

bool HTTPHeaderField ::operator <( const HTTPHeaderField &header)

/** Determina es igual respecto de otro objeto HTTPHeaderField ,

* en forma alfabetica respecto al nombre.

* \param header encabezado contra el que comparar.

* \return true si el nombre del campo es igual al de header.


*/

bool HTTPHeaderField :: operator ==( const HTTPHeaderField &header)

/** Limpia el contenido del campo del encabezado.

*/

void HTTPHeaderField :: ClearHeaderField ()

/** Asigna el valor del nombre del campo.

* \param field_name name del campo que se desea asignar.

*/

void HTTPHeaderField :: setFieldName(const StringInc& field_name)

/** Asigna el valor del nombre del campo.

* \param field_name name del campo que se desea asignar.



*/

void HTTPHeaderField :: setFieldName(const char* field_name)

/** Devuelve el nombre del campo.

* \return nombre del campo.

*/

StringInc HTTPHeaderField :: getFieldName () const

/** Asigna el valor del contenido del campo.

* \param field_value valor del campo que se desea asignar.

*/

void HTTPHeaderField :: setFieldValue(const StringInc& field_value)

/** Asigna el valor del contenido del campo.

* \param field_value valor del campo que se desea asignar.

*/

void HTTPHeaderField :: setFieldValue(const char* field_value)

/** Concatena line_size caracteres del valor del buffer field_value en el contenido del campo.

* \param field_value contenido a concatenar.

* \param line_size cantidad de caracteres a concatenar. Si se indica 0, se concatenan todos.

*/

void HTTPHeaderField :: appendFieldValue(const StringInc& field_value , unsigned int line_size)

/** Concatena line_size caracteres del valor del buffer field_value al comienzo del contenido del campo.



*/

void HTTPHeaderField :: appendFieldValueToBeginning(const StringInc& field_value , unsigned int line_size)

/** Concatena line_size caracteres del valor del buffer field_value al comienzo del _final_ del campo.



*/

void HTTPHeaderField :: appendFieldValueToEnding(const StringInc& field_value , unsigned int line_size)

/** Concatena line_size caracteres del valor del buffer field_value al comienzo del contenido del campo.



*/

void HTTPHeaderField :: appendFieldValueToBeginning(const char* field_value , unsigned int line_size)

/** Devuelve el contenido del valor del campo.

* \return Nombre del campo.

*/

StringInc HTTPHeaderField :: getFieldValue () const

/** Devuelve el campo completo , compuesto por:

* Nombre:valor

* \return Valor completo del campo , de la forma Nombre:valor.

*/

StringInc HTTPHeaderField :: getFullField () const

/** Compara el nombre del campo contra el del parametro field_name.

* La comparacion se realiza de forma case -insensitive.

* \param field_name nombre del campo contra el que se desea comparar.

* \return true en caso de que el nombre del campo sea _igual_ a field_name en una comparacion case -insensitive.

* \return false en caso de que el nombre del campo sea _distinto_ a field_name en una comparacion case -insensitive.

*/

bool HTTPHeaderField :: is_equals_field_name(const StringInc& field_name) const

/** Compara el nombre del campo contra el del parametro field_name.

* La comparacion se realiza de forma case -insensitive.

* \param field_name nombre del campo contra el que se desea comparar.

* \return true en caso de que el nombre del campo sea _igual_ a field_name en una comparacion case -insensitive.

* \return false en caso de que el nombre del campo sea _distinto_ a field_name en una comparacion case -insensitive.

*/

bool HTTPHeaderField :: is_equals_field_name(const char* field_name) const

/** Determina si el contenido del campo posee al menos un caracter SP

* \return true si el contenido del campo posee al menos un caracter SP.


*/

bool HTTPHeaderField :: containsSPInvalue () const

/** Quita todos los comentarios (i.e. el texto entre parentesis) del contenido del campo.

*/

void HTTPHeaderField :: RemoveAllComments ()

D.3.4. HTTPMessage.cpp

HTTPMessage :: HTTPMessage (): _RequestLine (), _StatusLine (), _entity_body ()

HTTPMessage ::~ HTTPMessage ()



/** Reinicializa el contenido de todos los campos internos.

* Se debe invocar antes de colocar un nuevo mensaje.

*/

void HTTPMessage :: ClearMessage ()

/** Devuelve true si el mensaje esta procesado completo , false en caso contrario.

*/

bool HTTPMessage :: getMessageIsComplete () const

/** Devuelve el contenido del cuerpo del mensaje , que sale del campo Content -Length

* \return largo del contenido del campo.

*/

int HTTPMessage :: getContentLength () const

/** Devuelve la cantidad de campos del encabezado.

* \return valor correspondiente a la cantidad de campos del encabezado.

*/

unsigned int HTTPMessage :: getHeadersCount () const




*/

unsigned int HTTPMessage :: removeFieldWithName(const char* field_name)

/** Elimina todos los campos de nombre desconocido.

* Estos son los que no esten definidos en el protocolo , ademas , se permite los

* siguientes , por ser de uso frecuente en las comunicaciones analizadas:

* Proxy -Connection

* Cookie

* Set -Cookie

* \return cantidad de campos eliminados.

*/

unsigned int HTTPMessage :: removeUnknownFields ()


* \return puntero al texto del campo encontrado.

* \return NULL en caso de tratarse de otro tipo de mensaje

*/

StringInc HTTPMessage :: getFieldValue(const char* field_name) const

/** Lee un mensaje HTTP completo.

* \param message buffer que contiene el mensaje

* \return largo del mensaje leido.


*/

int HTTPMessage :: LoadFullMessage(StringInc& message)

/** Asigna el tipo de mensaje (pedido o respuesta)

* \param message_type tipo de mensaje

*/

void HTTPMessage :: setMessageType(http_message_type_t message_type)

/** Devuelve la linea de pedido.

* Si no es un mensaje de pedido , devuelve una linea en blanco.

*/

StringInc HTTPMessage :: getRequestLine () const

/** Devuelve la linea de respuesta.

* Si no es un mensaje de respuesta , devuelve una linea en blanco.

*/

StringInc HTTPMessage :: getStatustLine () const

/** Devuelve la URI de pedido.

* \return string vacia si el mensaje no es un pedido , si no se cargo la URI de pedido

* o si la Request -Line es invalida.

* \return otro valor: corresponde a la URI de pedido.

*/

StringInc HTTPMessage :: getRequestURI () const

/** Devuelve el nombre del Host de destino , si se trata de un mensaje de pedido.


* \return string vacia en caso contrario.

*/

StringInc HTTPMessage :: getDestHostName () const

/** Devuelve el puerto (si no esta en el mensaje , el puerto default es el 80)

* \return numero de puerto de destino , si se trata de un mensaje de pedido.


StringInc HTTPMessage :: getDestPort () const

/** Modifica el valor del puerto de destino del encabezado del mensaje de pedido.

* Modifica la linea de pedido y el campo Host (si existe ).

* Si el puerto indicado en el parametro es NULL , lo quita.

* \param puerto valor del puerto. Si es igual a NULL , quita el puerto

* (en consecuencia , se tomara el valor por default: 80).

*/

void HTTPMessage :: changeDestPort(const char* puerto)

/** Devuelve el nombre del Host de destino incluido el puerto , si se trata de un mensaje de pedido.





*/

StringInc HTTPMessage :: getFullDestHostName () const

/** Devuelve una cadena correspondiente al contenido completo del mensaje , para ser utilizada en los envios.

* \return cadena de caracteres que contiene la totalidad del mensaje HTTP.

*/

StringInc HTTPMessage :: getFullContent () const

/** Devuelve el tipo de mensaje HTTP (pedido o respuesta)

* \return tipo de mensaje: UNKNOWN_MSG_TYPE , REQUEST , REPLY

*/

HTTPMessage :: http_message_type_t HTTPMessage :: getMessageType () const

/** Devuelve el cuerpo del mensaje.

* \return Cuerpo del mensaje.

*/

StringInc HTTPMessage :: getEntityBody () const

/** Vacia el cuerpo del mensaje. */

void HTTPMessage :: clearEntityBody ()

/** Agrega a la linea de estado de la respuesta cant caracteres de message.

* \param message mensaje a agregar en la linea de estado.

* \param cant cantidad de caracteres a agregar de mensaje en la respuesta.

*/

void HTTPMessage :: _SetStatusLine(StringInc message , unsigned int cant)

/** Obtiene el codigo de estado de la respuesta a partir de la lineas de status.

* \return codigo de estado de la respuesta.

* \return 0 en caso de error

*/

unsigned int HTTPMessage :: getStatusCode () const

/** Devuelve el texto del mensaje de la linea de estado de la respuesta.

* \return texto de la respuesta , si no se encuentra devuelve una string vacia.

*/

StringInc HTTPMessage :: getStatusText () const

/** Calcula el tamanio del cuerpo del mensaje.

* \return tamanio en bytes del cuerpo del mensaje.

* \return -1 si no se conoce.

*/

int HTTPMessage :: calculateBodySize () const

// Los siguientes son los metodos de aplicacion de esteganografia generales

/** Aplica las tecnicas esteganograficas al mensaje.

* Este metodo se invoca tanto para mensajes de pedido (request de HTTP), cuanto mensajes de respuesta (reply HTTP).

* \param p puntero al manejador del mensaje esteganografico , de donde realizar la lectura.



*/

int HTTPMessage :: ApplyStegMessage(SharedStegProtocol& p)

/** Lee el mensaje esteganografico del mensaje HTTP , de acuerdo a las tecnicas aplicadas.


* \param p puntero al manejador del mensaje esteganografico , donde aplicar el mensaje leido.



*/

int HTTPMessage :: ReadStegFromMessage(SharedStegProtocol& p)

/** Aplica "ruido" al mensaje HTTP para evitar la propagacion de mensajes

* esteganograficos a partir de las tecnicas aplicadas.




*/

int HTTPMessage :: ApplyStegNoiseToMessage ()

// ///////////////////////////////////////////////////////////////

// Metodos para la aplicacion de las tecnicas esteganograficas //

// ///////////////////////////////////////////////////////////////

// Los metodos que realizan la aplicacion de tecnicas esteganograficas particulares


* Este metodo se invoca para mensajes de pedido (request de HTTP).




*/

int HTTPMessage :: ApplyStegToRequestMessage(SharedStegProtocol& p)






*/

int HTTPMessage :: ReadStegFromRequestMessage(SharedStegProtocol& p)



/** Aplica "ruido" al mensaje HTTP para evitar la propagacion de mensajes

* esteganograficos a partir de las tecnicas aplicadas.




*/

int HTTPMessage :: ApplyStegNoiseToRequestMessage ()


* Este metodo se invoca para mensajes de respuesta (reply de HTTP).




*/

int HTTPMessage :: ApplyStegToReplyMessage(SharedStegProtocol& p)






*/

int HTTPMessage :: ReadStegFromReplyMessage(SharedStegProtocol& p)

/** Aplica "ruido" al mensaje HTTP para evitar la propagacion de mensajes esteganograficos a partir de las tecnicas

* aplicadas.




*/

int HTTPMessage :: ApplyStegNoiseToReplyMessage ()

// /////////////////////////////////////////////////////////////////

// Metodos que aplican las tecnicas esteganograficas propiamente //

// /////////////////////////////////////////////////////////////////

/** Armar una lista de numeros a partir del mensaje , donde en cada posicion se colocan hasta un maximo de max_cant

* valores


* \param lista_numeros lista donde colocar los numeros obtenidos.

* \param max_cant cantidad de bits a leer para cada posicion de la lista.

* \param cant_numbers_for_vector cantidad de valores a colocar en el vector , si se

* indica 0, se colocaran tantos valores como campos hay en el encabezado.

*/

void HTTPMessage :: _PreparaListaDeNumerosDesdeMensaje(SharedStegProtocol& p, lista_numeros_t& lista_numeros ,

unsigned int max_cant , unsigned int cant_numbers_for_vector)

/** Agrega bits al mensaje esteganografico de acuerdo a los numeros leidos de la lista de numeros.


* \param lista_numeros lista de numeros de donde obtener los bits.

* \param max_cant cantidad maxima de bits a obtener de cada posicion de la lista de numeros.

*/

void HTTPMessage :: _AgregarBitsDeLaListaDeNumerosAlMensaje(SharedStegProtocol& p,

lista_numeros_t& lista_numeros , unsigned int max_cant)

// Caracteres LWS antes del contenido del campo.

/** Agrega espacios al comienzo del contenido de cada uno de los valores de campos ,

* de acuerdo a lo interpretado en el mensaje esteganografico.

* \param p puntero al manejador del mensaje esteganografico , donde obtener el mensaje.

*/

void HTTPMessage :: AddLWSToBeginningOfValues(SharedStegProtocol& p)

/** Lee los espacios colocados al comienzo de cada uno de los campos del encabezado y

* agrega los bits correspondientes al mensaje esteganografico.


*/

void HTTPMessage :: ReadLWSFromBeginningOfValues(SharedStegProtocol& p)

/** Quita todos los caracteres LWS que encuentra al comienzo del contenido de todos los valores de los campos.

* Este metodo es para ser utilizado por el guardian.

*/

void HTTPMessage :: RemoveLWSFromBeginningOfValues ()

// Case sensitive para el nombre del campo

/** Aplica case sensitive a los nombres de los campos.

* Aplica un bit del mensaje en cada uno de los campos.

* Si el bit del mensaje es 1, coloca la inicial en mayuscula.

* Si el bit del mensaje es 0, coloca la inicial en minuscula.

* \param p puntero al manejador del mensaje esteganografico , de donde leer el mensaje.

*/

void HTTPMessage :: ApplyCaseSensitiveToFieldNames(SharedStegProtocol& p)

/** Lee case sensitive de los nombres de los campos.

* Lee un bit del mensaje en cada uno de los campos.

* Si la inicial del campo esta en mayuscula , el bit leido para el mensaje es 1.



* Si la inicial del campo esta en minuscula , el bit leido para el mensaje es 0.


*/

void HTTPMessage :: ReadCaseSensitiveFromFieldNames(SharedStegProtocol& p)

/** Coloca la primer letra del nombre del campo en minuscula , para evitar la propagacion del mensaje esteganografico.


*/

void HTTPMessage :: RemoveCaseSensitiveFromFieldNames ()

// Folding en el contenido del campo

/** Aplica folding al contenido de los campos.

* Aplica un bit del mensaje en cada uno de los campos.

* Si el bit del mensaje es 1, se aplica un folding.

* Si el bit del mensaje es 0, no se aplica un folding.


*/

void HTTPMessage :: AddFoldingToValues(SharedStegProtocol& p)

/** Lee el folding del contenido de los campos.

* Lee un bit del mensaje en cada uno de los campos.

* Si en el contenido del campo se aplico folding , el bit leido para el mensaje es 1.

* Si en el contenido del campo no se aplico folding , el bit leido para el mensaje es 0.


*/

void HTTPMessage :: ReadFoldingFromValues(SharedStegProtocol& p)

/** Quitar el folding del contenido de todos los campos.


*/

void HTTPMessage :: RemoveFoldingFromValues ()

// Linea en blanco antes de la linea de pedido

/** Agrega una linea en blanco al comienzo de la linea de pedido , de acuerdo al bit leido del mensaje esteganografico

* Este metodo se aplica solo a mensajes de pedido.


*/

void HTTPMessage :: AddBlankLineBeforeRequestLine(SharedStegProtocol& p)

/** Lee si hay lineas en blanco antes del comienzo de la linea de pedido y agrega un bit correspondiente al mensaje

* esteganografico.

* Agrega 1 si encuentra una linea previa , 0 en caso contrario.

*/

void HTTPMessage :: ReadBlankLineBeforeRequestLine(SharedStegProtocol& p)

/** Quita las lineas en blanco antes de la linea de pedido.


*/

void HTTPMessage :: RemoveBlankLineBeforeRequestLine ()

// Funciones esteganograficas para agregar comentarios a campos

/** Agrega un comentario al campo de nombre indicado en field_name.

* El comentario se construye con contenido obtenido del mensaje esteganografico.

* Si no encuentra un campo con ese nombre , sale sin aplicar modificaciones.


* \param field_name nombre del campo donde se desea agregar el comentario extraido del mensaje esteganografico.

*/

void HTTPMessage :: AddStegCommentToField(SharedStegProtocol& p, const char* field_name)

/** Lee el comentario esteganografico que se haya aplicado en el campo de nombre

* field_name , y lo adiciona al mensaje esteganografico p.

* Si no encuentra un campo con ese nombre , sale sin aplicar modificaciones.


* \param field_name nombre del campo donde se desea obtener el comentario extraido del mensaje esteganografico.

*/

void HTTPMessage :: ReadStegCommentFromField(SharedStegProtocol& p, const char* field_name)

/** Quita todos los comentarios de todos los campos.

* Paran usar por el guardian esteganografico.

*/

void HTTPMessage :: RemoveAllComments ()

// esteganografia sobre el orden de los campos

/** Reordena los campos del mensaje , de acuerdo a los bits extraidos del mensaje esteganografico.

* Los campos se toman de a pares (incluyendo las repeticiones de campos , que se toman juntas),

* y se coloca primer el menor , si el valor del vector es 0, o viceversa , si el valor del vector es 1.

* Inicialmente , los campos se ordenan alfabeticamente. Luego se aplican estas consideraciones.


*/

void HTTPMessage :: AddStegToFieldsOrder(SharedStegProtocol& p)

/** Lee los valores de ordenamiento de los campos , de acuerdo a las modificaciones

* introducidas por AddStegToFieldsOrder(SharedStegProtocol& p).




*/

void HTTPMessage :: ReadStegFromFieldsOrder(SharedStegProtocol& p)

/** Ordena alfabeticamente los campos , para cambiar el orden. */

void HTTPMessage :: ChangeFieldsOrder ()

////accept -Charset

// Aplicacion de esteganografia sobre la colocacion de un campo de tipo lista en un unico campo , o multiples campos

// cada uno con un valor de la lista.

/** Convierte el campo de tipo lista de valores , con nombre field_name a multiples campos ,

* si el bit leido del mensaje esteganografico es 1, o lo convierte a un solo campo si el bit leido es 0.

* \param p puntero al manejador del mensaje esteganografico , de donde leer el bit del mensaje.

* \param field_name nombre del campo sobre el que se aplica esta tecnica.

*/

void HTTPMessage :: AddStegToFieldList(SharedStegProtocol& p, const char* field_name)

/** Lee si el campo de tipo lista , de nombre field_name esta escrito como multiples campos

* (en cuyo caso agrega un bit 1 al mensaje esteganografico), o si esta escrito como un solo campo

* (en este caso , coloca un bit 0).


* \param field_name nombre del campo sobre el que se aplica esta tecnica.

*/

void HTTPMessage :: ReadStegFromFieldList(SharedStegProtocol& p, const char* field_name)

/** Convierte un campo ingresado como lista , existente en multiples campos ,

* en un unico campo con la lista de valores separados por comas.

* Este metodo es para ser usado por el guardian esteganografico.


*/

void HTTPMessage :: ChangeListFromField(const char* field_name)

// esteganografia en el puerto 80, que es optativo colocar

/** Agregar esteganografia a partir de la aplicacion del puerto cuando es el 80, que corresponde al valor estandar.

* Si no se coloca , o si se coloca 80, es equivalente.

* Se coloca un solo bit del mensaje esteganografico en el mensaje HTTP:

* si se lee un 1 del mensaje esteganografico , se coloca el puerto 80 de todos modos ,

* si se lee un 0 del mensaje esteganografico , se quita el puerto 80.

* Si el puerto de destino del mensaje de destino no es el 80, no se realiza accion.


*/

void HTTPMessage :: AddStegToRequestHostnamePort(SharedStegProtocol& p)

/** En caso de que el puerto de destino sea el 80, si el valor 80 esta explicitamente

* en la URI , se interpreta como un 1 en el mensaje esteganografico.

* En caso contrario , se interpreta como un 0.


*/

void HTTPMessage :: ReadStegFromRequestHostnamePort(SharedStegProtocol& p)

/** Si el puerto es 80, lo quita en todos los casos. Este metodo es para ser utilizado por el guardian.

*/

void HTTPMessage :: ChangeRequestHostnamePort ()

// esteganografia en el campo para el e-mail (campo "From")

/** Codifica un bit del mensaje esteganografico a partir del uso del campo para el e-mail del usuario.

* El campo es From. El bit se extrae del mensaje esteganografico p.

* Si se debe colocar un bit de valor 1, se coloca como mail la direccion: [email protected].

* Si se debe colocar un bit de valor 0, se coloca como mail la direccion: [email protected].

* Si el campo ya contenia una direccion de mail , entonces no se aplica esteganografia.


*/

void HTTPMessage :: AddStegToEmailField(SharedStegProtocol& p)

/** Lee un bit a partir del campo correspondiente al e-mail del usuario (campo From).

* Si se lee la direccion [email protected] , se interpreta un un bit de valor 1.

* Si se lee la direccion [email protected] , se interpreta un un bit de valor 0.

* Si se lee una direccion de mail distinta , no se interpreta como mensaje esteganografico.


*/

void HTTPMessage :: ReadStegFromEmailField(SharedStegProtocol& p)

/** Quita el campo "From" que corresponde al e-mail del usuario , para impedir su uso esteganografico.


* Nota: esta accion limita la funcionalidad del protocolo.

* Aunque el objetivo principal de la comunicacion no resulta malogrado.

*/

void HTTPMessage :: RemoveEmailField ()

// esteganografia en un campo propietario (campo "Example ")

/** Codifica un bit del mensaje esteganografico en un campo propietario del encabezado del mensaje HTTP.

* Se define como campos propietarios: Example0 y Example1. El valor de este campo es indistinto.

* Un bit con valor 1 se codifica con la presencia del campo Example1.

* Un bit con valor 0 se codifica con la presencia del campo Example0.


*/



void HTTPMessage :: AddStegToPropietaryField(SharedStegProtocol& p)

/** Lee la existencia de un campo propietario para agregar un bit al mensaje esteganografico.

* Si se encuentra la existencia del campo Example1 , se interpreta como un bit con valor 1.

* Si se encuentra la existencia del campo Example0 , se interpreta como un bit con valor 0.


*/

void HTTPMessage :: ReadStegFromPropietaryField(SharedStegProtocol& p)

// esteganografia en un cero al comienzo de la version HTTP /1.1 en la URI de pedido

/** Codifica un bit del mensaje esteganografico en la forma de escribir la version de

* HTTP en la URI del mensaje de pedido.

* Si la version de la linea de pedido no es HTTP /1.1, se sale sin aplicar el mensaje esteganografico.

* Si se debe colocar un bit 1, escribe la version como HTTP /01.1.

* Si se debe colocar un bit 0, escribe la version como HTTP /1.1.


*/

void HTTPMessage :: AddStegToHTTPRequestVersion(SharedStegProtocol& p)

/** Agrega un bit al mensaje esteganografico de acuerdo a la forma en la que esta escrita la version de HTTP.

* Si esta escrito como HTTP /01.1 , agrega un 1.

* Si esta escrito como HTTP /1.1, agrega un 0.

* Si esta escrito de otra manera , no se adiciona ningun bit al mensaje esteganografico.

* \param p puntero al manejador del mensaje esteganografico , donde aplicar el bit leido.

*/

void HTTPMessage :: ReadStegToHTTPRequestVersion(SharedStegProtocol& p)

/** Modifica la version de HTTP de la URI del mensaje de pedido , que puede estar escrita como: HTTP /01.1 a HTTP /1.1.


*/

void HTTPMessage :: NormalizeHTTPRequestVersion ()

D.3.5. HTTPProxy.cpp

/** Constructor */

HTTPProxy :: HTTPProxy (): _proxy_dest_name ()

/** Destructor */

HTTPProxy ::~ HTTPProxy ()

/** Envia un mensaje HTTP.

* Si se ha enviado previamente un mensaje al host de destino no establece una nueva conexion

* (reutiliza una existente ).

* \param message mensaje HTTP a enviar.

* \return 0 en caso de envio correcto.

* \return -1: en caso de error.

*/

int HTTPProxy :: SendHTTPMessage(HTTPMessage& message)

/** Configura el socket servidor a partir de los parametros que se debieron leer del

* archivo de configuracion y queda a la espera de conexiones entrantes.

* \param port puerto en el que se debe escuchar conexiones entrantes.

* \param name nombre de fantasia del proxy.

* \param proxy_type tipo de proxy:

* - transparente ,

* - lector esteganografico ,

* - escritor esteganografico ,

* - guardian.

* \param steg_direction direccion de los mensajes a los que se les aplica esteganografia.

* \param proxy_dest_name (opcional) nombre del proxy al que se debe conectar el proxy cliente.

* \param proxy_dest_port (opcional) puerto del proxy al que se debe conectar el proxy cliente.

* \param is_debug (opcional) indica si se debe mostrar mensajes de debug.

* \return -1 en caso de error en los parametros.

* \return -2 en caso de error al hacer el bind del socket.

* \return 0 en otro caso.

*/

int HTTPProxy ::Setup(int port , const char* name , proxy_type_t proxy_type , steg_direction_t steg_direction ,

const char* proxy_dest_name , unsigned int proxy_dest_port , bool is_debug)

/** Metodo principal del proceso hijo que atiende los pedidos del cliente.

* \param ClientConnection socket conectado del cliente.

* \param name Nombre del proxy (e.g.: alicia)

* \param proxy_type tipo de proxy: TRANSPARENT , STEG_WRITER , STEG_READER , STEG_WARDEN

* \param steg_direction direccion en la que se aplica esteganografia: TO_SERVER , TO_CLIENT , NON_DIRECTION

* \param proxy_dest_name (opcional) nombre del proxy de destino (NULL si se conecta al servidor de destino)

* \param proxy_dest_port (opcional) puerto TCP del proxy de destino (0 si se conecta al servidor de destino)

* \param is_debug (opcional) indica si se debe mostrar mensajes de debug.


* \return 0 en caso de haber finalizado correctamente la conexion con el cliente.

*/

int HTTPProxy :: SetupClient(TCPSocket* ClientConnection , StringInc& name , proxy_type_t proxy_type ,

steg_direction_t steg_direction , const char* proxy_dest_name , unsigned int proxy_dest_port , bool is_debug)

/** Metodo principal del proceso hijo que atiende los pedidos del cliente.

* \param ClientConnection socket conectado al cliente.



* \param ServerConnection socket conectado al servidor.

* \param name Nombre del proxy (e.g.: alicia)

* \param proxy_type tipo de proxy: TRANSPARENT , STEG_WRITER , STEG_READER , STEG_WARDEN

* \param steg_direction direccion en la que se aplica esteganografia: TO_SERVER , TO_CLIENT , NON_DIRECTION


* \return 0 en caso de haber finalizado correctamente la conexion con el cliente.

*/

int HTTPProxy :: SetupServer(TCPSocket* ClientConnection , HTTPConnection* ServerConnection , StringInc& name ,

proxy_type_t proxy_type , steg_direction_t steg_direction)

/** Busca en el pool de conexiones si hay alguna conexion ya establecida con el servidor y el puerto pasados por

* parametro.

* \param servername nombre del servidor.

* \param port numero de puerto.

* \return devuelve el puntero a la conexion establecida.

* \return NULL en caso de error o no existir una conexion a ese servidor

*/

HTTPConnection* HTTPProxy :: SearchForConnectionToServer(StringInc& servername , StringInc& port)

/** Procesa el mensaje que recibio el proxy. Se aplican consideraciones esteganograficas.

* \param message mensaje que envio el cliente



*/

int HTTPProxy :: ProcessMessage(HTTPMessage& message)

/** Escribe el contenido del mensaje en un archivo de log. Se usa a los fines de Debug.

* \param message mensaje HTTP a escribir en el log.

*/

void HTTPProxy :: WriteMessageToLogFile(HTTPMessage& message)

D.3.6. HTTPSemaphore.cpp

/** Crea el semaforo para usar en la comunicacion HTTP.

* \param proxy_name nombre del proxy que invoca al semaforo.

* \param type tipo de proxy: SERVER o CLIENT

*/

HTTPSemaphore :: HTTPSemaphore(const char* proxy_name , http_sem_t type)

/** Destructor. */

HTTPSemaphore ::~ HTTPSemaphore ()

/** Bloquea el proceso hasta que se libera el semaforo. Toma el uso exclusivo del mismo. */

int HTTPSemaphore ::Wait()

/** Libera el uso exclusivo del semaforo. */

int HTTPSemaphore :: Signal ()

D.4. Archivos auxiliares (utils/)

D.4.1. ConfigFile.cpp

ConfigFile :: ConfigFile ()

ConfigFile ::~ ConfigFile ()

/** Lee los parametros de un archivo de configuracion.

* Los parametros se colocan uno por lineas de la forma: clave:valor

* \param FileName nombre del archivo de configuracion.



*/

int ConfigFile :: LoadConfigFromFile(const char* FileName)

/** Devuelve el contenido del valor de cofiguracion ConfigKey.

* \param ConfigKey nombre del parametro de configuraicon.

* \return NULL en caso de no existir un valor para ese parametro.

* \return cadena de caracteres con el valor de ese campo.

*/

const char* ConfigFile :: getValue(const char* ConfigKey)

D.4.2. random.cpp

/** Devuelve aleatoriamente true o false , de acuerdo a la funcion random del sistema.

* \return true|false aleatoriamente.

*/

bool Random :: getRandomBit ()

/** Devuelve un valor random comprendido en un inervalo deseado.

* \param min_value valor menor del intervalo

* \param max_value valor mayor del intervalo

* \return valor aleatorio comprendido en el intervalo [min_value , max_value]

*/

long int Random :: getRandomNumber(long int min_value , long int max_value)



D.4.3. Semaphore.cpp

Semaphore :: Semaphore(key_t key)

Semaphore ::~ Semaphore ()

/** Crea e inicializa el semaforo.

* \return 0 semaforo creado correctamente.

* \return -1 error al crear el semaforo.

* \return -2 error al inicializar el valor del semaforo.

*/

int Semaphore :: Create ()

/** Espera que el semaforo este libre.

* Bloquea a otros procesos que ejecuten wait.

* Esta funcion se conoce con el nombre "P".


* \return -1 en caso de error el abrir el semaforo

*/

int Semaphore ::Wait()

/** Libera el semaforo.

* Esta funcion se conoce con el nombre "V".


* \return -1 en caso de error el abrir el semaforo

*/

int Semaphore :: Signal ()

/** Abre un semaforo ya creado.

* \return 0 semaforo abierto correctamente.

* \return -1 error al abrir el semaforo.

*/

int Semaphore :: _OpenSemaphore ()

D.4.4. shmem.cpp

ShMem::ShMem ()

ShMem ::~ ShMem()

/** Crea una memoria compartida.

*/

int ShMem:: Create(key_t key , size_t size)

/** Abre el area de memoria compartida , para poder utilzarla.

* \return -1 en caso de error al abrir la memoria.

* \return -2 en caso de error al obtener el tamanio del area de memoria compartida.


*/

int ShMem::Open(key_t key)

/** Cierra el area de memoria compartida creada del proceso.



*/

int ShMem::Close()

/** Destruye el area de memoria compartida creada.



*/

int ShMem:: Destroy ()

/** Attach de la memoria compartida al proceso.



*/

int ShMem:: _Attach ()

/** Detach de la memoria compartida al proceso.



*/

int ShMem:: _Detach ()

D.4.5. StringInc.cpp

/** Contructor */

StringInc :: StringInc ()

/** Contructor

* \param text asigna el valor de text al string construida.

*/

StringInc :: StringInc(const char* text): std:: string(text)

/** Destructor */

StringInc ::~ StringInc ()

/** Agrega el contenido. Como es el comportamiento clasido del operador <<

* \param str contenido a agregar.

*/



StringInc& StringInc ::operator <<(const std:: string &str)

/** Agrega un caracter al final de la string.

* \param c caracter a agregar.

* \return referencia a la string completa.

*/

StringInc& StringInc :: append_char(char c)

/** Agregar el contenido de str antes de los caracteres de fin de linea de la propia string.

* \param str string a insertar.


*/

StringInc& StringInc :: append_before_eol(const StringInc& str)

/** Agregar el contenido de str antes de los caracteres de fin de linea de la propia string.

* \param str string a insertar.


*/

StringInc& StringInc :: append_before_eol(const char* str)

/** Reemplaza todas las ocurrencias de what en la string por with_what.

*/

StringInc& StringInc :: replaceAll(const char* what , const char* with_what)

/** Realiza el /unfolding/ de un texto en base a las reglas de la RFC de HTTP:

* se puede colocar un salto de linea , pero la siguiente linea debe comentar con un caracter SP o un TAB

* (i.e. caracteres LWS).

* \return el propio objeto

*/

StringInc& StringInc :: unfold ()

/** Realiza el /unfolding/ de un tipo de fin de linea en particular en base a las reglas de la RFC de HTTP:

* se puede colocar un salto de linea , pero la siguiente linea debe comentar con un caracter SP o un TAB

* (i.e. caracteres LWS).

* \return puntero al propio objeto

*/

StringInc& StringInc :: unfold(const char* end_on_line)

/** Realiza folding de la cadena en la posicion deseada.

* Si la posicion es mayor o igual al tamanio de la cadena , no se realiza la operacion.

* \param pos posicion donde se debe realizar el folding.


*/

StringInc& StringInc :: foldAtPosition(size_t pos)

/** Aplicar folding en la primer ocurrencia del caracter c.

* Puede decidir aplicarse obligatoriamente si no se encuentra el caracter.

* \param c caracter a buscar para determinar la posicion donde aplicar folding.

* \param apply_mandatory indica si se debe aplicar oblicatoriamente el folding , por mas que no se encuentre el

* caracter.


*/

StringInc& StringInc :: ApplyFoldingInFirstChar(char c, bool apply_mandatory)

/** Cuenta la cantidad de veces que se aplico folding sobre la cadena de caracteres.

* \return cantidad de veces que se aplico foldign sobre la cadena de caracteres.

*/

unsigned int StringInc :: countFoldingChars () const

/** Realizar una comparacion case -insensitive con la string str.

* \param str string contra la que compararse

* \return true si las string es igual en forma case insensitive

*/

bool StringInc :: insensitive_comparison(const StringInc& str) const

/** Realizar una comparacion case -insensitive con la string str.


* \return true si las string es igual en forma case insensitive

*/

bool StringInc :: insensitive_comparison(const char* str) const

/** Realiza la comparacion de string de forma "case insensitive ".


* \return true si las string es menor (alfabeticamente) en forma case insensitive

*/

bool StringInc ::operator <(const std:: string &str) const

/** Realiza la comparacion de string de forma "case insensitive ".


* \return true si las string es igual (alfabeticamente) en forma case insensitive

*/

bool StringInc :: operator ==( const std:: string &str) const

/** Convierte la cadena de caracteres a minusculas (lowercase ). */

void StringInc :: tolower ()

/** Convierte la cadena de caracteres a mayusculas (uppercase ). */

/** Quita el intervalo de la cadena de caracteres comprendido enste los caracteres first_char y second_char.

* Si hay varios subconjuntos de cadenas de caracteres con este rango , quita todos.

* Por ejemplo , si first_char == ’(’ y second_char == ’)’, quita todos los textos entre parentesis.

* Incluye first_char y second_char.

* \param first_char caracter de comienzo del intervalo a quitar.

* \param second_char caracter de fin del intervalo a quitar.

* \return cantidad de intervalos quitados.

*/

int StringInc :: removeSubstringBetween(char first_char , char second_char)



D.4.6. TCPSocket.cpp

/** Constructor */

TCPSocket :: TCPSocket ()

/** Destructor */

TCPSocket ::~ TCPSocket ()

TCPSocket :: TCPSocket(const TCPSocket &socket)

/**

* Realiza el open activo que hace un cliente utilizando protocolo TCP.

* Inicializar un socket con los datos del destino. Alocar el socket y establecer la comunicacion (conectarse)

* \param server nombre del host server

* \param port nro de port

* \return 0 si se conecto

* \return -1: si hubo error en la conexion

*/

int TCPSocket :: connect(const char* destination_name , const char* port)

if (:: connect(sock , res ->ai_addr , res ->ai_addrlen) != 0)

/**

* Realiza el open pasivo usando protocolo TCP. Inicializa y crea el socket. Realiza el binding con el SO.

* \param port puerto TCP donde espera conexiones

* \param wait_queue tamanio de la cola de espera de clientes.

* \return 0 si la operacion fue exitosa

* \return -1 si hubo error

*/

int TCPSocket :: listen(int port , unsigned int wait_queue)

/** Lee de a un byte por vez a un buffer hasta encontrar un "\n".

* Agrega un "\0" al final. (simil funciones del C: fgets (3) y strlen (3))

* \param ptr puntero al buffer donde se coloca lo leido

* \param maxlong tamanio del buffer (en bytes)

* \return numero de caracter leidos


*/

int TCPSocket :: recibir(char *ptr , unsigned int maxlong)

/** Lee del socket una cantidad maxlong de caracteres binarios.

* Bloquea al proceso que lo ejecuta hasta recibir al menos 1 byte.

* \param ptr puntero al buffer donde se coloca lo leido

* \param maxlong tamanio maximo a recibir.

* \return numero de caracter leidos


*/

int TCPSocket :: recibir_binario(void *ptr , unsigned int maxlong)

/** Escribe n bytes sobre el socket descriptor:

* si no se escribieron n bytes

* repetir hasta que se hayan escrito los n bytes

* \param ptr puntero al mensaje

* \param n cantidad de bytes a enviar

* \return numero de caracter enviados


*/

int TCPSocket :: enviar(char *ptr , unsigned int n)

/** Espera que se conecten clientes.

* Bloquea al proceso hasta que se produzca una conexion entrante.

* \return NULL en caso de error

* \return otro valor: puntero al socket hijo construido.

*/

TCPSocket* TCPSocket :: sock_accept ()

/** Devuelve el estado de conexion del socket.

* \return true en caso de que el socket se encuentre conectado.

* \return false en caso que el socket no este conectado.

*/

bool TCPSocket :: is_connected ()

/** Devuelve el valor de file descriptor del socket.

*/

int TCPSocket :: getSockFd ()

/** Asigna el valor de file descriptor al socket.

*/

void TCPSocket :: setSockFd(int sockfd)



E. Script PHP para mostrar encabezados HTTP

El siguiente es el codigo fuente del script PHP de nombre prueba_headers.php, utilizadopara determinar los campos que recibe e interpreta el servidor en las pruebas del artefactoHTTP.<html >

<head ><title >Mostrar HTTP headers </title ></head >

<body >

<ul>

<?php

foreach($_SERVER as $h=>$v)

if(ereg(’HTTP_ (.+)’,$h,$hp))

echo "<li>$h = $v </li >\n";

header(’Content -type: text/html’);

?>

</ul >

</body >

</html >

Listado 1: Script PHP utilizado para comprobar los campos que recibe el servidor


Bibliografıa

[75.] 75.06 Organizacion de Datos - Facultad de Ingenierıa. Introduccion a la Teorıa dela Informacion - Teorıa de la Informacion. Compresion de Datos. Codigos Autoco-rrectores. Criptografıa.

[AB] Juan Ignacio Pastore y Virginia L. Ballarin Agustina Bouchet. Encriptacion deimagenes: integracion del algoritmo RSA y tecnicas de codificacion de contornos.Laboratorio de Procesos y Medicion de Senales, Departamento de Electronica. Uni-versidad Nacional de Mar del Plata / CONICET.

[ABS08] Cynthia E. Irvine Timothy E. Levin Alan B. Shaffer, Mikhail Auguston. A SecurityDomain Model to Assess Software for Exploitable Covert Channels. PLAS’08, Jun2008.

[AD03] Simon Castro Alex Dyatlov. Exploitation of data streams authorized by a networkaccess control system for arbitrary data transfers: tunneling and covert channelsover the HTTP protocol. 2003.

[Ado01] Adobe Systems Incorporated. PDF Reference, third edition. Adobe Portable Do-cument Format. Version 1.4. ADDISON-WESLEY, page 978, 2001.

[Ali10] Alissa Figueroa. Privacy issues hit Facebook again. The Christian Science Moni-tor, 2010. http://www.csmonitor.com/Money/new-economy/2010/0730/Privacy-issues-hit-Facebook-again.

[Aur95] Tuomas Aura. Practical invisibility in digital communication. HUT Seminar onNetwork Security, 1995. Helsinki University of Technology, Digital Systems Labo-ratory - FIN-02150 Espoo, Finland.

[AY05] Moti Yung Adam Young. Malicious cryptography: Kleptographic aspects. Topicsin cryptology–CT-RSA 2005: the cryptographers’ track at the RSA, pages 7–18,2005.

[AY07] Moti Yung Adam Young. Space-Eficient Kleptography Without Random Oracles.Information hiding: 9th international workshop, IH 2007, Saint Malo, France, 2007.

[Bai50] M. A. Bailly. Dictionaire Grec-francais. Librairie Hachette. Redige avec le concoursde M. E. Egger., Paris, 1950.

[Bal] Balachander Krishnamurthy, Jeffrey C. Mogul, David M. Kristol. Key Dif-ferences between HTTP/1.0 and HTTP/1.1. http://www8.org/w8-papers/5c-protocols/key/key.html.

[Bau03] Matthias Bauer. New Covert Channels in HTTP - Adding Unwitting Web Browsersto Anonymity Sets. WPES’03, pages 72–78, OCT 2003.

171


[Bob03] Bob Clary. Browser Detection and Cross Browser Support. Feb 2003.https://developer.mozilla.org/en/Browser Detection and Cross Browser Support.

[Bor41] Jorge Luis Borges. El jardın de senderos que se bifurcan (Ficciones, 1944), 1941.

[Bry01] Bryan Clair. Steganography: How to Send a Secret Message. oct 2001.http://www.strangehorizons.com/2001/20011008/steganography.shtml.

[Cac04] Christian Cachin. An Information-Theoretic Model for Steganography. March, 42004.

[Cac05] Christian Cachin. Digital Steganography. 2005. IBM Research - Zurich ResearchLaboratory - CH- 8803 Ruschlikon, Switzerland.

[Chi10] Susan Chira. Answers to Readers’ Questions About State’s Secrets. The New YorkTimes, November 29 2010.

[CK01] Ariana Eunjung Cha and Jonathan Krim. Washington Post Staff Writers, Terro-rists’ Online Methods Elusive, Wednesday, September 19, 2001.

[CMB+08] Ingemar J. Cox, Matthew L. Miller, Jeffrey A. Bloom, Jessica Fridrich, and TonKalker. Digital Watermarking and Steganography. Morgan Kaufmann Publishers,edition edition, 2008.

[Col03] Eric Cole. Hiding in Plain Sight - Steganography and the Art of Covert Communi-cation. Bob Ipsen. Edited by Carol Long., 2003.

[Com] JPEG Committee. JPEG Homepage. http://www.jpeg.org/jpeg/index.html.

[Cor] Symantec Corporation. Crimeware: Trojans & Spyware.http://www.symantec.com/norton/cybercrime/trojansspyware.jsp.

[Cra] Scott Craver. On Public-key Steganography in the Presence of an Active Warden.Intel Corporation, Microcomputer Research Labs.

[Crı10] Crıtica de la Argentina - Sociedad. China elimina men-sajes de texto con contenido sexual. Enero 26 2010.http://www.criticadigital.com/impresa/index.php?secc=nota&nid=37529.

[Dav] Davarynejad M., Sedghi S., Bahrepour M., Chang Wook Ahn, AkbarzadehM., Coello Coello C. A. Detecting Hidden Information from Watermarked Sig-nal using Granulation Based Fitness Approximation.

[Dav81] David L. Chaum. Untraceable Electronic Mail, Return Addresses, and DigitalPseudonyms. Technical Note Programming Techniques and Data Structures, 24(2),February 1981. University of California, Berkeley.

[Def81] Defense Advanced Research Projects Agency. RFC 791 - Internet Protocol, Sep-tember 1981.

[DK] Kamran Ahsan Deepa Kundur. Practical Internet Steganography: Data Hiding inIP.

[Dou06] Douglas E. Comer. Internetworking with TCP/IP - Principles, Protocols, andArchitecture, volume Volume I. Fifth edition edition, 2006.



[Eri] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns CD- Elements of Reusable Object-Oriented Software. Addison-Wesley Longman Inc.

[Exp09] ExpandIT - Tecnologıa para crecer. El enemigo vive en casa. Seguridad Informatica.Informe Especial. Ano V, Numero 40:34–37, 2009.

[FFPN] Gina Fisk, Mike Fisk, Christos Papadopoulos, and Josh Neil. Eliminating Stega-nography in Internet Traffic with Active Wardens.

[HVP] Mark Handley and Christian Kreibich Vern Paxson. Network Intrusion Detection:Evasion, Traffic Normalization, and End-to-End Protocol Semantics.

[ith08] ithilgore. SOCK RAW Demystified. May 2008. [email protected] sock-raw.org / sock-raw.homeunix.org - http://sock-raw.org/papers/sock raw.

[JG] Peter Litwack Richard Tibbetts John Giffin, Rachel Greenstadt. Covert MessagingThrough TCP Timestamps.

[JM90] S. Deering J. Mogul. Network Working Group - Request for Comments: 1191. PathMTU Discovery. November 1990. http://www.faqs.org/rfcs/rfc1191.html.

[K. 02] K. Moore. On the use of HTTP as a Substrate - Request for Comments: 3205,February 2002. Category: Best Current Practice.

[Kip04] Greg Kipper. Investigator’s Guide to Steganography. Auerbach Publications, 2004.

[Kir04] Kirchner, Alberto A. Fernandez, Julio M. De Vido, Anıbal D. Fernandez. Decre-to 1563/2004, 2004. http://infoleg.mecon.gov.ar/infolegInternet/anexos/100000-104999/100806/norma.htm.

[Kir05] Kirchner, Alberto A. Fernandez, Anıbal D. Fernandez, Julio M. De Vido. De-creto 357/2005, 2005. http://infoleg.mecon.gov.ar/infolegInternet/anexos/105000-109999/105679/norma.htm.

[KR91] Brian W. Kernighan and Dennis M. Ritchie. El lenguaje de Programacion C.Pearson Educacion, segunda edition, 1991.

[La 10] La Nacion. Una filtracion cuyo origen es todavıa un gran misterio. 2010.http://www.lanacion.com.ar/1329149.

[Laf10] Sharon Lafraniere. Text Messages in China to Be Scanned for ’Ille-gal Content’. The New York Times - Technology, January 19 2010.http://www.nytimes.com/2010/01/19/technology/20text.html.

[Lam73] Butler W. Lampson. A Note on the Confinement Problem. Xerox Palo Alto Re-search Center, 1973.

[LaR08] Les nouveaux defis de la Cryptologie. La Recherche, 420:31, 2008. Paris, France.http://www.larecherche.fr/.

[Luo98] Ari Luotonen. Tunneling TCP based protocols through Web proxy servers. Nets-cape Communications Corporation, August 1998. http://curl.haxx.se/rfc/draft-luotonen-web-proxy-tunneling-01.txt.

[McC01] Declan McCullagh. Bin Laden: Steganography Master? July, 2 2001.



[Mic05] Michael Rash, Angela Orebaugh, Graham Clark, Becky Pinkard, Jake Babbin. In-trusion prevention and active response: deploying network and host IPS - DeployingNetwork and Host IPS. Syngress Publishing Inc., 2005.

[Mix] Mixter. A brief programming tutorial in C for raw sockets. BlackCode Magazine.

[NBL] James Pease Steve J. Chapin Norka B. Lucena, Douglas F. Calvert. Semantics-Preserving Application-Layer Protocol Steganography. Center for Systems Assu-rance, Syracuse University, Syracuse University, 111 College Place 3-114, Syracuse,NY 13244.

[NJH02] Luis von Ahn Nicholas J. Hopper, John Langford. Provably Secure Steganography.June 20 2002. School of Computer Science, Carnegie Mellon University, Pittsburgh,PA 15213.

[PAK99] Fabien A. P. Petitcolas, Ross J. Anderson, and Markus G. Kuhn. Information Hi-ding - A Survey. Proceedings of the IEEE, special issue on protection of multimediacontent, July 1999.

[Pap05] Nick Papanikolaou. Review of Data Privacy and Security, by David Salomon. 2005.

[Pft96] Birgit Pftizmann. Information Hiding Terminology - Results of an informal ple-nary meeting and additional proposals -. Proc.Information Hiding Workshop, UK,30.5.1.6,LNCS, Springer-Verlag, 1996.

[Piy10] Piyush Marwaha, Paresh Marwaha. Visual cryptographic steganography in images.2010 Second International conference on Computing, Communication and Networ-king Technologies, 2010.

[PK00] Fabien A. P. Petitcolas and Stefan Katzenbeisser. Information Hiding Techniquesfor Steganography and Digital Watermarking. 2000.

[Pos81] J. Postel. RFC 792 - Internet Control Message Protocol, September 1981.

[Pro] Niels Provos. Defending Against Statistical Steganalysis. Center for InformationTechnology Integration, University of Michigan.

[PV01] Luıs Rodrigues Paulo Verıssimo. Distributed Systems for Systen Architects. KluwerAcademic Publishers, 2001.

[R. 99] R. Fielding and UC Irvine and J. Gettys and J. Mogul and H. Frystyk and L.Masinter and P. Leach and T. Berners-Lee. RFC 2616 - Hypertext Transfer Protocol– HTTP/1.1uni, June 1999.

[RCN07] CISSP Robert C. Newman. Covert Computer and Network Communications. 2007.

[Rec08] W3C Recommendation. Extensible Markup Language (XML) 1.0 (Fifth Edition),November, 26 2008.

[RJA97] Fabien A.P. Petitcolas Ross J. Anderson. On The Limits of Steganography. 1997.

[Roo] SANS Institute InfoSec Reading Room. Hiding in Plain View: Could Steganographybe a Terrorist Tool?

[Ros] Ross Anderson. Stretching the Limits of Steganography. Cambridge UniversityComputer Laboratory.



[Sco10] Scott Shane and Andrew W. Lehren. Leaked Cables Offer Raw Look at U.S.Diplomacy. The New York Times, November 28 2010. A version of this articleappeared in print on November 29, 2010, on page A1 of the New York edition. -http://www.nytimes.com/2010/11/29/world/29cables.html?pagewanted=1.

[Sha48] Claude E. Shannon. A Mathematical Theory of Communication. The Bell SystemTechnical Journal, 27:379–423, 623–656, July, October 1948.

[Sim83] Gustavus Simmons. The prisoner’s problem and the subliminal channel. Advancesin Cryptology: Proceedings of Crypto ’83, pages 51–67, Plenum Press 1983.

[Sta04] William Stallings. Comunicaciones y Redes de Computadoras. Septima edition,2004.

[Sta06] William Stallings. Criptography and Network Security - Principles and Practices.Fourth edition edition, 2006.

[T. 98] T. Berners-Lee (MIT/LCS), R. Fielding (U.C. Irvine), L. Masinter (Xerox Corpo-ration). RFC 2396 - Uniform Resource Identifiers (URI): Generic Syntax. NetworkWorking Group, August 1998. http://www.ietf.org/rfc/rfc2396.txt.

[Tan97] Andrew S. Tanenbaum. Redes de Computadoras. Prentice-Hall HispanoamericanaS.A., tercera edition, 1997.

[The10] The New York Times. A Note to Readers: The Decision to PublishDiplomatic Documents. 2010. A version of this article appeared inprint on November 29, 2010, on page A10 of the New York edition -http://www.nytimes.com/2010/11/29/world/29editornote.html.

[Uni97] Network Working Group: S. Bradner. Harvard University. Key words for use inRFCs to Indicate Requirement Levels, March 1997. Request for Comments: 2119.Category: Best Current Practice.

[van] van Hauser. Placing Backdoors Through Firewalls - v1.5.

[Vla05] Vlastimil Klıma. Finding MD5 Collisions - a Toy For a Notebook. March. 5 2005.Vlastimil Klıma Prague, Czech Republic. http://cryptography.hyperlink.cz/.

[Wes03] Kristy Westphal. Steganography Revealed. Security Articles - Symantec, April2003. http://www.symantec.com/connect/articles/steganography-revealed.

[Zav08] Patricio Zavolinsky. Abstraccion en el desarrollo de software indepen-diente de la plataforma. 2008. http://materias.fi.uba.ar/7500/zavolinsky-tesisdegradoingenieriainformatica.pdf.


Tesis de Ingeniería en Informática - Facultad de ...materias.fi.uba.ar/7500/TesisDeymonnaz.pdf ·...

Documents

Transcript of Tesis de Ingeniería en Informática - Facultad de ...materias.fi.uba.ar/7500/TesisDeymonnaz.pdf ·...