Ingenieria Informatica. Cifrado Punto a Punto en HTML5 con KHTML. Realizado por Eduardo Robles Elvira. Dirigido por Jose Ramon Portillo

Transcripción

1 ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA Ingenieria Informatica Cifrado Punto a Punto en HTML5 con KHTML Realizado por Eduardo Robles Elvira Dirigido por Jose Ramon Portillo Departamento Matematica Aplicada Sevilla, (05/2010)

2 Resumen Cada vez está tomando más importancia la web y multitud de aplicaciones que antes eran típicamente de escritorio ahora lo son web. Estas aplicaciones web son usadas tanto por particulares como por empresas o instituciones como universidades. Muchas de estas aplicaciones web que han pasado de ser aplicaciones de escritorio a ser aplicaciones web son aplicaciones cuyo fin es la comunicación entre personas, debido a la facilidad con la que las páginas web son capaces de cumplir ese objetivo. Los clientes de correo electrónico o los clientes de mensajería instantánea son claros ejemplos de aplicaciones que antes eran típicamente de escritorio y que ahora en muchos casos son web. Los protocolos involucrados en este tipo de comunicaciones están diseñados con el concepto cliente-servidor, de manera que cualquier comunicación entre dos clientes pasa necesariamente por un servidor. Siendo así, las aplicaciones de escritorio para mantener una conversación segura entre dos cliente suelen implementar cifrado y firmado punto a punto: los clientes de correo suelen soportar PGP para este efecto, y para la mensajería instantánea se suele utilizar OTR. Sin embargo, en un mundo web en el que la información discurre con una facilidad nunca antes conocida, el único estándar de seguridad de las comunicaciones de extendido uso en las páginas web es SSL (Secure Socket Layer) mediante HTTPS, que permite mantener una conversación segura entre el cliente y el servidor web, pero no permite una comunicación segura, privada y/o autenticada entre dos clientes porque no implementa seguridad punto a punto entre dos cliente. Por tanto el servidor web que permite la comunicación entre ambos siempre podrá conocer y modificar el contenido de las mismas. HTTPS es un estándar actualmente muy arraigado en Internet que funciona razonablemente bien para el objetivo que fue diseñado. Gracias a HTTPS muchas personas realizan compras por Internet, administran sus cuentas mediante la banca electrónica y realizan trámites gubernamentales online (entre otros usos), sin necesidad de salir del salón de su casa, de forma segura, y sin necesidad de instalarse ningún software adicional, todo I

3 II desde su navegador web preferido. El siguiente paso natural en seguridad para que las aplicaciones web puedan equipararse a nivel de características a las aplicaciones de escritorio es introducir el concepto de cifrado punto a punto (Point-to-point Encryption) directamente en los navegadores web, de forma que sea tan fácil y transparente a nivel de programación web, así como igual de confiable a nivel de usuario de una navegador web, como HTTPS. Ese es el objetivo de este proyecto. Llevar el concepto de cifrado punto a punto a las páginas web no es una idea nueva, y ya hay empresas ofreciendo servicios de este tipo. En esta memoria también estudiaremos las soluciones ya existentes y razonaremos porqué no son suficientes.

4 Agradecimientos Quiero agradecer especialmente a mis amigos su apoyo, puesto que con nuestras conversaciones acerca del cifrado punto a punto y la seguridad he podido averiguar cual era el camino que creo correcto a la hora de realizar este proyecto. También quiero agradecer a mi familia su apoyo y comprensión, porque ellos han sabido comprender mi proceder con el proyecto y consiguieron que nunca tirase la toalla. Otro bastión de apoyo crucial para la realización de este proyecto han sido mis compañeros de trabajo, gracias a los cuales surgieron buenas ideas y me impulsaron entre otras cosas a dar una charla sobre este proyecto en las Oficinas de Google España. Por último, agradecer a la comunidad de KDE su contribución al software libre mediante el motor de renderizado de páginas web KHTML en el que se basa este proyecto, y a KDE España y la organización del Akademy-es por permitir que diese una ponencia sobre el mismo. III

5

6 Índice general Índice general Índice de cuadros Índice de figuras V VII IX 1 Motivación y Objetivos Motivación Objetivos Introducción Definiciones y abreviaturas Análisis de antecedentes y aportación realizada 19 4 Comparación con otras alternativas Aplicaciones de Escritorio Correo electrónico Mensajería Instantánea Aplicaciones web HTTPS y SSL Hushmail XML Signature y XML Encryption Análisis de requisitos 35 6 Solución propuesta Algo de Historia y primera solución barajada Solución elegida Implementación Funcionamiento interno de KHTML Analizadores léxico y sintáctico El árbol DOM V

7 VI Índice general CSS Cargando Objetos externos Pintando en pantalla Estructura de directorios Manejo de excepciones Palabras finales Introducción al parche de khtml Tokenizer Parser Librería de cifrado y descifrado Implementación de Input Type Text Implementación de Div Pruebas y conclusiones Pruebas Aplicación de ejemplo 1: chat web cifrado Aplicación de ejemplo 2: Plugin de mensajes privados en Sweetter Conclusiones Análisis temporal y costes de desarrollo Análisis temporal Costes de desarrollo Inversiones Costes de software Costes de hardware Costes indirectos Costes de personal Presupuesto Manual Manual de usuario Introducción Instalar paquetes requeridos Configuración del entorno Compilación de KDE Compilación del proyecto Creación de claves GPG Aplicación de prueba: Sweetter Apéndices 87 Licencia 89 Bibliografía 97

8 Índice de cuadros 9.1 Planificación del proyecto Presupuesto del proyecto VII

9

10 Índice de figuras 2.1 Arquitectura cliente-servidor Leyendo un correo firmado y cifrado en KDE con KMail Leyendo un mensaje firmado en Thunderbird con Enigmail Leyendo un mensaje mal firmado con Evolution Leyendo un correo firmado en Mac OS X Mail Chateando mediante OTR con Kopete Manejando las claves OTR con Adium Conversación segura en Adium con OTR mostrando lo que el usuario ve y lo que realmente se transmite Conversación cifrada con GPG en Adium en PSI Chateando mediante GMail por https Interfaz de la vista principal del cliente web de correo electrónico de Hushmail, utilizando una cuenta gratuita de 2MB de capacidad Kleocypher Resultado de cómo se visualiza un DIV cifrado mostrando el texto en claro del ejemplo Menú contextual de un DIV cifrado mostrando la opción Details of Encrypted Message Diálogo mostrando los detalles de un mensaje contenido en un DIV cifrado Chat cifrado con khtml en el navegador web Konqueror, y el mismo chat motrado en Firefox Diálogo pidiendo al usuario su frase de paso IX

11 X Índice de figuras 8.3 Sweetter enviando un mensaje privado cifrado. También se observa el enlace para enviar mensajes privados al usuario cuyo perfil se está observando en la barra de cabecera y en la barra lateral, así como la imagen con forma de escudo verde que aparece en todos los sweets que sirve para responder al sweet con un mensaje privado Un usuario viendo su lista de mensajes privados recibidos ( Private timeline ), y comprobando que un mensaje está cifrado con el menú contextual. Uno de los mensajes privados recibidos no tiene recuadro verde indicando que no está cifrado, debido a que fue enviado mediante Firefox Diálogo para crear una nueva clave Configurando la clave privada del usuario desde su perfil El mensaje cifrado que previamente nos habíamos enviado aparece en el Private timeline

12 CAPÍTULO 1 Motivación y Objetivos 1.1 Motivación Relacionados con la informática, existen dos grandes hitos tecnológicos relevantes: el primero es sin duda el boom tecnológico del microchip gracias al cual hemos conseguido ordenadores de una potencia de cálculo descomunal a bajo coste y nunca antes si quiera soñada. El segundo, es sin duda Internet, que permite comunicarnos entre personas de forma instantánea desde cualquier parte del planeta. Si unimos ambos hitos tecnológicos, que son la casi infinita capacidad de cálculo de los ordenadores actuales junto con la facilidad de coste marginal de comunicación que nos ofrece la red de redes, obtenemos varios resultados interesantes: 1. La comunicación entre personas se realiza cada vez más mediante medios digitales, a través de la red de redes debido al bajo coste y lo fácil que esto resulta, frente a los antiguos métodos de comunicación como pueden ser: teléfono, fax, carta, teletipo, o incluso presencial. Ahora en vez de hablar en persona, hay muchas personas que prefieren hacerlo de forma online. 2. La red almacena cada vez más información sobre nosotros en la nube, puesto que la capacidad de almacenamiento de los datos es notablemente alta y puesto que almacenar información online permite acceder a ella desde cualquier lugar en cualquier momento. 3. Gran parte de la información es fácilmente procesable por medios automáticos debido a la gran capacidad de cálculo de los ordenadores actuales. 4. Los usuarios se acostumbran a servicios que son de coste marginal 1

13 2 1. Motivación y Objetivos y por ende a servicios gratuitos cuyo modelo de negocio se basa en la publicidad contextual. 5. Los gobiernos y empresas se aprovechan de toda esta información que anteriormente era imposible de recopilar, estructurar o usar de forma masiva, y ahora sí que es posible hacerlo de forma masiva y transparente. No es ningún secreto que empresas como Google basan su modelo de negocio en la información, y tampoco es ningún secreto (de hecho por definición una ley debe ser pública) que los Gobiernos se aprovechan de la digitalización de la información promulgando leyes como la Directiva Europea de Retención de Datos y la transposición de dicha directiva en España, la Ley de Retención de Datos, que especifica que por ejemplo debe guardarse la siguiente información sobre todas las páginas web que visitemos: URL, fecha de visita, dirección IP desde la cual se visitó. Por último y no menos importante, debido a que la información es poder, tampoco hay que descartar la posibilidad de que malhechores intenten beneficiarse de la inseguridad de nuestros datos para hacer negocios ilegales con ellos. En un mundo cada vez más informatizado, hay una cantidad creciente y preocupante de información sobre nosotros en la red, que inevitablemente pasa por múltiples intermediarios y que no controlamos. Por supuesto, existen medios para conseguir controlar en mayor o menor medida esta información, siendo el cifrado la principal herramienta. El cifrado consiste en el intercambio de mensajes de manera que sólo puedan ser leídos en claro por personas a las que van dirigidos y que poseen los medios para descifrarlos. Muchos protocolos de comunicación en Internet soportan cifrado, y sería del todo aconsejable que se cifrasen las comunicaciones siempre que fuese posible, no obstante no es así. Sin ir más lejos, el protocolo fundamental bajo el que funcionan las páginas web, HTTP, soporta cifrado mediante su variante HTTPS, pero un muy bajo porcentaje de páginas web lo soporta, y un porcentaje mucho menos lo utiliza por defecto. Cuando entramos en una página web mediante HTTPS mantenemos una conversación segura con el servidor, de tal manera que la llamada comunicación cliente-servidor no resulta comprometida. Este sistema es bastante robusto y suficente como para que millones de personas realicen sus compras por Internet, se autentiquen de forma segura o administren sus cuentas mediante la banca electrónica. No obstante cuando nos comunicamos por Internet con otras personas lo corriente no es intentar comunicarnos con personas que se encuentren en el servidor, sino con personas que se encuentran al mismo nivel que nosotros, conectadas al servidor, de tal manera que la conexión segura se establece entre nosotros y el servidor, y luego entre el servidor y la persona con la que queramos hablar, en el mejor de los casos. Los tres puntos que

14 1.1. Motivación 3 pueden ver el texto de la comunicación en claro son: nosotros, el servidor, y la persona con la que nos comunicamos. Sin embargo, el servidor no es el destinatario de la información y por tanto para mayor seguridad no debería de conocer el contenido de la misma. HTTPS utiliza para establecer una comunicación segura el protocolo SSL (Secure Socket Layer). Servicios no basados en la web como el correo electrónico (con IMAP o POP) soportan el mismo método de seguridad de las comunicaciones, pero tienen el mismo problema: la comunicación no es segura de punto a punto sino de cliente a servidor. Lo mismo ocurre con otros servicios de comunicación entre personas (que son los puntos que se comunican), como la mensajería instantánea o el VoIP: muchos soportan únicamente cifrado de cliente a servidor de forma nativa. Para resolver dicho problema, existen diferentes soluciones que implementan la seguridad punto a punto ( énd-to-end security ): Para el correo electrónico se puede utilizar PGP (Pretty Good Privacy) o su variante libre GnuPG para cifrar y firmar los mensajes. Este es un estándar utilizado e implementado por la mayoría de clientes de correo electrónico: KMail, Outlook, Thunderbird, etc. Para la mensajería instantánea se puede utilizar OTR (Off The Record), igualmente para firmar y cifrar los mensajes. OTR se ha convertido también en un estándar soportado por una plétora de clientes de mensajería instantánea, entre ellos Kopete, Pidgin, o Adium. Para el VoIP existe otro sistema criptográfico llamado ZRTP y que es una creación de Phil Zimmermann, uno de los creadores del anteriormente mencionado PGP, y que permite ser usado en la mayoría de clientes VoIP. (Es normal que el lector no conozca algunos o todos los términos aquí empleados. Por ello en el siguiente apartado explicaremos muchos de los conceptos que subyacen en el problema que abordamos, y definiremos muchos de los términos técnicos antes mencionados.) Uno de los principales inconvenientes que surge a la hora de utilizar un sistema seguro de comunicación es que suele ser necesario bien instalarse un software concreto para que este funcione, o bien configurarlo de forma especial. Plantearse usar cifrado o no ya es una barrera infranqueable para la mayoría de los usuarios de ordenadores puesto que no están concienciados en el problema que supone la pérdida de privacidad inherente a enviar mensajes en claro por la red, porque ni se dan cuenta de que ésto está ocurriendo ni de las repercusiones a largo o medio plazo que ésto conlleva. Por otra parte, podría pensarse que al menos la tecnología está ahí y sólo es necesario llevar a cabo un movimiento de concienciación social en el tema de la seguridad para que empiece a usarse. En parte esto

15 4 1. Motivación y Objetivos es cierto, y por ejemplo hay software como Adium (uno de los clientes de mensajería instantánea antes mencionado) que viene configurado por defecto con OTR activado de manera que utiliza lo que es conocido como cifrado oportunista : si el usuario comienza una conversación con una persona que esté utilizando también un cliente de mensajería instantánea con soporte de OTR, Adium se da cuenta y automáticamente comienza una sesión de OTR segura en la que los mensajes van firmados y cifrados. No obstante incluso si los clientes de comunicaciones de escritorio parece que cada vez son más amigables en este sentido, también debemos contar con el factor web. Y es que cada vez más aplicaciones que antes eran típicamente aplicaciones de escritorio, ahora lo son directamente web. Ésto está ocurriendo con Gmail por ejemplo, que ahora sirve tanto como cliente de correo como de mensajería instantánea. Y recientemente ahora estas aplicaciones web cada vez soportan más características, como por ejemplo videoconferencia y conversaciones de voz. Es decir, mediante los clientes web tenemos la mayoría de las características que se encontraban en los clientes de escritorio, pero con la ventaja de que a diferencia de éstos, no hace falta instalar ni configurar ningún software (a parte del navegador) para hacerlos funcionar, y están disponibles en cualquier navegador web y sistema operativo, desde dispositivos móviles a ordenadores de sobremesa. Si bien con los clientes de escritorio era posible mantener cierto grado de seguridad énd-to-end, pese a no haberse llegado a un uso generalizado de estos sistemas de cifrado de las comunicaciones, en los sistemas de comunicación via web nos encontramos con una situación desoladora, puesto que la seguridad punto a punto no se implementa de forma nativa en prácticamente ningún de estos servicios web y de hecho, como veremos a lo largo de este documento, esto es debido entre otras cosas a que no existe ninguna manera confiable y sencilla de implementarla. Mientras que las páginas web cada vez se utilizan más para comunicar a las personas, la privacidad online se deteriora. Tal y como mencinaban en un artículo recientemente en Slashdot [6], la industria del software no focaliza sus esfuerzos en mantener la privacidad de sus clientes porque no es lo que sus clientes no se lo piden. Y cuando se lo piden, entonces es una ocurriencia tardía. La seguridad y privacidad son conceptos que no son fácilmente empotrables en un sistema si no ha sido diseñado para ello. Todo esto es lo que motivó al autor a realizar su proyecto de fin de carrera sobre un tema tan controvertido. En la siguiente sección se detallarán los objetivos que se plantean en base a los motivos anteriormente expuestos.

16 1.2. Objetivos Objetivos Este proyecto informático tiene como principal objetivo demostrar que es posible implantar un sistema de seguridad punto a punto en las páginas web de forma que el usuario de dichas páginas web no tenga que confiar en dichas páginas web para saber que los mensajes que el usuario envíe y reciba van por un canal seguro, en el que se puede saber que sólo el destinatario de los mensajes puede leerlos y que el remitente es quien dice ser. Al utilizar el sistema de seguridad que se propone en este proyecto, el usuario únicamente debe confiar en que su navegador esté implementando los algoritmos correspondientes, como con cualquier otro software con soporte de cifrado de escritorio. Para cumplir el mencionado objetivo, se propondrá una pequeña extensión de HTML5 y luego se implementará dicha extensión en el motor de renderizado KHTML utilizado en todo el entorno de escritorio KDE y en concreto en el navegador web Konqueror. También se expondrán las soluciones que existen actualmente como por ejemplo Hushmail o FirePGP y las ventajas y desventajas que tienen. Es más que probable que existan otras tantas personas alrededor del globo trabajando en diferentes proyectos con el mismo objetivo que el que aquí se presenta de forma simultánea, y si no lo están haciendo ahora lo harán tarde o temprano. Implementar un esquema confiable de seguridad punto a punto en el navegador web es algo tan básico que tarde o temprano se establecerá algun tipo de estándar en los navegadores dominantes y las páginas web empezarán a utilizarlo. Mediante este proyecto además se persigue el objetivo de concienciar a la sociedad de la relevancia de la privacidad y la seguridad en la red. No obstante el autor es consciente de las limitaciones que tiene este trabajo. Si bien el autor está convencido de haber conseguido de forma exitosa el objetivo del proyecto, no espera que todo Internet realice el salto a la tecnología propuesta de la noche a la mañana. La extensión de HTML5 que aquí se propone debido a la naturaleza de un proyecto de fin de carrera tiene también sus limitaciones y es un proof-of-concept más que otra cosa: una demostración de lo que es posible realizar, una huella más en el camino que marca el siguiente paso natural en la seguridad web tras la aparición de HTTPS, pero ni mucho menos el fin del trayecto. Otra de las motivaciones que hay detrás de este proyecto es mostrar que un motor de renderizado actualmente bastante olvidado como KHTML aun tiene mucho que decir. La integración de KHTML con el resto del entorno de escritorio KDE hace que resulte más sencillo adentrarse en su código para alguien que conozca el funcionamiento de las librerías KDE como es el caso del autor, a la par de que debido también a dicha integración un cambio en KHTML repercutirá en todas las partes de KDE que utilizen este motor de renderizado web. En esta memoria se enseña en

17 6 1. Motivación y Objetivos la sección del Manual a instalar y configurar el entorno de desarrollo de KDE para poder compilar el código, y también se explica el funcionamiento interno de KHTML puesto que es necesario conocerlo para luego poder aplicar los cambios necesarios para implementar la extensión de HTML. Se explicará dicha implementación, su funcionamiento y las medidas de seguridad que se han desarrollado. Por último, se ha comenzó creando una aplicación de ejemplo consistente en un sencillo chat que utiliza la extensión de HTML desarrollada para poder mantener una conversación cifrada y segura de forma sencilla y transparente al desarrollador. De hecho esta aplicación de chat se ha desarrollado basándose una aplicación de chat existente creada con django y añadiéndole soporte de cifrado. No obstante el código de la aplicación de chat en la que se basó el autor dejaba bastante que desear y al final se deshechó la idea y se optó por desarrollar una segunda aplicación de ejemplo, una extensión para la aplicación web Sweetter de microblogging. Este plugin añade soporte de envío y recepción de mensajes privados cifrados mediante GPG entre los usuarios.

18 CAPÍTULO 2 Introducción 2.1 Definiciones y abreviaturas Arquitectura cliente-servidor Esta arquitectura consiste básicamente en un cliente que realiza peticiones a otro programa (el servidor) que le da respuesta. Aunque esta idea se puede aplicar a programas que se ejecutan sobre una sola computadora es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras. En esta arquitectura la capacidad de proceso está repartida entre los clientes y los servidores, aunque son más importantes las ventajas de tipo organizativo debidas a la centralización de la gestión de la información y la separación de responsabilidades, lo que facilita y clarifica el diseño del sistema. La separación entre cliente y servidor es una separación de tipo lógico, donde el servidor no se ejecuta necesariamente sobre una sola Figura 2.1: Arquitectura cliente-servidor 7

19 8 2. Introducción máquina ni es necesariamente un sólo programa. Los tipos específicos de servidores incluyen los servidores web, los servidores de archivo, los servidores del correo, etc. Mientras que sus propósitos varían de unos servicios a otros, la arquitectura básica seguirá siendo la misma. Cifrado de clave pública También llamado cifrado asimétrico, es el método criptográfico que usa un par de claves para el envío de mensajes. Las dos claves pertenecen a la misma persona a la que se ha enviado el mensaje. Una clave es pública y se puede entregar a cualquier persona, la otra clave es privada y el propietario debe guardarla de modo que nadie tenga acceso a ella. Además, los métodos criptográficos garantizan que esa pareja de claves sólo se puede generar una vez, de modo que se puede asumir que no es posible que dos personas hayan obtenido casualmente la misma pareja de claves. Si el remitente usa la clave pública del destinatario para cifrar el mensaje, una vez cifrado, sólo la clave privada del destinatario podrá descifrar este mensaje, ya que es el único que la conoce. Por tanto se logra la confidencialidad del envío del mensaje, nadie salvo el destinatario puede descifrarlo. Si el propietario del par de claves usa su clave privada para cifrar el mensaje, cualquiera puede descifrarlo utilizando su clave pública. En este caso se consigue por tanto la identificación y autentificación del remitente, ya que se sabe que sólo pudo haber sido él quien empleó su clave privada (salvo que alguien se la hubiese podido robar). Esta idea es el fundamento de la firma electrónica. Criptografía El arte o ciencia de cifrar y descifrar información mediante técnicas especiales y se emplea frecuentemente para permitir un intercambio de mensajes que sólo puedan ser leídos por personas a las que van dirigidos y que poseen los medios para descifrarlos. CSS, Cascading Style Sheets Las hojas de estilo en cascada, es un lenguaje usado para definir la presentación de un documento estructurado escrito en HTML o XML (y por extensión en XHTML). El W3C (World Wide Web Consortium) es el encargado de formular la especificación de las hojas de estilo que servirán de estándar para los agentes de usuario o navegadores. La idea que se encuentra detrás del desarrollo de CSS es separar la estructura de un documento de su presentación. Por ejemplo, el elemento de HTML <h1> indica que un bloque de texto es un encabezamiento y que es más importante que un bloque etiquetado como <h2>. Versiones más antiguas de HTML permitían atributos extra dentro de la etiqueta abierta para darle formato (como el color o el tamaño de fuente). No obstante, cada etiqueta <h1>

20 2.1. Definiciones y abreviaturas 9 debía disponer de la información si se deseaba un diseño consistente para una página y, además, una persona que lea esa página con un navegador pierde totalmente el control sobre la visualización del texto. Cuando se utiliza CSS, la etiqueta <h1> no debería proporcionar información sobre como va a ser visualizado, solamente marca la estructura del documento. La información de estilo separada en una hoja de estilo, especifica cómo se ha de mostrar <h1>: color, fuente, alineación del texto, tamaño y otras características no visuales como definir el volumen de un sintetizador de voz (véase Sintetización del habla), por ejemplo. La información de estilo puede ser adjuntada tanto como un documento separado o en el mismo documento HTML. En este último caso podrían definirse estilos generales en la cabecera del documento o en cada etiqueta particular mediante el atributo style. End-to-end Security También conocida en español como Seguridad punto a punto, significa que los datos van firmados y/o cifrados entre aquellos que se comunican. En vez de confiar en Seguridad de la capa de transporte (transport-layer security, TLS), la seguridad punto a punto funciona a través de dominios de confianza. Esto resuelve por ejemplo el problema, cuando las sesiones TLS son finalizadas en un cortafuegos, y el DMZ es considerado diferente al dominio de confianza. GPG, Gnu Privacy Guard o GnuPG Es la alternativa de software libre a la suite de software criptográfico PGP. GnuPG cumple con el RFC 4880, que es la actual especificación estándar del IETF de OpenPGP. Las versiones actuales de PGP son interoperables con GnuPG y con otros sistemas OpenPGP-compatibles. GPG es parte del proyecto de software GNU de la Free Software Fundation, y ha recibido un importante apoyo financiero del gobierno alemán. Está disponible bajo la versión 3 de la Licencia General Pública GNU. HTML, HyperText Markup Language En castellano lenguaje de marcas de hipertexto, es el lenguaje de marcas predominante para las páginas web. Provee un medio para crear documentos estructorados mediante la denotación de semánticas estructurales para texto como cabeceras, párrafos, listas, enlaces, citas, y otros elementos. Permite incrustar imágenes y objetos y puede usar para crear formularios interactivos. Está escrito en forma de elementos HTML que consisten en etiquetas rodeadas con < y > dentro del contenido de la página. Puede cargar scripts en idiomas como Javascript que

21 10 2. Introducción afectan al comportamiento de las páginas HTML. HTML también puede incluir hojas de estilo en cascada (CSS) para definir la apariencia y distribución del texto y el resto de los elementos. El W3C es el mantenedor de ambos estándares: HTML y CSS. HTTPS, Hypertext Transfer Protocol Secure En español Protocolo seguro de transferencia de hipertexto, más conocido por sus siglas HTTPS, es un protocolo de red basado en el protocolo HTTP, destinado a la transferencia segura de datos de hipertexto, es decir, es la versión segura de HTTP. Es utilizado principalmente por entidades bancarias, tiendas en línea, y cualquier tipo de servicio que requiera el envío de datos personales o contraseñas. HTTP, Hypertext Transfer Protocol o HTTP En español protocolo de transferencia de hipertexto, es el protocolo usado en cada transacción de la World Wide Web. HTTP fue desarrollado por el World Wide Web Consortium y la Internet Engineering Task Force (IETF), colaboración que culminó en 1999 con la publicación de una serie de RFC, siendo el más importante de ellos el RFC 2616, que especifica la versión 1.1. HTTP define la sintaxis y la semántica que utilizan los elementos de software de la arquitectura web (clientes, servidores, proxies) para comunicarse. Es un protocolo orientado a transacciones y sigue el esquema petición-respuesta entre un cliente y un servidor. Al cliente que efectúa la petición (un navegador web o un spider) se lo conoce como user agent (agente del usuario). A la información transmitida se la llama recurso y se la identifica mediante un localizador uniforme de recursos (URL). Los recursos pueden ser archivos, el resultado de la ejecución de un programa, una consulta a una base de datos, la traducción automática de un documento, etc. HTTP es un protocolo sin estado, es decir, que no guarda ninguna información sobre conexiones anteriores. El desarrollo de aplicaciones web necesita frecuentemente mantener estado. Para esto se usan las cookies, que es información que un servidor puede almacenar en el sistema cliente. Esto le permite a las aplicaciones web instituir la noción de sesión, y también permite rastrear usuarios ya que las cookies pueden guardarse en el cliente por tiempo indeterminado. IMAP, Internet Message Access Protocol Es un protocolo de red de acceso a mensajes electrónicos almacenados en un servidor. Mediante IMAP se puede tener acceso al correo electrónico desde cualquier equipo que tenga una conexión a Internet. IMAP tiene varias ventajas sobre POP, que es el otro protocolo empleado para obtener correo desde un servidor. Por ejemplo, es posible especificar en

22 2.1. Definiciones y abreviaturas 11 IMAP carpetas del lado servidor. Por otro lado, es más complejo que POP ya que permite visualizar los mensajes de manera remota y no descargando los mensajes como lo hace POP. Javascript Es un lenguaje de scripting orientado a objetos, utilizado para acceder a objetos en aplicaciones. Principalmente, se utiliza integrado en un navegador web permitiendo el desarrollo de interfaces de usuario mejoradas y páginas web dinámicas. JavaScript es un dialecto de ECMAScript y se caracteriza por ser un lenguaje basado en prototipos, con entrada dinámica y con funciones de primera clase. JavaScript ha tenido influencia de múltiples lenguajes y se diseñó con una sintaxis similar al lenguaje de programación Java, aunque más fácil de utilizar para personas que no programan. Todos los navegadores modernos interpretan el código JavaScript integrado dentro de las páginas web. Para interactuar con una página web se provee al lenguaje JavaScript de una implementación del DOM. El lenguaje fue inventado por Brendan Eich en la empresa Netscape Communications, la que desarrolló los primeros navegadores web comerciales. Apareció por primera vez en el producto de Netscape llamado Netscape Navigator 2.0. Tradicionalmente, se venía utilizando en páginas web HTML, para realizar operaciones y en el marco de la aplicación cliente, sin acceso a funciones del servidor. JavaScript se ejecuta en el agente de usuario, al mismo tiempo que las sentencias van descargándose junto con el código HTML. En 1997 los autores propusieron JavaScript para que fuera adoptado como estándar de la European Computer Manufacturers Ássociation ECMA, que a pesar de su nombre no es europeo sino internacional, con sede en Ginebra. En junio de 1997 fue adoptado como un estándar ECMA, con el nombre de ECMAScript. Poco después también como un estándar ISO. KDE Es una comunidad de software libre que produce un conjunto integrado de aplicaciones multiplataforma diseñadas para funcionar en Linux, FreeBSD, Windows, Solaris y Mac OS X. Es más conocido conocido por el entorno de escritorio Plasma, el entorno de escritorio que viene como el entorno de trabajo por defecto en muchas distribuciones como opensuse, Mandriva Linux, Slackware, PCLinuxOS, Kubuntu, Arch Linux, VectorLinux, Pardus y otras. El fin del proyecto es proveer las funciones básicas de escritorio y las aplicaciones de uso diario así como las herramientas y la documentación para que los desarrolladores puedan escribir aplicaciones para el sistema. En este aspecto, el proyecto KDE sirve como un proyecto que acoge a muchas otras aplicaciones y menores proyectos que están

23 12 2. Introducción basados en tecnología KDE, entre las que se incluyen KOffice, KDevelop, Amarok, K3B y muchas otras aplicaciones. El software KDE está basado en el toolkit Qt, aunque tambien tiene soporte para programas basados en GTK, así como para temas visuales basados en GTK. La versión original GPL de este toolkit sólo existía para la plataforma X11, pero desde el lanzamiento de Qt 4, hay versiones GPL disponibles para todas las plataformas soportadas. Esto permite al software KDE basado en Qt4 ser también ser distribuido en Microsoft Windows y Mac OS X. KHTML Es el motor de renderizado HTML libre desarrollado para el proyecto KDE. Fue creado para el navegador web de KDE, Konqueror. El motor fue más tarde adaptado en enero del 2003 por Apple para su navegador Safari, y la compañía devolvió todas las mejoras aplicadas sobre el código original, tal como pide la licencia. Otra compañía utilizando KHTML es YellowTAB, la cual comercializa una distribución de BeOS. KHTML fue escrito en C++ y se encuentra liberado bajo la licencia LGPL. Man in the Middle En criptografía, un ataque man-in-the-middle (MitM o intermediario, en castellano) es un ataque en el que el enemigo adquiere la capacidad de leer, insertar y modificar a voluntad, los mensajes entre dos partes sin que ninguna de ellas conozca que el enlace entre ellos ha sido violado. El atacante debe ser capaz de observar e interceptar mensajes entre las dos víctimas. El ataque MitM es particularmente significativo en el protocolo original de intercambio de claves de Diffie-Hellman, cuando éste se emplea sin autenticación. OTR, Off-the-Record Es un protocolo criptográfico que provee cifrado fuerte para conversaciones de mensajería instantánea. OTR usa una combinación del algoritmo de clave asimétrica AES, el intercambio de claves de Diffie-Hellman, y la función de hash SHA-1. Además de autenticación y cifrado, OTR provee secreto perfecto y cifrado maleable. La principal motivación detrás del protocolo era permitir la negación de la conversación de sus participantes al vez que se mantenía conversación confidencial, como con una conversación en la vida real. Eso es en contraste con la mayoría de herramientas de cifrado que se asemejan más a una escritura firmada en papel, que puede ser usada luego como un registro para demostrar que la comunicación ocurrió, los participantes, y el contenido de la comunicación. En la mayoría de los casos la gente usando software de cifrado no se da cuenta de esto y puede que OTR les fuese más útil. El paper inicial introductorio se llamaba. O ff-the-record Communication, or, Why Not To Use PGP.

24 2.1. Definiciones y abreviaturas 13 El protocolo OTR fue diseñado por los criptógrafos Ian Goldberg y Nikita Borisov. Crearon una librería para facilitar a los desarrolladores de clientes de mensajería instantánea implementar el protocolo y un proxy-otr especial para AIM, ICQ, y.mac, clientes que soportan proxies. OpenPGP La IETF se ha basado en el diseño de PGP para crear el estándar de Internet OpenPGP. Las últimas versiones de PGP son conformes o compatibles en mayor o menor medida con ese estándar. PGP, Pretty Good Privacy En español privacidad bastante buena, es un programa desarrollado por Phil Zimmermann y cuya finalidad es proteger la información distribuida a través de Internet mediante el uso de criptografía de clave pública, así como facilitar la autenticación de documentos gracias a firmas digitales. PGP originalmente fue diseñado y desarrollado por Phil Zimmermann en El nombre está inspirado en el del colmado Ralph s Pretty Good Grocery de Lake Wobegon, una ciudad ficticia inventada por el locutor de radio Garrison Keillor. PKI, Public Key Infrastructure En criptografía, una infraestructura de clave publica es una combinación de hardware y software, políticas y procedimientos de seguridad que permiten la ejecución con garantías de operaciones criptográficas como el cifrado, la firma digital o el no repudio de transacciones electrónicas. El término PKI se utiliza para referirse tanto a la autoridad de certificación y al resto de componentes, como para referirse, de manera más amplia y a veces confusa, al uso de algoritmos de clave pública en comunicaciones electrónicas. Este último significado es incorrecto, ya que no se requieren métodos específicos de PKI para usar algoritmos de clave pública. POP3 En informática se utiliza el Post Office Protocol (Protocolo de la oficina de correo) en clientes locales de correo para obtener los mensajes de correo electrónico almacenados en un servidor remoto. Es un protocolo de nivel de aplicación en el Modelo OSI. Privacidad La privacidad puede ser definida como el ámbito de la vida personal de un individuo que se desarrolla en un espacio reservado y debe mantenerse confidencial. Aunque privacy deriva del latín privatus, privacidad se ha incorporado a nuestra lengua en los últimos años a través del inglés, por lo cual el término es rechazado por algunos como un anglicismo, alegando que el término correcto es intimidad, y en cambio es aceptado por otros como un préstamo lingüístico válido.

25 14 2. Introducción Según el Diccionario de la lengua española de la Real Academia Española - DRAE, privacidad se define como ámbito de la vida privada que se tiene derecho a proteger de cualquier intromisión. ei ntimidad se define como zona espiritual íntima y reservada de una persona o de un grupo, especialmente de una familia. El desarrollo de la Sociedad de la Información y la expansión de la Informática y de las Telecomunicaciones plantea nuevas amenazas para la privacidad que han de ser afrontadas desde diversos puntos de vista: social, cultural, legal, tecnológico... S/MIME, Secure / Multipurpose Internet Mail Extensions En español Extensiones de Correo de Internet de Propósitos Múltiples / Seguro, es un estándar para criptografía de clave pública y firmado de correo electrónico encapsulado en MIME. SIP, Session Initiation Protocol Es un protocolo desarrollado por el grupo de trabajo MMUSIC del IETF con la intención de ser el estándar para la iniciación, modificación y finalización de sesiones interactivas de usuario donde intervienen elementos multimedia como el video, voz, mensajería instantánea, juegos en línea y realidad virtual. La sintaxis de sus operaciones se asemeja a las de HTTP y SMTP, los protocolos utilizados en los servicios de páginas Web y de distribución de s respectivamente. Esta similitud es natural ya que SIP fue diseñado para que la telefonía se vuelva un servicio más en Internet.[1] En noviembre del año 2000, SIP fue aceptado como el protocolo de señalización de 3GPP y elemento permanente de la arquitectura IMS (IP Multimedia Subsystem). SIP es uno de los protocolos de señalización para voz sobre IP, otro es H.323 y IAX actualmente IAX2. SSL, Secure Sockets Layer En español Protocolo de Capa de Conexión Segura- (SSL) y Transport Layer Security -Seguridad de la Capa de Transporte- (TLS), su sucesor, son protocolos criptográficos que proporcionan comunicaciones seguras por una red, comúnmente Internet. Existen pequeñas diferencias entre SSL 3.0 y TLS 1.0, pero el protocolo permanece sustancialmente igual. El término SSL según se usa aquí, se aplica a ambos protocolos a menos que el contexto indique lo contrario. Seguridad El término seguridad proviene de la palabra securitas del latín. Cotidianamente se puede referir a la seguridad como la ausencia de riesgo o también a la confianza en algo o alguien. Sin

26 2.1. Definiciones y abreviaturas 15 embargo, el término puede tomar diversos sentidos según el área o campo a la que haga referencia. La seguridad es un estado de ánimo, una sensación, una cualidad intangible. Se puede entender como un objetivo y un fin que el hombre anhela constantemente como una necesidad primaria. Según la pirámide de Maslow, la seguridad en el hombre ocupa el segundo nivel dentro de las necesidades de déficit. VoIP Voz sobre Protocolo de Internet, también llamado Voz IP, VozIP, VoIP (por sus siglas en inglés), es un grupo de recursos que hacen posible que la señal de voz viaje a través de Internet empleando un protocolo IP (Protocolo de Internet). Esto significa que se envía la señal de voz en forma digital, en paquetes, en lugar de enviarla en forma digital o analógica, a través de circuitos utilizables sólo para telefonía como una compañía telefónica convencional o PSTN (sigla de Public Switched Telephone Network, Red Telefónica Pública Conmutada). Los Protocolos que se usan para enviar las señales de voz sobre la red IP se conocen como protocolos de Voz sobre IP o protocolos IP. Estos pueden verse como aplicaciones comerciales de la Red experimental de Protocolo de Voz (1973), inventada por ARPANET. El tráfico de Voz sobre IP puede circular por cualquier red IP, incluyendo aquellas conectadas a Internet, como por ejemplo las redes de área local (LAN). W3C, World Wide Web Consortium Es un consorcio internacional que produce recomendaciones para la World Wide Web. Está dirigida por Tim Berners-Lee, el creador original de URL (Uniform Resource Locator, Localizador Uniforme de Recursos), HTTP (HyperText Transfer Protocol, Protocolo de Transferencia de HiperTexto) y HTML (Lenguaje de Marcado de HiperTexto) que son las principales tecnologías sobre las que se basa la Web. XML Encryption, XML-Enc Es una especificación, gobernada por una recomendación del W3C, que define como cifrar los contenidos de un elemento XML. Aunque el cifrado XML puede usarse para cifrar cualquier tipo de datos, es sin embargo conocido como Cifrado XML porque un elemento XML (que es bien un elemento EncryptedData o Encrypted- Key) contiene o se refiere al texto cifrado, a la información de la clave, y a los algoritmos. Ambos XML Signature y XML Encryption usan el elemento KeyInfo, que aparece como hijo de los elementos SignedInfo, Encrypted- Data, o EncryptedKey y provee información a un destinatario sobre

27 16 2. Introducción el material de claves usado para validar una firma o descrifrar datos. No obstante el elemento KeyInfo es opcional: puede ir adjunto en el mensaje o ser obtenido por un canal seguro. XML Signature, XMLDsig, XML-DSig, XML-Sig Es una recomendación del W3C que define una sintaxis XML para firmas digitales. Funcionalmente, tiene mucho en común con PKCS#7 pero es mucho más extensible y más enfocado hacia la firma de documentos XML. Se usa en varias tecnología web como en SOAP, SAML y otros. Las firmas XML pueden usarse firmar documento XML, pero cualquier cosa que sea accesible mediante una URL puede realmente ser firmada. Una firma XML usada para firmar un recurso fuera de un documento XML se llama una firma separada (detached). Si se utiliza para firmar una parte del documento que la contiene, se llama una firma envuelta (enveloped). Si contiene los datos firmados dentro de sí mismo se llama una firma envolvente (enveloping). XMPP, Extensible Messaging and Presence Protocol, Jabber El Protocolo extensible de mensajería y comunicación de presencia anteriormente llamado Jabber, es un protocolo abierto y extensible basado en XML, originalmente ideado para mensajería instantánea. Con el protocolo XMPP queda establecida una plataforma para el intercambio de datos XML que puede ser usada en aplicaciones de mensajería instantánea. Las características en cuanto a adaptabilidad y sencillez del XML son heredadas de este modo por el protocolo XMPP. A diferencia de los protocolos propietarios de intercambio de mensajes como ICQ, Y! y Windows Live Messenger, se encuentra documentado y se insta a utilizarlo en cualquier proyecto. Existen servidores y clientes libres que pueden ser usados sin coste alguno. Este es el protocolo que seleccionó Google para su servicio de mensajería Google Talk. ZRTP ZRTP es una extensión de Real-time Transport Protocol (RTP) que describe el establecimiento de un intercambio Diffie-Hellman de claves para el Secure Real-time Transport Protocol (SRTP). Fue enviado al IETF por Phil Zimmermann, Jon Callas y Alan Johnston el 5 de marzo de Session Initiation Protocol (SIP) es un estándar VoIP. ZRTP se describe en el Internet-Draft como un protocolo de acuerdo de claves que realiza un intercambio de claves Diffie-Hellman durante el establecimiento en banda (in-band) de una llamada en el flujo de datos Real-time Transport Protocol (RTP) que ha sido establecido empleando otro protocolo de señalización como pueda ser

28 2.1. Definiciones y abreviaturas 17 Session Initiation Protocol (SIP). Esto genera un secreto compartido que es usado para generar las claves y el salt para una sesión de Secure RTP (SRTP). Úna de las funcionalidades de ZRTP es que no requiere el intercambio previo de otros secretos compartidos o una Infrastructura de Clave Pública (PKI), a la vez que evita ataques de man in the middle. Además, no delegan en la señalización SIP para la gestión de claves ni en ningún servidor. Soporta cifrado oportunista detectando automáticamente si el cliente VoIP del otro lado soporta ZRTP. ZRTP puede usarse con cualquier protocolo de señalización como SIP, H.323, Jabber, y Peer-to-Peer SIP. ZRTP es independiente de la capa de señalización, puesto que realiza toda su negociación de claves dentro del flujo de datos RTP.

29

30 CAPÍTULO 3 Análisis de antecedentes y aportación realizada En primer lugar en este apartado es recalcable reseñar que en la actualidad no existe ningún antecedente de extensión HTML que permita realizar un cifrado punto a punto de manera segura. El único desarrollo existente parecido es FireGPG, que sin embargo más que una extensión de HTML era una extensión para Firefox de Javascript, lo cual implica que el usuario debe dar un mayor grado de confianza al servidor web. Otro antecedente de este tipo de seguridad en la web ha sido Hushmail, un servicio web que implementaba el cifrado en un plugin Java aportado por el propio servidor. No obstante la seguridad de este sistema se puso en entredicho cuando la NSA [9] por requisito legal forzó a Hushmail a cambiar su plugin Java para permitirle el acceso a los textos en claro de ciertos usuarios. Por diferentes razones, anteriores intentos de utilizar cifrado punto a punto en navegadores web han fallado. Bien lo han implementado en un navegador web pero sin miras a una estandarización e implementando la solución a nivel de Java/Javascript y no mediante HTML, como es el caso de FireGPG, o bien el cifrado es implementado mediante Javascript o Java por el servidor, servidor en el cual no confiamos o no debemos confiar porque forma parte de la cadena de transporte del mensaje y no es su destinatario. El presente proyecto fue presentado por el autor de la memoria al profesor con el cual realizó el proyecto de fin de carrera porque al autor le pareció crucial que la seguridad en la web avance en la dirección correcta, liberando a las aplicaciones web de la carga de la inseguridad o falta de seguridad que actualmente llevan, y permitiendo su avance en ese mismo campo. Este proyecto intenta arrojar luz sobre este tema y presentar una primera aproximación al problema. El principal objetivo y la principal aportación realizada es conseguir hacer sonar la alarma para que los in- 19

31 20 3. Análisis de antecedentes y aportación realizada ternautas se den cuenta del problema del Server in the middle, a la par que se brinda una solución o más bien se muestra un camino que puede dar con una solución a dicho problema.

32 CAPÍTULO 4 Comparación con otras alternativas 4.1 Aplicaciones de Escritorio Nuestro objetivo más básico es lograr la comunicación de forma segura entre un mínimo de dos personas mediante Internet, la forma actualmente de realizar esto es mediante el software actualmente disponible que permite realizar dicha tarea Correo electrónico El medio de comunicación que permite cifrado punto a punto más típicamente usado es el correo electrónico. El sistema de correo electrónico funciona mediante un esquema distribuido de cliente servidor, donde cada cliente se conecta a un servidor, y luego los servidores se conectan entre ellos, de tal manera que un cliente de un servidor puede mandar un mensaje al cliente de otro servidor de forma transparente para el usuario. Un sistema de cifrado punto a punto establece que nadie más que los extremos comunicantes, en este caso los dos clientes, pueden leer el texto en claro. Y el sistema de seguridad más extendido en este medio es PGP/GnuPG. La inmensa mayoría de clientes de correo electrónico de escritorio existentes tienen soporte de cifrado y firma mediante PGP: KMail de KDE, Thunderbird mediante el plugin Enigmail de Mozilla, Evolution de Gnome, Microsoft Outlook mediante GPG4Win, o Mail de Mac OS X mediante Mac GPG. Se pueden ver adjuntas algunas capturas relacionadas en las figuras que siguen: Como denominador común de todas estas diferentes aplicaciones destacar que permiten ver de una u otra manera el estado del mensaje que se recibe: si está firmado o cifrado, y si este firmado o cifrado ha sido realizado de forma correcta. En caso de que no sea así, se muestra un mensaje de información. Destacar también el uso de un código de colores (rojo para 21

33 22 4. Comparación con otras alternativas Figura 4.1: Leyendo un correo firmado y cifrado en KDE con KMail Figura 4.2: Leyendo un mensaje firmado en Thunderbird con Enigmail

34 4.1. Aplicaciones de Escritorio 23 Figura 4.3: Leyendo un mensaje mal firmado con Evolution

35 24 4. Comparación con otras alternativas Figura 4.4: Leyendo un correo firmado en Mac OS X Mail errores o problemas, azul y/o verde para mensajes firmados y cifrados). Las aplicaciones de escritorio de correo electrónico tienen la ventaja de que están dedicadas exclusivamente a este objetivo y por tanto la interfaz de seguridad respecto al cifrado y firmado de cara al usuario siempre es igual y totalmente reconocible. Eso es algo que intentaremos replicar mediante ciertas medidas de seguridad en nuestra implementación. Además estas aplicaciones de escritorio no sufren tanto el problema de seguridad consistente en saber si el código de cifrado y descifrado que utilizan es legítimo porque dicho código está implementado no por el servidor al cual le mandamos el mensaje sino por la propia aplicación específica de correo electrónico. Por supuesto si el sistema ha sido comprometido mediante un troyano o infectado mediante un virus, la seguridad se puede ver afectada, pero ese es un problema que la solución que propondremos tampoco solucionará y que es el Sistema Operativo quien debe solucionarlo. Probablemente la única desventaja de las aplicaciones de escritorio de correo electrónico según observa el autor es que resulta necesario tenerlas instaladas en el sistema. El objetivo que nosotros nos hemos marcado no es sólo conseguir que el usuario pueda transmitir y recibir mensajes de forma segura por Internet, sino que lo haga desde su navegador directamente, mediante una página web, y eso es algo que evidentemente las aplicaciones de escritorio por definición no pueden conseguir Mensajería Instantánea Como alternativa al correo electrónico se presenta la mensajería instantánea, que es parecida al pero con la salvedad de que la natu-

36 4.1. Aplicaciones de Escritorio 25 raleza de la mensajería instantánea es de mensajes por lo general mucho más cortos en una conversación mucho más fluida por realizarse en vivo, conversación parecida a una charla entre los interlocutores, pero escrita. No obstante en últimos términos es lo mismo: un interlocutor envía un mensaje al otro, y viceversa. Es por esto que también en la mensajería instantánea se ha implantado el sistema de cifrado punto a punto GPG. Aplicaciones como Kopete, PSI, Miranda o Pidgin lo soportan. Recodemos que en un sistema criptográfico de clave pública como PGP tenemos dos claves, una pública y otra privada, de tal suerte que si se cifra un mensaje con una de ellas, sólo se puede descifrar el mensaje con la otra. Cuando un interlocutor A envía un mensaje cifrado a otro interlocutor B, utiliza la clave pública de B para cifrar el mensaje, y B usa su clave privada para descifrarlo. Así mismo, cuando B envía un mensaje firmado, firma el mensaje con su clave privada y A comprueba la firma con su clave pública. Y cada vez que un interlocutor utiliza su clave privada PGP, el interlocutor debe introducir la frase de paso con la que PGP almacena de forma cifrada la clave privada. Así, cada vez que se envía un mensaje firmado o se recibe un mensaje cifrado, ha de introducirse dicha frase. Debido a que se suelen enviar y recibir muchos mensajes a la vez en una conversación de IM (Mensajería Instantánea), para no tener que andar introduciendo la frase de paso todo el tiempo se suele meter en una caché en RAM durante un tiempo, de la forma más segura posible. Esto no lo suele hacer la aplicación de mensajería en sí, sino la librería que ésta utiliza que se encarga de cifrar, descifrar y en general todo el tema criptográfico. Esto ocurre por lo general también en los clientes de correo y como veremos, también ocurrirá en la extensión HTML que se implementa en este proyecto. PGP/GPG es un sistema de seguridad muy robusto que sin embargo algunos pensaron que se tornaba algo aparatoso frente a la volatilidad y asociada sencillez de una aplicación de IM. Esa es una de las razones por las que nació OTR (Off The Record). OTR es parecido en el fondo a GPG, en cuanto a que mezcla un sistema de cifrado simétrico y asimétrico para proporcionar seguridad punto a punto con cifrado y autenticación. Pero la principal motivación de su desarrollo fue la de poder proporcionar a los participantes de una conversación la negación plausible de su participación en ella, a la par de mantener las conversaciones confidenciales, como en una conversación privada en la vida real. También existen muchos clientes que incluyen soporte de OTR o es posible conseguirlo mediante plugins, como Kopete, Pidgin o Adium. Por lo general la interfaz de usuario para el soporte de OTR o de GPG en los clientes de IM suele ser parecida a la hora de realizar una conversación. No obstante, mientras que normalmente la gestión de las claves de GPG se suele realizar en un programa dedicada aparte, en OTR todo eso suele gestionarlo el software de IM en cuestión. Esta gestión incluye el listado

37 26 4. Comparación con otras alternativas Figura 4.5: Chateando mediante OTR con Kopete de claves, creación de pares de claves pública/privada, adición de claves de conocidos, y eliminación de claves antiguas o inválidas. Podemos observar algunas capturas de pantalla de clientes de mensajería instantánea para ver qué tipo de interfaz se muestra al usuario a la hora de chatear y de gestionar las claves. La conclusión sobre esta alternativa, que es la de utilizar un cliente de mensajería instantánea con soporte de algún sistema de seguridad punto a punto como GPG u OTR, es que el sistema funciona y es fácil de usar, pero sin embargo ocurre igual que en el apartado anterior: el objetivo que nosotros nos hemos marcado no es sólo conseguir que el usuario pueda transmitir y recibir mensajes de forma segura por Internet, sino que lo haga desde su navegador directamente, mediante una página web, y eso es algo que evidentemente las aplicaciones de escritorio por definición no pueden conseguir. 4.2 Aplicaciones web HTTPS y SSL En cuanto a conseguir mantener una conversación segura con cierto interlocutor, existe en esencia un único método estándar para conseguirlo en las páginas web y es la utilización de HTTPS y SSL, si nuestro interlocutor no forma parte del servidor. Precisamente lo problemático en SSL estriba en que ese cierto interlocutor con el que se mantiene una conversación segura sólo puede ser el servidor, y no aquel con el que queremos conversar realmente debido a que SSL (o TLS que es su sucesor) es un protocolo de seguridad en la capa de transporte.

38 4.2. Aplicaciones web 27 Figura 4.6: Manejando las claves OTR con Adium Figura 4.7: Conversación segura en Adium con OTR mostrando lo que el usuario ve y lo que realmente se transmite

39 28 4. Comparación con otras alternativas Figura 4.8: Conversación cifrada con GPG en Adium en PSI HTTPS utiliza un sistema de certificados de tal manera que se puede asegurar que la página web a la que estamos accediendo no ha sido modificada por nadie y por tanto su contenido es el que sirvió el servidor y no otro. Se utiliza un esquema de árbol de confianza análogo al utilizado en PGP, con autoridades certificadoras como Verisign cuyas claves públicas suelen venir instaladas en el navegador web, de tal manera que si el sitio mipaginaweb.com tiene un certificado firmado por Verisign, nuestro navegador lo mostrará como seguro. Además la comunicación no suele ir únicamente autenticada sino que en la inmensa mayoría de los casos también va cifrada. Es un esquema en el que la seguridad la recibe más el cliente que el servidor puesto que el cliente conoce la clave pública del servidor pero no al revés, de manera que las conexiones entrantes en el servidor son anónimas por no estar autenticadas. Si nuestra comunicación pasa por un servidor que actúe de intermediario, como ocurre en todas las páginas web, y lo que estamos es comunicándonos mediante este servidor con otra persona, HTTPS (mediante SSL/TLS) nos asegura que el servidor recibe los mensajes en claro y los procesa así. Servicios web que permiten a sus usuarios mandarse mensajes entre ellos existen muchos. GMail por ejemplo es un servicio de con una interfaz web que nos permite, en lo básico, realizar las mismas funciones que cualquier cliente de escritorio de correo electrónico. No obstante no tiene soporte de GPG, y por tanto los mensajes se mandan y reciben siempre en claro por el servidor, y de hecho su modelo de negocio se basa en gran medida en poner publicidad contextual al correo que se esté leyendo. Servicios parecidos a este son Yahoo, Hotmail o Linuxmail.

40 4.2. Aplicaciones web 29 Figura 4.9: Chateando mediante GMail por https Pero las páginas web no sólo versan sobre la comunicación mediante correos. También es posible chatear mediante sitios web, y por ejemplo GMail facilita esto aunando en una sola web ambas características, cliente de y de IM. Es interesante hacer notar cómo los servicios web son en realidad aplicaciones web que proveen acceso a servicios accesible mediante otros medios, y no servicios únicamente accesibles mediante web: por ejemplo GMail provee acceso al correo electrónico mediante su interfaz web, pero también es posible acceder a la misma cuenta mediante cualquier otro cliente de correo electrónico de escritorio (o web, porqué no) mediante IMAP, SMTP y POP3. También existen servicios cuya experiencia es totalmente web y no permiten (o tradicinalmente no han permitido) ningún método de acceso más que web, como por ejemplo Tuenti, o hasta hace poco, Facebook. Estos servicios fidelizan a sus usuarios mediante la trampa de no utilizar ningún tipo de estándar para poder acceder a los datos, que son retenidos por los servicios web. En esto reside el más preocupante problema respecto a la libertad de los usuarios a la hora de utilizar servicios web, según el fundador de la FSF Richard Stallman [4]. No obstante incluso si se permite el acceso al servicio mediante aplicaciones de terceros mediante una API y un protocolo estándar como GMail lo hace con el correo mediante POP, IMAP y SMTP, y mediante XMPP para la mensajería instantánea, los usuarios pierden seguridad al utilizar

41 30 4. Comparación con otras alternativas un servicio web. Este servicio simplifica la vida del usuario (o al administrador del sistema) al no tener que instalar y mantenerlo actualizado, configurado y libre de virus porque la aplicacion es una web, pero el usuario está cediendo igualmente sus datos debido a estas facilidades a empresas con cada vez mayor cantidad de datos, mayor capacidad de analizarlos y estructurarlos, y con una necesidad incipiente de hacer negocio con ellos. La facilidad que implica que el usuario no tenga que hacer las veces de administrador configurando y manteniendo su cliente de correo, o incluso que el administrador tampoco tenga que hacerlo, es muy grande, y eso conlleva un problema de seguridad igual de grande y creciente. Es una opción muy golosa que sin embargo deja de lado la potencial seguridad que podría mantener la web con una extensión de HTML como la que proponemos. Recientemente han aparecido varias administraciones que empiezan a usar directamente GMail como sistema completo integrado de correo electrónico, como la ciudad de Los Ángeles en Estados Unidos, donde ahora empleados utilizarán el sistema de de Google [5] Hushmail Hushmail responde a las inquietudes de seguridad de algunos respecto a los servicios web de correo electrónico y mensajería instantánea proveyendo cifrado PGP en el suyo. Eso es precisamente lo que el presente proyecto de fin de carrera intenta permitir, así que cómo es que Hushmail parece ya haberlo conseguido? El problema de Hushmail es que los navegadores web actuales no proveen ningún sistema de cifrado estandarizado tipo PGP así que Hushmail es quien debe implementarlo. Hushmail cuenta con dos implementaciones: una en Java, y otra directamente en el servidor. En la primera, es un plugin Java que ellos desarrollan el que realiza el cifrado en el cliente. El problema de seguridad de esto es que el cliente debe confiar en que ese plugin java no envíe el texto en claro al servidor. En el segundo caso, se envía la clave de paso al servidor que es quien se encarga de cifrar y descifrar. Por tanto en ambos casos estamos confiando en los servidores de Hushmail para cifrar. Hushmail era sin embargo el sistema de correo electrónico web más seguro que existía y hasta 2007 la mayoría de las críticas le eran favorables. No obstante en 2007 salieron varios casos en los que la NSA había obligado por imperativo legal a Hushmail a que le dejase acceder al texto en claro de mensajes enviados o recibidos por varios de sus usuarios. Y es que el problema consiste en que por muchas buenas intenciones que tenga Hushmail al mantener un sistema seguro de correo electrónico, si es posible de alguna manera (y como hemos visto, puesto que estamos confiando en el servidor, si este es comprometido, se puede) acceder al texto en claro, se hará tarde o temprano. Las razones pueden ser diversas:

42 4.2. Aplicaciones web 31 Figura 4.10: Interfaz de la vista principal del cliente web de correo electrónico de Hushmail, utilizando una cuenta gratuita de 2MB de capacidad bien porque los administradores del servidor no sean de fiar, bien porque el servidor sea comprometido, o porque las autoridades lo requieran. La cadena de seguridad es tan fuerte como su eslabón más débil. Y si sólo confiamos en el destinatario como es o debería ser el caso al utilizar un sistema de seguridad end to end como es PGP/GPG, no debemos de confiar en que el servidor nos provea de un sistema criptográfico seguro porque rompe la cadena de confianza. La solución evidentemente es implementar el sistema de seguridad en el navegador, igual que con SSL y HTTPS, de tal manera que no confiemos en el sitio web sino en el navegador web. Porqué no se ha intentado estandarizar un sistema de cifrado web para el navegador de estas características hasta ahora? Lo cierto es que la seguridad en las aplicaciones web muchas veces es, en el mejor de los casos, un añadido y no una parte fundamental de su arquitectura. Ciertamente eso no es cierto normalmente en las aplicaciones de banca y comercio electrónico. Pero en ambos casos esa seguridad no implica privacidad de comunicaciones entre usuarios sino de un usuario con una entidad superior. Sin embargo la revolución de Internet es que es un medio de comunicación no al uso, no es un medio de un sólo sentido como lo han sido tradicionalmente (y siguen siéndolo mayormente) la radio, televisión o el periódico que son de uno a muchos, sino un medio de mucho a muchos, de iguales a iguales. Y la seguridad y privacidad en esa comunicación

43 32 4. Comparación con otras alternativas entre iguales hasta ahora ha sido siempre lo que los ingleses denominan un afterthought, es decir algo secundario y no fundalmental. Otro de los pilares de Internet es, queramos admitirlo o no, el todo gratis. Los servicios gratuitos que se financian mediante la publicidad triunfan y el gigante americano Google es una buena prueba de ello. Pero los sitios gratuitos también necesitan mantenerse de alguna manera. Con este fin, la publicidad contextual tiene muchas ventajas porque aumenta las probabilidades de que el usuario acceda a esa publicidad puesto que está relacionada con aquello en que en ese momento anda interesado, y por tanto es posible sacar un beneficio con este tipo de publicidad notablemente mayor. Sin embargo esa publicidad no sería posible respecto a un mensaje cifrado al cual el servidor no puede acceder. Eso conlleva que servicios como Hushmail donde al menos teóricamente el texto seguro no es accesible por el servidor apenas proliferen, y que además no sean apenas conocidos porque sólo ofertan o pueden permitirse ofertar servicios gratuitos muy limitados (una cuenta de correo de 2MB y sin acceso POP ni IMAP). No, el negocio para servicios web que venden seguridad no parece pasar por esa gratuidad que tanto vende, sino en ofrecer el servicio con su mantenimiento incluido a empresas y administraciones. 4.3 XML Signature y XML Encryption Estos dos son recomendaciones del W3C de firmado y cifrado de las comunicaciones mediante XML. Involucran una serie de elementos XML, como el elemento KeyInfo, usado por ambos y que aparece como hijo de los elementos SignedInfo, EncryptedData, o EncryptedKey y provee información a un destinatario sobre el material de claves que usar en la validación de una firma o descifrar datos cifrados. El elemento KeyInfo es opcional: puede ser adjuntado al mensaje, o entregado mediante un canal seguro. Este conjunto de tecnologías se engloba en lo que viene a ser llamado como xmlsec, acrónimo de XML Security. No obstante por ejemplo no es actualmente compatible con otros métodos de cifrado bastante extendidos en los ámbitos de comunicaciones tipo correo electrónico o IM, como PGP u OTR, puesto que estos últimos son más bien comparable a xmlsec al mismo nivel y no como una capa que va por encima. Por tanto la elección se encuentra más bien entre PGP/OTR y xmlsec. Un sencillo y simplificado ejemplo de código XML que incluye XML Encryption podría ser el siguiente: <?xml version= 1.0?> <PurchaseOrder> <Order> <Item>book</Item>

44 4.3. XML Signature y XML Encryption 33 <Id> </Id> <Quantity>12</Quantity> </Order> <Payment> <CardId> <EncryptedData Type= xmlns= > <CipherData> <CipherValue>A23B45C564587</CipherValue> </CipherData> </EncryptedData> </CardId> <CardName>visa</CardName> <ValidDate> </ValidDate> </Payment> </PurchaseOrder> También sería posible extender xmlsig (XML Signature) y xmlenc (XML Encryption) para soportar PGP u OTR, pero esto aumentaría aun más la complejidad que conlleva el uso de xmlsec. Existen críticas que atacan a la seguridad de XML en general y a la idoneidad de utilizar la canonización XML en particular como un frontend para el firmado y cifrado de datos XML debido a su complejidad, inherente de su procesamiento, y a su bajo rendimiento [2]. Es cierto que podría haberse utilizado xmlsec como método de cifrado y firmado en este proyecto. La velocidad de procesamiento no era un requisito indispensable para el autor, no obstante debido a que se trata de una prueba de concepto que requería la máxima simplicidad, se optó por no utilizar xmlsec.

45

46 CAPÍTULO 5 Análisis de requisitos En este capítulo describiremos cuales son los requisitos específicos que buscamos que vaya a cumplir nuestro proyecto. El objetivo a nivel de programación es conseguir extender HTML de la forma más sencilla posible para soportar seguridad de punto a punto, e implementar dicha extensión en el motor de renderizado KHTML de KDE. También será necesario crear un página web de ejemplo que utilice las características que brinda esta nueva extensión de manera que se pueda ver fácilmente cual es el posible uso útil de dicha extensión. No se va a realizar un análisis de requisitos muy extenso por ser este proyecto más bien un trabajo de investigación. La manera específica en que se consigue implementar este sistema de seguridad no será abordada en este capítulo sino en el siguiente, en el que se explica las soluciones que hay para abordar el problema, para luego explicar aquella por la cual optamos y las razones que respaldan esa decisión. También es relevante mencionar aquí el capítulo que le sigue, que es el de Implementación, donde se detalla el funcionamiento interno de KHTML para luego continuar explicando cómo se ha modificado KHTML para conseguir implementar la extensión propuesta, y qué medidas de seguridad se han adoptado. Esta extensión de HTML debe permitir a los desarrolladores de sitios web utilizar seguridad de punto a punto sin que los usuarios tengan que confiar en que el sitio web utilice el cifrado de forma correcta, sino que por el contrario el usuario sólo deba confiar en su navegador web. El cifrado y descifrado debe realizarse por el navegador y la página web no debe nunca poder acceder al texto en claro. El internauta que navegue por páginas web que permitan la comunicación segura mediante este nuevo sistema debe poder de alguna manera estandarizada reconocer cuándo un mensaje está siendo enviado de manera segura y conocer en todo momento a quien se está enviando el mensaje. Igualmente, debe poder reconocer visualmente 35

47 36 5. Análisis de requisitos cuándo un mensaje ha sido recibido de forma segura, y comprobar los datos del mensaje. Debido a que esta extensión tiene como objetivo aumentar la seguridad de los interanutas a la hora de utilizar Internet como una herramienta de comunicación, uno de los requisitos que debemos cumplir es implementar las medidas de seguridad necesarias para que un sitio web malicioso no pueda ni acceder al texto en claro saltándose las medidas de seguridad que implemente el navegador, ni engañar al usuario haciéndole creer que el mensaje que esté recibiendo o enviando lo esté haciendo de forma segura.

48 CAPÍTULO 6 Solución propuesta En esta sección se explica cómo fue el proceso por el cual se llegó a decidir la solución elegida para solventar el problema planteado en las secciones anteriores. En la primera sección se explica algo la historia que llevó al autor a plantearse el problema en primer lugar, y la primera solución que se barajó. Gran parte de esa historia se puede leer en cierta entrada del blog del autor [10]. En la siguiente sección, se explica cual es la aproximación que finalmente se siguió ante el problema. 6.1 Algo de Historia y primera solución barajada Ya era de noche en una tarde a finales del mes enero del año 2009, cuando Daniel García Moreno (alias danigm ) que es un muy buen amigo del autor y el autor iban hablando de sus cosas de vuelta de la facultad. De las siguientes cosas que cuento íbamos hablando: Danigm participaba ese año en el Concurso Universitario de Software Libre organizado por cierto por personas afines a ambos, por miembros de la asociación universitaria de la Universidad de Sevilla SUGUS GNU/Linux a la que pertenecemos. El proyecto con el que danigm participaba es GECO (GEstor de COntraseñas), que permite administrar tus contraseñas online de manera que entre otras cosas puedes sincronizarlas entre diferentes ordenadores. Por supuesto, el almacenar todas tus contraseñas de una forma centralizada y para más inri accesible mediante Internet debe realizarse de forma muy segura si no quieres llevarte disgustos. La conexión con el servidor debe ser segura (SSL) para que nadie más pueda conocer tus contraseñas. Pero aun así es totalmente legítimo preguntarse vas a almacenar las contraseñas en claro? De ninguna manera, eso es demasiado arriesgado. Personalmente no confiaría todas mis contraseñas ni a mejor amigo, e incluso si así fuese, qué ocurre si su máquina resulta comprometida? Si alguien le roba el fichero de contraseñas en claro, seremos totalmente vulnerables. 37

49 38 6. Solución propuesta El caso es que GECO está diseñado para tener tanto un cliente web como un cliente de escritorio. El problema aquí es que los navegadores web no proveen un framework estándar para cifrar y descifrar datos desde el cliente web. Tienes SSL, pero éste sólo cifra las comunicaciones entre el navegador y el servidor, y eso no resuelve el problema. Así pues qué es lo que mi amigo danigm resolvió hacer? Se pondría a utilizar Slow AES, una implementación software libre de AES realizada tanto en Javascript como en Python. Hay que tener en cuenta que no sólo necesita ser capaz de cifrar y descifrar texto en el cliente web mediante Javascript, sino que también debe asegurarse que cuando se utiliza el cliente que ha desarrolado en Python para el escritorio Gnome, exactamente la misma implementación del algoritmo AES debe ser utilizada, de manera que aquella contraseña que sea cifrada utilizando el cliente web pueda ser descifrada en el cliente de escritorio y viceversa. Desde luego lo último que querría danigm que ocurriese es que uno de sus felices usuarios no pudiese recuperar la contraseña que había confiado a GECO debido a incompatibilidad entre clientes, o incluso peor, que la contraseña se perdiese. La penalización de esto es que dicha implementación de AES es, como su propio nombre indica, lenta. Pero eso no es un gran problema a la hora de realizar cifrado de pequeñas cadenas de texto como suelen ser las contraseñas. No obstante toda esta problemática hizo encenderse una bombilla dentro de mi cabeza. Me di cuenta de que esta aplicación era tan sólo un ejemplo de lo que iba a venir en el futuro, porque las aplicaciones web están convirtiéndose cada vez más en algo más común en nuestra vida diaria en Internet. Por ejemplo está GMail, que es una maravillosa pieza de software por la sencilla, útil e intuitiva interfaz que ofrece al usuario, y de hecho por entonces estaba tentado a reemplazar el bueno de KMail por GMail, pero existía una gran característica que echaba de menos: GPG. Intrigado, había probado el plugin FireGPG para GMail, pero no funcionaba muy bien y además no funciona en otros navegadores que no fuesen basados en Mozilla/Firefox, como por ejemplo Konqueror. También había usado de vez en cuando el chat de GMail, que me permite conectar mediante Jabber con todos mis contactos de IM y además con todos los contactos de que usan GMail, lo cual resulta útil algunas veces. Pero siendo un ávido usuario del plugin OTR de Kopete, echaba de menos la seguridad que éste me ofrecía. Me di cuenta de que cada vez más datos estaban siendo almacenados y transmitidos online y que sin embargo en vez de mejorar cada vez más en el tema de la seguridad y privacidad de las comunicaciones, las aplicaciones web estaban menoscabando este aspecto. Como consecuencia, SSL ya no era suficiente como manera de proteger nuestra privacidad en la web: necesitamos un framework completo y bien diseñado para poder cifrar y descifrar datos desde el navegador. La siguiente pregunta era, por tanto, cómo podría ser dicho sistema? Se me ocurrieron algunas algunas ideas sobre esto: debería utilizar im-

50 6.1. Algo de Historia y primera solución barajada 39 plementaciones estándares de algoritmos conocidos de clave pública y/o privada, como GPG, RSA u OTR. Probablemente un binding para Javascript de libcrypto sería suficiente para eso, cosa que ya provee Firefox por cierto. Pero era necesario algo más, era necesario conseguir una manera de que los usuarios tengan asegurado que los datos en claro no serán accesibles por nadie más que ellos, que el código Javascript y HTML no está haciendo trampas como por ejemplo acceder a los datos en claro y enviarlos al servidor web. El servidor web no debía poder acceder más que a los datos cifrados. Para conseguir algo así, se me ocurrió que la mejor manera era aislar la parte de la página que lidia con los datos cifrados de la parte de la página que maneja los datos en claro, creando una jaula de software para esta última parte. La idea es tener una etiqueta HTML que cree dicha jaula. Todo el código HTML, CSS o Javascript que se encuentre dentro de la jaula podría acceder al texto en claro, pero en cambio al comunicarse con el exterior, los datos tengan que ir necesariamente cifrados con una clave concreta. De manera que: 1. Su apariencia permite ser modificada mediante css (ya no estamos en los años noventa). 2. Los datos cifrados pueden ser procesados de forma segura y transparente en el navegador mediante Javascript sin comprometer su seguridad. El código externo a la jaula vería los datos que se envían y reciben de ella de forma cifrada, y sería posible comunicarse con la jaula por los métodos usuales: bien enviando un formulario por POST/GET o mediante AJAX. Por otra parte, el código Javascript que se ejecute dentro de la Jaula vería los datos cifrados en claro, pero no podría comunicarse con nadie sin cifrar antes los datos de forma segura con la aprobación del usuario. Porqué no es esta la solución elegida? Básicamente porque es un proyecto demasiado grande como para poder realizarlo dentro del ámbito de un proyecto de fin de carrera. Aislar en una jaula una parte del código de una página web de forma segura requiere cambios muy importantes que atacan la arquitectura de un motor de renderizado como KHTML. Además existe la problemática de cómo abordar el problema de que el usuario sepa reconocer los datos que estén cifrados o vayan estar cifrados de una manera estándar en el navegador. Además la solución de la jaula és muy flexible y deja mucha libertad de implementación al desarrollador de páginas web, pero eso también deteriora la facilidad del usuario de reconocer contenido seguro. Se concluye que no es una tarea imposible, de hecho probablemente sea el camino a seguir en el futuro si se consigue

51 40 6. Solución propuesta una implementación que resuelva estos problemas, pero no es la solución acertada para el presente proyecto. 6.2 Solución elegida Una solución más simple que crear una jaula pasa también por aislar el código de la página web que lidia con los datos cifrados del código de la página web que lidia con los datos en claro, pero minimizando hasta la última expresión éste último y haciéndolo desaparecer. Como resultado, sencillamente no habrá código de la página web que pueda acceder al texto en claro, sin embargo el usuario naturalmente sí podrá acceder a él. Esto elimina de un plumazo los problemas que tiene la solución anterior. La manera de conseguir esto es también bien sencilla. A la hora de descifrar un texto cifrado, he elegido el elemento DIV de HTML para realizar dicho cometido. El DIV tan sólo deberá indicar que se encuentra cifrado y el sistema de cifrado mediante el atributo encryption. Igualmente, he elegido el elemento INPUT de tipo text como aquel que permite enviar texto cifrado. Para ello igualmente se utilizará el atributo encryption descrito anteriormente, además de otro atributo más, encryption-key, que indica cón qué clave pública debe cifrarse el texto. Igualmente, para firmar mensajes se añadiría el atributo signature-key. Ejemplo: de código HTML y PHP que hacen uso de dicha extensión: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" " <html xmlns=" xml:lang="en" lang="en" dir="ltr"> <head> <title>encryption</title> </head> <body> <form action="index.php" method="post"> <input type="text" name="field" encryption="gpg" encryption-key="35c30cbe"/> <input type= submit name="go" value="go" title="go!"/> </form> <?php if (isset($_request[ field ])) { echo "<div encryption=\"gpg\"">".$_request[ field ]."</div>"; }?> </body> </html> El anterior es un ejemplo sencillo de un formulario en que el usuario puede enviar un texto que será cifrado con la clave pública 35C30CBE, y al enviarse luego será mostrado en un DIV cuando el usuario descifre el texto. El flujo de trabajo por tanto sería:

52 6.2. Solución elegida El usuario entra en la página. 2. El usuario escribe el texto que desee enviar cifrado en el recuadro de texto llamado field. 3. El usuario pulsa el botón Go!. 4. El navegador cifra el texto. 5. El navegador envía el formulario al servidor, con el texto de field cifrado. 6. El servidor devuelve la misma página con un elemento DIV que contiene el texto cifrado. 7. El navegador muestra dicha página de respuesta al usuario y comprueba que el usuario tiene la clave privada capaz de descifrar dicho texto. 8. El navegador muestra si resulta necesario un diálogo pidiéndole al usuario la frase de paso correspondiente a dicha clave privada. 9. El usuario introduce su frase de paso. 10. El navegador muestra la página con el texto descifrado que el usuario anteriormente había escrito. De forma parecida funcionaría el atributo signature-key, sólo que la contraseña sería solicitada al usuario a la hora de enviar el mensaje y no a la hora de recibirlo. Existen algunas restricciones de seguridad asociadas a esta extensión que hay que recalcar: 1. El funcionamiento debe ser tal que si se intenta acceder mediante javascript al valor del elemento input de tipo text, no se acceda al contenido en claro sino al texto cifrado. Lo mismo debe ocurrir con el DIV cifrado. 2. Debido a que sólo se permite enviar texto plano mediante el input type text, y por simplificar, el elemento DIV cuando esté cifrado sólo podrá contener texto en claro. 3. Como mínimo la implementación debe soportar el tipo de cifrado gpg. 4. La implementación debe encargarse de que el usuario pueda reconocer fácilmente cuándo un DIV o un input type text está usando cifrado o no.

53 42 6. Solución propuesta 5. La implementación debe encargarse de que la página web no pueda maliciosamente modificar los elementos HTML que usen esta extensión u ocultarlos, y debe de alguna manera impedir que la web intente engañar al usuario haciéndole creer que un elemento es seguro cuando no lo es. Esta solución no está carente de problemas, tiene sus limitaciones y no es ni mucho menos la solución final al problema planteado; de hecho como ha sido mencionado a lo largo de esta memoria, debe de tomarse sólo como una primera aproximación. Por ejemplo, no se ha tenido en cuenta el soporte de cifrado en otros elementos de entrada de información por parte del usuario, como los textarea, checkboxes, ficheros, o soporte para cifrar todo el contenido de un formulario en vez de ir elemento por elemento. Además el texto en claro mostrado por un DIV siempre será texto plano y no enriquecido con imágenes u otros elementos, y debido a que ninguna parte del código de la web puede acceder al texto en plano, no podrá de ninguna manera procesarlo. Procesarlo sería útil por ejemplo a la hora de realizar un chat cifrado, para sustituir emoticonos por imágenes de los mismos. No obstante esto también puede ser visto como una característica de seguridad (seguridad mediante simplicidad), puesto que el usuario siempre verá directamente el texto en claro y no una versión del mismo modificada por terceros, cosa que podría ocurrir en la solución de la jaula - no obstante este problema siempre podría arreglarse en la implementación ofreciendo al usuario alguna manera estándar de acceder al texto en plano sin procesar.

54 CAPÍTULO 7 Implementación En el presente capítulo se detalla cómo se procedió a la hora de realizar la implementación del proyecto, consistente en la modificación del motor de renderizado KHTML para que soportase la extensión de HTML detallada en el capítulo anterior. Debido a que el proyecto se basa en la modificación del código de un software ya existente (KHTML), resulta preciso primero explicar el funcionamiento interno del mismo, y la primera sección de este capítulo se dedica a dicha tarea. Seguidamente, se pasa a explicar los detalles de implementación del soporte de cifrado en el campo input de tipo text y las medidas de seguridad que se tuvieron en cuenta. Finalmente, se detalla la forma en que se ha añadido al elemento DIV de HTML soporte de texto cifrado y las medidas de seguridad que se han aplicado. 7.1 Funcionamiento interno de KHTML Esta sección intenta dar una visión general sobre el funcionamiento interno de la librería KHTML. Es principalmente una traducción del inglés al español del documento DESIGN.html existente en el proyecto kdelibs y se encuentra bajo la misma licencia que el mencionado documento. Según cuenta el autor del texto, lo escribió porque la librería se había convertido en algo bastante grande, y es difícil al principio encontrarse a gusto con su código fuente. Eso no significa que después de leer esta descripción se comprenda completamente KHTML tras leer el presente texto, pero sí que resultará más fácil la lectura del código. Tengo cierta experiencia en adentrarme en el código fuente en C++ de software con muchas líneas de código, comprenderlo y modificarlo para llevar a cabo el objetivo marcado; la primera vez que hice esto fue en el primer Concurso Universitario de Software Libre, cuando junto a Daniel García Moreno hice mi primera contribución en KDE, consistiendo en 43

55 44 7. Implementación añadir la característica de poder recuperar pestañas recientemente cerradas en Konqueror. También en su día hice cierto parche para VirtualBox. Ambos proyectos están en C++ y son de grandes dimensiones, y de hecho Konqueror y KHTML están bastante relacionados. No obstante el código de KHTML nunca antes lo había tocado. La descripción que aquí presento traducida del funcionamiento interno de esta librería resultó crucial para conseguir el éxito en el desarrollo del proyecto. La librería KHTML forma parte a su vez del conjunto de librerías Kdelibs, que son las librerías principales usadas en el entorno de escritorio KDE. A su vez, todo KDE está basado en el toolkit gráfico Qt, que permite a KDE abstraerse bastante del hardware y las primitivas de renderizado (pintado) que hay que utilizar según en qué sistema se ejecute el software (Linux, Unix, Windows, Symbian..). Qt está programado en C++ y la inmensa mayoría del software de KDE también, incluida la librería KHTML. Se escapa del objetivo de este documento explicar el funcionamiento de Qt [8] o de C++ [7], y se supone su conocimiento. La librería está compuesta de varias partes. Básicamente, cuando se usa la librería, se crea una instancia de la clase KHTMLPart, y se le mandan datos. Eso es más o menos lo que ha de saberse si lo único que se quiere es utilizar khtml para otra aplicación. Sin embargo si se quiere comenzar a hackear khtml, he aquí un compendio de los objetos que serán construídos cuando por ejemplo se ejecuta el programa testkhtml con una url como argumento. KHTMLPart crea una instancia de un KHTMLView (que hereda a su vez de QScrollView), el widget que muestra todo realmente. Al mismo tiempo se crea un árbol DOM a partir del HTML o XML encontrado en el fichero especificado. Describamos esto con un ejemplo: khtml hace uso del DOM (Document Object Model) para almacenar el documento en una estructura de tipo árbol. Imaginemos un código HTML como el siguiente: <html> <head> <style> h1: { color: red; } </style> </head> <body> <H1> some red text </h1> more text <p>

56 7.2. Analizadores léxico y sintáctico 45 a paragraph with an <img src="foo.png"> embedded image. </p> </body> </html> En lo que sigue veremos como esta entrada es procesada paso por paso para finalmente generar la salida visible que se muestra en la pantalla. Se describirá el proceso como si las etapas ocurriesen una tras otra de manera secuencial, para que sea más fácil comprenderlo. Sin embargo en realidad para conseguir una salida visible en la pantalla lo antes posible (desde el análisis léxico hasta la construcción y maquetación del árbol de renderizado) ocurren más o menos en paralelo. 7.2 Analizadores léxico y sintáctico Lo primero que ocurre cuando la libreria abre un fichero es que se analiza léxica y sintácticamente, trabajos realizados por el tokenizer y el parser, respectivamente. Lo primero que ocurre cuando comienza a analizarse un nuevo documento es que el objeto DocumentImpl* para los documentos XML/XHTML (o el objeto HTMLDocumentImpl* si se trata de HTML) es creado por el KHTMLPart en la función begin. Un objeto de tipo Tokenizer* es creado tan pronto como la función DocumentImpl::open() es llamada por el KHTMLPart, cosa que también ocurre en la función begin() mencionada anteriormente, tanto si se trata de un XMLTokenizer como de un HTML- Tokenizer. El analizador léxico de XML (XMLTokenizer) usa las clases de QXML en Qt para analizar el documento, y su interfaz SAX para introducir los elementos en el árbol DOM de khtml. En el caso de HTML, el analizador léxico se encuentra en khtmltokenizer.cpp. El tokenizer úsa los contenidos de un fichero HTML como entrada y desgrana el contenido en una lista enlazada de elementos llamados tokens, reconociendo entidades y etiquetas HTML. Así mismo, el texto entre las etiquetas de comienzo y finalización es manejado de forma especial para algunas etiquetas concretas. La distinción estriba en la manera en que los espacios, el manejo de líneas, entidades HTML y otros tags son manejados dentro de dichas etiquetas. El analizador léxico está basado completamente en estados que pueden cambiar carácter a carácter. Todo el texto que se pasa al analizador léxico se convierte a tokens directamente. El texto puede ser pasado al analizador por completo carácter por carácter (lo cual no es muy eficiente) o bien por bloques de cualquier tamaño.

57 46 7. Implementación El analizador léxico HTML (clase HTMLTokenizer) crea un HTML- Parser que interpreta el torrente de tokens que genera el analizador léxico y construye el árbol de nodos que representan el documento de acuerdo al DOM El árbol DOM Analizando el documento HTML mostrado anteriormente se general el siguiente árbol DOM de clases en khtml: HTMLDocumentElement --> HTMLHeadElement \--> HTMLStyleElement \--> CSSStyleSheet \--> HTMLBodyElement --> HTMLHeadingElement \--> Text --> Text \--> HTMLParagraphElement --> Text --> HTMLImageElement \--> Text No obstante estas clases son únicamente las interfaces que se crean para acceder al árbol DOM. Los datos realmente se almacenan en las clases con el sufijo Impl, que son aquellas que implementan la lógica interna de los elementos. Así pues, tenemos un árbol interno de clases de implementación con la siguiente estructura: HTMLDocumentElementImpl* --> HTMLHeadElementImpl* \--> HTMLStyleElementImpl* \--> CSSStyleSheetImpl* \--> HTMLBodyElementImpl* --> HTMLHeadingElementImpl* \--> TextImpl* --> TextImpl* \--> HTMLParagraphElementImpl* --> TextImpl* --> HTMLImageElementImpl* \--> TextImpl* Se utiliza un esquema de recuento de referencias para asegurarse de que todos los objetos son eliminados en caso de que el objeto padre sea eliminado, siempre que no exista una clase de tipo interfaz que contenga una referencia a la clase de implementación en cuestión.

58 7.2. Analizadores léxico y sintáctico 47 Las clases de tipo intefaz (aquellas sin el sufijo Impl) se definen dentro de la estructura de directorios del código de khtml en el subdirectorio dom/, y no es usada internamente por khtml. El único lugar donde este tipo de clases es usado es en los bindings para Javascript, que las usa para acceder al árbol DOM. La gran ventaja de tener esta separación entre las clases de interfaz y de implementación es que es posible tener varios objetos de tipo interfaz que apuntan a la misma implementación. Esto cumple con el requisito de compartimiento explícito exigido por la especificación DOM. Otra ventaja es que debido a que las clases de implementación son púramente internas y no son accesibles mediante la interfaz pública de la librería, los hackers de khtml tienen mucha más libertad para realizar cambios a la implementación sin romper la compatibilidad binaria de la librería. Existen casi una correspondencia total entre las clases de tipo interfaz con las de implementación. En el caso de las de implementación se han añadido algunas clases intermedias más, que no son visibles desde fuera por razonez varias, como por ejemplo para conseguir más fácilmente compartir características entre clases o reducir el uso de memoria. Usando C++, se puede accer a todo el árbol DOM desde fuera de KHTML usando las clases de tipo interfaz. Una cosa que ha sido omitida en el texto anterior son las hojas de estilo definidas en el elemento style (como ejemplo de una hoja de estilo) y el elemento imagen (como ejemplo de un recurso externo que debe ser cargado). De esto tratarán las siguientes dos subsecciones CSS El contenido del elemento style (en el caso del código HTML de ejemplo se trata de la regla h1 color: red; ) será pasado al objeto HTMLStyleElementImpl. Esto objeto crea a su vez un objeto CSSStyleSheetImpl al que le pasa dichos datos. El analizador sintáctico CSS recogerá los datos, y creará una estructura DOM para CSS similar a la que se crea al analizar código HTML. Esto será utilizado más adelante para definir el aspecto de los elementos HTML del árbol DOM. De hecho eso de más adelante és relativo porque como dijimos anteriormente, esto ocurre parcialmente en paralelo con la construcción del árbol DOM Cargando Objetos externos Algunos elementos HTML (como img, link, object, etc) contienen referencias a objetos externos que tienen que ser cargados. Esta tarea es realizada por el cargador (clase Loader ) y clases relacionadas (ver

59 48 7. Implementación archivos misc/loader.*). Los objetos que puedan necesitar cargar elementos externos heredan de CachedObjectClient, y pueden pedir al cargador (que también actúa como una memoria caché) que descargue el objeto que necesita de la web. Una vez el cargador tiene disponible el objeto requerido, se lo notificará al CachedObjectClient correspondiente, y el cliente entonces puede procesar los datos recibidos Pintando en pantalla Ahora una vez tenemos el árbol DOM, y las hojas de estilo asociadas y los objetos externos, cómo conseguimos que realmente todo sea mostrado por pantalla? Ese es el objetivo del motor de renderizado, que está completamente basado en CSS. De lo primero que se encarga es de recoger todas las hojas de estilo que se aplican al documento y crear una buena lista de reglas de estilo que deben aplicarse a los elementos de la página. Esto se hace en la clase CSSStyleSelector. Se basa en la hoja de estilo por defecto de HTML (definida en css/html4.css), una hoja de estilo opcional definida por el usuario, y todas las hojas de estilo del documento, y las combina en una buena lista de reglas de estilo optimizada para una mayor velocidad de acceso. Las reglas exactas de cómo estas hojas de estilo deben ser aplicadas a HTML o a documentos XML pueden encontrarse en las especificaciones de CSS 2 y 3. Una vez tenemos esta lista, podemos obtener un objeto de tipo RenderStyle para cada elemento DOM a través del CSSStyleSelector llamando a la función sytyleforelement(dom::elementimpl *). El objeto de estilo describe en una forma compacta todas las propiedades CSS que deben ser aplicadas al nodo en cuestión. Después de eso, comienza la generación del árbol de renderizado/pintado. Usando el objeto de estilo, el nodo DOM crea el objeto de renderizado correspondiente (todos estos están definidos en el subdirectorio rendering ) y lo añade al árbol de pintado. Esto crea otra estructura de tipo árbol, que a rasgos generales se parece a la estructora del árbol DOM del cual proviene, pero que también puede contener algunas diferencias significativas. En primer lugar, las llamadas cajas anónimas [3], que no tienen un homólogo en el árbol DOM, puede que sean insertadas en el árbol de renderizado para satisfacer los requerimientos de DOM. En segundo lugar, la propiedad display del estilo afecta a qué tipo de objeto de renderizado se escoge para representar a un objeto DOM. En el ejemplo del comienzo al que venimos refiriéndonos, obtendríamos el siguiente árbol de pintado: RenderRoot* \--> RenderBody*

60 7.2. Analizadores léxico y sintáctico 49 --> RenderFlow* (<H1>) \--> RenderText* ("some red text") --> RenderFlow* (anonymous box) \--> RenderText* ("more text") \--> RenderFlow* (<P>) --> RenderText* ("a paragraph with an") --> RenderImage* \--> RenderText* ("embedded image.") Una llamada a la función layout() del objeto RenderRoot (que es aquel del cual cuelgan todos los demás en el árbol de renderizado) consigue que el árbol de pintado se distribuya a sí mismo en el espacio disponible (en anchura) dada por la vista donde se pintará la página (KHTMLView). Después de esto, el método KHTMLView::drawContents() puede llamar a RenderRoot::print() con los parámetros adecuados para realmente pintar el documento. Esta descripción no es 100 % correcta cuando se realiza un analizado sintáctico incremental al cargar inicialmente el documento, pero es exactamente lo que ocurre cuando se redimensiona la vista. Como se puede ver en el árbol de renderizado, la conversión realizada ha resultado en la eliminación de las referencias al elemento head del código HTML, y se ha insertado un objeto anónimo de renderizado que engloba a la cadena more text. De nuevo, porqué esto ha sido necesario es explicado en la especificación de CSS [3] Estructura de directorios Una pequeña explicación de la estructura de directorios en khtml: css Contiene todas las cosas relevantes a la parte CSS de DOM Level 2 (únicamente las clases de implementación, el analizador sintáctico CSS, y el código para crear el objeto RenderStyle dado un nodo y las hojas de estilo vigentes. dom Contiene toda la API DOM externa (las clases de interfaz DOM) para todo el DOM. ecma Los bindings javascript para el DOM y khtml. html la parte HTML del DOM (únicamente las clases de implementación), los analizadores léxico y sintáctico HTML y una clase que define el DTD a usar en HTML (utilizada principalmente por el analizador sintáctico). java Todas las cosas relacionadas con Java.

61 50 7. Implementación misc Código variado necesitado en khtml. Contiene el cargador de imágenes, algunas definiciones variaas y la clase decodificadora que convierte datos a unicode. rendering Todo lo relacionado con llevar el árbol DOM y las declaraciones CSS a la pantalla. Contiene la definición de los objetos utilizados en el árbol de pintado, el código de distribución del espacio de los elementos, y los objetos RenderStyle. xml La parte XML de la implementación DOM, el analizador sintáctico XML Manejo de excepciones Para conseguir una librería más ligera, el uso de excepciones de C++ está solo habilitado en el subdirectorio dom/, debido a que el uso de excepciones es obligado según la API DOM. En el resto del código de khtml se pasa un flag de error (usualmente llamado exceptioncode ), y la clase que es parte del subdirectorio dom/ comprueba este flag y si está activo lanza la excepción Palabras finales... Todo lo anterior sólo es una rápida introducción a la manera en que khtml muestra un fichero XML/HTML en la pantalla. No es ni mucho menos una descripción completa ni 100 % correcta. Muchos problemas quedaron en el tintero; para muestra una lista de las cosas que faltan: El decodificador que convierte un torrente de datos entrante en texto unicode La interacción con Konqueror u otras aplicaciones. Javascript. Reflow dinámico y cómo utilizar el árbol DOM para manipular la salida visual de khtml. manejo de eventos/ratón. Las interacciones reales cuando se analiza incrementalmente. Java. No obstante esta pequeña introducción sirve como primera aproximación a khtml y cómo funciona.

62 7.3. Introducción al parche de khtml 51 khtml es actualmente una librería bastante grande y toma cierto tiempo comprender su funcionamiento. No hay que frustrarse si no se comprende inmediatamente cómo funciona. Por otra parte, es actualmente una de las librerías que se usan mucho que probablemente sea la que tenga un mayor número de bugs (incluso si muchas veces es difícil saber si cierto comportamiento es realmente erróneo). 7.3 Introducción al parche de khtml En la sección anterior hemos visto cual es el funcionamiento interno de KHTML. Esto es crucial para poder comprender de qué manera hemos desarrollado la implementación de la extensión HTML propuesta. Esta implementación se materializa principalmente en un parche (khtml.patch) de varios miles líneas de código. Pero podemos desgranar el parche conceptualmente según las capas que toca. Nuestra intención es añadir varios atributos a HTML (encryption, encryption-key, etc), que sólo podrán ser utilizados en algunos elementos (div, input), y que tendrán por supuesto ciertas repercusiones a nivel de comportamiento del árbol DOM, del árbol interno, y del árbol de pintado o renderizado. 7.4 Tokenizer Para que los atributos que añadimos no sean extraños a khtml, tenemos que ir por partes, y lo primero que tenemos que hacer es que el analizador léxico de HTML los reconozca, pues es la primera etapa en la que khtml se encontrará con ellos. Para ello simplemente hace falta añadir esos atributos a la lista de atributos del tokenizer, lista que se puede encontrar en el fichero misc/htmlattrs.in. Como es el caso en muchos analizadores léxicos, el de khtml no se escribe totalmente a mano sino que está automatizado. Dado la lista de atributos antes mencionada y mediante un script que se encuentra en misc/makeattrs, se genera y actualiza el código en C++ del analizador léxico que lee los atributos. No sólo eso, sino genera los ficheros de cabecera en los que se definen las etiquetas y su valor numérico correspondiente para cada atributo, que son utilizadas para referirse a ellos a lo largo de todo khtml. Existe otro script análogo para cambiar la lista de tags reconocidos por el tokenizer ó analizador léxico, pero debido a que nuestro parche no necesitamos de ningún tag especial, no es preciso utilizarlo. También hizo falta volver a ejecutar el script python misc/gennames.py que genera los ficheros htmlnames.h y htmlnames.cpp que se encarga de asociar a cada define (macro de preprocesador) de cada etiqueta

63 52 7. Implementación o atributo la cadena que corresponde a dicho token, de manera que el parser pueda reconocer la cadena y que pueda utilizarse en khtml. Ejecutar estos scripts de generación y actualización del código del analizador léxico es por tanto indispensable porque de lo contrario khtml seguirá sin tener ningún conocimiento sobre estos nuevos atributos y no podríamos hacer referencia a ellos ni utilizarlos de ninguna manera. 7.5 Parser Como vimos en la sección anterior, el analizador sintáctico o parser se encarga de recibir la salida en forma de lista de tokens generada por el analizador léxico y general el árbol DOM de uso interno por khtml. A medida que recibe tokens, el parser instancia las clases *Impl según va necesitando y va añadiéndoles los atributos correspondientes y colgándolas de sus clases padres. No ha sido necesario modificar el parser puesto que éste está diseñado de forma genérica tal que cualquier atributo se le añade a la clase *Impl correspondiente y es ésta la encargada de lidiar con dicho atributo, de saber si es válido y procesarlo o por lo contrario generar un error. 7.6 Librería de cifrado y descifrado Debido a que ya la comprensión del código de KHTML (para poder luego saber modificarlo) es un trabajo ímprobo, y a que el objetivo del proyecto es probar y demostrar la viabilidad del concepto más que ser una implementación completa, se ha optado por simplicidad implementar un sólo tipo de cifrado, GPG. Existen multitud de librerías que nos permiten cifrar y descifrar GPG, pero he optado por utilizar libkleo puesto que es la librería de KDE que también se usa en Kleopatra, el gestor claves de KDE. Está diseñada con las librerías de KDE y Qt, usando clases como QString, QList, señales y slots de Qt, etc. Además a la hora de descifrar o de firmar un mensaje muestra un mensaje con diálogos de KDE, y por tanto tiene una máxima integración con el entorno de escritorio objetivo. Sin embargo no son todo ventajas: libkleo está diseñada únicamente con Kleopatra en mente y no para ser utilizada por terceros. Esto no significa que no sea posible hacerlo porque la interfaz esté acoplada a Kleopatra, sino que mantener una librería de propósito general conlleva mantener también una interfaz estable compatible binariamente entre revisión menores, además de tener que revisar toda la interfaz previamente para asegurarse de que es correcta. Cuando les pregunté por estos asuntos, estas son las razones que los mantenedores y desarrolladores actuales de la librería esgrimieron como razón por la cual no exportaban las cabeceras de la librería para que otros pudiesen utilizarlas, y la razón por la cual

64 7.7. Implementación de Input Type Text 53 libkleo se encontraba en el paquete kdepim (donde normalmente sólo se encuentran programas de PIM) y no en kdepimlibs (donde se recopilan librerías de PIM de uso general). Otro problema es que mientras que khtml se encuentra en kdelibs, libkleo no. Si sus desarrolladores estuviesen dispuestos a abrirla para su uso por parte de terceros, para usarla en kdelibs requeriría bien mover libkleo a kdelibs, o eliminar su uso de kdelibs y meterla en kdesupport, que son las librerías en que kdelibs se puede apoyar. Aun con todo, debido a que el propósito de al menos esta primera versión del parche a khtml no es ser incluido en la versión oficial de khtml por sus limitaciones y más bien tendrá un uso y distribución limitados, no importan mucho estos problemas. Resuelto a utilizar libkleo por sus ventajas, he realizado un pequeño parche que permite exportar sus cabeceras de manera que las pueda utilizar en khtml. Por supuesto no he movido libkleo a kdesupport, por lo que tras aplicar este parche, necesario para poder luego aplicar el de khtml, hace falta compilar kdepimlibs y todas sus dependencias (entre ellas kdelibs que incluye khtml), para luego volver a compilar khtml con soporte de libkleo. Cómo hacer esto se detalla en el capítulo dedicado al manual de instalación. Con el fin de detectar si existe soporte de libkleo o no, también he realizado algunos cambios al sistema de compilación CMake que usa khtml (y es usado en todo KDE actualmente). Al inspeccionar el parche a khtml, llama la atención el extensivo uso de condicionales del preprocesador del tipo #ifdef KLEO_SUPPORT. Esta regla es la que comprueba si existe soporte de libkleo. De esa manera aun con el parche aplicado es posible compilar khtml sin problemas cuando libkleo aun no está disponible, aunque evidentemente todo el código relativo al presente proyecto no será compilado. El uso de este tipo de directivas de preprocesador es muy típico en estos casos. Para aprender a utilizar la librería libkleo el autor desarrolló un pequeño programa de KDE llamado kleocypher que permite cifrar y descifrar textos con ella. Esto me permitió aprender a utilizar en un entorno controlado las mencionadas anteriormente instrucciones del preprocesador, la detección de libkleo, leer las claves GPG con clave privada disponible y sus detalles como nombre e , cifrar texto, descifrar texto y comprobar errores al respecto. He aquí una pequeña captura de pantalla de dicha utilidad: 7.7 Implementación de Input Type Text Recordemos el ejemplo del capítulo anterior de un código HTML que usa la extensión e HTML desarrollada: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "

65 54 7. Implementación Figura 7.1: Kleocypher <html xmlns=" xml:lang="en" lang="en" dir="ltr"> <head> <title>encryption</title> </head> <body> <form action="index.php" method="post"> <input type="text" name="field" encryption="gpg" encryption-key="35c30cbe"/> <input type= submit name="go" value="go" title="go!"/> </form> <?php if (isset($_request[ field ])) { echo "<div encryption=\"gpg\"">".$_request[ field ]."</div>"; }?> </body> </html> Cuando el analizador sintáctico el el elemento input del código anterior, crea un HTMLInputElementImpl, y luego a medida que las va leyendo va añadiéndole a éste elemento sus atributos. Esa clase de implementación se encarga de todos los tipos de elemento input: linea de texto, ficheros, botones, elementos ocultos, etc, y en ella es donde se debe añadir la lógica relacionada con el elemento seguro input de tipo linea de texto.

66 7.8. Implementación de Div 55 HTMLInputElementImpl contiene una variable donde almacena el valor (atributo value, variable m_value) actual del elemento. Ahora también contiene otra variable con el valor en texto plano (descifrado del elemento), así como referencias a si elemento está encriptado o firmado y las claves de firmado y cifrado a utilizar. La idea es que la variable m_value siempre contenga el valor inseguro, y m_encryptedvalue el valor seguro. Cuando el elemento no sea de tipo texto o no use nuestra extensión, estas nuevas variables no se usarán. Sin embargo, cuando el texto deba estar por ejemplo cifrado, m_value contendrá el valor en claro, y m_encryptedvalue el valor cifrado. Todas las funciones de HTMLInputElementImpl que acceden a m_value han sido modificadas para que lo hagan mediante la función value(), y la función value devolvería m_encryptedvalue en este caso. Así mismo, cada vez que el usuario modifica el valor del cuadro de texto seguro, m_encryptedvalue es actualizado. La idea es que de ninguna manera de forma externa sea posible acceder al valor en claro, para mantener la seguridad. Los puntos en que se acceden al valor en claro - por ejemplo cuando es actualizado o cuando es pintado en pantalla - están controlados y acotados como medida de seguridad. Existe una función plaintextvalue() que devuelve el texto en claro, que no es usada más que por la clase LineEditWidget que es la que se encarga de pintar el elemento input de tipo texto. En el árbol de renderizado, el homólogo al elemento HTMLInputElementImpl dependiendo del tipo que sea es de una clase u otra. Como acabamos de mencionar, en el caso que nos ocupa la clase encargada es LineEditWidget. El primer paso fue hacer que a la hora de pintar el texto del LineEdit, éste accediese al texto en claro siempre, por tanto llamando a la función plaintextvalue(). No obstante es necesario que el usuario pueda saber reconocer a simple vista que el LineEdit es seguro. Para ese caso se implementaron varias medidas de seguridad en el LineEditWidget cuando está en modo seguro: El color de fondo por defecto no es blanco sino de un color amarillento característico. Ni el color de fondo ni el color del texto se pueden modificar por Javascript ni CSS. Dentro del propio widget se añade el icono de un candado de seguridad, en el que haciendo clic se muestra un popup con información acerca de la seguridad de la clave del destinatario de la imagen. Maximizar su Z-Index para que el widget nunca pueda ser ocultado por otros elementos de la página. En la siguiente figura podemos ver el resultado gráfico de todo ello:

67 56 7. Implementación Figura 7.2: 7.8 Implementación de Div Una vez implementado el elemento input type text, ya era posible conseguir enviar de forma segura datos cifrados mediante GPG a través de khtml. Pero esto era sólo la primera parte de la extensión. También era necesario añadir la posibilidad de mostrar esos mismos datos que habían sido enviados previamente al usuario, de forma igualmente segura y transparente al usuario y al desarrollador. Descifrar el contenido de un DIV resultó bastante más complejo que lo anterior. Esto es debido a que un DIV no es un elemento autocontenido, una hoja del árbol DOM, sino que por el contrario es un contenedor de toda suerte de subelementos. Un DIV de HTML es un nodo más en el árbol DOM, y puede contener texto plano, pero también imágenes, otros DIVs, listas.. cualquier cosa. Esta complejidad de los DIV hace que también se creen cajas anónimas con fines de maquetado. En este caso era más fácil asegurarse que nadie iba a acceder al texto en claro puesto que por defecto la función value() ya devolvía el texto cifrado o firmado. Por otra parte, para simplificar y también como medida de seguridad que se detalla en el capítulo anterior, el elemento DIV en modo cifrado sólo acepta contener un primer subelemento y de tipo texto. Por seguridad si un DIV que contenga texto cifrado si también contiene otros elementos, serán ignorados y no incluídos en el arbol DOM ni en el árbol de renderizado puesto que se genera a partir del árbol DOM. Hay varias razones detrás de esta decisión: El elemento input anterior sólo es capaz de cifrar texto y no otro tipo de elementos como imágenes, ficheros, etc.

68 7.8. Implementación de Div 57 Simplifica en gran medida el renderizado y el descifrado, al no tener que descifrar más que un texto y pintarlo. Para seguir, pongamos un ejemplo de elemento DIV que contenga texto cifrado: <div encryption="gpg"> -----BEGIN PGP MESSAGE----- Version: GnuPG v (GNU/Linux) hmwdn3tuozxddl4bbf97gggilj4zxr+ibq8qmoxugzjlq3wnpm1g562ke8yqff+y zgmsceucjyaftwzv5vc/lghpjf2iuguw4sodnoiozvnxbov2oejivxdjizun29om UMaKxSLMZdrFjS5JlbQsMuqtNLnv7/tDmyZQQdTlWRvVG2GcjmPJsLg2iFjHFT21 vz5voo9jt0zuentdjwwk+v99zyy8xmfloms+asjdvqlyiqqr5gufxheexkbk/tcr lshwcy6dctt/rxkwsfnswggayi309m3eblnb/4n94jqfaj7w7vhehgegbt0/cegs 547rDc+O6cyhqtS2kwRe5bCDaoiPvHHbsgoAxm27eznKNQvrre5cKzaXePmqBWim 3q7+01ha714WsQ== =Xgbn -----END PGP MESSAGE----- </div> El árbol DOM de este DIV sería: HTMLDivElementImpl \ TextImpl De tal manera que el texto cifrado realmente se encuentra en TextImpl. Y como hemos simplificado los elementos DIVs seguros de manera que sólo soporten texto en plano, esa misma será la estructura de todos los DIVs que contengan texto cifrado. El primer paso que realicé es modificar el elemento HTMLDivElementImpl, que como toda clase de implementación se encarga de la lógica del elemento que maneje, para soportar texto cifrado y/o firmado con GPG. Este proceder es el más lógico puesto que las clases de implementación ya las conocía debido a HTMLInputElementImpl,y procedí de forma parecida, modificando la función parseattribute() para que manejase el token ATTR_ENCRYPTION de tipo gpg, añadiendo una variable que indicase si el elemento está en modo seguro. Igualmente, en TextImpl añadí una variable con el texto cifrado, y funciones de acceso y modificación del texto en claro. Teniendo en cuenta que el texto que fue cifrado con nuestra clave pública es Lorem ipsum dolor sit amet, el árbol de renderizado correspondiente al ejemplo del DIV cifrado sería el siguiente: [RenderBlock [RenderText "Lorem ipsum dolor sit amet."] ]

69 58 7. Implementación Para conseguir esto, hubo que indicarle a RenderText que accediese al texto en claro del DIV, y por supuesto acotar que sólo sea ese el caso en que se permitiese acceder al texto en claro de un DIV en khtml: la función plaintextvalue() de TextImpl es protected y RenderText es una clase amiga. No obstante este no es realmente el último árbol que se genera, sino que antes de pintar en pantalla se genera un árbol de cajas por línea. Para comprenderlo, veamos una representación conceptual del resultado de pintar ese texto en pantalla: Lorem ipsum dolor sit amet. Como vemos, suponiendo que la anchura disponible para el DIV fuese limitada y el texto no cupiese una sóla linea, tendría necesariamente que ocupar una más. Debido a cómo funciona HTML y CSS según sus especificaciones y por motivos de maquetación, en khtml cada línea se trata de forma separada. Se genera una árbol más, el árbol de cajas de líneas (LineBox Tree en inglés), que en el caso de antes sería el siguiente: [RootInlineBox [InlineTextBox "Lorem ipsum dolor"] ] [RootInlineBox [InlineTextBox "sit amet."] ] Y eso es lo que finalmente se pinta en pantalla. No obstante a la hora de conseguir que el texto se pinte y correctamente en pantalla y la maquetación se haga con el texto en claro y no con el texto cifrado, basta con que el elemento del árbol de renderizado RenderText contenga el texto en claro, y él ya se encarga de pasárselo a los elementos de tipo InlineText- Box y se realiza con ese mismo texto la maquetación. Es importante hacer notar que estas clases que tienen acceso al texto claro son todas internas de khtml y en ningún caso es posible acceder a ellas externamente desde HTML, CSS o Javascript. Bien, hemos conseguido exitósamente que el texto cifrado se pinte en claro en pantalla, de forma totalmente transparente al usuario. Cuando el texto necesite ser pintado, la función plaintextvalue() de TextImpl será llamada y entonces si aun el texto no ha sido descifrado, lo será, y si es necesario se le pedirá la frase secreta con la que libkleo descifrará la clave privada que necesita para poder descifrar el texto.

70 7.8. Implementación de Div 59 Figura 7.3: Resultado de cómo se visualiza un DIV cifrado mostrando el texto en claro del ejemplo No obstante aun falta por añadir alguna indicación gráfica al usuario que le permita reconocer que el texto ahí mostrado es seguro, ha sido descifrado y sólo él puede acceder al mismo; que ni siquiera el administrador de la página que está mostrando dicho texto puede acceder al texto en claro. También faltan añadir algunas medidas de seguridad. La indicación gráfica que he elegido en este caso es mostrar el texto descifrado (o firmado) siempre dentro de un recuadro con reborde verde, fondo blanco, y texto de color negro. Esta vez en vez de mostrar un icono en el que al pinchar saliese información, se puede acceder a dicha información haciendo clic derecho en cualquier parte del DIV seguro y accediendo a una opción llamada Detalles del mensaje cifrado... que mostrará un diálogo con dichos detalles. El razonamiento detrás de esta decisión se basa en que habría que hacer cambios demasiado extensos para poder añadir un icono de seguridad al DIV cifrado y por otra parte quizás cargase demasiado la página ver un candado de seguridad en todos los elementos descifrados, si por ejemplo se trata de un chat y se han recibido muchos mensajes. Entre las medidas de seguridad están algunas parecidas a las aplicadas anteriormente: el color de fondo, color de letra, y el color de los rebordes de un DIV cifrado no son modificables. Además, el ZIndex también es máximo de manera que el DIV no es ocultable por otros elementos. Un usuario que vea un mensaje cifrado sabrá reconocerlo siempre por las indicaciones gráficas características que le acompañan, y para asegurarse de que el DIV no es una imitación siempre puede ver si se encuentra en el menú contextual del DIV la entrada Detalles del mensaje cifrado... y ver ahí el mensaje original, y los detalles del receptor o de quien firmó el mensaje. Se muestran algunas capturas de pantalla de las mencionadas características:

71 60 7. Implementación Figura 7.4: Menú contextual de un DIV cifrado mostrando la opción Details of Encrypted Message..

72 7.8. Implementación de Div 61 Figura 7.5: Diálogo mostrando los detalles de un mensaje contenido en un DIV cifrado

73

74 CAPÍTULO 8 Pruebas y conclusiones 8.1 Pruebas Aplicación de ejemplo 1: chat web cifrado La extensión de HTML que se ha desarrollado tiene como finalidad ser usada en aplicaciones web. Por ello, se ha desarrollado una aplicación de ejemplo que demuestra su uso y a la par sirve como aplicación con la que realizar las pruebas. La primera aplicación de ejemplo que comencé a desarrollar se trataba de un chat web con la tecnología django con python, basándome en una aplicación llamada django-chat ya existente. Se puede a continuación ver el resultado de ese pequeño desarrollo. No obstante debido a que el código de django-chat dejaba bastante que desear y también a que surgió una idea más prometedora, opté por finalmente seguir otro camino. Como podemos ver en la imagen 8.1, en la zona de la izquierda se muestra la aplicación de chat tal como se ve en KHTML con la extensión de HTML desarrollada. Los mensajes se envían cifrados, y la lista de mensajes remarca en un recuadro verde los mensajes cifrados recibidos. Haciendo clic derecho en dichos mensajes eligiendo la opción del menú contextual llamada Ver detalles del mensaje cifrado... se puede comprobar que efectivamente es un mensaje cifrado. Cuando un de claves pública y privada tiene su clave privada cifrada por una frase de paso, durante el renderizado si libkleo no ha cacheado previamente la frase de paso, el diálogo 8.2 que pregunta al usuario por su clave privada es mostrado. Una vez se muestra ese diálogo, la frase de paso no se vuelve a mostrar durante un tiempo debido a que libkleo, la librería que utilizamos para cifrar y descifrar, la cachea en memoria. Esto permite descifrar varios mensajes cifrados seguidos sin interrumpir repetidamente al usuario. 63

75 64 8. Pruebas y conclusiones Figura 8.1: Chat cifrado con khtml en el navegador web Konqueror, y el mismo chat motrado en Firefox Figura 8.2: Diálogo pidiendo al usuario su frase de paso

76 8.1. Pruebas 65 Figura 8.3: Sweetter enviando un mensaje privado cifrado. También se observa el enlace para enviar mensajes privados al usuario cuyo perfil se está observando en la barra de cabecera y en la barra lateral, así como la imagen con forma de escudo verde que aparece en todos los sweets que sirve para responder al sweet con un mensaje privado Aplicación de ejemplo 2: Plugin de mensajes privados en Sweetter Sweetter es una aplicación web de microblogging, de hecho probablemente la primera aplicación web software libre de esas características. Fue ideada en un principio por Daniel García Moreno y por el autor de este proyecto, en una primera versión. Su versión 3.0 comenzó su desarrollo como proyecto de fin de carrera de Luis Manuel García Conde y Christian López Espínola, proyecto realizado en este mismo departamento de la Universidad de Sevilla, y su desarrollo continúa. Sweetter 3.0 tiene una arquitectura extensible basada en plugins que pueden engancharse én varios puntos de extensión. La idea que surgió fue desarrollar un plugin de sweetter que permitiese enviarse mensajes privados cifrados entre los usuarios. Para hacerlo, se ha añadido en la barra lateral (sidebar) un enlace para que el usuario pueda enviar mensajes privados al usuario que actualmente esté siendo mostrado en dicho sidebar. Además, si el usuario está viendo el

77 66 8. Pruebas y conclusiones Figura 8.4: Un usuario viendo su lista de mensajes privados recibidos ( Private timeline ), y comprobando que un mensaje está cifrado con el menú contextual. Uno de los mensajes privados recibidos no tiene recuadro verde indicando que no está cifrado, debido a que fue enviado mediante Firefox. perfil de otro usuario, podrá acceder también a dicho enlace en la headbar ó barra de cabecera. En la lista de enlaces superior donde salen las vistas/acciones principales de sweetter, se añadió la vista Private timeline donde cada usuario puede acceder a sus mensajes privados, que salen en forma de una lista mensajes parecidos a una lista de sweets corriente. Todos los puntos mencionados son puntos de extensión realizados en forma de funciones en el plugin que denominé private timeline plugin. De hecho tuve que añadir un punto de extensión que antes no existía, el de la barra de enlaces, para poder añadir el enlace a la Private timeline ó lista de mensajes. Otro punto de extensión en el que se engancha él plugin de mensajes privados es el de opciones, donde cada usuario puede configurar la clave privada con la que el resto puede enviarle mensajes cifrados. Y otro más aun, es el de un reply privado, respondiendo a un sweet (mensaje) concreto de un usuario mediante un mensaje privado. La arquitectura de Sweetter es bastante flexible y ha permitido que el plugin desarrollado se meta en todos los recovecos de sweetter y se fusione de manera que ahora parece una funcionalidad persistente en todo el flujo de trabajo del usuario. Desarrollar un plugin para sweetter además ha sido bastante agradable y sencillo de hacer debido a que está basado en Django y Python, herramientas de desarrollo web bastante potentes. La extensión desarrollada ya está en visos de entrar en la web oficial

78 8.2. Conclusiones 67 de sweetter, y Daniel García Moreno, mantenedor actual y principal desarrollador, ya ha realizado algunos parches, debido a que el desarrollo se ha realizado mediante un modelo abierto en un repositorio Git. El plugin además permite igualmente enviar y recibir mensajes privados aunque no estén cifrados si se hace desde otro navegador o si no se configura la clave privada del usuario que va a recibir el mensaje, como puede verse en 8.4. Los mensajes se envían mediante peticiones AJAX, se accede por Javascript al contenido del cuadro de texto seguro, el cual devuelve no el texto en claro sino el texto cifrado. Además cada vez que se escribe un mensaje nuevo hay que borrar el contenido del cuadro de texto, y cada vez que se escribe un mensaje a un destinatario distinto hay que cambiar la clave con la que se cifra el texto en claro. Nuestra extensión no permite realizar dichas acciones sobre un cuadro de entrada texto (input type=text) seguro porque ello comprometería la privacidad del mensaje, por lo que el cuadro de texto es eliminado y se crea uno nuevo mediante Javascript en esos casos. 8.2 Conclusiones Finalmente y como colofón a esta memoria, describiremos en este apartado las distintas conclusiones que hemos obtenido durante la elaboración de este proyecto. Debemos recordar que en dicho proyecto el autor ha desarrollado una extensión de HTML que añade soporte de seguridad end to end directamente al navegador web con el fin de demostrar el peligro del Server in the middle y de mejorar mejorar la seguridad de las aplicaciones web para que puedan ser tan seguras como las aplicaciones análogas de escritorio. Además, se ha desarrollado un plugin para la aplicación web Sweetter que muestra el uso potencial que puede tener dicha extensión. Abordar un proyecto existente de la envergadura de khtml no es sencillo. No obstante el desarrollo de la extensión ha sido exitoso, consiguiendo en efecto desarrollar el plugin propuesto, y cumpliendo con los requisitos seguridad del texto cifrado. Uno de los principales objetivos de realizar esta extensión es conseguir simplificar al máximo el uso y aplicación de la seguridad punto a punto en páginas web. A parte de añadir unos pocos atributos HTML y añadir una opción en la configuración del usuario para que indique su clave pública, la extensión de mensajes privados para sweetter no ha requerido ningún otro un esfuerzo adicional para que incluyese soporte de cifrado punto a punto. Además, el mismo plugin puede usarse tal cual en navegadores web que no soporten la extensión sin tener que hacer ninguna modificación de la misma, por lo que es cien por cien reutilizable en ese aspecto. Este último punto es importante porque permite una migración gradual y sin problemas por parte de usuarios con navegadores que no soporten la extensión. El autor considera importante recalcar la visión global

79 68 8. Pruebas y conclusiones de la extensión que se describe en la presente memoria. En el mundo de la informática como en muchos otros, cuando surge una nueva idea como es en nuestro caso el aplicar la seguridad punto a punto directamente desde el navegador, luego es fácil ver que en realidad es el siguiente paso lógico a dar en la evolución de dicha tecnología, y que tarde o temprano iba a realizarse. Pero es necesario dar el paso para descubrir realmente si se erra en dicho análisis o no. Por supuesto, la extensión desarrollada sólo es un pequeño paso. Tiene sus limitaciones, que fueron reflejadas en capítulos anteriores, pero sirve como prueba de concepto sólida, basada en el código de una librería de renderizado potente como es KHTML, y demostrando su potencial mediante una la aplicación web de calibre como es Sweetter. El futuro? El futuro del cifrado punto a punto en el navegador web puede que siga por los caminos expuestos en la primera solución propuesta en el capítulo de Soluciones propuestas, solución en la que se creaba una jaula, un entorno controlado donde es posible acceder y manipular los contenidos seguros para poder crear aplicaciones más ricas y versátiles. Es una apuesta más arriesgada que la que el autor hizo en el presente proyecto, pero también una apuesta con un potencial si cabe más prometedor. Un factor muy importante para conseguir la concienciación de los internautas ante el problema del Server in the middle y de su solución mediante el cifrado punto a punto pasa por la estandarización de jure de las extensiones que se desarrollen, en el W3C, y de uso de métodos de cifrado y descifrado conocidos y estándares.

80 CAPÍTULO 9 Análisis temporal y costes de desarrollo 9.1 Análisis temporal En los apartados anteriores se ha descrito fielmente todo el proceso que ha dado como resultado la implementación de la extensión de HTML. Una vez cubierta la descripción del proceso, pasaremos a tratar en detalle la planificación seguida para la realización de este proyecto, así como un desglose de las labores más importantes. Dicha tarea la desarrollaremos a lo largo del capítulo que nos ocupa. Para comenzar con el análisis temporal, hemos de distinguir todas las etapas que nos han ocupado durante la elaboración de este proyecto. Un desglose de estas etapas sería: Aprendizaje y documentación sobre KHTML El autor del proyecto tenía buen conocimiento de las tecnologías que se usan en KDE como son C++, Qt, parte de kdelibs o CMake. No obstante desconocía por completo el código de khtml y su funcionamiento interno, y tampoco conocía la librería libkleo que sirve de interfaz para todos los asuntos relacionados con GPG. Lo primero que tuvo que hacer es estudiar el código de khtml para conocer la viabilidad del proyecto y cómo abordarlo, así como buscar una librería que sirviese para manejar GPG y aprender a usarla. Creación de kleocypher Tras decir que iba a usar libkleo, me dediqué primero a conocer esta herramienta de ejemplo que hace uso de ella y establecer cómo iba a detectar con CMake la disponibilidad de la librería. Implementación del elemento input cifrado Este fue el primer gran paso a la hora de implementar la extensión de HTML. Fue bastante 69

81 70 9. Análisis temporal y costes de desarrollo costoso temporalmente hablando porque fue mi primera contribución al código de khtml y no tenía soltura con él, pero el resultado fue satisfactorio. Implementación del elemento div cifrado Después de unos meses habiendo dejado el proyecto de lado por motivos laborales, lo retomé para implementar lo que quedaba de la extensión html, que es el elemento div cifrado. Debido al tiempo que había pasado, tuve que volver a ponerme al día además de aprender más sobre khtml por la dificultad añadida que entrañaba la implementación del elemento div. Aplicación de prueba y testeo de la extensión El fin del proyecto es en gran medida demostrar que la extensión propuesta es válida y puede ser útil, y la mejor manera de demostrarlo fue creando una aplicación web, en concreto un chat basado en django, que lo utilizase. Además esta aplicación sirvió como banco de pruebas de la extensión. Elaboración de los capítulos de la memoria Durante esta fase hemos realizado la redacción de los capítulos que conforman la memoria de este proyecto. La planificación temporal consistirá en una estimación del tiempo dedicado a cada una de las fasesde desarrollo del proyecto. Para ello asignaremos a cada una de esas fases las dos estimaciones siguientes: Estimación Inicial la cual es empleada en los inicios del desarrollo. Suele ser poco exacta, pero se usan como primera aproximación para la viabilidad del proyecto. Estimación Final la cual expresa la duración y el esfuerzo real empleado. Para realizar una evaluación de la exactitud de la estimación se realiza una comparación de los valores reales con los valores estimados, teniendo en cuenta el error relativo medio. Tomando RE = A E A, donde A representa el valor real y E el valor estimado previamente, calculamos el error relativo medio mediante la expresión: ( ) n 1 RE n i=1 Las estimaciones de cada fase se han realizado en días, considerando una dedicación del autor de una media de 4 horas al día. Dicho esto obtendríamos las estimaciones mostradas en la Tabla 9.1. Analizando los datos de la misma obtenemos un error relativo medio de %.

82 9.2. Costes de desarrollo 71 Tarea Est. Inicial Est. Final RE Aprendizaje y documentación sobre KHTML 25 días 36 días 30.5 % Creación de kleocypher 18 días 19 días 5.3 % Implementación del elemento input cifrado 22 días 32 días 30.1 % Implementación del elemento div cifrado 31 días 42 días 30.9 % Aplicación de prueba y testeo de la extensión 12 días 14 días 14.3 % Elaboración capítulos memoria 8 días 10 días 20 % Elaboración de los capítulos de la memoria 5 días 5 días 0 % Cuadro 9.1: Planificación del proyecto 9.2 Costes de desarrollo En esta sección estudiaremos detalladamente los costes que han supuesto la creación del proyecto. Comenzaremos diciendo que no ha sido necesaria inversión alguna destinada a la adquisición de dispositivos específicos, hardware o software. Este hecho ha supuesto una gran ventaja a la hora de elaborar el proyecto que nos ocupa, ya que los costes se centrarán unicamente en los campos de costes de personal y costes indirectos Inversiones En lo que respecta a la inversión para la adquisición de dispositivos específicos, tenemos que decir que en nuestro caso dicha inversión ha sido nula. Esto se debe a que no requeriamos de ningún material específico para materializar en khtml Costes de software En lo que respecta los costes de software usado para el desarrollo del proyecto, he de indicar primeramente que todo el software empleado es free software (software libre) disponible en Internet de forma gratuita. Esto supone un coste cero en lo que respecta a este apartado. Además del coste cero, el sofware libre también nos proporciona muchas otras ventajas. Este tipo de software brinda libertad a los usuarios sobre su producto adquirido y por tanto, una vez obtenido, puede ser usado, copiado, estudiado, modificado y redistribuido libremente. Según la Free Software Foundation, el software libre se refiere a la libertad de los usuarios para ejecutar, copiar, distribuir, estudiar, cambiar y mejorar el software; de modo más preciso, se refiere a cuatro libertades de los usuarios del software: la libertad de usar el programa, con cualquier propósito; de estudiar el funcionamiento del programa, y adaptarlo a las necesidades; de distribuir copias, con lo que puede ayudar a otros; de mejorar el programa y hacer públicas las mejoras, de modo que toda la comunidad se beneficie. El software libre suele estar disponible gratuitamente, o al

83 72 9. Análisis temporal y costes de desarrollo precio de coste de la distribución a través de otros medios; sin embargo no es obligatorio que sea así, por ende no hay que asociar la idea de software libre a software gratuito. Entre el software usado podemos citar entre otros: Arch Linux, como distribución Linux. KDE, como sistema base sobre el cual se ha desarrollado. Kdevelop, entorno de desarrollo utilizado. CMake, como sistema de compilación. Kile, como editor L A TEX sobre Linux. GDB, como depurador de software. Okular como visor de documentos PDF Costes de hardware En el proceso de desarollo no ha sido necesaria la adquisición de equipos informáticos ni de ninguna clase de hardware que no tuviese ya disponible. El hardware utilizado es el portátil personal del autor Costes indirectos Dentro de esta sección dedicada a los costes indirectos incluiremos el gasto producido por material consumible (CD, impresora, papel, etc), luz consumida, limpieza de la zona de desarrollo, etc. He considerado adecuado que un incremento del 5 % en el presupuesto total sería representativo de este gasto Costes de personal Para calcular el coste personal he utilizado como referencia los sueldos brutos estipulados mínimos fijados en el BOE del 21 de Marzo de 2010, en el Anexo III. El sueldo anual para un Titulado de grado medio es de euros ó 6.53 euros hora. También es necesario tener en cuenta el número total de horas dedicadas a la elaboración de este proyecto. Dicho dato tiene un valor de 672 horas, representado por el trabajo realizado por una persona durante 168 días dedicando una media de 4 horas/día. De esta forma el coste personal supondrá una cuantía de: 672horas 6,53 euros hora = 4388,16euros.

84 9.2. Costes de desarrollo 73 Inversiones Costes Software Costes Hardware Costes Personal Costes Indirectos TOTAL 0 euros 0 euros 0 euros euros euros euros Cuadro 9.2: Presupuesto del proyecto Presupuesto Haciendo uso de los costes especificados anteriormente, obtendremos el presupuesto mostrado en la Tabla 9.2.

85

86 CAPÍTULO 10 Manual 10.1 Manual de usuario Esta es la documentación del proyecto que implementa una extensión HTML de cifrado punto a punto para el motor de renderizado KHTML de KDE. Este capítulo está destinado para que aprendas cómo utilizar la extensión y poder crear tu propia aplicación web con ella. Para poder hacer uso de esta extensión es necesario parchear la librería khtml. Explicamos en la siguiente sección cómo realizar este importante paso Introducción La extensión está desarrollada sobre la versión de desarrollo de la librería khtml puesto que si se hiciese sobre la versión estable sería más difícil continuar su desarrollo al entrar en conflicto el parche con las novedades incluídas en próximas versiones. Concretamente la revisión de KDE con la que es funcional el parche es la Como requisito indispensable para poder hacer uso de la extensión actualmente se encuentra compilar la versión de desarrollo de KDE y luego parchear kdelibs. Se explicará cómo compilar y configurar el entorno de desarrollo de KDE para la distribución Arch Linux. Es posible por supuesto configurar KDE para que pueda ser usado en otras distribuciones y los pasos necesarios para hacerlo se detallan en el wiki para desarrolladores de KDE, techbase [1]. He de aclarar que esta no es la única forma de compilar KDE. También es posible hacer uso de por ejemplo el script kdesvn-build que facilita mantenerse actualizado a la última versión, y también es posible utilizar una cuenta a parte para el desarrollo de KDE. Todas esas posibilidades se explican en techbase [1]. 75

87 Manual 10.3 Instalar paquetes requeridos Para instalar las dependencias necesarias para compilar KDE en Arch Linux, hay que ejecutar el siguiente comando con permisos de superusuario: pacman -Sy subversion bzip2 libxslt libxml2 libjpeg \ libungif shared-mime-info mesa boost dbus \ openssl pkgconfig xine-lib clucene redland \ gpgme hal cmake qt qca libical lcms \ automoc4 akonadi eigen taglib soprano \ strigi qimageblitz phonon kdesdk git Es necesario tener activado el repositorio [extra] para poder instalar dichas dependencias, entre las que incluyen las librerías incluidas en kdesupport. También he incluido git como dependencia porque lo necesitaremos para descargar el código del presente proyecto Configuración del entorno Configuraremos el sistema para que convivan tanto la posible instalación de KDE estable como la versión trunk ó de desarrollo. Asumiremos que todo lo relativo a la versión de desarrollo de KDE lo albergaremos en el directorio proyectos/kde4. Crearemos un script en bash llamado environment.sh én ese directorio, con permisos de ejecución, y que contenga las siguientes líneas: export KDEDIR=$HOME/proyectos/kde4 export KDETMP=/tmp/$USER-kde4 mkdir -p $KDETMP export KDEVARTMP=/var/tmp/$USER-kde4 export KDEDIRS=$KDEDIR export PKG_CONFIG_PATH=$KDEDIR/lib/pkgconfig:$PKG_CONFIG_PATH export KDEDIRS=$KDEDIR export PATH=$QTDIR/bin:$KDEDIR/bin:$PATH export YACC= byacc -d export LD_LIBRARY_PATH=$QTDIR/lib/:$KDEDIR/lib/:$LD_LIBRARY_PATH export CMAKE_LIBRARY_PATH=$KDEDIR/lib/:$CMAKE_LIBRARY_PATH export CMAKE_INCLUDE_PATH=$KDEDIR/include:$CMAKE_INCLUDE_PATH export CMAKE_PREFIX_PATH=$KDEDIR:$CMAKE_PREFIX_PATH export KDE_BUILD=$KDEDIR/src/build/ export KDE_SRC=$KDEDIR/src/

88 10.4. Configuración del entorno 77 export KDEHOME=$HOME/.kde-trunk export KDE_COLOR_DEBUG=1 export QTEST_COLORED=1 ## # A function to easily build the current directory of KDE. # # This builds only the sources in the current ~/{src,build}/kde subdirectory. # Usage: cs KDE/kdebase && cmakekde # will build/rebuild the sources in ~/src/kde/kdebase # function cmakekde { if test -n "$1"; then # srcfolder is defined via command line argument srcfolder=$1 else # get srcfolder for current dir srcfolder= pwd sed -e s,$kde_build,$kde_src, fi # we are in the src folder, change to build directory # Alternatively, we could just use makeobj in the commands below... if [ "$srcfolder" = pwd ]; then cb fi # to enable tests, add -DKDE4_BUILD_TESTS=TRUE to the next line. # you can also change "debugfull" to "debug" to save disk space. # added "nice make..." to allow the user to work on the box while # compiling nice -n 15 cmake $srcfolder -DKDE4_BUILD_TESTS=TRUE -DCMAKE_INSTALL_PREFIX=$KDED -DPYTHON_SITE_PACKAGES_DIR:PATH=~/.local/lib/python2.6/site-packages \ -DCMAKE_BUILD_TYPE=debugfull && \ make -j2 VERBOSE=1 && \ make install; } ## # A function to easily change to the build directory. # Usage: cb KDE/kdebase # will change to $KDE_BUILD/KDE/kdebase # Usage: cb # will simply go to the build folder if you are currently in a src folder # Example:

89 Manual # $ pwd # /home/user/src/kde/kdebase # $ cb && pwd # /home/user/build/kde/kdebase # function cb { # Make sure build directory exists. mkdir -p $KDE_BUILD } # command line argument if test -n "$1"; then cd $KDE_BUILD/$1 return fi # substitute src dir with build dir dest= pwd sed -e s,$kde_src,$kde_build, if test! -d $dest; then # build directory does not exist, create mkdir -p $dest fi cd $dest ## # Change to the source directory. Same as cb, except this # switches to $KDE_SRC instead of $KDE_BUILD. # Usage: cs KDE/kdebase # will change to $KDE_SRC/KDE/kdebase # Usage: cs # will simply go to the source folder if you are currently in a build folder # Example: # $ pwd # /home/user/build/kde/kdebase # $ cs && pwd # /home/user/src/kde/kdebase # function cs { # Make sure source directory exists. mkdir -p $KDE_SRC # command line argument if test -n "$1"; then cd $KDE_SRC/$1 else

90 10.5. Compilación de KDE 79 } fi # substitute build dir with src dir dest= pwd sed -e s,$kde_build,$kde_src, if [ $dest = pwd ]; then cd $KDE_SRC else cd $dest fi export DISPLAY=: Compilación de KDE Ahora pasaremos a compilar todo el sistema base KDE que usaremos. Pese a que por si acaso las instalamos anteriormente, para asegurarnos que las librerías incluidas en el paquete kdesupport están suficientemente actualizadas también las compilaremos. Los comandos que debemos ejecutar en la consola con nuestro usuario son los siguientes: cd ~/proyectos/kde4. environment.sh # carga las variables de entorno y funciones útiles usadas para compila cs # entra en el directorio ~/proyectos/kde4/src y lo crea si no existiese. # Ahora descargaremos el software que usaremos de KDE: svn checkout svn://anonsvn.kde.org/home/kde/trunk/kde/kdesupport svn checkout svn://anonsvn.kde.org/home/kde/trunk/kde/kdelibs svn checkout svn://anonsvn.kde.org/home/kde/trunk/kde/kdebase svn checkout svn://anonsvn.kde.org/home/kde/trunk/kde/kdepimlibs svn checkout svn://anonsvn.kde.org/home/kde/trunk/kde/kdepim # y ahora lo compilaremos e instalaremos: cd kdesupport; cmakekde; cd.. cd kdelibs; cmakekde; cd.. cd kdebase; cmakekde; cd.. cd kdepimlibs; cmakekde; cd.. cd kdepim; cmakekde; cd.. Ya tenemos todo lo necesario de KDE compilado. Hemos compilado e instalado khtml y una navegador que lo utiliza, konqueror. Podemos comprobar que eso es así ejecutando el comando which konqueror, que debería de devolver algo así: $ which konqueror /home/edulix/proyectos/kde4/bin/konqueror

91 Manual 10.6 Compilación del proyecto Ahora proseguiremos aplicando el parche a khtml y recompilando khtml con el parche: git clone # descargamos el código del presente cd kdepim/libkleo patch -p0 <../../pfc/find_kleo.patch # parcheamos libkleo make install # recompilamos y reinstalamos libkleo cd../../kdelibs/khtml patch -p0 <../../pfc/khtml.patch # parcheamos khtml make install # recompilamos y reinstalamos khtml Ha resultado necesario recompilar antes libkleo para que pueda accederse a dicha librería externamente, en nuestro caso desde khtml. Luego hemos recompilado y reinstalado khtml con el parche que implementa el presente proyecto aplicado. Y con esto ya hemos terminado: tenemos un sistema funcional en el que podemos utilizar la nueva extensión HTML descrita en esta memoria en aplicaciones web seguras. El navegador que utilizaremos para usar la extensión de khtml es Konqueror. De aquí en adelante siempre que vayamos a ejecutar konqueror, previamente arrancaremos un terminal y configuraremos el entorno si no lo hemos hecho antes en ese terminal. Ejemplo: $. ~/proyectos/kde4/environment.sh $ which konqueror # comprobamos que el binario konqueror es el correcto /home/edulix/proyectos/kde4/bin/konqueror $ konqueror El mismo comando (. ~/proyectos/kde4/environment.sh) nos servirá para poder ejecutar cualquier aplicación de KDE que hayamos compilado, como por ejemplo kleopatra Creación de claves GPG Evidentemente necesaremos tener un par de claves pública y privada para poder utilizar la extensión. Podemos usar la aplicación kleopatra para este fin. Adjuntamos una captura de pantalla del diálogo con los pasos a seguir para crear una nueva clave GPG con dicha aplicación. El primer paso es abrir la aplicación Kleopatra y luego pulsar Ctrl+N para abrir el diálogo de crear un nuevo certificado Elegit la opción OpenPGP, escribir nuestro nombre e , pulsar siguiente, y crear nuestra clave.

92 10.8. Aplicación de prueba: Sweetter 81 Figura 10.1: Diálogo para crear una nueva clave

93 Manual 10.8 Aplicación de prueba: Sweetter La aplicación de prueba que finalmente desarrollamos fue un plugin para el software de microblogging Sweetter. Para instalar sweetter necesitamos instalar primero sus dependencias: sudo pacman -S django python-pysqlite Para descargarnos la última versión de django del repositorio de gitorious donde se alberga, ejecutamos el siguiente comando en el directorio donde vayamos a descargarlo: git clone git://gitorious.org/sweetter/sweetter.git Esto nos creará un directorio sweetter/ donde se descargó la aplicación. Ahora vamos a instalarlo. Al crear la base de datos nos pedirá cierta información como si queremos crear un usuario, le diremos que sí, y daremos los datos del usuario que queramos crear. Esto lo haremos ejecutando el comando python manage.py syncdb: $ python manage.py syncdb Creating table auth_permission Creating table auth_group Creating table auth_user Creating table auth_message Creating table django_admin_log Creating table django_content_type Creating table django_session Creating table django_site Creating table django_flatpage Creating table ublogging_profile Creating table ublogging_option Creating table ublogging_post Creating table groups_group Creating table recoverpw_recover Creating table karma_karma Creating table karma_karmasweet Creating table karma_vote Creating table karma_log Creating table followers_follower Creating table privatetimeline_privatesweet Creating table jabberbot_jabber You just installed Django s auth system, which means you don t have any superuse Would you like to create one now? (yes/no): yes

94 10.8. Aplicación de prueba: Sweetter 83 Username (Leave blank to use edulix ): edulix address: Password: Password (again): Superuser created successfully. Installing index for auth.permission model Installing index for auth.message model Installing index for admin.logentry model Installing index for flatpages.flatpage model Installing index for ublogging.option model Installing index for ublogging.post model Installing index for karma.karmasweet model Installing index for karma.vote model Installing index for karma.log model Installing index for followers.follower model Installing index for privatetimeline.privatesweet model Installing index for jabberbot.jabber model Ya tenemos Sweetter instalado. Ahora podemos ejecutarlo, de la siguiente manera: $ python manage.py runserver Validating models... 0 errors found Django version 1.1.1, using settings sweetter.settings Development server is running at Quit the server with CONTROL-C. Como podemos observar, ya tenemos el servidor sweetter ejecutándose. Si entramos en el navegador en veremos la página de inicio de sweetter, y nos permite autenticarnos. Para ello usaremos el usuario y contraseña que elegimos anteriormente. Haciendo clic en la barra de urls superior en Profile podemos configurar cual es el identificador de nuestra clave GPG, que utilizaremos para recibir mensajes privados cifrados. Lamentablemente kleopatra no nos muestra para las claves GPG su identificador corto, pero verlo ejecutando el siguiente comando: $ gpg --list-keys pub 1024D/7198F [expires: ] uid Eduardo Robles Elvira <edulix@gmail.com> sub 1024g/0F8F7B8D

95 Manual Figura 10.2: Configurando la clave privada del usuario desde su perfil En nuestro caso el identificar sería 7198F146. Lo introducimos en la página de Profile de sweetter en el campo correspondiente, como vemos en la figura Ahora podemos ya recibir mensajes cifrados. No hace falta crear otro usuario para que nos envíe un mensaje privado, porque podemos enviarnos un mensaje privado a nosotros mismos. Podemos por ejemplo hacer clic en la barra lateral donde pone Send private message, y el recuadro donde se suele escribir el sweet se convierte en un recuadro donde podemos escribir el mensaje que nos queremos enviar. Luego, podemos ver el mensaje cifrado haciendo clic en la barra de urls superior en la opción Private timeline. El resultado puede verse en Para poder enviar un mensaje cifrado a cualquier otro usuario, debemos de tener su clave pública instalada en el sistema. Desde Kleopatra podemos importar claves públicas desde el menu File, tanto desde un fichero como desde un servidor, únicamente es necesario conocer algún dato como el nombre y apellidos o la dirección de correo electrónico de aquella persona cuya clave querramos obtener.

96 10.8. Aplicación de prueba: Sweetter 85 Figura 10.3: El mensaje cifrado que previamente nos habíamos enviado aparece en el Private timeline