Cust-OTEA: Marcado de documentos de forma segura

Facultad de Inform´atica Trabajo de Fin de Grado Cust-OTEA: Marcado de documentos de forma segura Por Samuel Antonio Eugercios Nevado Dirigido por Jos´e Luis V´azquez Poletti David Pacios Izquierdo MADRID, 2022–2023 ii Abstract This work aims to protect PDF documentation under secure and invisible watermarks, to prevent its theft and fraudulent use by websites illegally. In order to do such a thing, it has been used Python 3.8 to create the watermark and create the key-value from the author. On the other hand, L A T EX has been used to develop the document and this document itself. In addition, it has been compared the time to process 1000 documents in a local computer with cloud computing and serverless. It has been checked that the serverless architecture process faster the documents than the other two. Because of that, it has been created a distributed architecture to process the documents. As a future work, the application will be conected with the Moodle. Keywords: Lambda, serverless, pdf, fraudulent, watermarks and cloud computing. iii iv Resumen Este trabajo pretende proteger la documentaci´on PDF bajo marcas de agua seguras e invisibles, para evitar su robo y uso fraudulento por parte de sitios web de forma ilegal. Para ello, se ha utilizado Python 3.8 para crear la marca de agua y crear la clave-valor del autor. Por otro lado, se ha utilizado L A T EX para desarrollar el documento y este mismo. Adem´as, se ha comparado el tiempo de procesado de 1000 documentos en un ordenador local frente cloud computing y serverless. Se ha comprobado que la arquitectura serverless procesa m´as r´apido los documentos que las otras dos. Por ello, se ha creado una arquitectura distribuida para procesar los documentos. Como trabajo futuro, la aplicaci´on se conectar´a con Moodle. Palabras Clave: Lambda, serverless, pdf, fraudulento, marcas de agua y cloud computing.. v vi ´ Indice general Abstract ............................................................ V Cap´ıtulo 1 Introduction .......................................... 1 Cap´ıtulo 1 Introducci´on .......................................... 1 Cap´ıtulo 2 Estado del Arte ....................................... 3 Cap´ıtulo 3 Tecnolog´ıas ........................................... 15 Cap´ıtulo 4 Dise˜no de soluci´on .................................... 19 Cap´ıtulo 5 Arquitectura e implementaci´on ......................... 25 Cap´ıtulo 6 Mediciones y resultados ............................... 29 Cap´ıtulo 7 Conclusiones y trabajo a futuro ........................ 31 Cap´ıtulo 7 Conclusions and future work ........................... 33 Bibliograf´ıa ......................................................... 36 vii viii Chapter 1. Introduction 1.1. Motivation Many times we think that the world is a fair and nice place, that everyone will respect what has taken you so much time and effort, whether it is to create a document, a piece of writing or a thesis. Until one day you see all that work fraudulently has been stolen by another person or company, to use it for their own benefit and eliminating any trace of the original author, claiming for themself the authorship. Unfortunately, it happens more often than we think and in many areas of society, from the student who copies the homework done years before by another classmate, to the company that steals documentation and uploads it on their websites for financial gain, without the author being aware of it or being credited with the recognition of authorship. With the growing technology of document editing and the dozens of programs that serve this purpose, it is logical to seek methods of securing the documentation created. And that the authorship cannot be removed in the event that it is obtained by third parties for possible malicious use. We are able to create tools and technologies that can be used to protect our work. Researching and developing an efficient, free and free means of protection. The main problem is the normalization of documentation theft, due to the free access to information at any time and place thanks to the Internet. Causing an endless trickle of document theft, for its fraudulent use or illegal sale without having to face the consequences, being the author who has the obligation to prove that he/she is the owner before the courts. In conclusion, the rise of this type of theft is an extremely serious and widespread problem, rooted in all levels of society. Every year millions of economic losses are generated to companies, institutions and individuals, with a gradual growth of websites selling fraudulently acquired documentation. The most common cases are digital books and academic notes that are distributed and sold without the corresponding legal permissions. 1 6 Figura 2.5: Esquema de inserci´on de la marca de agua para la generaci´on de un patr´on de difracci´on. En el procedimiento para crear una abertura como una rejilla de difracci´on se han utilizado dos t´ecnicas, una usando un modelo abertura matem´atico y haciendo su propagaci´on sobre ella misma. El otro es el c´odigo QR cifrado, que es generado tras la inserci´on de la informaci´on cifrada con el algoritmo DES, una imagen en blanco y negro en un mapa de bits de 256 colores. 7 Figura 2.6: Sistema de la difracci´on de las aberturas para las Marcas de Agua 2.1.6. Ley 3/2014, de 27 de marzo El d´ıa 27 de marzo del 2014 entr´o en vigor la modificaci´on de Ley de protecci´on del consumidor de contenidos digitales[6], donde se reforma una ley anticuada y de poca validez. Con esta modificaci´on se pretend´ıa proteger tanto a consumidores como a suministradores de contenido digital, donde especificaba con claridad la responsabilidad de ambos en los servicios demandados y adquiridos, adem´as de sus responsabilidades dentro del marco de la protecci´on de derechos de autor. 2.1.7. Sistemas DRM Los sistemas DRM(Digital Rights Management [7], es decir, sistema de gesti´on de derechos digitales) sirven para encriptar y distribuir la informaci´on a solo aquellos usuarios autorizados por el due˜no de la misma, permiti´endoles su acceso. 8 Compa˜n´ıa Producto Adobe/Gassbook Adobe ebook reader Alchemedia Clever Content Aries Systems Docurights PDF Store Content Guard XrML Copyright C.C. Rightslink Republicacion lic. Digital World Ser. Secure online del. Digital Goods Softlock Digital Owl KineticEdge lntertrust Metatrust Utility MediaDNA Eliminator Microsoft MS Reader/DAS NctLibrary Ebooks Reciprocal Digital Clearing Ser. SealedMedia Softseal Vyou.com Vyoufirst DOI Digital object Identifier OEB Open eBook Forum OPIMA Open platform initiative XrML Extensible Rights Markup Language Esto conlleva a la restricci´on de la libre circulaci´on de informaci´on y ya que el sistema esta dise˜nado en post al beneficio econ´omico de las grandes empresas, escud´andose en los derechos de autor y provocando en ´ultima instancia un perjuicio para el consumidor. 2.1.8. Reconocimiento de marcas de agua embotellada Este fue un proyecto de fin de master realizado en UPC(Universidad Polit´ecnica de Catalu˜na)[8] en el a˜no 2018, donde se utiliz´o una Red Neuronal Convolucional (Convolutional Neural Network), y se comprob´o si era factible la creaci´on de un sistema de reconocimiento de im´agenes en las que aparece una marca de agua embebida. Debido a que las redes neuronales aprenden tras iteraciones, le es posible al sistema tras varias rondas de prueba y error, aprender a reconocer las etiquetas en las im´agenes que hacen referencia a la marca de agua embebida que tienen inscrita. 9 Figura 2.7: Funcionamiento de una red neuronal 2.1.9. Desarrollo de aplicaciones Serverless en entornos distribuidos En 2021 en la UNPL(Universidad Nacional de la Plata de Argentina)[9], se realiz´o una conferencia sobre el desarrollo y uso de aplicaciones Serverlees en entornos distribuidos. Se analiz´o la evoluci´on y uso del mismo, para aplicaciones de corta duraci´on como microservicios, backends IoT m´oviles, procesamiento de flujo modesto, bots e integraci´on de servicios y reconocimiento de datos e im´agenes. Pese a sus beneficios como la rapidez operacional, sencillez de desarrollo, bajo coste econ´omico y la modularizaci´on, tambi´en tiene grandes desventajas como su dif´ıcil depuraci´on, cierta perdida de control operativo, problemas con APIs a terceros y bibliotecas que no son reconocidas por el sistema, riesgos de seguridad al ser sistemas en los que el desarrollador debe registrarse e identificarse. 10 Figura 2.8: Funcionamiento de una arquitectura Serverless 2.1.10. Arquitectura serverless para el procesado de datos y detecci´on de anomal´ıas en el instrumento MARSIS Este trabajo realizado por David Pacios Izquierdo y otros investigadores[10] en colaboraci´on con la ESA(Agencia Espacial Europea). El objetivo era procesar im´agenes obtenidas por la MARSIS, que es una sonda orbital de radar y alt´ımetro de pulso limitado y baja frecuencia creado por la Universidad de Roma. 11 Figura 2.9: Misi´on ESA Mars Express Se implement´o una arquitectura serverless que analizaba la informaci´on enviada por la MARSIS en busca de anomal´ıas. En este proceso se comprobaban un gran n´umero de im´agenes en pocos segundos. Al implementarlo se ha obtenido una ganancia de tiempo y coste para la investigaci´on de las anomal´ıas de la superficie marciana. 2.1.11. Computaci´on en Serverless para el an´alisis de datos de secuencias de ARN En esta investigaci´on se ha desarrollado una soluci´on para el an´alisis de datos de secuencias de ARN[11] utilizando serverless. Ha sido realizada por Pietro Cinaglia, Jos´e Luis V´azquez-Poletti y Mario Cannataro. 12 Figura 2.10: Secuencias de ADN y ARN Esta arquitectura sin servidor desarrollada se centraba en el escaneo de las lecturas de secuenciaci´on del genoma objetivo. Se demuestra que su soluci´on mapea y analiza un gran n´umero de secuencias ( hasta 1000 muestras en base 16). Se compara con el entorno local y se muestra que este ´ultimo requiere de un alto uso de la CPU y grandes cantidades de memoria. 2.1.12. Marca de agua inteligente aplicada al dinero electr´onico En este proyecto[12] se propone aplicar el uso de marcas de agua inteligentes al dinero electr´onico, a trav´es de un c´odigo ejecutable insertado en la marca para evitar incompatibilidades de funciones y demostrando que se puede emplear en el ´ambito financiero digital. 13 Figura 2.11: Problemas de incompatibilidad del dinero digital Se cre´o un escenario donde el usuario puede manejar diferentes tipos de dinero electr´onico, mediante una aplicaci´on est´andar para su uso con marcas de agua inteligentes. Adem´as, se implement´o un cajero autom´atico para pagos, ofreciendo el servicio a aquellos usuarios que no tuvieran cuenta bancaria para poder realizarlos. Figura 2.12: Generaci´on de marca de agua inteligente 14 Cap´ıtulo 3. Tecnolog´ıas 3.1. AWS AWS(Amazon Web service)[13] es la colecci´on de servicios en la nube m´as completa y adaptada del mundo. Al contar con m´as de 200 servicios, es utilizado para el desarrollo de arquitecturas y software en el ´ambito p´ublico y privado. Figura 3.1: Imagen del entorno de bienvenidade AWS Esta herramienta que requiere previo registro, nos ha servido para utilizar y mejorar el rendimiento del c´odigo, pudiendo llegar a gestionar un centenar de hilos de ejecuci´on a bajo coste y capacidad de memoria. 3.1.1. Lambda Lambda o Amazon Lambda1es un servicio sin servidor y que se basa en eventos, permitiendo ejecutar c´odigo de cualquier aplicaci´on o backend, sin la necesidad de reservar o gestionar servidores. 1Direcci´on de lambda y de la imagen https://aws.amazon.com/es/lambda/ 15 22 Figura 4.3: Google Scholar o Acad´emico 4.4.2. Fase de desarrollo local Tras haber realizado una investigaci´on previa y haber asimilado los conocimientos necesarios para la implementaci´on en Python de los primeros m´odulos, se empez´o con el desarrollo y pruebas en local(Ordenador de sobremesa). Marcado de documento El primer paso fue generar un m´odulo o aplicaci´on que al recibir una direcci´on de correo electr´onico, la transformara en una imagen utilizable y con el fondo transparente, adem´as de prefijar el tama˜no y fuente del texto(correo electr´onico). Tras la generaci´on de dicha imagen, se genera un segundo m´odulo que transforma esa imagen en un documento PDF para su uso posterior como marca de agua en los documentos. Con estos dos m´odulos finalizados, se soluciona el problema de crear una marca de agua de forma f´acil y r´apida, para poder ser utilizada en el tercer m´odulo. Este ´ultimo m´odulo se encarga de agregar la marca de agua a las hojas de un PDF en la posici´on prefijada que se prefiera. Al finalizar esta parte de la fase de desarrollo local, se consigui´o solucionar el problema de generaci´on de una marca de agua a partir de un texto dado (en este caso un correo electr´onico) y de adici´on en todas las hojas del documento en 23 la posici´on previamente determinada. Seguridad del Documento Anteriormente se ha marcado el documento. La marca de agua generada es d´ebil y poco robusta, por lo que pod´ıa ser eliminada por aplicaciones para eliminaci´on de marcado de documentos e im´agenes. Es por esto que se decidi´o fortalecer la marca de agua generada y adem´as obtener el texto o correo electr´onico, que se usar´a para la marca de agua del documento y as´ı evitar errores de escritura por parte del autor. El siguiente m´odulo creado es el encargado de leer un texto y extraer el correo que se utiliza al generar la marca de agua. A partir de este m´odulo, se a˜nadi´o la funcionalidad de obtener el d´ıa y hora de lectura del texto y encriptarlo (codificarlo de forma segura), para luego concatenarlo al correo y generar la marca de agua segura, adem´as de un documento de texto con la clave de encriptaci´on para el autor. Tras tener la marca de agua segura, se procedi´o a generar un m´odulo adicional para la modificaci´on de los metadatos del nuevo documento marcado, para a˜nadir un nivel de seguridad extra al documento. Tambi´en se modific´o la marca de agua para ser imperceptible ante cualquiera que quisiera eliminarla, sin ser el propio autor. Al finalizar las pruebas, se obtuvo ´unico programa modular que consigui´o solventar el problema de la seguridad, la automatizaci´on de la creaci´on de la marca de agua y el marcado en el documento. 4.4.3. Fase de Desarrollo en el Servicio Web En este punto, se tiene una aplicaci´on funcional capaz de ejecutarse en cualquier ordenador, el problema que a´un no se hab´ıa solucionado era el coste en tiempo, dinero y la cantidad de documentos posibles a procesar. En ese momento, se decidi´o utilizar Amazon Web Service(AWS)3como servicio web por su capacidad de procesar una gran cantidad de datos e hilos de ejecuci´on(Programas que puede procesar) y el bajo coste de su uso. Tras un estudio y aprendizaje intensivo de dos semanas y media sobre Amazon Web Service, registro, familiarizaci´on con la plataforma, pruebas de uso y an´alisis de costes, se procedi´o a la migraci´on del c´odigo en Python, a˜nadiendo 3Direcci´on web:https://aws.amazon.com/es/what-is-aws/ 24 las instrucciones Lambda de Amazon para su correcto funcionamiento. Se decidi´o ir probando los diferentes m´odulos en Amazon Web Service y finalmente, se gener´o una versi´on totalmente operativa que superaba las expectativas en tiempo, coste y capacidad de ejecuci´on, Se gener´o todo lo esperado de la arquitectura tras solucionar varios problemas de integraci´on con Python. Cap´ıtulo 5. Arquitectura e implementaci´on 5.1. Arquitectura de Proyecto en Amazon Web Service En este apartado se va a mostrar y explicar la arquitectura desarrollada en Amazon Web Service. Se mostrar´a su funcionamiento paso a paso. Primero se mostrar´a el esquema de la arquitectura y luego se desglosar´a de la siguiente forma: Figura 5.1: Arquitectura del proyecto en Amazon Web Service 25 26 5.1.1. Dockerizaci´on del proyecto Durante el desarrollo se generaron problemas debido a las librer´ıas asociadas a las dos funciones Lambda. Para solucionarlos se empaquet´o el proyecto en un Docker (librer´ıas incluidas) y se subi´o a un ordenador local mediante un API Gateway. De esta forma se solucionaron los problemas de incongruencia y p´erdida de librer´ıas (asociadas con el tratamiento de im´agenes) al ejecutar estas funciones. Esto ha provocado una penalizaci´on en el tiempo de ejecuci´on total de la arquitectura, ya que se tiene que desempaquetar y utilizar los paquetes en vez de tenerlos ya instalados por defecto en los Layers de cada una de las dos funciones Lambda, pero no supone un gran incremento en el coste total de tiempo y dinero de la arquitectura. 5.1.2. API Gateway Una vez dockerizado el proyecto se subir´a a la API Gateway previamente creada y concedi´endole una pol´ıtica de permisos de invocaci´on que se basa en los recursos de funci´on. Pudiendo enviar la informaci´on o las APIs(Librer´ıas necesarias para el buen funcionamiento del c´odigo) a las Funciones Lambda 1 y 2 o enviando los datos de entrada como el documento a marcar y el documento que contiene el correo electr´onico al S3-1. En nuestro caso, la API Gateway invoca una funci´on s´ıncronamente que contiene una solicitud JSON de evento y queda a la espera de respuesta por cualquiera de los m´odulos que necesiten las APIs o la informaci´on que contiene. S3-1 mandar´ıa una respuesta a API Gateway solicitando los documentos de entrada, que ser´ıa el PDF a marcar y el documento de texto que contiene el correo electr´onico. La API Gateway responde a S3-1 y env´ıa los documentos a S3-1, para su uso en el lambda funci´on 1 a la vez que este tambi´en solicitar´a las APIs o librer´ıas a API Gateway para la correcta ejecuci´on del c´odigo que contienen. 5.1.3. S3 En la arquitectura se usaron tres contenedores S3, que servir´an como almacenamiento temporal de los datos de entrada, salida e intermedios que necesitaran utilizar nuestras dos funciones Lambda y sobre los que trabajaran en su ejecuci´on. El S3-1 contendr´a los documentos de entrada que utilizar´a la Lambda Funci´on 1 y que han sido requeridos a la API Gateway mediante la funci´on de eventorespuesta del mismo, como se ha explicado en el punto anterior. La S3-2 que 27 contendr´a el resultado de la ejecuci´on de Lambda Funci´on 1 y lo almacenar´a, esperando el requerimiento de los mismos para su utilizaci´on por Lambda Funci´on 2. El S3-3 que recibir´a los datos finales de toda la ejecuci´on de la arquitectura, devolviendo el documento pdf marcado y el documento de texto con la clave-valor. Figura 5.2: S3-3 con los archivos de salida al final de la ejecuci´on de la arquitectura 5.1.4. Lambda Funci´on 1 Esta funci´on Lambda se activa al recibir el documento que hay que marcar por parte de S3-1. Una vez se activa, empieza a ejecutar y a descargar los archivos necesarios. Luego lee el archivo de texto para obtener el correo electr´onico para fabricar la marca de agua y lo guardar´a como una variable de texto. A continuaci´on se obtendr´a una cadena de texto con la fecha y la hora actual del sistema, creando un diccionario clave-valor con el correo electr´onico y la variable de texto que contiene la cadena de fecha y hora con hash codificado en formato sha-256, para finalmente concatenarlo con el correo electr´onico para ser usado por la marca de agua. Se generar´a la imagen que servir´a como base para la marca de agua y se agregar´a como texto la concatenaci´on anterior de correo+diccionario y se volver´a transparente, para luego finalmente transformarla en un PDF de una sola hoja que se usar´a como marca de agua. El siguiente paso ser´ıa proceder a extraer las hojas del documento a marcar y se fusionan con la marca de agua, generando un nuevo documento PDF con la marca de agua invisible en todas sus hojas y totalmente seguro. Al finalizar la funci´on lambda, se enviar´a a S3-2 el documento de texto con el diccionario y el 28 nuevo PDF marcado de forma segura para su utilizaci´on por parte de Lambda Funci´on 2. 5.1.5. Lambda Funci´on 2 La funci´on Lambda recibe el evento de ejecuci´on y extrae los documentos de S3-2, tomando el documento PDF seguro que se ha creado para la modificaci´on de los campos que se quieran de sus metadatos como segundo m´etodo de asegurar el documento y su autor´ıa frente a posibles intentos de manipulaci´on. Figura 5.3: Metadatos modificados del documento marcado de forma segura Al finalizar el proceso de modificaci´on de los metadatos, se env´ıa a S3-3 el documento ya marcado y con los metadatos modificados, adem´as del archivo de texto con el correo y el diccionario cifrado listos para descargar al ordenador local. Cap´ıtulo 6. Mediciones y resultados 6.1. Pruebas de costes y tiempos Se ha procedido a realizar las pruebas de costes y de tiempo en diferentes entornos, para hacer una comparativa de cual ser´ıa opci´on m´as viable para una empresa o instituci´on. Los entornos de prueba son los siguientes: Ordenador Local. Google Cloud. Amazon Web Service. Los c´alculos han sido realizados utilizando la calculadora de costes de Google cloud y AWS Lambda Cost Caculator, en comparativa con el coste total de un ordenador local est´andar de 1000€y cuanto tiempo tardar´ıa en amortizar las operaciones. 6.1.1. Google Cloud vs Ordenador local Los c´alculos sobre un total de 1000 operaciones son los siguientes: Par´ametros Comparativos Google Cloud Ordenador Local N´umero de iteracciones 1000 1000 Espacio de almacenamiento 2GB 500GB Tiempo en realizar una iteracci´on 4.8seg 4.8seg Tama˜no de la memoria RAM 1GB 16GB Coste total/mes 0.61USD/mes 83.33€(Amortizaci´on: 1000/12) Cuadro 6.1: Comparativa entre Google Cloud y el ordenador local En el Cuadro 6.1 se puede observar que Google Cloud tiene un menor coste mensual para analizar 1000 documentos con una capacidad menor y mismo tiempo de ejecuci´on. Para ejecutar el mismo n´umero de documentos en local se necesitar´ıan 136 a˜nos. 6.1.2. AWS vs Ordenador local Los c´alculos sobre un total de 1000 operaciones son los siguientes: 29 30 Par´ametros Comparativos AWS Ordenador Local N´umero de iteracciones 1000 1000 Espacio de almacenamiento 512MB 500GB Tiempo en realizar una iteracci´on 4.8seg 4.8seg Tama˜no de la memoria RAM 128MB 16GB Coste total/mes 0.01USD 83.33€(Amortizaci´on: 1000/12) Cuadro 6.2: Comparativa entre AWS y el ordenador local Como se observa en el Cuadro 6.2 con una capacidad de almacenamiento menor y RAM, su coste es ´ınfimo al mes por la paralelizaci´on. Un ordenador local tardar´ıa 69444 a˜nos en procesar estos 1000 documentos. Cap´ıtulo 7. Conclusiones y trabajo a futuro 7.1. Conclusiones Este proyecto ten´ıa como objetivo crear una marca de agua totalmente segura y fortalecer los documentos contra su eliminaci´on, adem´as de proteger los derechos del autor y su uso fraudulento por parte de terceras personas o empresas sin consentimiento expl´ıcito. Para ello se han revisado las distintas soluciones creadas en el apartado del estado del arte y se ha buscado una soluci´on efectiva para proteger documentos mediante marcas de agua. La metodolog´ıa utilizada para el desarrollo de esta arquitectura ha sido desplegada por fases progresivas, ampliando las funcionalidades de la misma de forma paulatina. Para la implementaci´on de la arquitectura, se eligi´o como lenguaje de desarrollo Python en su versi´on 3.8 para ´ambito local y AWS de Amazon para generar la versi´on final, por su potencia y capacidad de manejos de altas cantidades de datos en tiempos r´apidos y a bajo coste. El desarrollo empez´o con la creaci´on de los primeros m´odulos, donde a partir de un correo electr´onico se generaba una marca de agua y marcaba documentos de una forma r´apida. En los siguientes pasos se consigui´o crear un diccionario de datos clave-valor encriptado y concatenado al correo electr´onico, generando con ellos una marca de agua que se volvi´o segura haci´endola invisible y finalmente, se modificaron los metadatos necesarios del documento previamente creado. Finalmente, tras el ´exito en la versi´on local, se empez´o con la migraci´on o implementaci´on en AWS. Al hacer las primeras pruebas sobre el entorno de Amazon, se generaron problemas en los Layers de los m´odulos o funciones Lambda al intentar acceder a las bibliotecas de Python previamente definidas, haciendo que el sistema fallara. Tras varias pruebas, se tom´o la decisi´on de englobar todas las librer´ıas y los m´odulos en un Docker, que se subi´o a una API Gateway como gestor de la librer´ıa para los diferentes m´odulos de AWS. Al utilizar este m´etodo, la arquitectura funcion´o de forma correcta, pasando las pruebas de forma correcta y siendo presentado a los responsables del proyecto para su validaci´on. 7.2. Trabajo a futuro 31