APLICACIÓN DE MENSAJERÍA CERTIFICADA PARA IPHONE

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO EN INFORMÁTICA

APLICACIÓN DE MENSAJERÍA CERTIFICADA PARA IPHONE

Autor: Alberto Rodríguez Gómez Director: Alejandro Besada Juez

Madrid

Septiembre de 2012

como incorporar metadatos para realizar el registro de la obra e incorporar “marcas de agua”

o cualquier otro sistema de seguridad o de protección.

(b) Reproducirla en un soporte digital para su incorporación a una base de datos electrónica, incluyendo el derecho de reproducir y almacenar la obra en servidores, a los efectos de garantizar su seguridad, conservación y preservar el formato. .

(c) Comunicarla y ponerla a disposición del público a través de un archivo abierto institucional, accesible de modo libre y gratuito a través de internet.²

(d) Distribuir copias electrónicas de la obra a los usuarios en un soporte digital. ³

4º. Derechos del autor.

El autor, en tanto que titular de una obra que cede con carácter no exclusivo a la Universidad por medio de su registro en el Repositorio Institucional tiene derecho a:

a) A que la Universidad identifique claramente su nombre como el autor o propietario de los derechos del documento.

b) Comunicar y dar publicidad a la obra en la versión que ceda y en otras posteriores a través de cualquier medio.

c) Solicitar la retirada de la obra del repositorio por causa justificada. A tal fin deberá ponerse en contacto con el vicerrector/a de investigación ([email protected]).

d) Autorizar expresamente a COMILLAS para, en su caso, realizar los trámites necesarios para la obtención del ISBN.

d) Recibir notificación fehaciente de cualquier reclamación que puedan formular terceras personas en relación con la obra y, en particular, de reclamaciones relativas a los derechos de propiedad intelectual sobre ella.

2 En el supuesto de que el autor opte por el acceso restringido, este apartado quedaría redactado en los siguientes términos:

(c) Comunicarla y ponerla a disposición del público a través de un archivo institucional, accesible de modo restringido, en los términos previstos en el Reglamento del Repositorio Institucional

3 En el supuesto de que el autor opte por el acceso restringido, este apartado quedaría eliminado.

2

El autor se compromete a:

a) Garantizar que el compromiso que adquiere mediante el presente escrito no infringe ningún derecho de terceros, ya sean de propiedad industrial, intelectual o cualquier otro.

b) Garantizar que el contenido de las obras no atenta contra los derechos al honor, a la intimidad y a la imagen de terceros.

c) Asumir toda reclamación o responsabilidad, incluyendo las indemnizaciones por daños, que pudieran ejercitarse contra la Universidad por terceros que vieran infringidos sus derechos e intereses a causa de la cesión.

d) Asumir la responsabilidad en el caso de que las instituciones fueran condenadas por infracción de derechos derivada de las obras objeto de la cesión.

6º. Fines y funcionamiento del Repositorio Institucional.

La obra se pondrá a disposición de los usuarios para que hagan de ella un uso justo y respetuoso con los derechos del autor, según lo permitido por la legislación aplicable, y con fines de estudio, investigación, o cualquier otro fin lícito. Con dicha finalidad, la Universidad asume los siguientes deberes y se reserva las siguientes facultades:

a) Deberes del repositorio Institucional:

- La Universidad informará a los usuarios del archivo sobre los usos permitidos, y no garantiza ni asume responsabilidad alguna por otras formas en que los usuarios hagan un uso posterior de las obras no conforme con la legislación vigente. El uso posterior, más allá de la copia privada, requerirá que se cite la fuente y se reconozca la autoría, que no se obtenga beneficio comercial, y que no se realicen obras derivadas.

- La Universidad no revisará el contenido de las obras, que en todo caso permanecerá bajo la responsabilidad exclusiva del autor y no estará obligada a ejercitar acciones legales en nombre del autor en el supuesto de infracciones a derechos de propiedad intelectual derivados del depósito y archivo de las obras. El autor renuncia a cualquier reclamación frente a la Universidad por las formas no ajustadas a la legislación vigente en que los usuarios hagan uso de las obras.

- La Universidad adoptará las medidas necesarias para la preservación de la obra en un futuro.

b) Derechos que se reserva el Repositorio institucional respecto de las obras en él registradas:

3

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO EN INFORMÁTICA

APLICACIÓN DE MENSAJERÍA CERTIFICADA PARA IPHONE

Autor: Alberto Rodríguez Gómez Director: Alejandro Besada Juez

Madrid

Septiembre de 2012

Agradecimientos

Me gustaría agradecer el esfuerzo y ayuda prestados por parte de mi familia, amigos, profesores y de mi director de proyecto, ya que sin ellos y su inestimable esfuerzo este proyecto no habría sido posible.

A mis compañeros y amigos, que me acompañaron durante la carrera y me prestaron su ayuda ante cualquier problema que se me presentó durante la duración del mismo.

Además de por los innumerables buenos momentos que he pasado a su lado.

A mis padres, porque sin su esfuerzo y comprensión no habría sido posible realizarlo.

Y a mis profesores y directores, por compartir sus conocimientos conmigo y mostrarme un mundo totalmente nuevo.

A todos ellos,

MUCHAS GRACIAS.

Resumen

APLICACIÓN DE MENSAJERÍA CERTIFICADA PARA IPHONE

Autor: Rodríguez Gómez, Alberto.

Director: Besada Juez, Alejandro.

Entidad Colaboradora: Ansib.Net Solutions, S. L.

RESUMEN DEL PROYECTO

En la era de la información, donde cualquier usuario envía asiduamente correos y mensajes con sus móviles, es difícil saber si uno de estos mensajes ha llegado a su destinatario.

En ciertas circunstancias es de vital importancia para el usuario saber cuándo un mensaje ha llegado a su destinatario, especialmente en comunicaciones administrativas.

Este proyecto intenta solventar esa cuestión, de forma que se certifique al emisor cuándo un mensaje ha sido recibido por su destinatario.

Para ello se firmarán electrónicamente las notificaciones de recepción del proveedor de servicios de mensajería y se custodiará dicha firma de forma que se obtenga la validez jurídica que demuestre que el mensaje fue recibido a tiempo.

Por tanto se puede afirmar que el proyecto consiste en el desarrollo y la implantación de un sistema de certificación de mensajería móvil así como su correspondiente aplicación para dispositivos iOS. Dicho sistema únicamente certifica la entrega de un mensaje a un número de terminado. En ningún caso determina si el mensaje ha sido leído por el destinatario. Sin embargo, dado que la aplicación va dirigida especialmente a compañías, siempre que una persona firme un contrato de conformidad dando su permiso para ser notificado de cualquier tipo de asuntos mediante un mensaje de móvil, la certificación de una notificación de entrega tiene validez jurídica para demostrar que la persona en cuestión fue notificada.

Actualmente únicamente existe una solución parecida a la propuesta en este proyecto, sin embargo se trata de una API para enviar mensajes certificados. Esta solución puede encontrarse en www.smscertificado.es.

El proyecto aquí descrito no sólo implica un cambio en la forma en que la solución existente en el mercado se integra con aplicaciones externas, ya que para este proyecto se utilizará un Servicio Web que será el que realice la lógica, tanto del envío de los mensajes como de la recepción de las notificaciones y la firma de las mismas, sino que también se realizará una aplicación para la plataforma iOS, presente en los dispositivos iPhone y iPad, debido a que se presume que es una buena plataforma para el envío de

mensajes, además de que permite notificaciones push que permiten el envío de los resultados del mensaje al emisor.

El atractivo personal de este proyecto es, además de aprender a utilizar los diferentes métodos de firma electrónica, el entorno en el que se rige el proyecto, de seguridad y autenticación de documentos electrónicos, la posibilidad de desarrollar una aplicación para el sistema operativo de móviles iOS y la oportunidad de desarrollar un portal web que haga las veces de FrontEnd y desde el que el usuario pueda consultar todos los detalles del servicio.

El sistema ha sido planificado para que pueda ser usado desde distintos entornos. Con este fin se ha desarrollado como un servicio web que recibe una solicitud de envío de mensaje y realice toda la lógica necesaria para el envío y confirmación del mismo.

Así mismo el proyecto ha sido concebido como una nueva funcionalidad dentro de un elenco de servicios que están siendo prestados actualmente, tales como llamadas certificadas o notificaciones TextToSpeech certificadas. Por tanto la metodología de firma así como la creación de tablas en la base de datos han sido planificadas con el fin de reutilizar lo máximo posible los recursos del resto de servicios, así como integrarlos para garantizar una buena escalabilidad.

El proyecto cuenta con varias aplicaciones de cara al usuario final. Estos son:

 Aplicación Móvil: Desde esta aplicación se consumirán los servicios web que llevan toda la lógica del sistema. Por tanto el usuario podrá enviar mensajes, ya sean certificados o no, a través del proveedor de mensajería contratado así como consultar el estado de los mensajes enviados.

 Consola de usuario: Se trata de un portal web desde el que el usuario podrá consultar las transacciones realizadas por los distintos servicios contratados.

Además podrá consultar estadísticas y facturación de su usuario o aquellos a los que supervise.

 Consola de administración: Desde este portal web se podrán dar de alta y modificar todos los aspectos relacionados con los usuarios, tales como los servicios contratados, la tarificación de los servicios, proveedores de terceros que se usarán en los procesos de certificación, contraseñas, cambios en el saldo de los usuarios, etc.

Todas estas aplicaciones funcionarán a través de consultas a servicios web, en el caso de la aplicación móvil, servlets, en el caso de la consola de usuario y la de administración, y aplicaciones independientes, especialmente servidores HTTP, que serán las encargadas de recibir las notificaciones de confirmación de entrega, comprobación del estado de los mensajes en estado pendiente y envío de las notificaciones push para la aplicación móvil.

Todos los datos de los mensajes y las firmas electrónicas se guardarán en una base de datos durante un mínimo de 5 años según estipula el Real Decreto-ley 14/1999, de 17 de septiembre, sobre firma electrónica.

La principal ventaja de este proyecto es la de la movilidad, ya que tanto la aplicación de móvil como las consolas de usuario y administración pueden verse desde un smartphone con conexión a Internet. Este avance en cuanto a certificación de notificaciones es muy importante, ya que la alternativa son lo burofaxes, que resultan caros y engorrosos, ya que se hace imprescindible personarse en la oficina de correos para su envío.

Uno de los requisitos más importantes en una aplicación para smartphone es la de que la interfaz de ésta sea lo más sencilla y minimalista posible. El requisito de la simplicidad se hace evidente cuando se piensa en una aplicación móvil, ya que una aplicación que necesite de una lectura previa de un manual de utilización de la misma resulta engorrosa para el usuario final y la utilidad de la aplicación puede verse comprometida. La interfaz minimalista es la forma en la que la aplicación tiene distribuidos los distintos elementos de forma que las pequeñas pantallas de los dispositivos no acaben llenas de elementos de difícil acceso para las pulsaciones táctiles de los usuarios.

Con este proyecto se pretende, por tanto, acercar las notificaciones certificadas a cualquier usuario que posea un smartphone, pudiendo realizarlas desde cualquier lugar con acceso a Internet y con un coste visiblemente más barato que el de cualquier otra solución de certificación de notificaciones.

MESSAGING APPLICATION CERTIFIED FOR IPHONE

In the information age, where any user sends regularly emails and messages with their mobile phones, it is difficult to know if one of these messages has been delivered to its addressee.

In certain circumstances is of vital importance for the sender to know when a message has been delivered to the target, especially in administrative communications.

This project tries to solve that problem, to certify to the sender when a message has been received by the addressee.

This messaging service provider received notifications will be electronically signed and will be guarded in order to obtain the legal validity proving that the message was received on time.

Therefore it can be said that the project consists in the development and implementation of a system of certification for mobile messaging as well as its corresponding application for iOS devices. This system only certifies delivery of messages to a mobile number. In any case determines if the message has been read by the addressee.

However, because the application is intended especially to companies, always that a person sign a contract giving his permission to be notified for any issues using a mobile message, the certification of a delivery notification has legal validity to demonstrate that the person concerned was notified.

Currently there is only a solution similar to the proposal in this project, it is however an API to send certified messages. This solution can be found in www.smscertificado.es.

The project described here not only implies a change in the form that existing solutions on the market integrate themself with external applications, because for this project it is going to be used Web services which will perform the logic, sending the messages, the reception of delivery notifications and the signature of them, but that will also perform an application for the platform, iOS, present in the iPhone and iPad devices since it is presumed that it is a good platform for sending messages that enables push notifications that allow the sending of the results of the message to the sender.

The personal appeal of this project is not only to learn how to use different methods of electronic signature, the environment of security and authentication of electronic documents in which the project is governed, the possibility of developing an application for iOS mobile operating system and the opportunity to develop a website that will be used as a FrontEnd and from which the user can check all the service details.

The system has been planned in order to can be used from different environments. For this it has developed as a web service that receives a request for sending message and perform all the necessary logic for sending and confirm it.

Likewise the project has been conceived as a new feature in a list of services that are being provided at present, such as certified calls or notifications using TextToSpeech certified. Therefore the methodology of signature as well as the creation of tables in the database have been planned in order to reuse as much as possible the resources of other services, as well as to integrate them to ensure good scalability.

The project has several applications for the final user. These can be seen below:

 Mobile application: Web services that carry all the logic of the system will be consumed from this application. Therefore the user can send messages, whether certified or not, through the contracted provider of messaging as well as check the status of sent messages.

 User console: it is a website from which the user can chack transactions carried out by the different services contracted. Can be also viewed statistics and billing of their supervised users.

 Management Console: from this website will be able to register and modify all aspects related to users, such as the contracted services, pricing of services, third-party vendors to be used in the processes of certification, password, changes in the users balance, etc.

All of these applications will work through requests to web services, in the case of the mobile application, servlet in the case of the console user and administration and standalone applications, especially HTTP servers, which will be responsible for receiving notifications of delivery confirmation, checking the status of messages in pending status and sending the push notifications for mobile application.

All data of messages and electronic signatures will be saved in a database for a minimum of 5 years as provided for the Royal Decree-Law 14/1999 from 17 September, on electronic signature.

The main advantage of this project is the mobility, since both the application of mobile user and management consoles can be used from a smartphone with Internet connection. This advance in terms of notifications certification is very important, since the alternative is the burofaxes, which are expensive and cumbersome, since it is essential to go to the post office for shipment.

One of the most important requirements in a smartphone application is that the interface has to be as simple and minimalist as possible. The requirement of simplicity is evident where thinking in a mobile application, an application that requires for reading a user manual of the same is cumbersome for the final user and the usefulness of the application can be compromised. The minimalist interface is the way in which the application distributes its different fields so that the small screens of devices are not full of elements that can difficult access for user‟s touches.

This project is intended bring certified notifications to any user who has a smartphone, and can made from anywhere with Internet access and visibly more cheaply cost than any other notifications certification solution.

Í ndice

Capítulo 1. Asentando conceptos ... 1

Componentes de la Firma Digital ... 2

Autoridad de Certificación ... 4

Cómo se realiza la firma digital ... 4

PKI ... 5

Criptografía y tipos de Algoritmos ... 6

Capítulo 2. El proyecto ... 9

Capítulo 3. Requisitos del proyecto ... 13

Requisitos hardware ... 13

Requisitos software ... 13

Capítulo 4. Planificación del proyecto ... 17

Planificación del proyecto ... 17

Adquisición de los recursos ... 17

Diseño de la Base de Datos ... 17

Diseño de los distintos módulos de desarrollo ... 17

Implementación de los distintos módulos de las aplicaciones servidor ... 17

Implementación de los distintos módulos de la aplicación iOS ... 18

Pruebas, actualizaciones y control de fallos ... 18

Documentación ... 18

Instalación ... 19

Capítulo 5. División del desarrollo ... 21

Módulo de envío de mensajes ... 21

Módulo de notificaciones de recepción de mensajes... 23

Módulo de consulta de estado mensajes ... 24

Módulo de búsqueda de mensajes no entregados ... 25

Módulo web de usuario ... 25

Módulo web de administrador ... 26

Módulo de facturación ... 26

Capítulo 6. Herramientas utilizadas... 29

Sistemas Operativos ... 29

Entorno de desarrollo... 30

Lenguajes de programación ... 31

Servidor de aplicaciones ... 32

Gestores de Bases de Datos ... 32

Administrador de Bases de Datos ... 33

Herramienta de ofimática ... 33

Otras herramientas ... 33

Capítulo 7. La Base de Datos ... 35

User ... 36

PersonalData ... 38

Company ... 38

ProductForUser ... 39

Product ... 40

TSA ... 40

PricePlan ... 41

CertifiedSMSSetup ... 41

CertifyPartner ... 42

DeviceTokens ... 43

SMSCarrier ... 43

SMSNotification ... 44

SMSDataSigned ... 47

WebRole ... 48

FailedLogins ... 48

BillAbstract ... 49

BillParams ... 50

ConsumedCreditByMonth ... 50

TaxId_BillTaxIdCodes ... 51

TaxByPostCode ... 51

Capítulo 8. Instalación del sistema ... 53

Capítulo 9. Valoración económica ... 55

Capítulo 10. Planificación ... 57

Capítulo 11. Conclusión ... 59

Anexo I. Manual de funcionamiento ... 61

Aplicación Móvil ... 61

Pantalla Principal ... 61

Nuevo mensaje ... 63

Notificaciones locales ... 64

Notificaciones push ... 65

Consola de usuario ... 66

Descripción ... 66

Pantalla de autenticación ... 67

Menú lateral ... 68

Pestaña de empresa ... 70

Pestaña de mensajes... 71

Pestaña de datos de usuario ... 72

Pestaña de estadísticas ... 73

Pestaña de facturación ... 74

Pestaña de configuración avanzada ... 75

Anexo II. Obtención de un certificado digital ... 77

Anexo III. Algoritmos de cifrado ... 83

Algoritmos simétricos ... 83

DES ... 83

3DES ... 84

IDEA ... 84

BlowFish ... 84

RC5 ... 84

CAST ... 85

Rijndael ... 85

Algoritmos asimétricos ... 85

DH ... 85

RSA ... 86

Curvas Elípticas ... 86

Algoritmos HASH ... 87

MD4 ... 87

MD5 ... 87

SHA-1 ... 88

Anexo IV. Vulnerabilidades de los algoritmos ... 89

MD5 ... 89

SHA-1 ... 89

DES ... 90

Anexo V. Seguridad en comunicaciones móviles ... 94

Bibliografía ... 95

Í ndice de tablas

Tabla 1. Parámetros petición SensSMS ... 22

Tabla 2. Parámetros respuesta sendSMS ... 23

Tabla 3. Parámetros petición getSMSStatus ... 24

Tabla 4. Parámetros respuesta getSMSStatus... 25

Tabla 5. Columnas de Tabla "User" ... 37

Tabla 6. Columnas de Tabla "PersonalData" ... 38

Tabla 7. Columnas de Tabla "Company" ... 39

Tabla 8. Columnas de Tabla "ProductForUser" ... 39

Tabla 9. Columnas de Tabla "Product" ... 40

Tabla 10. Columnas de Tabla "TSA" ... 40

Tabla 11. Columnas de Tabla "PricePlan" ... 41

Tabla 12. Columnas de Tabla "CertifiedSMSSetup" ... 42

Tabla 13. Columnas de Tabla "CertifyPartner" ... 42

Tabla 14. Columnas de Tabla "DeviceTokens" ... 43

Tabla 15. Columnas de Tabla "SMSCarrier" ... 44

Tabla 16. Columnas de Tabla "SMSNotification" ... 46

Tabla 17. Valores sendStateReasonCode ... 47

Tabla 18. Columnas de Tabla "SMSDataSigned" ... 47

Tabla 19. Columnas de Tabla "WebRole" ... 48

Tabla 20. Columnas de Tabla "FailedLogins" ... 48

Tabla 21. Columnas de Tabla "BillAbstract" ... 49

Tabla 22. Columnas de Tabla "BillParams" ... 50

Tabla 23. Columnas de Tabla "ConsumedCreditByMonth" ... 50

Tabla 24. Columnas de Tabla "TaxId_BillTaxIdCodes" ... 51

Tabla 25. Columnas de Tabla "TaxByPostCode" ... 51

Tabla 26. Elementos software ... 55

Tabla 27. Elementos hardware ... 56

Tabla 28. Resumen de costes ... 56

Í ndice de ilustraciones

Ilustración 1. Componentes del proyecto ... 11 Ilustración 2. Relaciones entre tablas ... 52 Ilustración 3. Diagrama de GANT de la planificación ... 58 Ilustración 4. Pantalla principal ... 62 Ilustración 5. Pantalla de nuevo mensaje... 63 Ilustración 6. Notificación local ... 64 Ilustración 7. Notificación push ... 65 Ilustración 8. Consola de usuario ... 66 Ilustración 9. Pantalla de login ... 67 Ilustración 10. Menú lateral. Cabecera ... 68 Ilustración 11. Menú lateral. Validador de firmas ... 69 Ilustración 12. Menú lateral. Ayuda ... 69 Ilustración 13. Pestaña de empresa ... 70 Ilustración 14. Pestaña de mensajes ... 71 Ilustración 15. Pestaña de datos de usuario ... 72 Ilustración 16. Pestaña de estadísticas ... 73 Ilustración 17. Pestaña de facturación ... 74 Ilustración 18. Pestaña de configuración avanzada ... 75 Ilustración 19. Página CERES ... 77 Ilustración 20. CERES. Certificado de usuario ... 78 Ilustración 21. CERES. Solicitud certificado ... 79 Ilustración 22. CERES. Enviar petición ... 80 Ilustración 23. CERES. Confirmar solicitud ... 80 Ilustración 24. CERES. Creación clave privada ... 81 Ilustración 25. CERES. Código de usuario ... 81 Ilustración 26. CERES. Instrucciones finales ... 82 Ilustración 27. Funcionamiento de una llamada ... 92 Ilustración 28. Diagrama de cifrado GPRS ... 92

Capí tulo 1. Asentando conceptos

Antes de comenzar a explicar en qué consiste el proyecto y cómo se va a desarrollar el mismo, se deberán tener claros varios conceptos de los que se hablará en este documento y que pueden dar lugar a dudas, tergiversaciones o equivocaciones.

En primer lugar se deberá entender el concepto de firma electrónica y los componentes que hacen posible que esta adquiera validez jurídica.

La firma electrónica es un medio por el cual una persona es capaz, mediante la utilización de una clave privada y un algoritmo criptográfico, de firmar documentos que se encuentren en formato digital. Para validar dicha firma los datos serán descifrados utilizando la clave pública asociada a la privada con que se cifró. En sí mismo no es más que un cifrado de datos mediante el uso de una de las dos claves anteriormente mencionadas y que sólo puede descifrarse mediante la clave complementaria.

Al igual que las firmas manuscritas en papel, el objetivo de las firmas digitales es aceptar o validar los contenidos recogidos en un documento, ya que con el procedimiento de la firma, se podrá verificar la autoría de los datos firmados. La ventaja que tiene la firma digital frente a la manuscrita es que la firma digital no requiere de ningún otro documento para cotejar la firma de manera visual.

Debido a la aparición de este tipo de forma de autenticar tanto al autor como a los datos que este ha firmado, se creó la ley de firma electrónica el 19 de diciembre del 2003 (ley 59/2003).

El lugar donde son más utilizadas las firmas digitales, es en el comercio electrónico, ya que constituyen un elemento clave de la mayoría de los procesos de autenticación.

Aunque de forma cada vez más común los organismos públicos la utilizan para la realización de cierta burocracia.

Componentes de la Firma Digital

La firma digital se basa en la criptografía asimétrica, donde se usan dos códigos alfanuméricos indisociables y que están ligados uno al otro, estos son: la Clave Pública y la Clave Privada.

La clave privada sólo es conocida por el propietario del certificado digital, está protegida por un código pin, del que sólo conoce la clave el propietario del certificado. La clave privada es el componente que da seguridad a la hora de utilizar el certificado para firmar documentos.

La clave pública, como su nombre indica, es de carácter público, ya que con ella se comprueba la integridad de los datos firmados por el propietario del certificado.

Otra operación que se puede realizar con la clave pública de un certificado digital, es el cifrado de un documento, de esta forma sólo el propietario del certificado puede acceder a la información firmada, descifrándola mediante su clave privada.

El certificado digital lo expende una Autoridad de Certificación, que se debe de encargar de verificar la identidad del solicitante del certificado. Como todo procedimiento, este tiene ventajas y desventajas algunas de ellas son:

Ventajas de la Firma digital:

I. La principal ventaja de la firma digital frente a la firma autografiada, reside en la verificación ya que la firma electrónica es imposible falsificarse.

II. Otra ventaja de la firma digital es que no está ligada a la necesidad de utilizar testigos que verifiquen la operación realizada, mientras que los documentos en papel muchas veces deben realizarse en presencia de testigos que atestigüen su validez, por ejemplo la presencia de un notario.

III. La firma digital se puede realizar en cualquier aparato electrónico susceptible de realizar cifrado de datos, tales como PC‟s, Notebooks, Smartphones o en un chip incorporado en una SmartCard, como es el caso del DNI electrónico, por lo que se puede realizar la operación de firmar y verificar en diferentes lugares, siempre y cuando contemos con uno de estos dispositivos.

Desventajas de la Firma digital:

1. La principal desventaja de la firma digital es que actualmente no está legalmente aceptada en todos los países, mientras que la firma manuscrita si lo está.

2. La mayor desventaja es la falta de formación a nivel informático, incluso en países desarrollados, sobre los conceptos de seguridad informática.

3. La seguridad de la firma digital, recae en mantener secreta la clave privada, ya que sino la robustez de la firma electrónica queda al descubierto por lo que puede llegar a ser utilizada por usuarios no autorizados.

Autoridad de Certificación

Una Autoridad de certificación es la empresa que se dedica a emitir certificados digitales, mediante la verificación de datos del solicitante.

Los certificados, son documentos en los que se incorpora información del titular del mismo. Estos datos son firmados con la clave privada de la Autoridad de Certificación, para garantizar su integridad y veracidad.

Otra función de la Autoridad de Certificación es publicar y mantener actualizada la lista de certificados revocados, es decir, todos aquellos certificados que hayan sido cancelados por sus propietarios o la autoridad que los expidió.

Cómo se realiza la firma digital

La firma digital es un sistema que se utiliza para firmar documentos en formato digital.

En el proceso de firma digital se obtiene un código digital, después de ejecutar una función matemática, denominada función HASH o función resumen, la cual se puede adjuntar a un mensaje transmitido por medios electrónicos y que identifica de manera exclusiva el contenido del documento.

La parte que garantiza la fiabilidad de la firma digital es la mencionada función HASH.

Esta función matemática es de una sola dirección es decir, no se puede obtener un documento original de una función HASH. Parten de una información de entrada y se obtiene como salida un código o huella que, en cierto modo, se puede considerar como único para cada entrada.

Una vez obtenido el código HASH de un documento, se cifra dicho código con la clave privada del usuario. Desde ese momento cualquier persona puede verificar, utilizando la clave pública del firmante y el mismo algoritmo de criptográfico que se utilizó para la generación de la misma, que dicho código ha sido cifrado con la clave privada y, por tanto, proviene del dueño del certificado.

La función HASH la compone en esencia un algoritmo matemático, los más utilizados son el MD5 y el SHA en sus variantes de 128 y 256 bits.

PKI

Se conoce como PKI a la infraestructura de clave pública (Public Key Infrastructure).

Es una estructura, formada por diversas autoridades de confianza que proporciona seguridad e integridad en los medios telemáticos.

La estructura PKI asegura que los usuarios, al autenticarse frente a otros usuarios y enviar información digital, no repudien¹ la información enviada.

Una operación criptográfica que haga uso infraestructura PKI, se compone como mínimo de los siguientes componentes:

1. Un usuario que envía unos datos firmados.

2. Un usuario que recibe los datos firmados.

3. Unas autoridades de confianza común para ambos usuarios que garantice la validez de los certificados implicados en la operación (Autoridad de certificación, Autoridad de registro, fecha de emisión y caducidad del servidor).

Las operaciones criptográficas de clave pública, son procesos en los que se utilizan algoritmos de cifrado basados en la utilización de dos claves (una pública y otra privada). Por este motivo la seguridad que pueden aportar la tecnología PKI, está estrechamente ligada a la privacidad de la clave privada y los procedimientos operacionales o Políticas de seguridad aplicados.

Por ejemplo, la PKI con respecto a las políticas de seguridad del ciclo de vida de los certificados establece:

Primero la generación de la clave pública y la clave privada. Después la emisión de certificados con todos los datos del propietario de certificado y de la Autoridad de Certificación, la utilización y validación de las claves cada vez que éstas se hayan utilizado y por último, una vez que el certificado expire, la actualización de las mismas.

1 El no repudio consiste en la imposibilidad por parte de un usuario de negar que una determinada

Criptografía y tipos de Algoritmos

La criptografía es el arte o ciencia de cifrar y descifrar información utilizando técnicas matemáticas que permitan el intercambio de mensajes de manera que solo puedan ser leídos por las personas a quienes van dirigidos o que garanticen otras características básicas de seguridad.

La finalidad de la criptografía es, en primer lugar, garantizar el secreto en la comunicación entre dos entidades o personas y en segundo lugar asegurar que la información que se envía es auténtica comprobando dos detalles: que el remitente sea realmente quien dice ser y que el contenido del mensaje enviado no haya sido modificado en su tránsito.

En la actualidad la criptografía se ha concentrado en dos grandes bloques:

El primero se trata de la criptografía de clave simétrica o convencional. Este sistema utiliza la misma clave para cifrar y descifrar mensajes, por lo que su robustez reside en dos aspectos; en que la clave permanezca en todo momento secreta a todo el mundo, excepto para el emisor y el receptor del mensaje cifrado, y que sea muy difícil de adivinar.

El segundo tipo se conoce en criptografía como algoritmo de clave pública o asimétrica. Los sistemas de cifrado de clave pública o sistemas de cifrado asimétricos surgieron ante la necesidad de encontrar una solución al problema que suponía el envío de la clave en los algoritmos de clave simétrica entre el emisor del mensaje y el receptor.

Además estos algoritmos permiten cubrir otras necesidades de seguridad como son la integridad y la autoridad de documentos.

Los algoritmos de clave asimétrica, están compuestos de un par de claves, una privada y otra pública. La clave pública es conocida por todo el mundo, mientras que la clave privada sólo es conocida por el propietario, además de estar protegida por un código pin, para asegurar su confidencialidad y que sólo su propietario pueda acceder a ella. En este tipo de algoritmo los datos se cifran con una de las dos claves, dependiendo de los criterios de seguridad que se deseen seguir (confidencialidad o integridad y no repudio) y se descifran utilizando la otra clave.

Debido a la complejidad de estos algoritmos los recursos de procesamiento utilizados para firmar son mucho más costosos que en los algoritmos simétricos, por lo que se suele utilizar un algoritmo HASH para “resumir” los datos a cifrar y se cifra el código HASH resultante. Por tanto para comprobar la validez de los datos se realiza el algoritmo HASH sobre los datos, se descifra el algoritmo HASH enviado y se comparan.

De esta forma podemos concluir que una firma electrónica no sólo contiene el algoritmo HASH cifrado con una de las dos claves, si no que contiene el documento original y, en el caso de que se trate de una firma electrónica, es decir, de un cifrado mediante una clave privada, se suele incluir la clave pública del certificado. Además de esto se pueden incluir otro tipo de datos tales como un sello de tiempo, que certifica el momento en el que se realizó la firma.

Por último ambos usuarios deben conocer tanto el algoritmo asimétrico como el de HASH o resumen empleados durante el cifrado de los datos. Esta información también suele incluirse en la firma.

Capí tulo 2. El proyecto

En primer lugar se deberá entender en qué consiste el proyecto, especialmente las especificaciones que se requieren para el desarrollo e implantación de la aplicación.

El proyecto consiste en el desarrollo y la implantación de un sistema de certificación de mensajería móvil así como su correspondiente aplicación para dispositivos iOS. Dicho sistema únicamente certifica la entrega de un mensaje a un número de terminado. En ningún caso determina si el mensaje ha sido leído por el destinatario. Sin embargo, dado que la aplicación va dirigida especialmente a compañías, siempre que una persona firme un contrato de conformidad en el da su permiso para ser notificado de cualquier tipo de asuntos mediante un mensaje de móvil la certificación de una notificación de entrega tiene validez jurídica para demostrar que la persona en cuestión fue notificada.

El sistema ha sido planificado para que pueda ser usado desde distintos entornos. Con este fin se ha desarrollado como un servicio web que recibe una solicitud de envío de mensaje y realice toda la lógica necesaria para el envío y confirmación del mismo.

Así mismo el proyecto ha sido concebido como una nueva funcionalidad dentro de un elenco de servicios que están siendo prestados actualmente, tales como llamadas certificadas o notificaciones TextToSpeech certificadas. Por tanto la metodología de firma así como la creación de tablas en la base de datos han sido planificadas con el fin de reutilizar lo máximo posible los recursos del resto de servicios, así como integrarlos para garantizar una buena escalabilidad.

Por tanto el desarrollo de éste proyecto consta de las siguientes partes:

1. Desarrollo de dos servicios web. Uno para el envío de mensajes y otro para comprobar el estado de un mensaje. En el caso de la comprobación del estado de un mensaje la lógica únicamente necesita consultar la base de datos del sistema, pero la lógica del envío de los mensajes implica también el desarrollo de un cliente HTTP que realizará peticiones POST al servicio de envío de mensajes del proveedor.

2. Desarrollo de un servicio HTTP que recibirá las notificaciones del proveedor de mensajería indicando el estado de recepción de los mensajes.

3. Desarrollo de un servicio que compruebe cíclicamente el estado de los mensajes.

4. Diseño y creación de las tablas en la base de datos. Para el diseño de las mismas se requiere que se integren lo máximo posible dentro de los esquemas que conforman el resto de servicios que ya existen en el entorno de producción, lo que implicará un estudio previo de dicho esquemas y de las aplicaciones para que el sistema no interfiera en las actividades que realizan dichos servicios.

5. Desarrollo de Web Front-end para la consulta de los mensajes, facturas, etc.

6. Desarrollo de aplicación iOS para el consumo de los servicios web desarrollados anteriormente.

7. Desarrollo de servicio utilizando ApnsPHP que se comunicará con el Apple Push Notification Service, es decir, el servicio de notificaciones push de Apple, que registra y distribuye notificaciones dirigidas a los dispositivos de la firma.

8. Desarrollo de servicio de notificaciones para la aplicación iOS.

9. Desarrollo de Web Front-end para la monitorización del servicio así como para la creación de nuevos usuarios y compañías.

10. Pruebas de carga. En las que se comprobará el consumo de los recursos.

11. Pruebas de seguridad. En las que se realizarán diversos tests para comprobar el estado de la seguridad ante ataques, ya sean externos o internos.

12. Pruebas de diseño y usabilidad. En las que se seleccionarán individuos externos al “mundo informático” y se les consultará sobre posibles mejoras en la usabilidad y el diseño de las interfaces de usuario.

13. Documento de instalación para las aplicaciones del servidor.

14. Manual de usuario de la aplicación móvil.

15. Manual de usuario del portal web front-end de usuarios.

16. Manual de usuario del portal web front-end de usuarios.

17. Documentación de servicios web, incluyendo la descripción de los parámetros que utilizará cada uno de ellos, el esquema WSDL y ejemplos de código de clientes para consumirlos.

Además, todas las herramientas que se instalen en servidor deberán contar con un sistema de log apropiado, así como un sistema de notificaciones vía email para avisar a los administradores en caso de que surja cualquier problema.

El front-end debe contar además con una aplicación de verificación de los archivos firmados y permitir al usuario configurar los parámetros tanto del proceso de firma como de los parámetros de usuario. Este front-end deberá ser lo más intuitivo posible y contar con información tanto del usuario como de la empresa a la que este pertenece.

Dado que se trata de un servicio especialmente orientado a empresas todos los diseños y desarrollos se realizarán de acuerdo a las máximas de seguridad y privacidad con el fin de proteger los intereses de las compañías y por supuesto de los propios usuarios.

Todas las aplicaciones de servidor se desarrollarán en el lenguaje Java y dado que como servidor de aplicaciones se ha elegido un Apache Tomcat sobre un Ubuntu Linux en su edición servidor todas las clases pertenecientes a los proyectos que conforman cada uno de los servicios se compilarán a través de un script. De esta forma se controlarán de manera controlada todas las clases y librerías que se utilizarán durante el proyecto, evitando de esta forma todos los elementos innecesarios que se suelen incluir en las compilaciones realizadas de manera automática por la mayoría de los entornos de desarrollo.

Además se ha requerido que las distintas aplicaciones que conformarán el sistema deberán ir acompañadas de un script con las operaciones de inicio, reinicio, parada y consulta del estado de la aplicación para facilitar el trabajo de administración.

También se ha propuesto una página de administración desde la que poder dar de alta y modificar los usuarios y compañías dados de alta en el sistema. También se deberán poder gestionar los servicios asociados a cada uno de los usuarios así como monitorizar los mensajes enviados y sus estados.

Dado que el servicio de mensajería ofertado por el proveedor no contempla la caducidad de la entrega de los mensajes, se han de desarrollar técnicas que permitan añadir dicha funcionalidad al sistema. Para ello se desarrollará un servicio recurrente que compruebe el estado de los mensajes cada cierto período de tiempo, especificado en la configuración de la aplicación, y que cambie el estado de los mensajes que hayan sobrepasado el tiempo de expiración del mensaje, según se haya determinado en el envío del mismo.

A continuación se muestra un resumen de los distintos componentes que forman parte del proyecto:

Ilustración 1. Componentes del proyecto

.

Capí tulo 3. Requisitos del proyecto

Para el desarrollo completo del proyecto se han estudiado los requisitos necesarios, tanto para su desarrollo como para implementación y funcionamiento, y se han descrito a continuación:

 Requisitos hardware

o Ordenador personal, que se utilizará para el desarrollo y las pruebas preliminares de la aplicación y de los distintos servicios.

o Servidor, en el que se implantarán todos aquellos servicios que lleven la lógica del proyecto, es decir, los servicios web, los servicios de notificaciones y los portales de usuario y administración.

o Dispositivo iPhone, que se utilizará para realizar las pruebas finales del sistema.

 Requisitos software

o Sistema Operativo Linux Ubuntu Server 10.04 LTS. Se trata de una versión del Sistema Operativo para entornos servidor en su versión LTS (Long Term Support), que certifica su estabilidad, seguridad y la tranquilidad de saber que tendrá soporte técnico extendido.

o Sistema Operativo Windows 7. Ya que la mayor parte del proyecto se desarrollará en Java, se ha escogido este Sistema Operativo para el desarrollo del proyecto debido a que el entorno de desarrollo; Eclipse; es más estable y funciona de mejor forma que en otros sistemas.

o IDE Eclipse Indigo. Que será el entorno de desarrollo desde el que se escribirá el código fuente de las aplicaciones de servidor.

o Oracle VM VirtualBox. Se trata de un programa de virtualización, en el que se instalará el entorno de desarrollo Xcode para la programación de la aplicación de iPhone. Se ha elegido dicho sistema debido a su condición de software libre además de permitir la creación de máquinas virtuales a partir de imágenes de OS X Lion.

o OS X Lion. Sistema Operativo que se utilizará tanto para el desarrollo de la aplicación de iPhone como para la fase de pruebas en el simulador del IDE Xcode.

o Xcode, será el IDE de la aplicación para iPhone, además de permitir probar la aplicación gracias al simulador que trae por defecto. Se trata de una herramienta gratuita y la que más soporte da en la programación de aplicaciones iOS. Además se integra perfectamente con InterfaceBuilder.

o

o Microsoft Office 2010, que se utilizará para la realización de la documentación del proyecto y la cumplimentación de los distintos anexos que se deban ir entregando durante el curso así como para la creación del pase de diapositivas que se utilizará durante la exposición del proyecto.

o Microsoft Project Standard 2010, que se utilizará únicamente para la planificación del proyecto y el cálculo de los costes del mismo. Por tanto, no se considera necesaria la compra de una licencia, ya que Microsoft proporciona una versión de evaluación de 60 días, tiempo más que suficiente para realizar la planificación de las actividades.

o MySQL, será el gestor de base de datos que se utilizará, dada su condición de software libre y su alta compatibilidad con hibernate.

o Hibernate. Framework de gestión de base de datos que permite trabajar con las tablas como si fueran objetos. Se ha seleccionado este framework debido a su facilidad de uso, su fiabilidad y su gestión de errores.

Además permite diseñar las distintas tablas como clases de un lenguaje de programación; en este caso Java; por lo que cualquier cambio o relación de dichas clases se verá reflejado automáticamente en el esquema de la base de datos.

o PDFBox. Librería de Java de código abierto, que permite trabajar con documentos en formato PDF. Se ha elegido este complemento y no otro por su facilidad de uso.

o Apache Tomcat 7.0. Se trata de uno de los servidores de aplicaciones más utilizado. Su alta fiabilidad y facilidad de configuración lo hacen una perfecta herramienta para el proyecto. Además es altamente integrable con Eclipse.

o Apache Axis2. Se trata de la versión mejorada del contenedor de Servicios Web AXIS. La nueva versión ha evolucionado independientemente de la primera versión debido a que implementa especificaciones diferentes. Esta herramienta facilita extremadamente la creación de servicios web, ya que incorpora una herramienta con la que poder crear las clases Java que se usarán como interfaz del servicio a través de su wsdl, por lo que reduce la complejidad del servicio a la implementación de su lógica.

o ApnsPHP. Es una librería PHP que permite enviar notificaciones push a aplicaciones iOS. Para ello sólo necesita el “Device Token” del dispositivo al que se desee notificar.

Capí tulo 4. Planificacio n del proyecto

El proyecto se ha dividido en distintas fases o actividades, definidas tanto por los requisitos propios del proyecto, como por la metodología utilizada para la planificación de proyectos.

Las distintas fases en las que se ha dividido el proyecto son:

1. Planificación del proyecto. En esta actividad se describirán las bases que deberá seguir el proyecto, así como los tiempos aproximados de cada una de las diferentes fases del proyecto.

2. Adquisición de los recursos. La duración de esta fase se extenderá a lo largo de todo el proyecto, en la medida en que los recursos (aplicaciones, librerías, documentación, certificados servidor y hardware) se vayan requiriendo para la realización de una determinada actividad.

3. Diseño de la Base de Datos. En esta parte del proyecto se diseñará la Base de Datos que utilizará la aplicación para la realización del seguimiento de los mensajes así como para la consecución de las actividades de custodia que se requieran. Se determinarán las tablas y la información contenida en cada una de ellas para el correcto funcionamiento de la aplicación y el cumplimiento de sus requisitos de funcionalidad. Además se deberá diseñar el esquema de la base de datos SQLite que utilizará la aplicación iOS para guardar la información de los mensajes y sus estados.

4. Diseño de los distintos módulos de desarrollo. La fase de diseño de los distintos módulos se realizará en paralelo con la fase de diseño de la Base de Datos. Dado que el framework hibernate será el encargado de crear los esquemas de las tablas de las aplicaciones servidor se podría decir que la Base de Datos será consecuencia del diseño de los módulos de desarrollo. En esta fase se especificarán los distintos requisitos de cada módulo, tanto de recursos como de diseño, y los flujos de información que existirán entre ellos.

5. Creación de la Base de Datos. Aquí estarán incluidos los procesos de creación de la Base de Datos anteriormente diseñada, las distintas tablas y las asociaciones que existen entre ellas o claves extranjeras. Esta fase no concurrirá en la creación de un script sql sino que será consecuencia de la creación de las distintas clases o entidades desarrolladas durante el proceso de implementación del código de la aplicación. También se creará el esquema de la base de datos SQLite para la aplicación iOS.

6. Implementación de los distintos módulos de las aplicaciones servidor. Constará del desarrollo de las aplicaciones web y las pruebas preliminares de cada módulo de desarrollo por separado y en conjunto con los módulos con los que se comunique cada uno de ellos.

7. Implementación de los distintos módulos de la aplicación iOS. En esta fase se desarrollarán los distintos módulos de la aplicación iOS, tanto el módulo de envío de mensajes como el de solicitud de estado en caso de que las notificaciones no lleguen al dispositivo por alguna razón.

8. Pruebas, actualizaciones y control de fallos. Esta actividad incluirá la fase de pruebas exhaustivas de la aplicación y la monitorización del comportamiento de la misma bajo distintos niveles de flujo de transacciones. Así mismo se definirán las acciones a realizar por la aplicación para cada uno de los posibles fallos que puedan dar lugar las tareas que se vayan realizando, tales como escritura de registros en el log, notificación de fallos vía correo electrónico, etc. Así mismo se podrán realizar correcciones o actualizaciones sobre los distintos módulos del sistema en caso de que surjan nuevos requisitos que no se contemplaron durante las fases de diseño.

Las distintas pruebas que se realizarán pueden clasificarse en los siguientes grupos:

 Pruebas de usabilidad. Estas pruebas determinan si una aplicación es fácilmente utilizable por el usuario final. Para ello se pedirá a varias personas ajenas al proyecto y con conocimientos básicos sobre informática que prueben la aplicación y realicen distintas acciones.

 Pruebas de diseño. La aplicación móvil deberá ser compatible con distintos dispositivos en los que pueden variar la resolución de la pantalla, la versión del sistema operativo o ambas simultáneamente.

Además las aplicaciones web de la consola de usuario y la de administración deberán visualizarse correctamente en los navegadores más utilizados por los usuarios.

 Pruebas de seguridad. En estas pruebas se ejecutarán varios test de seguridad que comprobarán las brechas de seguridad o exploits más utilizadas por los hackers.

 Pruebas de carga. Durante varios días se probarán de forma masiva todos lo módulos para comprobar los límites de recursos que se deberán establecer.

9. Documentación. Deberán documentarse todos los procesos que se realizarán durante la ejecución normal de los distintos módulos. Para ello se crearán manuales de usuarios tanto de la aplicación móvil como de las consolas web.

Además se deberá documentar una guía de instalación de proyecto en un servidor, indicando los comandos shell a ejecutar, las librerías necesarias, las distintas configuraciones de las aplicaciones, tanto las propias del proyecto como las de terceros, etc.

10. Instalación. Será la última de las actividades que se realizarán. Se instalarán los servicios así como los front-end en un servidor de un entorno de producción y se monitorizará su comportamiento durante el uso real de la aplicación. Así mismo se publicará la aplicación iOS en la AppStore para posibilitar la descarga y uso de la aplicación por parte de los usuarios finales.

Capí tulo 5. Divisio n del desarrollo

El desarrollo de la aplicación se ha divido en distintos módulos de forma que se complementen unos con otros para ultimar el desarrollo final, pero que a la vez que sean parcialmente independientes, tanto por su definición como por las funciones que realicen cada uno de ellos.

De esta forma se puede obtener una visión global del proyecto, así como una visión más específica de cada una de las funciones que deberá realizar la aplicación. Esta división, además, permite definir de forma más detallada el consumo temporal y de recursos que conlleva el desarrollo del proyecto.

Los distintos módulos en los que se ha dividido el desarrollo de la aplicación son:

1. Módulo de envío de mensajes. Este módulo será el encargado de recibir las peticiones de envío de mensajes, realizar el envío de los mensajes a través de la plataforma de mensajería e informar al remitente del mensaje del estado del envío.

El módulo de mensajería funcionará de la siguiente forma:

 El cliente del servicio web SendSMS enviará una petición de envío de mensaje.

 El servicio web SendSMS comprobará el usuario y la contraseña así como que todos los parámetros enviados sean correctos.

 El servicio web SendSMS establecerá una conexión con el servicio HTTP del proveedor de mensajería y enviará una solicitud de envío de mensaje.

 El proveedor de mensajería responderá con el estado del envío.

 El servicio web actualiza el estado del mensaje en la Base de Datos y se lo renvía al remitente.

Para llevar a cabo todas estas tareas se realizarán las siguientes implementaciones:

I. Servicio Web SendSMS. Se trata de un servicio web que recibirá los siguientes parámetros:

Parámetros Tipo Descripción

senderAddress Obligatorio Nombre del remitente del mensaje, con un tamaño máximo de 11 caracteres destinationAddress Obligatorio

Número de teléfono del destinatario del mensaje. En caso de que no se especifique el mensaje se enviará con el código de país de España (34) por defecto userData Obligatorio Texto del mensaje que se desea enviar, con un tamaño máximo de 160 caracteres relativeValidityTime Opcional

Tiempo de expiración del mensaje en caso de que no se entregue. Por defecto se establecen 24 horas antes de que el mensaje expire.

userName Obligatorio Nombre de usuario que identifica al emisor del mensaje

password Obligatorio Contraseña de usuario que identifica al emisor del mensaje

mode Opcional Modo de confirmación/certificación en el que se desea enviar el mensaje²

customerReference Obligatorio Referencia única del sistema cliente que identifica unívocamente el mensaje

Tabla 1. Parámetros petición SensSMS

Tras recibir los parámetros y validarlos enviará una solicitud de envío de mensaje a la plataforma de mensajería.

Una vez recibida una respuesta por parte de la plataforma de mensajería el servicio web generará y devolverá una respuesta al remitente con los siguientes parámetros:

2 Para más información sobre los distintos valores que puede tomar el modo de confirmación/certificación de un mensaje consultar el punto 3.2. Parámetro Mode del anexo “Servicios Web CertifiedSMS”

Parámetros Tipo Descripción

smsId Obligatorio

Identificador único del mensaje. En caso de fallo en el envío del mensaje se mandará como -1

statusCode Obligatorio Código del estado en el que se encuentra el mensaje³

statusDescription Obligatorio Descripción del estado en el que se encuentra el mensaje¹

reasonCode Obligatorio Código de la razón del estado del mensaje en el servidor⁴

Tabla 2. Parámetros respuesta sendSMS

II. Servicio HTTP de envío de mensajes. Este servicio será el encargado de enviar las peticiones HTTP para el envío de mensajes a través del proveedor de mensajería⁵.

III. Cliente iOS del servicio web SendSMS. Este cliente, integrado en la aplicación CertifiedSMS será el encargado de enviar las solicitudes de envío de mensajes al servicio web SendSMS de acuerdo a los parámetros especificados en el esquema wsdl del mismo.

2. Módulo de notificaciones de recepción de mensajes. Este módulo será el encargado de recibir las notificaciones de la recepción de los mensajes, firmarlas en caso de que proceda y enviárselas al remitente. Para ello se realizarán las siguientes implementaciones:

I. Servicio HTTP de gestión de notificaciones de recepción de mensajes.

Este servicio será el encargado de recibir las notificaciones de recepción de los mensajes, en caso de que proceda, mediante peticiones HTTP.

Una vez recibidas las notificaciones de acuerdo al formato indicado en la documentación del proveedor de mensajería⁵ se actualizará el estado de recepción del mensaje y se notificará a la aplicación cliente iOS mediante el Apple Push Notification Service.

II. Servicio de recepción de Device Token. Una vez iniciada la aplicación, ésta solicitará el “Device Token” a los servidores de Apple. Este parámetro constituye un identificador unívoco del dispositivo, que ayudará al servicio ApnsPHP a localizar al dispositivo para poder enviarle notificaciones push indicando al usuario el estado descrito en las notificaciones de recepción de mensajes que envíe el proveedor de mensajería.

3 Para más información sobre los distintos valores que puede tomar el estado de un mensaje consultar el punto 3.1. Parámetro SendStatus del anexo “Servicios Web CertifiedSMS”.

4 Para más información sobre los distintos valores que puede tomar la razón del estado de un mensaje consultar el punto 3.4. Parámetro ReasonCode del anexo “Servicios Web CertifiedSMS”.

5 Para más información sobre el servicio de mensajería consultar el documento que define el protocolo de mensajería de Altiria. Este documento puede descargarse desde el enlace contenido en la bibliografía.

III. Servicio de envío de notificaciones push. Se trata de un servicio que haciendo uso de la librería ApnsPHP envía notificaciones push a los dispositivos indicando los cambios en los estados de los mensajes enviados desde el mismo.

3. Módulo de consulta de estado mensajes. Se trata del encargado de proporcionar un método de consulta del estado de los mensajes enviados por los usuarios.

Éste módulo devolverá el estado del envío, de la recepción así como los detalles sobre sus valores. De esta forma los usuarios podrán saber en todo momento cuál es el estado de sus mensajes. Además en caso de que el mensaje consultado sea un mensaje certificado y se haya entregado este módulo devolverá un documento PDF certificando la fecha y hora de la recepción por parte del sistema.

El desarrollo de este módulo también puede servir a los sistemas utilizados como clientes para actualizar el estado de los mensajes en caso de que las notificaciones del servicio no hayan podido recepcionarse por parte de los mismos. Es, por tanto, un método complementario al módulo de notificaciones.

Para realizar esta tarea se desarrollarán las siguientes implementaciones:

I. Servicio Web GetSMSStatus. Se trata de un servicio web que recibirá los siguientes parámetros:

Parámetros Tipo Descripción

smsId Opcional Referencia única del sistema que identifica unívocamente el mensaje.

customerReference Opcional Referencia única del sistema cliente que identifica unívocamente el mensaje userName Obligatorio Nombre de usuario que identifica al

emisor del mensaje

password Obligatorio Contraseña de usuario que identifica al emisor del mensaje

Tabla 3. Parámetros petición getSMSStatus

Una vez recibida la petición el servicio web recuperará los datos sobre el estado del mensaje de la base de datos y en caso de que haya sido entregado y se haya enviado como mensaje certificado recuperará también el certificado PDF que acredita la certificación de la entrega.

Una vez recuperados los datos se incorporarán a la respuesta, que contendrá los siguientes parámetros:

Parámetros Tipo Descripción

smsId Opcional Referencia única del sistema que identifica unívocamente el mensaje.

statusCode Obligatorio Código del estado en el que se encuentra el mensaje³

statusDescription Obligatorio Descripción del estado en el que se encuentra el mensaje³

Pdf Opcional

Archivo PDF codificado en Base64 con la confirmación del estado final del mensaje

tsaDate Opcional Fecha en la que se entregó el mensaje

Tabla 4. Parámetros respuesta getSMSStatus

II. Cliente iOS del servicio web GetSMSStatus. Este cliente se encargará de actualizar el estado de los mensajes cuando se solicite la actualización manual del mismo. También se actualizarán mediante este método todos aquellos mensajes que hayan sobrepasado su tiempo de expiración y de los que no se haya recibido notificación alguna.

4. Módulo de búsqueda de mensajes no entregados. Para todos aquellos mensajes sobre los que no se haya recibido ninguna notificación indicando su entrega se ha creado un módulo que se encargará de consultar a la plataforma de mensajería el estado de estos mensajes cada cierto tiempo. Este tiempo podrá ser configurado.

Una vez analizados los mensajes se actualizará su estado, si procede, bien consultándolo al servicio del proveedor de mensajería o bien expirando el mensaje en caso de que se haya superado el tiempo indicado en la petición de envío.

5. Módulo web de usuario. En este módulo se implementará un portal web desde el que el usuario podrá consultar sus mensajes enviados tanto por él como por los usuarios pertenecientes a su compañía.

Dado que el servicio de mensajería certificada está especialmente orientado a empresas que deseen enviar notificaciones y certificar la entrega de las mismas, se han definido 3 roles de usuario, que son los que se listan a continuación:

 Usuario: Se trata del tipo más básico. Los usuarios definidos bajo este rol sólo tendrán acceso a aquellos mensajes que hayan sido enviados por ellos mismos.

 Supervisor: Bajo este rol se agruparán todos aquellos usuarios que se definan en la base de datos. Por tanto se definirán como supervisores todos aquellos usuarios que deban monitorizar o tener acceso por alguna otra razón a los mensajes enviados por otros usuarios.

 Administrador: Estos usuarios, a diferencia de los supervisores, tendrán acceso a los datos de todos los usuarios de su compañía sin excepción.