Firma móvil Cliente @firma

Módulo 3:
Integración del Cliente @firma
con clientes móviles
Presentación
Ministerio de Hacienda y Administraciones Públicas

AGENDA
 La administración electrónica desde dispositivos móviles
 Aspectos básicos de programación de firma electrónica en dispositivos
móviles.

La administración
electrónica desde
dispositivos móviles
AGENDA

 App vs. Navegador Web
 Los usuarios de teléfonos móviles de última generación han descartado el
navegador Web para aplicaciones en línea. La preferencia por el modelo App
es clara.
 Cifras Google Play (Agosto 2014):
1,3 millones de aplicaciones disponibles para descarga
En 2013 llevaba más de 50.000.000.000 descargadas.
 Los usuarios de tableta combinan el uso de Apps con el de navegador Web.
 El tamaño y resolución de la pantalla permite un acceso cómodo a los sitios Web
incluso si estos no están adaptados a dispositivos móviles.
 La experiencia de usuario en navegador sigue siendo deficiente comparada con
un navegador Web en ordenador personal o con una App nativa.
No hay complementos (Java, Flash en ciertos casos, etc.).
LA ADMINISTRACIÓN ELECTRÓNICA DESDE DISPOSITIVOS
MÓVILES

LA ADMINISTRACIÓN ELECTRÓNICA DESDE DISPOSITIVOS
MÓVILES
 Aplicaciones móviles de firma electrónica en navegador Web
 Desventajas:
 La carencia de complementos en el navegador hace que siga siendo necesaria la
ejecución de una App nativa (que ejecuta la propia firma PKCS#1 y gestiona el
almacén de claves y certificados).
 La comunicación entre el navegador Web (JavaScript) y App es problemática en
muchos sentidos, y por lo general no puede ser bidireccional.
 La experiencia de usuario es deficiente:
Dificultad de adaptarse al Look & Feel del dispositivo.
Componentes de interfaz más pobres.
 Ventajas
 Economía en el desarrollo (aunque no es especialmente significativo el ahorro).
 Permite una integración directa en los flujos de negocio Web actuales basados
en el Cliente @firma.

COMPATIBILIDAD CON DISPOSITIVOS MÓVILES
 La compatibilidad con dispositivos móviles viene dado por el JavaScript
de despliegue.
 Este JavaScript llamará a una aplicación nativa en lugar de al applet
cuando este no pueda cargarse.
 La aplicación nativa (app) de firma se llamará a través de una invocación
por protocolo.
 La app enviará los datos a un servidor intermedio que los guardará
temporalmente.
 La página web recuperará los datos realizando peticiones periódicas al
servidor intermedio.
 Para la compatibilidad con la aplicación nativa de firma es indispensable
el uso de las funciones callback para la obtención del resultado de las
distintas operaciones.

2
3
4
Aplicación JavaScript en
Navegador Web Móvil
App Nativa
Servidor
intermediario
1

 Se instala la aplicación nativa (app) en el dispositivo.
 La aplicación registra el protocolo "afirma".
1. Desde una página web se llama a la app a través de una URL con el
esquema "afirma". Como parámetros se pasa la configuración de la
operación o los medios para obtenerla.
2. La app realiza la firma electrónica de forma autónoma o ayudándose de
servicios externos.
3. La app registra el resultado en un servidor intermedio configurado por el
integrador a través de la página web.
4. La página web recoge del servidor intermedio la firma (o mensaje de
error si algo falló) y se elimina la firma del servidor.
 Una vez la página dispone de la firma realizada, ya puede continuar con
su flujo de trabajo.

 Para configurar el Cliente:
 Se establecen las URL de los servicios de guardado y recuperación mediante
el método setServlets(storageService, retrieveService)
 Para configurar los servicios:
 Se configuran en el fichero properties de los WAR de los servicios:
 Un directorio temporal.
 El tiempo máximo de caducidad.
 Los servicios de guardado y recuperación se pueden sustituir por
cualesquiera otros que responda a la misma interfaz de llamadas.

DEMOSTRACIÓN EN ANDROID

DISTINTOS MODOS DE FIRMA PARA DISTINTAS
NECESIDADES
 Firma en una fase:
 Todo el proceso de firma electrónica se realiza en el cliente (en el dispositivo).
 Óptimo para:
 El origen y el destino de la información es el propio dispositivo.
 Se requiere operación sin conectividad con la red.
 Desventajas:
 El desarrollo es más complejo.
Es necesario portar el 100% de la funcionalidad de firma a cada uno de los
dispositivos soportados.
 Ventajas
 Operación segura (o al menos tan segura como lo es el dispositivo
móvil).
 No necesita despliegue de servicios en servidor.

NECESIDADES
 Firma en tres fases:
 El proceso de firma electrónica se reparte entre el cliente (dispositivo) y un
servidor.
 Óptimo para:
 El origen y el destino de la información es un servidor.
 Se necesitan firmar documentos muy grandes.
 Desventajas:
 Requiere el despliegue de servicios en el servidor.
 Requiere medidas adicionales de seguridad en la comunicación cliente
<-> servidor.
 Ventajas
 Operación segura: Es posible firmar un documento sin que este salga
del servidor.
 El desarrollo es más simple en un soporte multi-dispositivo.
El código servidor es común a todas las implementaciones.

FIRMA TRIFÁSICA EN MINIAPPLET
 Pre-firma:
 Firma:
 Post-firma:

NECESIDADES
 Firma en tres fases: Pre-Firma
1. El dispositivo móvil solicita una pre-firma al servidor Web indicando un
identificador de documento.
2. El servidor Web solicita el documento a servidor documental.
3. El servidor documental entrega el documento al servidor Web.
4. El servidor Web calcula la pre-firma, entregando el resultado (muy
pequeño en tamaño) al dispositivo.

NECESIDADES
 Firma en tres fases: Firma
1. El dispositivo móvil realiza, de forma completamente aislada una firma
electrónica simple (computacionalmente ligera) de los datos de la pre-
firma. La clave privada del usuario nunca sale del dispositivo y no se
expone externamente en ningún momento.

NECESIDADES
 Firma en tres fases: Post-Firma
1. El dispositivo móvil solicita una post-firma al servidor Web indicando un
identificador de documento y proporcionando el resultado de su pre-firma firmada.
2. El servidor Web solicita el documento a servidor documental.
3. El servidor documental entrega el documento al servidor Web.
4. El servidor Web calcula la post-firma y compone el documento final firmado,
entregando el resultado al servidor documental para su almacén.
5. El servidor documental almacena el nuevo documento y devuelve un identificador
al servidor Web.
6. El servidor Web comunica al dispositivo el éxito de la operación y el identificador
del fichero ya firmado y almacenado.

FIRMA TRIFÁSICA EN MINIAPPLET
 Para configurar una operación de firma trifásica en el MiniApplet:
 Se debe cambiar el formato de firma:
 CAdEStri
 XAdEStri
 PAdEStri
 Se debe configurar la ruta del servicio de firma trifásica en los parámetros de
la operación:
 Parámetro: serverUrl
 Los clientes móviles generan las firmas en 3 fases cuando no pueden
generar la firma internamente.
 Se podría generar una versión del MiniApplet que sólo soportase firmas
trifásicas.

Aspectos básicos de
programación de firma
electrónica en
dispositivos móviles.

APPLE IOS
CARACTERÍSTICAS PRINCIPALES
 Programación en Objective C, un derivado de C con soporte de
características de C++
 Comparte muchas características con la programación en Mac OS X.
 Hereda la arquitectura central de NextStep.
 Únicamente es posible programarlo desde Xcode en Mac OS X
 El entorno es gratuito en las versiones actuales de Mac OS X, pero…
 Necesita una suscripción al programa de desarrolladores de Apple para
poder publicar aplicaciones (80 € anuales por entidad o individuo) y
ejecutarlas para pruebas y depuración en emulador o dispositivo físico.
 Distintos medios de publicación de aplicaciones:
 Apple AppStore público, AppStore privado, descarga directa, gestión
centralizada de los dispositivos, etc.
 Buen soporte de funcionalidades de criptografía y firma electrónica en el
API.
 Almacén central de certificados para aplicaciones de Apple y almacenes
privados por aplicación.

APPLE IOS
ALMACENES DE CERTIFICADOS
 El almacén central (llavero según nomenclatura de Apple) solo es
accesible por las aplicaciones de Apple.
 Es posible una distribución masiva y centralizada de certificados mediante un
perfil de configuración.
 http://support.apple.com/downloads/DL1466/en_US/iPhoneConfigUtilityS
etup.exe
 Los perfiles de configuración pueden firmarse para que
automáticamente los certificados distribuidos se consideren como
seguros.
 Las aplicaciones pueden crear y compartir sus propios almacenes de
certificados en formato nativo (llavero de Apple iOS), pero:
 Solo pueden compartirse entre aplicaciones del mismo grupo: Firmadas por el
mismo desarrollador.
 Si se usa un llavero propio debe proporcionarse un gestor del llavero al
usuario:
 ¿Qué certificados tengo instalados? (consulta de propiedades)
 Borrar e insertar certificados.
 ¿Gestión de caducidades y revocaciones?

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist SYSTEM "http://www.apple.com/DTDs/PropertyList-1.0.dtd" PUBLIC "-//Apple//DTD
PLIST 1.0//EN">
<plist version="1.0"><dict>
<key>PayloadContent</key><array><dict><key>PayloadCertificateFileName</key><string/>
<key>PayloadContent</key><data> CERTTIFICADO_PKCS#12_EN_BASE_64</data>
<key>PayloadDescription</key><string>Provides device authentication (certificate).</string>
<key>PayloadDisplayName</key><string>afs</string>
<key>PayloadIdentifier</key><string>.credential</string>
<key>PayloadOrganization</key><string/>
<key>PayloadType</key><string>com.apple.security.pkcs12</string>
<key>PayloadUUID</key><string>315C74B9-761F-419C-AD2B-8E2F804683AF</string>
<key>PayloadVersion</key><integer>1</integer></dict></array>
<key>PayloadDescription</key><string>Profile description.</string>
<key>PayloadDisplayName</key><string>Profile Name</string>
<key>PayloadOrganization</key><string/>
<key>PayloadRemovalDisallowed</key><false/>
<key>PayloadType</key><string>Configuration</string>
<key>PayloadUUID</key><string>E810A1F2-F8D9-4148-8EC9-F9E8B288B3C4</string>
<key>PayloadVersion</key><integer>1</integer>
</dict></plist>
APPLE IOS
ALMACENES DE CERTIFICADOS

APPLE IOS
DISTRIBUCIÓN DE APLICACIONES
 La distribución de aplicaciones en la AppStore de Apple requiere la
aceptación de unos contratos con términos muy estrictos.
 Incompatibilidad con GPLv2.
 ¿Necesidad de CCATS? (export classification ruling).
 Vinculación contractual con Apple.

WINDOWS PHONE / WINDOWS RT
 Plataformas cerradas al estilo de Apple iOS: Solo permiten la ejecución
de aplicaciones descargadas desde su tienda de aplicaciones.
 Las aplicaciones pasan un estricto control para su certificación y admisión en
la tienda.
 Aplicaciones programadas en .NET (C#, Visual Basic .NET, etc.),
Silverlight o HTML 5.
 Compatibilidad cruzada con cualquier plataforma Windows: Windows (XP,
Vista, 7, 8), Windows RT, Windows Phone (7.5, 8) y Xbox.
 Interfaces gráficos al estilo “Modern UI” solo disponibles en Windows 8,
Windows 8 RT y Windows Phone 7.5 y 8 y Xbox.
 Entorno de programación muy avanzado:
 Microsoft Visual Studio + Microsoft Expression Blend.
 Versiones gratuitas de los entornos, incluyen depurador, emuladores, etc.
 Solo disponible para Windows.

 Buena disponibilidad de API criptográficos y de utilidad:
 BouncyCastle (C#)
 iText (C#)
 Internet Explorer 10/11 en la interfaz Modern no permite la ejecución de
Applets de Java, aspecto compartido con Windows RT y Windows Phone.
 No se tiene acceso a CAPI
 Cuentan con un almacén central de certificados pero las aplicaciones de la
tienda no tienen acceso a él.
 Microsoft baraja permitir el acceso en una futura versión del sistema
operativo.

DISTRIBUCIÓN DE APLICACIONES
 Distribución mediante “tienda de aplicaciones”.
 Importantes requisitos en cuanto a la experiencia de usuario.
 Incompatibilidad con ciertas licencias de software libre:
 The Application must not include software, documentation, or other materials that, in
whole or in part, are governed by or subject to an Excluded License, or that would
otherwise cause the Application or the Windows Phone Marketplace to be subject to the
terms of an Excluded License.
 “Excluded License” means any license requiring, as a condition of use, modification
and/or distribution of the software subject to the license, that the software or other
software combined and/or distributed with it be (i) disclosed or distributed in source code
form; (ii) licensed for the purpose of making derivative works; or (iii) redistributable at no
charge. (…) The GNU General Public License version 3, the GNU Affero General Public
License version 3, the GNU Lesser General Public License version 3, and any
equivalents to the foregoing are considered Excluded Licenses.
 http://cmsresources.windowsphone.com/devcenter/en-us/legal/Windows-
Phone-Marketplace-Application-Provider-Agreement.pdf

GOOGLE ANDROID
 Programación en un “sucedáneo” de Java: Dalvik
 Basado en Apache Harmony, que es compatible con Oracle JSE en
aproximadamente un 97%.
 http://harmony.apache.org/subcomponents/classlibrary/status.html
 Permite una programación cruzada JSE / Android sin apenas incidentes.
 Incorpora internamente BouncyCastle como JCE/JCA, con un excelente
soporte para operaciones criptográficas.
 Versión concreta de BouncyCastle expuesta en el ClassPath (y en una
versión obsoleta) lo que dificulta la integración de versiones actuales del API.
 El soporte a la firma electrónica da un gran avance en la versión 4.
 Entorno de desarrollo de buena calidad, integrable en Eclipse como
plugin.
 Cuenta con depurador, simuladores, ejecución en dispositivos reales…

GOOGLE ANDROID
ALMACÉN DE CERTIFICADOS
 Android hasta la versión 4 no tiene un almacén centralizado de
certificados y claves a disposición de las aplicaciones.
 Es necesario que cada aplicación cree y mantenga su propio almacén.
 JCA/JCE nos permite usar PKCS#12 y almacenes Java.
 Hay que crear los procedimientos de importación de certificados
completamente a medida.
 Cuidado con la seguridad del proceso.
 Android 4 por fin cuenta con un almacén central de claves y certificados
con un API público para su uso.
 Proceso de importación de certificados integrado en el sistema operativo.
 Desde PKCS#12 en almacenamiento externo (¡cuidado con la seguridad!).
 Se expone una callback para instalación desde aplicaciones.
 Soporte parcial de SSCD
 http://code.google.com/p/seek-for-android/

GOOGLE ANDROID
 Notas sobre el uso del almacén central de certificados
 En Android 2 y 3, al no existir un almacén central estaríamos obligados a
tener nuestro propio almacén de certificados.
 En Android 4, el proceso es asíncrono, se llama al Intent del sistema
retornando de inmediato a la aplicación, y se notifica que el usuario ha
seleccionado un certificado con una callback.
 Esta arquitectura dificulta la unificación entre JSE y Dalvik.
 En Android 4.3, se adopta la arquitectura de seguridad de JSE (JCA/JCE)
para la gestión del almacén interno de Android lo que permitiría su uso
homogéneo con respecto al resto de almacenes gestionados desde Java. Sin
embargo, los dispositivos móviles no implementan un proveedor para esta
arquitectura de seguridad.

GOOGLE ANDROID

Firma móvil Cliente @firma

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (20)

Similar a Firma móvil Cliente @firma

Similar a Firma móvil Cliente @firma (20)

Más de Tomás García-Merás

Más de Tomás García-Merás (20)

Firma móvil Cliente @firma