# Proyecto Criptografía Crit Esta página servirá para planear y revisar los avances del entregable de criptografía, un sistema de firma de documentos. En términos más robustos la implementación del proyecto consiste en una aplicación basada en tecnologías web para la firma electrónica de documentos mediante el uso algoritmos criptográficos seguros, así como el reconcimiento de la firma de documentos. ## Repositorio Las contribuciones se hacen a manera de PR desde su branch de desarrollo a `main`. La decisión de hacer merge o no al código contribuido queda a manos de todo el equipo. El código del proyecto lo encuentran [aquí](https://ooooooooooooooooooooooo.ooo/ooooοооoοᴏοoοᴏοoοᴏooοᴏoᴏoᴏооoоᴏᴏoоᴏᴏοᴏоοοоᴏᴏοᴏοοοᴏοoοᴏοοoоᴏоοоoоοоοοoоᴏᴏοоᴏᴏoоᴏοοοоοοooоοoοoοοοoοᴏoοοοоoοοᴏᴏοοооοοοοoᴏᴏᴏοᴏοooᴏᴏοoᴏoο). ## Requerimientos Las necesidades del Minimum Viable Product funcionan como un checklist y son las siguientes: 1. - [ ] Creación y autenticación de credenciales para la aplicación 2. - [ ] Generación de llaves para usuarios nuevos 3. - [ ] Recreación de llaves para usuarios existentes 4. - [ ] Modificación de datos personales 5. - [ ] Firma de documentos 6. - [ ] Validación de documentos firmados 7. - [ ] Instrucciones de uso siempre presentes ## Páginas Páginas presentes en la aplicación, cada una con una plantilla distinta, no serán bonitas pero funcionarán. * Login: Pantalla inicial para iniciar sesión * Signup: Creación de usuarios nuevos y generación de llaves * Home/Main: Página principal con instrucciones siempre presentes de como usar la aplicación para cargar documentos, firmarlos y guardarlos * Perfil: Simple perfil del usuario donde este puede acceder a datos de su cuenta como el nombre, el correo, y su llave, así como la opción de regenerar la llave. ## Tech stack Listado de tecnologías que usamos en el proyecto y para qué: * Flask | Django: Contenedor web * Endesive: Funciones criptográficas * Hashlib: Generación de hashes de contraseñas * Back4App: Backend para login y almacenamiento de datos de usuarios ## Ideas no aterrizadas para implementación Ideas que servirían para cumplir un requerimiento en particular. Los nombres en las ideas son para poder acercarnos con quien la tuvo para dudas de como debería funcionar. Para agregar algo por favor usen el siguiente formato: > * Req. #: Problema y/o pregunta > * Idea {Nombre}: Posible solución y/o respuesta. Lista de ideas: * Req. 6: Los documentos deben acabar en algún directorio, ¿dónde? * Idea Beto: Guardar documentos en el directorio `C:/Documentos/Archivos Firmados/`, si no existe, crearlo. * Req 1: Se deben pedir datos para crear una cuenta, ¿cuáles? * Idea Beto: El módulo de criptografía permite guardar varios metadatos al momento de firmar un documento, estos siendo: * "signature": Frase de firma del individuo * "signature_img": Path de un archivo de imagen * Solo se puede usar una de las 2 anteriores al mismo tiempo. * "contact": Dato de contacto de quien firma, correo o teléfono recomendados * "location": Ubicación geográfica donde se guardo la firma * "signingdate": Fecha del momento exacto en el que se genera la firma, obtenida por el sistema * "reason": Motivo para generar la firma * Por lo tanto se recomiendo guardar alguna de las 2 maneras de firmar, el contacto y la ubicación como datos de cuenta para mantener consistencia en las firmas. * Req. 2, 3: Al momento de crear una cuenta se requiere un correo y una contraseña. Al momento de crear una llave que requiere una contraseña. * Idea Beto: Usar la misma contraseña para la cuenta y para la generación de llaves. Al momento de solicitar la contraseña para crear una cuenta, hashearla localmente y subir el hash como la contraseña almacenada, de igual manera crear el archivo de firma `.p12`. Cuando el usuario quiera cambiar de contraseña de cuenta tendrá o regenerar su llave ocurrirán ambas cosas, se cambiará la contraseña y se regenerará su llave. ## Alcance y limitaciones Algunas de las cosas que no estarán presentes en la aplicación son las siguientes: * Almacenamiento de archivos ## Stretch goals Algunas cosas que estaría chido tener pero no son prioridad para nada: - [ ] ASCII art o QR basado en la firma única del usuario. - [ ] Historial de firmas por usuarios (¿nombre de los últimos 5?) - [ ] Mejorar estética de UI ## Q&A Preguntas para hacer al socio formador así como las respuestas que vamos recibiendo * ¿Solo se firmarán documentos en formato PDF? * ¿TODOS los usuarios de la plataforma cuentan con un correo del mismo dominio de la organización? * ¿Deberíamos guardar un historial de todas las firmas que realizó el usuario? * ¿Les interesa guardar algo más además de nombre completo y correo de cada usuario? ## Experimentos En esta sección cada subsección es el reporte de los experimentos realizados para cada uno de los requerimientos o componentes. ### Generación de llaves Observaciones: 1. Crear una llave requiere solamente de una contraseña, esta puede ser la misma que la de la cuenta, cuidando que la contraseña no pueda ser la misma que la anterior. Librerías o tecnologías: 1. endesive 2. cryptography ### Firma de documentos Observaciones: 1. Firmar documentos requiere varios datos de entrada, la mayoría siendo manejables por los scripts: ``` * "aligned": int 0 * "sigflags": int 3 * "sigflagsft": int 132 * "sigpage": int 0 * "sigbutton": bool True * "sigfield": str "Signature1" * "auto_sigfield": bool True * "sigandcertify": bool True * "signaturebox": int[4] (470, 800, 570, 640) * "signature": str "Esta es una firma de prueba" * "signature_img": str[path] "signature_test.png" * Solo se puede usar una de las 2 anteriores por documento. * "contact": str "hello@iambeto.dev" * "location": str "zapopan" * "signingdate": date date * Objeto de fecha obtenido al momento de generar la firma * "reason": str "Esta es una firma de prueba" * "password": str "1234" ``` 2. A partir de lo anterior, todo es asignable por el script a excepción de `reason` y `password`, `reason` debería variar por documento y se debería solicitar la contraseña, calcular su hash y comparar con el almacenado para la cuenta, si son el mismo dar permiso de firmar, de lo contrario negar, esto como medida de seguridad adicional. Librerías o tecnologías: 1. `endesive` 2. `cryptography` ## Tasks Cosas por hacer, breve descripción del problema, acompañado de alguna pista o sugerencia de como resolverlo. ### Interacciones con base de datos * Problema: * Es necesario interactuar con la base de datos de back4app para poder guardar a los usuarios así como sus datos y firma. * Sugerencias: * Revisar la documentación para encontrar los endpoints de `POST` y `GET`, así como sus `headers` y `body` para mandarlos a través de la librería `requests` de `python`. ## Referencias Aquí va la documentación de los módulos o herramientas que usemos para el proyecto. * [Leer pdfs como texto en python](https://stackoverflow.com/questions/29057724/python-convert-pdf-to-text-encoding-error) * [Firma de strings](https://pynacl.readthedocs.io/en/latest/signing/) * [Libreta de jupyter para experimentar](https://colab.research.google.com/drive/1shxz-I2VSxWk2EcPC-KcICXeoAPoY7rc?authuser=2#scrollTo=mDZ6lUPXRgz2) * [Flask docs](https://flask.palletsprojects.com/en/2.0.x/) * [Back4App docs](https://dashboard.back4app.com/apidocs?shell#user-api) * [Repositorio endesive](https://github.com/m32/endesive) * [Hashlib docs](https://docs.python.org/3/library/hashlib.html)